Settlement and finality
Settlement records a state change, while finality describes the confidence that the accepted history will not later be replaced under the network's consensus rules.
Category: RiskWarning cross category cue
System record
Start with the economic purpose, participants, resources, and entitlements before studying implementation detail.
Why it exists
Financial applications need to know when a transfer or contract result is safe to rely on, especially before releasing assets, recognizing claims, or acting across systems.
Traditional-finance analogy
Securities settlement finality is the closest comparison recorded for this concept.
Where the analogy stops
- Blockchain finality depends on protocol-specific consensus, validator, timing, and recovery assumptions rather than one legal settlement operator and jurisdiction.
- Inclusion, successful execution, economic confirmation, and protocol finality can occur at different times and must not be treated as synonyms.
Main actors
- ActorTransaction parties
- ActorValidator or consensus participant
- ActorApplication choosing a confirmation policy
- ActorBridge, exchange, or custodian relying on settled state
Assets and claims
Assets — controlled or transformed resources
Assets are resources the mechanism moves, holds, values, or transforms.
- AssetAssets transferred or locked by the accepted state change
- AssetAssets released by a downstream system after confirmation
Claims — entitlements and corresponding dependencies
Claims are rights to value, repayment, redemption, control, or another party's performance; each depends on an obligation or system that must honor it.
- ClaimFinalized balance or contract-state entitlement
- ClaimReceipt or state commitment relied on by another system
Settlement says a state change has been recorded; finality says when an application can rely on that history under a particular consensus model.
Why it exists
Section titled “Why it exists”Financial actions build on earlier actions. An exchange may credit a deposit, a bridge may release value, and a lender may accept collateral only after deciding that the source event is stable enough. Treating submission, inclusion, execution success, confirmation, and finality as one moment can create assets or claims on one system that no longer have backing on another.
Traditional-finance analogy
Section titled “Traditional-finance analogy”Final securities settlement is a helpful analogy because both systems need a point after which participants can rely on transfer. The analogy is limited: blockchain finality follows protocol-specific consensus, validator, timing, and recovery assumptions, whereas traditional finality also relies on operators, contracts, regulation, and courts. “Irreversible” is never permission to omit the assumptions that make reversal sufficiently unlikely or disallowed.
Actors, assets, and claims
Section titled “Actors, assets, and claims”Transaction parties create the requested state change. Consensus participants order and finalize history. Applications choose the confirmation rule they will accept. Exchanges, bridges, custodians, and protocols may release destination assets based on a source receipt or state commitment. That downstream position becomes a claim on the correctness and persistence of the source event.
Mechanism and flows
Section titled “Mechanism and flows”- A valid transaction is included and executes in a candidate history.
- Later blocks, votes, checkpoints, or proofs increase settlement confidence according to the chain’s consensus design.
- An application applies its own policy to the protocol signal and value at risk.
- Once the declared condition holds, the application recognizes the result or releases a dependent asset.
- Exceptional reorganization, halt, or recovery handling follows a separately specified reconciliation path.
Capital flow may wait until confirmation before assets are credited or released. Claim flow begins when another system relies on the source event. Information flow carries blocks, votes, proofs, and status. Control flow includes protocol governance and the application’s confirmation policy. Return flow is absent from finality itself; finality only changes when another economic return can be treated as settled. Risk flow runs from a replaced or stalled history into every dependent balance sheet.
State and loss allocation
Section titled “State and loss allocation”| State | Safe conclusion | Unsafe conclusion |
|---|---|---|
| Submitted | A request was created | It was included or executed |
| Included | A candidate block contains it | It succeeded or is final |
| Successful | The candidate state transition completed | No reorganization can replace it |
| Confirmed | A chosen confidence threshold was reached | Every other application uses the same threshold |
| Finalized | The protocol’s finality rule holds | Off-chain rights or exceptional recovery are impossible |
Finality does not pay return. It changes settlement risk and capital timing. When one system releases value too early and the source history is replaced, the bridge, exchange, liquidity provider, reserve, insurer, or users holding the unbacked destination claim must absorb the mismatch.
Beginner lens
Section titled “Beginner lens”A transaction can appear on screen before it is safe for another financial system to treat it as irreversible. Look for separate status and confirmation language instead of treating “complete” as a universal state.
Practitioner lens
Section titled “Practitioner lens”Set policies using the chain’s real finality model, asset value, attack cost, liquidity, reorganization history, sequencer behavior, and downstream action. Document how deposits, withdrawals, liquidations, and cross-chain messages behave during a halt or reorganization.
Engineer or auditor lens
Section titled “Engineer or auditor lens”Ethereum proof of stake uses attestations and checkpoint finality with protocol-specific supermajority conditions and penalties. That is an example, not a generic confirmation formula. Probabilistic chains, BFT-style chains, rollups, and centralized sequencers expose different signals and recovery paths; applications must integrate the one they actually depend on.
Security review notes
Section titled “Security review notes”Model observed, included, successful, confirmed, and finalized states separately. Test reorganization and halt paths, ensure irreversible downstream release waits for the declared condition, and reconcile any derived claim when source history changes. Record whether the policy comes from protocol finality or an application-specific confirmation heuristic.
Common misunderstandings
Section titled “Common misunderstandings”- “Included means settled.” Inclusion is only one lifecycle step.
- “More confirmations always mean finality.” The meaning of confirmations depends on the consensus model.
- “Finality eliminates all reversal.” Protocol recovery, software faults, governance, and off-chain enforcement remain distinct boundaries.
Prerequisites and learn next
Section titled “Prerequisites and learn next”Read blockchain and transactions and gas. Continue to bridges to see why two finality systems must be reconciled explicitly.
Sources
Section titled “Sources”- Ethereum.org, Proof-of-stake consensus — Ethereum-specific attestation and finality behavior (accessed 2026-08-09).
- Ethereum.org, Transactions — Ethereum transaction inclusion and execution context (accessed 2026-08-09).
- The supplied DeFi seed, sections 10, 12, and 14 — dependency, loss, and bridge-learning questions.
Machine-readable model
Key equations
Canonical expressions come from the structured concept record. KaTeX renders the notation, while the plain-text expression and variable table keep its meaning and units inspectable without JavaScript. Read the narrative above for the model's domain, assumptions, and rounding rules.
This concept does not require one canonical equation. Its mechanism and state transitions remain the authoritative explanation; do not invent a formula merely to make the topic look quantitative.
Assurance contract
Security properties
These structured statements define desired behavior. Their stable IDs can bind tests, invariants, specifications, audit findings, or proof results without turning descriptive review advice into an assurance claim.
Desired · not evaluated: No test, audit, or proof result is implied until scoped evidence is linked to this property.
Applications distinguish observed, included, successfully executed, confirmed, and finalized states
The confirmation rule is parameterized by the actual consensus model and value at risk
A reorganization cannot silently leave downstream accounting inconsistent with the canonical source state
Cross-system consumers delay irreversible release until their declared source-finality condition holds
Knowledge check
Quiz
Answer in your own words, then open the model answer.
Why might two applications wait different lengths of time?
Model answer
They may face different values at risk, downstream reversibility, consensus assumptions, and operational policies even when observing the same chain.