What deterministic finality means when you are reading a page

The short answer to “how many confirmations should I wait for” is none. The question does not apply to this chain, and the counter that would answer it is deliberately absent from every page on this site.

Probabilistic versus deterministic

On a proof-of-work or longest-chain proof-of-stake network, a block is only probably permanent. A competing chain could out-build it, so the block you are looking at could be reorganised away. Confidence grows as blocks accumulate on top, which is what a confirmation count measures: not a state, but a probability that never quite reaches one. This is why exchanges make you wait.

Arc uses Malachite, a BFT consensus. A proposer proposes a block, the validators vote, and when more than two thirds of the voting power has precommitted, the block is committed. Committed means final — not “final with high probability”. There is no competing chain to lose to, because a conflicting block would require more than a third of the validator set to have signed two contradictory things, which is a detectable, attributable protocol violation rather than a race someone can win with hardware.

In practice finality lands in under a second, at the same moment the block becomes visible.

What this changes on this site

• No confirmation counter. A transaction shows Success or Fail, and its block shows Finalized. There is no number that grows, because a growing number would imply a safety threshold you are working towards, and you are not.
• No reorgs, no orphaned or forked blocks. There is no uncle list and no “forked blocks” page, because those artefacts cannot be produced.
• Every height-keyed page is permanent. A block page or a transaction page can never change once rendered, so Arcscan caches them forever rather than revalidating them. That is why this site is fast — not an optimisation so much as a property of the chain.
• Nothing you read here can be un-read. A transfer visible on this site happened, permanently. Nobody — not us, not a validator, not the issuer — can reverse it.

The honest caveat

Chain finality is not the same as our view of the chain. Arcscan reads from a node, and a node can be behind, and some pages are built from an index that can be further behind still. A recent transaction can therefore be final on Arc and invisible here for a moment.

That is why this explorer distinguishes the two everywhere it can: a page served from the index says so and reports its coverage, and the network status page publishes our head height, how old it is and how far the index trails it. “Not found yet, our node is at block N” is an honest answer. “Pending” would not be.

One thing Arcscan will stop for: Arc cannot reorganise, so if a block header we receive does not link to the one before it, something is badly wrong rather than merely late. That condition is counted, published on the status page, and takes this service out of rotation rather than letting it serve a chain history that might be false.