Performance Race: Finality
You have just sold your car. The buyer hands you cash, you hand over the keys, and you both walk away. The transaction is done, irreversible and final. Now imagine they paid with a check instead. You deposit it, but there's a waiting period. The check might bounce. The funds might be reversed. For several days, uncertainty hangs in the air: did you really get paid or not?
This is the question of finality, and it matters profoundly in the world of blockchains. When your transaction appears on the blockchain, when can you be absolutely certain it's permanent? When can you trust that it won't be undone?
This is the fourth article in Performance Race - a five-part series exploring how blockchains chase speed without sacrificing their principles. Oh, finality: the point at which a transaction stops being a probability and becomes an irreversible, economically guaranteed truth.
To catch up, refer to the previous articles:
Instant Confirmation Illusion
Here's something that surprises many people new to blockchain: just because a transaction appears in a block doesn’t mean it’s truly final. That block itself might not be final.
Think back to Part 2, where we discussed block time. inclusion in a block gives you that first confirmation, but on many blockchains, especially those with fast block times, there’s still a chance the block could be replaced by an alternative version of history.
Because the network is distributed across thousands of machines, it’s common for two valid blocks to be created at nearly the same time, temporarily producing two competing versions of events. Eventually one wins and the other is discarded or “orphaned” in blockchain terms.
If your transaction was in the orphaned block, it may be included later or, in some cases, need to be resubmitted. This is why a single confirmation often isn’t enough for high-value transactions.
Probabilistic v Absolute
Bitcoin’s rule of thumb: wait for six confirmations before treating a transaction as final. With blocks every ~10 minutes, that’s about an hour.
Why six? Each new block makes reversing the previous ones exponentially harder. After six, undoing a transaction would require massive computing power, making it economically impractical for most amounts.
This is probabilistic finality: no transaction is absolutely irreversible, but after enough confirmations, the risk becomes negligible. The waiting period depends on risk. A coffee? One confirmation may suffice. A $100,000 payment? Many more. Exchanges commonly use six confirmations to balance speed and safety.
There’s another type: absolute finality. Here, once a block is confirmed, it’s final: no reversals, no waiting. Achieving this usually requires more complex consensus mechanisms, with staked validators, voting protocols, and economic penalties to prevent conflicting blocks.
Finality Timeline
Let's make this concrete by walking through what finality looks like on different blockchains:
Finality varies because blockchains reach consensus differently. Bitcoin uses proof of work, where miners compete to extend the chain. Short-range reorganizations are always possible, so finality is probabilistic: the more blocks added, the safer the transaction.
Proof-of-stake provides stronger guarantees. Ethereum finalizes blocks via stake-weighted votes on 32-block epochs; reversing a block would require slashing massive amounts of validator stake. Solana combines fast block production with BFT-style (Byzantine Fault Tolerant) voting, giving quick confirmations while full finality needs several supermajority rounds.
Some networks aim for near-absolute finality. Algorand uses single-round committee votes to prevent forks. Ripple relies on trusted validators that deterministically converge on each ledger, producing near-instant, irreversible results.
Slow finality creates practical problems for many actors in the whole ecosystem:
A 51% Problem & Tradeoffs
Finality is closely tied to security. In proof-of-work blockchains like Bitcoin, an attacker controlling over 50% of the network’s computing power could, in theory, rewrite history, reversing transactions, double-spending coins, and causing chaos.
This is called a 51% attack, and it's the reason we must wait for multiple confirmations. The deeper a transaction sits in the blockchain, the more computational work an attacker would need to redo to reverse it. It’s not truly impossible to reverse a transaction after six confirmations, just economically irrational, as the cost outweighs any potential gain.
Other consensus mechanisms differ in specifics. In proof-of-stake, an attacker needs a majority of staked assets, but the principle is the same: make attacks more costly than they could ever be worth.
Instant finality sounds universally better than probabilistic. Why would anyone choose to wait? But as with everything in blockchain design, there are tradeoffs:
UX Gap
Most blockchain apps fail to communicate transaction finality. Wallets often mark a transaction “confirmed” after one block, even though it may not be final. Users aren’t told whether to wait and how long.
Layer 2 systems add another layer of ambiguity: a transaction may be final within the L2, but not yet final on the base chain until settlement occurs. Apps rarely explain this distinction, leaving users unsure whether their action is only locally final or fully settled.
This uncertainty leads to confusion: Did the transaction succeed? Is it safe to close the app? Should I wait before treating the payment as complete?
Clearer apps now expose simple, explicit states:
- Pending (in mempool)
- Included (in a block or L2 state, not fully final)
- Final (irreversible and, for L2s, settled on the base layer)
Explicit states give users transparency and better expectations.
When finality is measured in seconds rather than minutes, entirely new applications become possible:
Finality intersects with the broader blockchain trilemma: the challenge of optimizing decentralization, security, and scalability simultaneously:
Different projects make different choices based on their priorities and risk tolerances.
Reactive in Focus
Reactive Network delivers fast, dependable finality by pairing Ethereum-style consensus with a quicker block time. Each slot (basic time step for proposing a block) lasts about 7 seconds. Every 32 slots are grouped into an epoch, a larger coordination interval used by validators to agree on the chain’s progress. With two epochs required for full economic finality, transactions become irreversible in roughly 7.5 minutes.
In practice, finality remains close to this theoretical target. Even with normal network variation (occasional missed slots or timing drift), it generally falls within a narrow 7.5 - 11-minute range. This corresponds to about 64 - 95 blocks before a transaction is fully locked in.
Closing Thoughts
Finality is getting faster across the ecosystem. New consensus mechanisms, better network infrastructure, and clever cryptographic techniques are all contributing to progress. What took an hour in 2010 now takes minutes or seconds in many modern blockchains.
But speed isn't the only consideration. The reliability of finality, the guarantee that it truly means "irreversible", matters just as much. A blockchain claiming instant finality that later experiences chain reorganizations has broken a fundamental promise to its users.
The projects that succeed are those that clearly communicate their finality guarantees, deliver on them consistently, and help users understand the level of certainty they can expect at any moment. As the ecosystem evolves, striking the right balance between speed and trustworthiness will define the next generation of resilient chains.
About Reactive Network
Reactive is an EVM-compatible execution layer for dApps built with Reactive contracts. These contracts differ from traditional smart contracts by using inversion-of-control for the transaction lifecycle, triggered by data flows across blockchains rather than by direct user input.
Reactive contracts listen for event logs from multiple chains and execute Solidity logic in response. They can determine autonomously when to transmit data to destination chains, enabling conditional cross-chain state changes. The network delivers fast and cost-effective computation via a proprietary parallelized EVM implementation.
Website | Blog | Twitter | Telegram | Discord | Reactive Docs
