The Question Is Not How Fast It Confirms. It Is When You Can Act on It

Two words that get used as though they were one

Confirmed means a record has been included. Final means it cannot subsequently be removed or reordered.

In some designs those are the same event. In others they are separated by a probabilistic gap: the longer you wait, the less likely a reversal becomes, and it never quite reaches zero. Systems built on that model have to choose a waiting period, and the choice is a risk judgement dressed as a configuration value.

A business needs to know which model it is standing on, because that determines whether "wait a bit longer" is a real safety measure or a superstition.

Why this matters for identity specifically

Less than people assume, and the reason is worth stating plainly.

Verifying a credential does not touch a chain. A verifier checks a signature against an issuer's key. That is arithmetic, it works offline, and no confirmation is involved. The overwhelming majority of what an identity system does is unaffected by finality entirely.

Where it does matter is the record of who may issue. Adding or removing an issuer from the trust registry is a state change, and a verifier acting on a stale view of that record may accept a credential from an issuer that has just been removed.

So the finality question in identity is really a question about how fast a removal becomes universally visible, which is a much narrower and more answerable question than it first appears.

The concession that bounds all of it

Deterministic finality assumes fewer than a third of the committee is faulty.

That assumption is about independent participants. With four validators operated by one party, the assumption is not being tested by anything, and a guarantee stated as a fraction of a committee is arithmetic about processes rather than about independent operators.

What is already done is the mechanism: a real consensus engine with a real commit rule, running and producing blocks. What has not happened is any deployment where the assumption behind the guarantee is meaningfully load-bearing.

What a buyer should actually check

Not the confirmation time. Ask what the verifier does with a stale registry view.

A well-designed system caches issuer status with a bounded staleness and tells you what that bound is. A poorly designed one either calls the network on every verification, which makes the network an availability dependency, or caches indefinitely and cannot tell you when it last checked.

That answer matters far more to your risk than a block time does, and it is answerable today regardless of how a chain reaches finality.

What to ask any network in an identity product

"Is finality deterministic or probabilistic?" If probabilistic, ask what waiting period the product uses and who chose it.

"What in my flow actually waits for finality?" For most identity operations the correct answer is nothing, and a vendor who cannot say which operations depend on the chain has not separated the layers.

"How stale can a verifier's view of the issuer registry be?" This is the real question, and it has a number.

"How many independent operators does the safety assumption rest on?" For us the answer is one, which is the honest bound on every guarantee above.

Where this leaves a decision

If your concern is how long a user waits, the chain is almost certainly not in that path, and you should be looking at the verification flow instead.

If your concern is how quickly a removed issuer stops being accepted everywhere, that is the question worth asking, the mechanism behind it commits deterministically, and the assumption it rests on is not yet being tested by a network with more than one operator.