Trust Anchor

Every chain of trust has to bottom out somewhere. You can verify that certificate B was signed by certificate A, and that A was signed by certificate C, but that chain can't go back forever. At some point there has to be something you simply trust directly, by policy, without any further proof, because trusting something is the only way to get started at all. That base case, the thing every other trust decision ultimately traces back to, is a trust anchor.

The everyday version of this runs on every device with a web browser: a small set of root certificate authorities, pre-installed by the operating system or browser vendor, are trusted directly. Every HTTPS certificate you ever encounter is trusted only because it chains back, through some number of intermediate certificates, to one of those pre-installed roots. Nobody verifies a root CA's certificate against something even more fundamental, it's the anchor, not a link in the chain.

Where the concept comes from

RFC 5280, the IETF standard governing X.509 public-key infrastructure, formally defines a trust anchor as a CA's public key that an application trusts directly and uses as the starting point for validating certificate chains. NIST SP 800-57 gives a broader key-management definition of the same underlying idea, useful beyond X.509 specifically. More recently, the Trust over IP Foundation has applied the same root-of-trust framing to decentralized identity ecosystems built on DIDs, where the question isn't "which root CA do I trust?" but "what governs whether a given DID method's resolved state is authoritative?" Solidus originated none of this; it applies an established security-engineering concept to its own infrastructure.

Why this matters specifically for DID systems

Resolving a DID (see DID Resolution) always bottoms out at trusting something. For a DID method backed by a blockchain, that something is the chain's own consensus state: whatever the validator committee agrees is current, by the rules of whatever consensus protocol they're running, is treated as authoritative, there's no separate root certificate to fall back on, cross-check, or distrust independently of the chain itself. The chain doesn't have a trust anchor sitting outside it; for practical purposes, the chain is the trust anchor.

Two concrete instances in Solidus, honestly scoped

For DID resolution: every did:solidus DID Document lives in the chain's own state tree (see did:solidus), so resolving one means trusting whatever Solidus's validator committee has agreed is current chain state. That committee, today, is a small, team-operated set of four testnet validators (see Validator): a meaningfully different trust anchor, in practice, than a large, adversarial, externally-operated network would be, even though the resolution mechanism itself works identically either way.

For issuer accreditation: Solidus's Trust Registry (see that entry) answers "is this credential issuer accredited?", and the registry itself is operated under Solidus's own key and infrastructure. That's a real, working accountability mechanism: de-listing a misbehaving issuer immediately flips every future verification of that issuer's credentials to reject, network-wide. It is also, honestly, a single point of trust that Solidus itself fully controls today, not a federation of independently governed registries the way, for instance, the EU's eIDAS Trusted Lists federate accreditation across 27 member states. The Trust Registry entry names this same centralization tradeoff directly; this entry names it as an instance of the more general trust-anchor concept.

Check it yourself

For the chain-as-trust-anchor claim: resolve a live did:solidus DID against rpc.solidus.network (exact command under DID Resolution), nothing but the chain's own state answers the query. For the registry-operator-as-trust-anchor claim: curl https://capture-api.solidus.network/registry/issuers/did:solidus:testnet:1111111111111111111111zz returns a live 404 (exact command and context under Trust Registry), confirming the registry's single operator enforces fail-closed behavior for unknown issuers, checkable by anyone with a terminal.