the key a verifier chooses to treat as axiomatic - the root of its trust decisions, from which every authorization chain must hang; in codexproof, one did:key per domain, held in each consumer's own list.
The consumer's own list: three lines of fiat, each removable by its owner alone.
Etymology and backstory
"trust anchor" is classical PKI vocabulary (RFC 5280 uses it for the root certificates a validator starts from). The deep point every PKI shares: verification cannot be turtles all the way down - somewhere a key is trusted by decision, not by proof. WebPKI centralizes that decision into a root store curated by browser vendors; codexproof radically decentralizes it - every consumer curates its own anchor list, per domain.
Ecosystem
browser root stores (Mozilla NSS, Microsoft, Apple), DNSSEC's root zone key ceremony, SSH known_hosts (the humblest anchor list), Sigstore's trusted root.
In codexproof
anchors are did:key identities; consumers hold them ("nobody administers the ring of trust - consumers hold the anchors"). The anchor signs exactly two artifact types, rarely: certificates licensing signing keys, and revocation lists. Cold by design; unrotatable by construction (Q19).
The DNS question, answered precisely: DNS binds names to addresses through one global registry everyone trusts; the anchor list is that binding with the root privatized to each consumer - a personal zone file of namespace-to-key rows, no global authority to capture. The bootstrap rides the old web once (fetch the domain's published anchor over HTTPS at a well-known path), then verification never touches the network again: DNS introduces, the anchor list remembers, arithmetic verifies. Humans read names (in production the namespace IS the domain, /aigamma.com/evidence/...); machines check keys; certificates bind the two.