Included, then gone
Seeing your transaction in a block on an explorer, it is easy to assume it is done. The most recent blocks, however, may not yet be fully agreed upon, and occasionally a reorganization, or reorg, replaces them with different blocks. A transaction may then be included in a different order or temporarily drop out.
This post walks through how Ethereum blocks move from the latest head to safe and then finalized, and the risk of reversal at each stage. It calculates finality time in slots and epochs and compares, with a hypothetical payment, which standard a service should use before accepting a deposit.
Slots, epochs, and checkpoints
Ethereum.org's page on proof of stake explains that a slot comes every 12 seconds and a validator may propose a block in each one. Thirty-two slots form an epoch, so an epoch lasts 6.4 minutes. Validators vote, or attest, on blocks to agree on the correct chain.
The first block of each epoch is a checkpoint. As Ethereum.org's page on Gasper explains, a checkpoint that receives votes from at least two-thirds of total staked ether becomes justified, and when the next checkpoint is also justified, the earlier one becomes finalized. Blocks therefore usually finalize after about two epochs, roughly 12.8 minutes.
Block states compared
Ethereum.org's JSON-RPC documentation describes block tags such as latest, safe, and finalized. The table compares what each means, its typical delay, and its reversal risk.
| Block tag | Meaning | Typical delay | Reversal risk | Example use |
|---|---|---|---|---|
| latest | The most recent block a node sees | 0–12 seconds | Short reorgs possible | Display, quick previews |
| safe | Unlikely to be reverted given an honest majority | Tens of seconds or more | Low when the network is healthy | Confirming small payments |
| finalized | At or before a finalized checkpoint | About 12.8 minutes | Reverting requires burning at least a third of staked ether | Large deposits, withdrawals |
Ethereum.org explains that reverting a finalized block would require an attacker to break the rules in a way that destroys at least one-third of all staked ether.
A hypothetical payment
Suppose an online shop ships goods as soon as a payment appears in the latest block. If a short reorg selects a block without the payment, and the buyer meanwhile gets a transaction moving the same funds elsewhere included first, the shop may have shipped goods without being paid.
If the shop waits for finalized, it must wait about 13 minutes after payment, but that risk effectively disappears. This is why many exchanges wait before crediting deposits. For small amounts where speed matters, safe may be enough; for large amounts, finalized is the stronger standard, splitting risk and speed by amount.
When finality is delayed
Finality needs votes from at least two-thirds of staked ether. If a major client bug or a network split keeps many validators from voting, blocks may keep coming while finality stalls. The latest block keeps advancing while the finalized block stays put.
If finality stalls for long, Gasper includes a mechanism that gradually reduces the stake of validators who are not voting until the two-thirds threshold is restored. Services should decide in advance how they will handle deposits and withdrawals while finality is stalled.
Monitoring the distance between the latest and finalized blocks is a simple way to notice such a stall. Under normal conditions the gap stays at around two to three epochs; a steadily widening gap is a signal to pause large credits.
Standards a service should set
If you run a service that accepts deposits or payments, or use one, check these items.
- Find whether the service credits deposits at latest, safe, or finalized, and how many blocks or minutes it waits.
- Check which block tag your node or RPC requests use, and make sure you are not simply relying on the default latest.
- Decide whether to use different standards for different amounts.
- Prepare procedures for handling deposits and withdrawals while finality is stalled.
- Layer 2s and other chains finalize differently, so check the standard for each chain separately.
How other chains differ
Proof-of-work Bitcoin uses confirmation counts rather than finality. The more blocks build on top, the harder reversal becomes, but it never becomes mathematically final. Ethereum's proof of stake adds an explicit finality step for checkpoints, making the cost of reversal clear.
Transactions on layer 2 rollups go through the rollup's own confirmation and then the stage where their data is posted to Ethereum and finalized. A rollup interface showing "confirmed" may not mean the data is finalized on Ethereum.
Variables beyond the numbers
The times here are typical values for a healthy network, and the payment case is hypothetical. Consensus rules can change through upgrades, and proposals to shorten time to finality are under discussion.
When setting a standard, check Ethereum.org and the current consensus specifications, checking how recent each one is. None of the figures here are a signal to buy or sell.