Ethereum confirmations vs finality: check the block, not just Success

An included Ethereum transaction can show Success before its containing block is finalized. Success describes execution; confirmations describe blocks added after inclusion according to the tool’s counting convention. Finality is a separate consensus state. Check the transaction’s block and the network’s finalized chain instead of treating those labels as interchangeable.

This guide concerns Ethereum Mainnet after its transition to proof of stake. Rollups, bridges, other chains and custodial services have additional rules. It is a read-only check of a transaction you already have, not a recommendation to send, cancel or repeat a payment.

Separate inclusion, execution and finality

The JSON-RPC receipt reference returns the transaction’s containing block number and hash, together with execution status. A pending transaction does not yet have an included receipt. Status 1, shown as 0x1 in raw JSON-RPC, indicates execution success; 0 or 0x0 indicates failure.

Neither value is a finality flag. A transaction that reverted can still belong to a finalized block. Conversely, a successful execution can be in a recent block that has not yet finalized. Waiting for finality will not turn a reverted action into a successful one.

Observation	What it tells you	What it does not settle
Receipt with a block	The provider reports inclusion there	Whether that block is finalized
Receipt status Success	The top-level execution succeeded	The intended token receipt or finality
Confirmation count	The tool reports depth since inclusion	A universal finality or crediting rule
Finalized chain includes the block	Consensus finality covers that block	Contract safety or an exchange credit

If the transaction is still pending, use the pending transaction guide before considering another action. If it succeeded but the intended tokens are missing, the transfer evidence guide addresses that separate question.

What Ethereum means by finalized

Ethereum’s proof-of-stake explanation describes validators voting on checkpoints. Finality gives a stronger guarantee than merely being near the current chain tip: reversing a finalized block would require a major consensus failure with severe economic consequences. It is not a promise that every application or asset in the block is safe.

The Ethereum Foundation’s application-layer explanation distinguishes the safe head from finalized blocks. Safe is an intermediate confidence state, not a synonym for finalized. The execution API exposes latest, safe and finalized block tags so a reader can ask about the relevant head.

Use those labels in their Ethereum context. A rollup may expose similar words for stages involving a sequencer and a parent chain. Do not apply the Mainnet procedure unchanged to a bridge transfer or assume a source-chain finalized transaction completes the destination-side action.

No fixed waiting time is promised here. A delay, a stale provider or a network problem can make a timer a poor substitute for checking the actual state. If a service asks for a particular confirmation count or other condition, consult its current official requirements as a separate check.

Check the transaction against the finalized chain

Start from a familiar Ethereum explorer or public block reader reached through a trusted route. Some explorers display finality directly; others expose only block details. The method names below identify public reads, not instructions to run a transaction or connect a wallet. This procedure was checked against documentation on 27 October 2026; it was not tested on a live wallet for this article.

1. Fix the transaction identity. Record Ethereum Mainnet and the full transaction hash. Read its receipt, noting the containing block number, block hash and execution status. An unavailable receipt remains unresolved; check the network and provider before calling it failed.
2. Read the reported finality state. Use the explorer’s documented block label. In a JSON-RPC reader, eth_getBlockByNumber with finalized asks for the current finalized head. Keep the returned block number and observation time. Unsupported or failed reads stay unverified.
3. Compare block identity as well as height. If the finalized head is lower than the transaction’s containing block, that observation does not yet cover the transaction. If it has reached or passed that height, re-read the canonical block at the containing height and compare its hash with the receipt’s block hash. Use a consistent, current provider and recheck the receipt if the hashes disagree.
4. Keep the outcome’s scope clear. A matching containing block at or behind the finalized head supports finality on that reported chain. A stale or inconsistent provider can still give misleading data. Preserve discrepancies and consult the provider’s official status or support rather than forcing an answer from mixed snapshots.
5. Check the application requirement separately. Establish what the transaction actually did and whether the receiving service has credited it under its own rules. Do not send a second payment just because a gallery or deposit page has not refreshed.

The block lookup documentation supplies the block’s number and hash. Height alone is insufficient when records disagree: two different blocks can occupy the same height across a chain reorganization. Keep the hash with the number so that your comparison names the block that contained the transaction.

Read a changing confirmation count carefully

Suppose a hypothetical receipt places a transaction in block 100, while a reader reports a finalized head at 98. The transaction may already show Success, but that finalized-head observation does not cover block 100. If a later consistent read reports finalized head 102, check that the canonical block at 100 still has the receipt’s hash before recording the transaction’s block as covered.

These deliberately small block numbers are an invented illustration, not a current Mainnet observation. They do not predict how long finality takes or specify a deposit threshold. A displayed confirmation count may use a convention that includes the containing block; read the tool’s definition before comparing counts from two interfaces.

A reorganization can move a transaction to a different block or leave it without its previous inclusion record. Keep the original hash, refresh its receipt and compare current records. A changed count alone is not evidence that you should resend. Nor does a wallet’s old notification override a newer block record.

Finish with a dated block record

Keep the network, transaction hash, containing block number and hash, execution status, observed finalized head and time of the check together. Mark whether the records were consistent and whether finality was directly labeled by an explorer or inferred from the block comparison above.

Finality does not prove that the correct token reached the correct recipient, that a contract is trustworthy, or that a custodial service completed its own accounting. A portfolio balance discrepancy can also be a display, coverage or pricing issue after a transaction is finalized.

No signature, approval or recovery phrase is needed for these public records. If a site asks for one merely to show confirmations or finality, stop that flow. Your result should be a specific observed state with its limits, not a universal promise that a green badge means every part of the payment is complete.