A Blockchain Is the Wrong Answer to Most Identity Questions, Including Several of Ours
We operate a chain, and this page is mostly about the parts of identity that do not need one.
The reflex, and why it is expensive
An identity product appears, and somewhere in its material is a chain. The reasoning is rarely stated because it is rarely examined: decentralised identity sounds like it should be decentralised, and a chain is the thing that sounds decentralised.
Then the costs arrive. Latency measured in block times instead of milliseconds. An operational burden that never goes away. A dependency on a network staying up. And a class of questions from every serious buyer about what exactly is written where.
Most of those costs buy nothing, because most identity operations do not involve the problem a chain solves.
What a chain is actually for
Agreement, among parties who do not trust each other, on an ordered set of facts, with no referee.
That is the property. It is narrow, it is genuinely hard, and consensus protocols are how it is obtained. The theory is decades old and predates cryptocurrency entirely.
If your problem does not have the shape of "several mutually distrusting parties must agree on a record and none of them may be able to rewrite it quietly", a chain is a costly way to obtain something a database already gives you.
Four identity operations that need no chain at all
Verifying a credential. A verifier checks a signature against an issuer's public key. That is arithmetic. It works offline, it takes milliseconds, and no network is consulted.
Storing personal data. Nothing containing personal data should be written to a chain, ever. Immutability is precisely the opposite of what data-protection law requires, and a record that cannot be deleted is a liability that cannot be discharged. Any product that puts identity attributes on a chain has created a permanent problem in exchange for a diagram.
Issuing. The issuer signs a statement. There is no distributed agreement in that act.
Presenting. A holder shows a credential to a verifier. Two parties, one exchange, no third party required and none wanted.
That is the overwhelming majority of what an identity system does, and it is all ordinary cryptography and ordinary infrastructure.
The one place the argument holds
Which issuers are trusted, and were they trusted at the moment a credential was accepted. That is the trust registry question.
This question has the right shape. Multiple verifiers need the same answer. The answer changes over time and the history matters, because a dispute a year later turns on what the record said then. And the party maintaining it should not be able to revise it silently, since the whole value of an accountability list is that removing an issuer is visible and permanent.
A record with those properties is worth the cost. That is where a chain earns its place in an identity system, and it is a much smaller footprint than most architecture diagrams imply.
Where our own chain sits against that standard
Honestly, short of it.
The specification describes a 21-of-100 committee. That is a spec. The running network is four validators, operated by one party, which is us. Those are different things, a specification and a deployment, and conflating them is the error this whole estate exists to avoid.
More pointedly: the four validators run in a single process against a shared data store. So the property a chain is supposed to deliver, that no single party can rewrite the record, is not delivered by our deployment today, because there is only one party. What exists is the mechanism, running, in a configuration where the trust assumption it is designed to remove is still present.
And the fault-tolerance guarantee has been checked against a formal model rather than against independent adversarial operators. A model exploring equivocating behaviour is a serious engineering artefact and it is not evidence about a production network, because there is no production network to be evidence about.
Why we still built it
Because the issuer-registry question above is the one we will eventually need answered by something other than a promise, and because retrofitting a consensus layer under a live trust registry is worse than starting with one.
That is a bet on a later requirement rather than a claim about a present benefit. A buyer evaluating us today should price the chain at what it currently delivers, which is a working mechanism under a trust assumption we have not yet removed, rather than at what the design intends.
What to ask any identity vendor with a chain
"What breaks if you delete the chain tomorrow?" The single best question here. If the answer is that credentials still verify, issuance still works and presentation still works, then the chain is carrying one specific thing and the vendor should be able to name it in a sentence. If the answer is nothing breaks, it is decoration.
"What personal data is on it?" The correct answer is none. Any other answer is a permanent obligation and should end the conversation until it is explained.
"How many independent operators run it, right now?" Not validators, operators. Four validators run by one team is one operator, and the distinction is the entire security argument.
"What has been tested against adversarial behaviour, and by whom?" A formal model is not a deployment, an internal test is not an audit, and both are worth having as long as nobody calls them the other thing.
Where this leaves a decision
If a vendor's chain cannot be given a one-sentence job, you are paying for it in latency and operational risk without a return.
For us, the job is issuer accountability, the deployment does not yet meet the standard that job requires, and we would rather you evaluate the credential layer on its own merits, since that is the part running today and the part that would still work if the chain underneath were replaced with something else entirely.