Why an Identity Anchor Can Never Hold or Send Value

A cryptographer at a national research institute, reviewing the chain, put it plainly: "I can decode your DID and read your entire payment history." It's a reasonable thing to assume, most blockchain identifiers double as addresses, and most addresses hold value, so an identity chain looks, at a glance, like a spending ledger with extra metadata. The answer wasn't a policy or a promise. It shipped as a consensus rule: a registered DID anchor on Solidus structurally cannot hold or move value, and you can check that yourself, right now, against a real one.

The rule, stated as a mechanism

Every did:solidus identity is anchored with a key that has never signed a transaction. That's not a naming convention, it's the input the chain checks at creation time: hand it a key with any prior transaction history and the anchor creation itself fails. And the other half of the rule lives on the other side of the ledger, in the executor: any Transfer instruction that names a registered identity anchor as sender or recipient is rejected before it changes state. Not flagged for review, not queued for a compliance check, not caught by an off-chain monitor watching for suspicious activity, rejected, in the same execution pass that would otherwise apply the transfer, by the same code path that validates every other transaction on the chain. There's no separate "identity firewall" bolted on top that could be misconfigured or skipped. The anchor exists to hold a DID Document and nothing else; the executor enforces that boundary the same way it enforces every other transaction rule, at the same layer, with the same code.

This matters because the two halves reinforce each other. A never-used key means an anchor never arrives with a balance. The executor's rejection rule means it can never acquire one afterward, either. Value separation isn't a property of how the anchor happened to be used so far: it's a property of what the chain will let happen to it, checked on every single transaction, forever.

The live proof

curl -X POST https://rpc.solidus.network \
  -H "Content-Type: application/json" \
  -d '{
    "jsonrpc": "2.0",
    "method": "solidus_getBalance",
    "params": ["46Hzv2Ek4MXwj1Kenvix4tWCPr1J"],
    "id": 1
  }'

{"jsonrpc":"2.0","id":1,"result":0}

Balance: zero. Not "zero because nothing has happened to this address yet", zero because nothing can happen to it. The same holds for fees: this anchor has paid 0 in transaction fees over its entire life, for the same structural reason it holds no balance: it has never been party to a value-moving transaction, because the executor won't let one through. Pick a different registered anchor and the numbers will match, every time, for the same reason.

Why "consensus rule," not "impossible" or "audited"

It's worth being precise about what this claim is and isn't, because it's the kind of sentence that gets quoted on its own. This is enforced by consensus rule, a specific, checkable condition inside the chain's execution logic: a Transfer touching a registered anchor address fails at the executor. It is not a formal-verification result. Nobody has produced a mathematical proof that no code path can ever route value to an anchor. What it is: a rule you can read the effect of, on a real chain, with a command that takes ten seconds to run. That's a narrower claim than "impossible," and it's the true one.

What this means if you're reading a DID's on-chain history

The practical version, for anyone who's ever worried that an identity record and a spending record are secretly the same document: they aren't, on Solidus, by construction. An identity anchor's on-chain trail, creation, key rotation, credential issuance and revocation, can never become a financial trail, because the chain itself refuses to let value touch that address. Reading someone's DID tells you about their identity claims. It cannot tell you what they bought, from whom, or for how much, because that information was never allowed to exist at that address in the first place. For a compliance lead evaluating a privacy-preserving identity layer, that's the one sentence worth remembering: the on-chain record of who someone is can never become the on-chain record of what they spent.

Run it yourself

Don't take the zero above on faith, resolve a DID first if you haven't (see Resolve a DID Yourself), pull its anchor address, and run the solidus_getBalance call against a different registered anchor. You'll get the same result. And if you want to see what a Solidus chain does let you find on-chain for an identity, credential status, revocation, the things that are deliberately visible rather than deliberately absent: the companion page is What's On-Chain for a Verifiable Credential. This page is about what's structurally missing from an anchor; that one is about what's structurally present for a credential. Read together, they're the honest map of what a stranger can and can't learn from watching Solidus.