Four networks, four meanings of finality

Ethereum's proof-of-stake chain separates two things that Bitcoin does not distinguish. A block is first justified, and then finalised, and the Ethereum documentation describes finality as a property of checkpoints: once two consecutive epochs are justified, the earlier checkpoint is finalised, and reverting a finalised checkpoint would require at least a third of the total staked ether to be destroyed. Before a checkpoint is finalised, however, the chain can still reorganise, and the documentation is explicit that short reorgs are a normal part of the protocol rather than a failure.

The security argument is economic rather than probabilistic. An attacker who wants to revert a finalised checkpoint must control enough stake to do it and must accept that the protocol's slashing conditions will destroy that stake. The cost is therefore bounded by the value of the stake at risk rather than by the cost of hardware, which is a different kind of guarantee: it is a statement about what an attacker would lose, not about how much work they would have to perform.

Solana's finality is also economic, but it is reached differently. The documentation describes a tower consensus in which validators vote on forks, and a vote at a given depth locks in the validator's earlier votes: a validator that votes for a fork is committing not to vote for a conflicting one at the same or lower depth. Once enough stake has voted on a fork, it is rooted and treated as final. The mechanism is a stake-weighted commitment rather than a checkpoint schedule, and the documentation describes the resulting finality as arriving in a small number of slots rather than after a fixed number of blocks.

The Internet Computer's consensus protocol produces a finalised block per round, and the documentation describes a block that has been agreed by a subnet as final: there is no competing chain to reorganise to, because the subnet's nodes agree on one chain and the protocol does not admit a fork. The documentation contrasts this directly with the probabilistic model, describing the Internet Computer's finality as deterministic and arriving in about a second rather than after a confirmation count.

The guarantee is a threshold one. A subnet's security rests on the assumption that fewer than a third of its nodes are faulty, and the protocol's safety argument holds within that bound. This is a different assumption from Bitcoin's, which makes no claim about the identity of participants and relies instead on the cost of accumulating work. A reader comparing the two should be clear that "deterministic" describes the shape of the guarantee, not its strength: a deterministic guarantee under a threshold assumption is not the same thing as an absolute guarantee under no assumption.

The practical consequence is that a canister's state change is settled as soon as the block containing it is finalised, and a client can verify a response against the subnet's public key rather than waiting for confirmations. That is what makes the platform usable for applications that need to read their own state immediately, and it is the property the rest of the ICP research cluster builds on.

The table describes the shape of each guarantee, not how long it takes in practice. Time-to-finality depends on block intervals, network conditions and the behaviour of participants, and a page that quoted a number for each network would be quoting a measurement that changes. The documentation states the mechanism; the reader who wants current figures should go to the networks' own dashboards.

The comparison also does not rank the guarantees. A deterministic guarantee under a threshold assumption and a probabilistic guarantee under no identity assumption are not points on one scale, and treating them as such is the most common error in this kind of comparison. Which one a user should prefer depends on what they are doing: a merchant accepting a small payment has different requirements from a bridge holding a large balance, and the confirmation policy that suits one may be inappropriate for the other.

Finally, the four networks are not static. Ethereum's finality mechanism has changed since the merge, Solana's consensus has been revised, and the Internet Computer's protocol continues to develop. This page describes each mechanism as its documentation describes it at the review date, and it does not treat a proposed change as a deployed one.