SolidusExplorer
⌘K
FINALITY
BLOCK HEIGHT
ACTIVE VALIDATORS

The Trust Anchor Behind a did:solidus Lookup: The Chain Has One, and Your Lookup Is Not Connected To It

The question, stated properly

A trust anchor is the thing you accept without further proof, so that everything else can chain back to it. Naming one is the whole substance of a trust model: it says exactly who you are relying on when you believe an answer.

So the question is not whether this chain has an anchor. It is whether a lookup connects you to it.

The chain has a real anchor

Every block header carries a state root, and you can read it on any block without an account.

It is not a placeholder. It is computed by building four sparse Merkle trees, one each for accounts, DIDs, credentials and validators, and combining the four roots with a hash into one value. So a DID document genuinely sits inside a tree whose root is published in a block that a quorum certified.

And it moves with state. A root read eighteen heights earlier is a different value. Three sampled blocks spanning six heights share one root, and the only transaction in that span failed, for insufficient balance to cover its fee. A field that changes when state changes and holds still when nothing commits is a reading, not decoration.

And your lookup is not connected to it

Resolving a DID is a single call, and the handler behind it is a key-value read out of the node's own store.

The response carries no proof. No inclusion path, no state root, no block height, no signature over the answer. You get a document, and the document does not say which chain state it came from.

So there is nothing to check the answer against. The anchor is published on every block, and the document you were handed has no thread running back to it.

The honest answer

What you are trusting when you resolve a did:solidus identifier today is the operator of the endpoint you asked.

Not the chain, because nothing links the answer to a certified root. Not the signature on the document, because there isn't one.

And you cannot route around it by asking somebody else. Every validator on this network is operated by the same team, so a second opinion from an independent operator is not available to ask for.

That is an ordinary position for a development network to be in. It is a completely different guarantee from the one the word "anchor" invites, and a reader deciding what a resolution is worth needs the real one.

The hash in the response is a self-check, not provenance

The document comes back with a content hash, computed over the document itself with that field cleared first, so a reader can recompute it and compare.

That detects corruption in transit and nothing else. Whoever hands you a document can hand you the matching hash for it, because the hash is over the thing they gave you rather than over anything they had to commit to first.

A value you can check against itself is not a value you can check against the chain. The two are easy to confuse and they are not close.

And the code states the trade that made it expensive

The tree that produces the root is built fresh in memory on each computation and then discarded.

That was deliberate, and the reason is written next to it. A store-backed version persisted around two hundred and fifty seven tree nodes per insert, so every root computation rewrote the whole tree to disk, and nothing ever read those nodes back. The comment names it as the bulk of roughly a gigabyte a day of disk growth.

So serving a proof means rebuilding the tree to produce it. That is a considered engineering trade rather than an oversight, and a reader is better served by the trade than by a list of absences.

One method is in the source and not on the wire

The call that would return a state root directly is registered in a second resolution layer in the source tree. The public endpoint does not serve it, and returns a method-not-found error.

CONTROL: the resolution call answers on the same endpoint in the same second, so that is a reading rather than a broken client.

It matters less than it looks. Any block already carries its state root, so the anchor is readable today. The missing piece is the proof, not the root.

What you can check yourself

solidus_didResolve with any identifier, then solidus_getBlock at the current height

Compare them. The block gives you state_root. The document gives you no way to reach it, and noticing that for yourself is the point of this page.

Keep reading

The Trust Anchor Behind a did:solidus Lookup: The Chain Has One, and Your Lookup Is Not Connected To It · Solidus — Solidus Explorer