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
- Actor Transaction parties
- Actor Validator or consensus participant
- Actor Application choosing a confirmation policy
- Actor Bridge, 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.
- Asset Assets transferred or locked by the accepted state change
- Asset Assets 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.
- Claim Finalized balance or contract-state entitlement
- Claim Receipt 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.
Recognized examples
Section titled “Recognized examples”Ranking basis. Educational order by historical influence, ecosystem visibility, and model contrast—not safety, decentralization, volume, TVL, or investment merit.
| Rank | Example | Best for understanding |
|---|---|---|
| 1 | Ethereum proof of stake | Justification and checkpoint finality |
| 2 | Bitcoin | Probabilistic confirmation confidence |
| 3 | Solana | Processed, confirmed, and finalized commitments |
| 4 | CometBFT | BFT rounds and deterministic commits |
Sources and scope. Primary documentation was reviewed 2026-09-02. These named models do not define every chain, rollup, validator set, or application confirmation policy. Protocol marks are shown for recognition only, not endorsement.
Common questions
Section titled “Common questions”Is a successful transaction already final?
Section titled “Is a successful transaction already final?”Not necessarily. Success means the candidate state transition executed without the recorded error. The containing block can still lack the protocol or application-specific finality condition required by a dependent system.
How many confirmations are enough?
Section titled “How many confirmations are enough?”There is no universal number. The answer depends on the consensus model, value at risk, reorganization or fault assumptions, downstream reversibility, and the application’s declared policy.
Does atomic DEX settlement mean instant finality?
Section titled “Does atomic DEX settlement mean instant finality?”No. Atomicity means the trade’s component state changes succeed together or revert together in the chosen execution context. Finality asks when that whole accepted history is safe for another system to rely on.
Who loses when an application credits value too early?
Section titled “Who loses when an application credits value too early?”The loss reaches whoever cannot reverse or recover the downstream asset: an exchange, bridge, liquidity provider, reserve, insurer, or users holding an unbacked claim. The confirmation policy should identify that absorber before release.
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”The primary network references, review dates, and implementation boundaries are recorded with each item under Recognized examples. The supplied DeFi seed, sections 10, 12, and 14, additionally informed the dependency, loss-allocation, and bridge-learning questions; it is background material rather than current network evidence.
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.
Security properties
These are common security properties to consider when implementing or reviewing this concept. Stable IDs make each property easy to reference.
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.