# What is transaction finality, and why does it matter for payments?

> Finality is the point at which a blockchain transaction cannot be reversed. The difference between probabilistic finality (minutes of risk) and deterministic finality (irreversible in under a second) decides whether a blockchain can work as a real-time settlement system.

7 min read · Updated 2026-06-09 · Topic: chains

Canonical: https://tempo.dataos.so/articles/transaction-finality-explained

When you send money over a traditional wire transfer, there is a moment at which the transfer is **done** — the bank on the other end has the funds, the transaction is in their ledger, and nothing short of a court order can undo it. That moment is called settlement, and it is the thing that makes a payment a payment rather than a promise.

Blockchain transactions have an equivalent concept: **finality**. But not all chains reach finality the same way, at the same speed, or with the same guarantees. The design choice a chain makes about finality is one of the most important things to understand about it as a payments rail.

## The basic problem: re-orgs

A blockchain is a chain of blocks, each containing a batch of transactions. When a new block is proposed, validators must agree on whether to add it to the canonical chain. Most of the time this is smooth. Occasionally — due to network partitions, software bugs, or deliberate attack — two validators propose competing blocks at the same height.

When the network later resolves which block is canonical, one of them is discarded. Every transaction in the discarded block disappears from the chain as if it never happened. This is a **re-organisation** (re-org).

For a payment, a re-org can mean a transaction that appeared confirmed — that a merchant accepted, that a payroll system recorded as sent — is erased. The funds return to the sender's wallet. The merchant or payee received nothing. This is not a theoretical edge case; re-orgs happen on real chains with real user impact.

**Finality** is the moment at which a re-org can no longer undo a specific transaction. Before finality, there is risk. After finality, there is none.

## Probabilistic finality

Most blockchain consensus mechanisms achieve finality **probabilistically** — the more blocks that are added on top of a transaction's block, the more computational or economic work would be required to re-org it out, and the more unlikely that becomes.

Bitcoin is the clearest example. A transaction in a block with one confirmation on top of it is reversible with moderate effort. After six confirmations (~60 minutes), the economic cost of re-orging it is so high that exchanges and merchants treat it as safe — not because it is provably irreversible, but because reversing it would cost more than it could possibly be worth.

Ethereum's proof-of-stake consensus achieves **economic finality** after two epochs — roughly **12–15 minutes**. At that point, reversing a transaction would require destroying at least one-third of all staked ETH (hundreds of billions of dollars as of 2026). The probability of a re-org is not zero in a mathematical sense, but the economic cost makes it effectively impossible in practice.

Tron uses Delegated Proof-of-Stake. A transaction is considered "solidified" — Tron's term for safe — once 19 of 27 Super Representatives have built blocks on top of it. This takes approximately **57 seconds** (19 three-second blocks). Before that point, a transaction can theoretically be reversed.

**Solana** processes transactions in roughly 400ms and gives first confirmation very quickly. Its optimistic confirmation (used for most user-facing applications) is fast but is not the same as BFT deterministic finality; full finality on Solana takes somewhat longer as supermajority agreement propagates.

## Deterministic finality

**Deterministic finality** is categorically different. Under a Byzantine Fault Tolerant (BFT) consensus protocol, a block that achieves finality is **permanently final** — not just economically unlikely to be reversed, but mathematically impossible to reverse under the protocol's safety assumptions.

BFT protocols work by requiring validators to vote in rounds. A block is only finalized when a supermajority (typically two-thirds) of validators explicitly vote to finalize it. Once that threshold is reached, the protocol guarantees — not probabilistically, but definitively — that no conflicting block at the same height can ever be finalized. The chain would have to violate its own safety rules to produce a re-org of a finalized block.

The trade-off: BFT requires communication between all validators in each round, which limits how many validators can participate before communication overhead slows things down. Many BFT chains operate with a smaller, known validator set rather than an open-ended permissionless one.

## Why it matters for payments specifically

For most blockchain applications — trading, lending, NFTs — finality time is a nuisance rather than a structural problem. You can afford to wait a few minutes for a high-value trade to settle.

For payments, finality time directly determines the design of your product.

**Merchant acceptance.** A retail merchant who accepts a payment must decide: hand over the goods now (risking a re-org), or wait for finality (degrading the customer experience). With 15-minute finality, the answer is usually "wait" — which means a blockchain payment at a physical point of sale is less convenient than a card tap.

**Payroll and B2B settlement.** A company sending payroll needs to know the payment is done, not that it is in a state where it will probably be done in 15 minutes. For automated systems reconciling thousands of transfers, a probabilistic risk window creates exceptions that require human review.

**Machine-to-machine payments.** AI agents and automated services paying per API call or per compute second cannot wait 57 seconds or 15 minutes for each transaction to finalize. Sub-second finality is a prerequisite for this use case.

**Fraud and chargeback prevention.** On a chain with deterministic finality, there is no reversal. For a merchant, this eliminates one class of fraud risk. For a payments system, it simplifies accounting: final means final.

## How each chain compares on finality

| Chain | Finality type | Time to finality |
|---|---|---|
| **Bitcoin** | Probabilistic | ~60 min (6 confirmations, conventional) |
| **Ethereum** | Probabilistic (economic) | ~12–15 min (2 epochs) |
| **Tron** | Probabilistic (solidified) | ~57 sec (19 blocks) |
| **Solana** | Optimistic / BFT hybrid | 1–2 sec (optimistic confirmation) |
| **Base** | Soft: sequencer-confirmed; Hard: L1-settled | Soft: 1–5 sec; Hard: ~1 day (post-Azul) |
| **Tempo** | Deterministic (Simplex BFT) | Sub-second (~500ms block time) |

## Tempo's design choice

Tempo uses **Simplex BFT** consensus, implemented through the Commonware library. Simplex BFT is a safety-first protocol: it requires a supermajority of validators to vote on each block before it is finalized, and once a block is finalized, it cannot be re-orged under any circumstances.

The block time is approximately **500 milliseconds**. Each block that finalizes is final: irreversible, permanently recorded, with no confirmation window required for a merchant or application to treat it as settled.

The safety-first design has a deliberate consequence: if more than one-third of Tempo's validators go offline simultaneously, the chain halts rather than continue producing blocks that could later conflict. This is the correct behavior for a settlement system. **A payment system that can be wrong is more dangerous than one that pauses.** A brief halt can be communicated and recovered from; a double-spend cannot be undone.

This is the same reasoning that makes traditional payment systems — card networks, SWIFT — prioritise correctness over availability. A SWIFT wire does not guess at whether it went through; it either settles or it returns a failure. Tempo's consensus model reflects the same design principle applied to blockchain.

For businesses building on Tempo, the practical implication is straightforward: once a transaction appears in a finalized block, it is done. No confirmation counting, no re-org risk window, no exception handling for reversed payments. The payment is final when the block is final — in under a second.

## What to read next

For how finality interacts with fees and throughput across all five major stablecoin chains, see [blockchains for stablecoin payments, compared](/articles/stablecoin-chains-comparison). For the specific comparison with Ethereum's probabilistic model, see [Tempo vs Ethereum for stablecoin payments](/articles/tempo-vs-ethereum-for-payments). For Base's two-speed finality model in detail, see [what is Base?](/articles/what-is-base-ethereum-l2).

## FAQ

**What is finality in blockchain?**

Finality is the guarantee that a confirmed transaction cannot be reversed, altered, or removed from the blockchain. A transaction with finality is settled — the payment is done. A transaction without finality is visible on-chain but still theoretically reversible, which creates a risk window for merchants and payment processors.

**What is the difference between probabilistic and deterministic finality?**

Probabilistic finality means a transaction becomes harder to reverse with each new block added on top of it, but is never mathematically guaranteed to be irreversible. Deterministic finality means that once a block is confirmed by the consensus protocol, it is permanently final — no re-org can undo it, regardless of future network conditions.

**How long does finality take on major chains?**

Ethereum: approximately 12–15 minutes (two epochs of ~6.4 minutes each). Tron: approximately 57 seconds (19 blocks, solidified when 2/3 of Super Representatives build on top). Solana: 1–2 seconds (optimistic confirmation; not the same as BFT deterministic finality). Base: 1–5 seconds soft finality (sequencer-confirmed); approximately 1 day hard finality (L1-settled, post-Azul). Tempo: sub-second deterministic finality (~500ms block time).

**Can a merchant safely accept a payment before finality?**

It depends on the chain and the risk tolerance. On Bitcoin, the traditional practice is to wait for 6 confirmations (~1 hour). On Ethereum, most merchants accept after a few confirmations (a few minutes). On chains with deterministic finality like Tempo, the transaction is final when confirmed — there is no additional waiting period for a merchant to be safe.

## Sources

1. [Ethereum.org — Finality](https://ethereum.org/developers/docs/consensus-mechanisms/pos/#finality)
2. [Commonware — Simplex BFT consensus](https://docs.rs/commonware-consensus/latest/commonware_consensus/simplex/index.html)
3. [Tempo docs — Performance](https://docs.tempo.xyz/learn/tempo/performance)
4. [Chainspect — Tron TPS & TTF](https://chainspect.app/chain/tron)
5. [Tempo blog — Tempo × Commonware](https://tempo.xyz/blog/tempo-commonware)

---
Neutral, sourced explainer from tempowiki. Index: https://tempo.dataos.so/llms.txt