A transaction appearing in an Ethereum block has reached an identifiable milestone. That observation should not be silently substituted for the network’s checkpoint-finality status or a custodian’s decision to credit an account. Ethereum’s proof-of-stake documentation explains finality through validator votes for checkpoint pairs, adding a consensus record beyond initial block inclusion. Ethereum.org: Proof-of-stake transaction processing and finality
Follow the evidence
Trace how the event could reach markets, then inspect a competing explanation.
Compare explanations
Switch lenses to see what each account explains—and what remains uncertain.
WFN analysis: consider a hypothetical deposit review with three timestamps: first block inclusion, confirmed finality status and the custodian’s account credit. The timestamps describe three different processes. A delay between them is a fact to investigate, but its cause cannot be established from the gap alone. The reviewer needs both the network evidence and the provider’s applicable deposit policy. A block-height screenshot may show inclusion while omitting checkpoint status. A provider’s completed-deposit message may describe its own internal treatment. Neither record should be relabelled without checking what it actually attests to. This is especially useful when two services display different progress indicators for the same underlying transaction. The clock also deserves careful handling. Protocol timing conventions do not supply a universal guarantee that every deposit will become spendable after a fixed number of minutes. The status of a particular transaction must be checked directly, and the service can apply additional conditions. A general description of the normal mechanism cannot replace an observed completion record.
WFN analysis: consider a hypothetical deposit review with three timestamps: first block inclusion, confirmed finality status and the custodian’s account credit. The timestamps describe three different processes. A delay between them is a fact to investigate, but its cause cannot be established from the gap alone. The reviewer needs both the network evidence and the provider’s applicable deposit policy. A block-height screenshot may show inclusion while omitting checkpoint status. A provider’s completed-deposit message may describe its own internal treatment. Neither record should be relabelled without checking what it actually attests to. This is especially useful when two services display different progress indicators for the same underlying transaction. The clock also deserves careful handling. Protocol timing conventions do not supply a universal guarantee that every deposit will become spendable after a fixed number of minutes. The status of a particular transaction must be checked directly, and the service can apply additional conditions. A general description of the normal mechanism cannot replace an observed completion record.
For an operational comparison, specify the chain, transaction hash, relevant block and the consensus status requested from the node or explorer. For an account-crediting comparison, retain the service’s written policy and its own timestamps. If measuring speed across providers, use the same starting and finishing milestones so that the results answer a consistent question. This framework can improve an institutional settlement review without implying that a finalized transaction is reversible through an ordinary customer-support request. It also avoids treating Ethereum mainnet’s consensus description as a complete account of every bridge, layer-two system or exchange workflow. Those arrangements need their own documented completion conditions alongside any relevant mainnet reference.
The checkpoint mechanism
The documentation divides Ethereum time into slots and epochs, with a checkpoint at the beginning of an epoch. Votes representing at least two-thirds of the total staked ETH can establish the required checkpoint link. In the described progression, a target checkpoint becomes justified and an earlier justified checkpoint becomes finalized. Ethereum.org: Proof-of-stake transaction processing and finality
This threshold concerns the weight of stake, rather than a simple count of validators. The documentation also explains the economic penalties associated with contradictory consensus behavior and reversing finality. These protections describe the protocol’s mechanism; they do not mean every newly proposed block already has the same finality status. Ethereum.org: Proof-of-stake transaction processing and finality
Three records can legitimately have different times
WFN analysis: consider a hypothetical deposit review with three timestamps: first block inclusion, confirmed finality status and the custodian’s account credit. The timestamps describe three different processes. A delay between them is a fact to investigate, but its cause cannot be established from the gap alone. The reviewer needs both the network evidence and the provider’s applicable deposit policy.
A block-height screenshot may show inclusion while omitting checkpoint status. A provider’s completed-deposit message may describe its own internal treatment. Neither record should be relabelled without checking what it actually attests to. This is especially useful when two services display different progress indicators for the same underlying transaction.
The clock also deserves careful handling. Protocol timing conventions do not supply a universal guarantee that every deposit will become spendable after a fixed number of minutes. The status of a particular transaction must be checked directly, and the service can apply additional conditions. A general description of the normal mechanism cannot replace an observed completion record.
Define completion before measuring it
For an operational comparison, specify the chain, transaction hash, relevant block and the consensus status requested from the node or explorer. For an account-crediting comparison, retain the service’s written policy and its own timestamps. If measuring speed across providers, use the same starting and finishing milestones so that the results answer a consistent question.
This framework can improve an institutional settlement review without implying that a finalized transaction is reversible through an ordinary customer-support request. It also avoids treating Ethereum mainnet’s consensus description as a complete account of every bridge, layer-two system or exchange workflow. Those arrangements need their own documented completion conditions alongside any relevant mainnet reference.