{"kind":"chain-guide","id":"MONAD-FINALITY","name":"Transaction confirmation on Monad","searchAliases":["Sub-second Finality and Block Commitments"],"status":null,"chain":"monad","category":{"id":"comprehension","name":"Comprehension & Display","description":"Making blockchain data readable to humans"},"journeyStages":[{"id":"status","name":"Status & Confirmation","description":"Waiting for and confirming outcomes"}],"uxImpact":"Current Monad documentation lists 300 ms blocks and a 600 ms full-finality protocol figure. Those figures describe block production and consensus, not end-to-end wallet or application completion. Show completion from the observed execution outcome and required block commitment; a speculative receipt can precede Finalized, while Verified is a later agreement on execution output.","officialUrl":"https://docs.monad.xyz/monad-arch/consensus/block-states","lastReviewed":"2026-09-21","lastUpdated":"2026-09-21","hasDetailedContent":true,"content":{"id":"MONAD-FINALITY","sources":[{"label":"Monad architecture: block states","url":"https://docs.monad.xyz/monad-arch/consensus/block-states","type":"official-doc"},{"label":"Monad architecture: speculative real-time data","url":"https://docs.monad.xyz/monad-arch/realtime-data/spec-realtime","type":"official-doc"},{"label":"Monad performance and commitment context","url":"https://docs.monad.xyz/introduction/why-monad","type":"official-doc"},{"label":"Monad developer changelog","url":"https://docs.monad.xyz/developer-essentials/changelog","type":"official-doc"}],"lastReviewed":"2026-09-21","lastUpdated":"2026-09-21","summary":"Current Monad documentation lists 300 ms blocks and a 600 ms full-finality protocol figure. Those figures describe block production and consensus, not end-to-end wallet or application completion. Show completion from the observed execution outcome and required block commitment; a speculative receipt can precede Finalized, while Verified is a later agreement on execution output.","designerTakeaways":["Use inline progress and continuity between actions. Monad's sub-second protocol figures can reduce waiting without removing delayed or failed transaction states.","Separate Submitted, Included, the execution receipt or outcome, and Finalized. Each state answers a different question.","Use latest, safe, and finalized RPC commitments deliberately. Monad maps them to Proposed, Voted, and Finalized block states.","If a real-time feed exposes a Proposed block, label the result as provisional and reconcile it when the block progresses or is abandoned.","Choose a commitment threshold per action. A low-risk inline update and a high-assurance transfer can need different evidence."],"chainContext":{"behavior":"Finality is part of Monad's consensus, not a feature an application enables. Your product chooses which block commitment to read and when that evidence is sufficient for a follow-up action. An execution result, a Finalized block, and Verified execution output answer different questions.","whenRelevant":["A transaction interface needs to distinguish submission, inclusion, execution outcome, and block commitment.","A product gates a follow-up action on a commitment level that matches its risk.","An explorer, indexer, or activity feed exposes Proposed data and must reconcile it by block id.","Product copy or a dashboard presents Monad timing or throughput figures with their basis and network scope."],"pitfalls":["Treating the 600 ms protocol figure as end-to-end wallet or application latency, or showing success from a timer.","Treating a receipt or execution success as Finalized, or treating Finalized as the same as Verified.","Treating Voted or latest/Proposed data as canonical history; Voted is not yet on the blockchain.","Using only a block number to identify a Proposed block, or applying mainnet timing figures to every Monad network."]},"prototypeFirst":[{"screen":"Commitment-aware transaction status","why":"A clear status model prevents a receipt and finality from collapsing into one ambiguous checkmark.","covers":["Submitted","Included","Execution receipt or outcome","Finalized"],"include":["Transaction hash","Block id or number","Commitment label","Success or revert outcome","Refresh and recovery path"]},{"screen":"Inline execution result with later finality","why":"The interface can show useful execution evidence before the product's finality threshold is met.","covers":["Provisional result","Finalized result","Changed or abandoned proposal"],"include":["Provisional badge","What the receipt means","A later Finalized update","Reconciliation when the proposal changes"]},{"screen":"High-assurance action gate","why":"Some actions should wait for a stronger commitment than an observed execution result.","covers":["Product commitment policy","Wait state","Finalized action"],"include":["Plain-language reason for waiting","Current commitment level","Retry or support path","No fixed timing promise"]},{"screen":"Activity feed with commitment context","why":"A feed can update early, but users need to know which entries are provisional and which are canonical.","covers":["Proposed data","Voted data","Finalized data","Verified data when needed"],"include":["Commitment filter or badge","Block id for provisional entries","Reconciliation notice","Finalized history"]}],"mentalModel":[{"label":"Submitted","description":"An endpoint received a signed transaction and can track its hash. Submission does not prove inclusion."},{"label":"Included","description":"A data source reports the transaction in an observed block. The block may still be Proposed or Voted."},{"label":"Execution outcome","description":"A receipt or execution event reports success, logs, or a revert for the observed block."},{"label":"Finalized","description":"The block is canonical under Monad's consensus rules. Current documentation lists two 300 ms slots, or 600 ms, as the full-finality protocol figure; the endpoint must report the actual commitment."},{"label":"Verified","description":"A later block carries a delayed Merkle root that verifies earlier execution output. This is distinct from Finalized."}],"statesToDesign":[{"state":"Submitted","trigger":"The application sends a signed transaction to an RPC endpoint.","userNeed":"Know that the request was sent.","designResponse":"Show Submitted with the hash and a way to track it. Do not show a final success state."},{"state":"Included","trigger":"The selected RPC or data source reports the transaction in a block.","userNeed":"Know that the transaction appears in an observed block.","designResponse":"Show Included with Proposed, Voted, or Finalized commitment context."},{"state":"Execution receipt or outcome","trigger":"The execution client reports the receipt, logs, success, or revert.","userNeed":"Know what the transaction did.","designResponse":"Show the outcome separately from block commitment, and label it provisional when the block is not Finalized."},{"state":"Finalized","trigger":"The containing block reaches the Finalized commitment level.","userNeed":"Know that the block is canonical under the network's finality rules.","designResponse":"Show Finalized only after the selected endpoint reports that commitment. Keep execution outcome and Verified state separate."},{"state":"Verified","trigger":"A later block verifies the prior execution output through the delayed Merkle root.","userNeed":"Know that the execution state has reached the stronger verification state when the product needs it.","designResponse":"Use Verified as an advanced state. Do not use it as a synonym for Finalized."},{"state":"Not finalized or proposal changed","trigger":"A competing proposal at the same block number is selected or finalized, implicitly abandoning the earlier proposal; no explicit abandonment event may be emitted.","userNeed":"Understand why a provisional result changed.","designResponse":"Reconcile by block id, explain the commitment change, and offer a safe next action."}],"designDecisions":[{"question":"What should the success checkmark mean?","recommendation":"Name whether it means execution succeeded, the transaction was included, or the block is Finalized.","rationale":"The user can make a different decision based on each level of evidence."},{"question":"When should balances update?","recommendation":"Use provisional updates only when the product can reconcile them. Mark a balance as settled after the product's chosen commitment threshold.","rationale":"Real-time data can come from a Proposed block that does not become canonical."},{"question":"Which commitment should gate a follow-up action?","recommendation":"Set the threshold by action risk and disclose it in the flow.","rationale":"A reversible interaction can tolerate earlier evidence than an irreversible transfer or administrative change."}],"problemsSolved":[{"problem":"Users cannot tell whether a checkmark means a receipt or finality","oldWay":"One Confirmed state covers submission, inclusion, execution, and finality.","newWay":"The UI labels Submitted, Included, execution outcome, and Finalized separately.","impact":"critical"},{"problem":"Speculative activity looks like canonical history","oldWay":"A real-time feed updates balances without showing block commitment.","newWay":"The feed shows Proposed, Voted, Finalized, or Verified context and reconciles by block id.","impact":"high"},{"problem":"Fixed timing copy hides real network and endpoint conditions","oldWay":"Every transaction is promised the same confirmation duration.","newWay":"The product reports observed commitment and keeps a recovery path for delays or changed proposals.","impact":"high"},{"problem":"High-assurance actions use the same gate as casual updates","oldWay":"Every follow-up action starts after an early execution result.","newWay":"Each flow chooses and explains its commitment threshold.","impact":"medium"}],"uxPatterns":[{"name":"Commitment-aware confirmation","description":"Show execution outcome and block commitment as separate pieces of evidence.","mockup":"concept/tx-status","components":["TransactionStatus","CommitmentBadge","ExecutionOutcome","FinalityGate"],"userFlow":["Submit the transaction","Show Submitted","Show Included with commitment context","Show the receipt or execution outcome","Show Finalized when the endpoint reports it"]},{"name":"Provisional update with reconciliation","description":"Use early execution data while making its provisional status and later correction path visible.","components":["ProvisionalBadge","BlockId","CommitmentTimeline","ReconciliationNotice"],"userFlow":["Receive execution data from a Proposed block","Mark the data as provisional","Update when the block becomes Voted or Finalized","Explain and repair the view if the proposal is abandoned"]},{"name":"Finality-gated action","description":"Hold a high-assurance follow-up action until the chosen commitment level is reported.","components":["CommitmentRequirement","WaitStatus","FinalizedAction","RecoveryAction"],"userFlow":["Show the commitment required by the action","Track the transaction by hash","Show the receipt or outcome","Enable the follow-up after the threshold is met"]}],"uiComponents":[{"name":"TransactionCommitmentStatus","description":"Shows submission, inclusion, execution outcome, and block commitment as separate states.","states":["submitted","included","receipt-success","receipt-reverted","finalized","verified","not-finalized"],"props":["transactionHash","commitment","isSpeculative","requiredCommitment"]},{"name":"CommitmentBadge","description":"Labels the block state attached to a receipt or activity item.","states":["proposed","voted","finalized","verified","abandoned"],"props":["commitment","blockId","helpText"]},{"name":"FinalityGate","description":"Explains and enforces the commitment threshold required for a follow-up action.","states":["waiting","ready","changed","failed"],"props":["requiredCommitment","currentCommitment","onReady"]}],"antiPatterns":[{"pattern":"Treat 600 ms consensus finality as a timer for user-visible success","why":"Wallet approval, submission, network conditions, and RPC delivery affect when a user sees completion.","instead":"Explain sub-second consensus finality as a network capability, then show success from the observed outcome and required commitment.","severity":"critical"},{"pattern":"Show Finalized after a receipt arrives","why":"A receipt can describe execution in a Proposed or Voted block.","instead":"Show the receipt outcome and Finalized as separate states.","severity":"critical"},{"pattern":"Treat latest as canonical history","why":"Monad maps latest to Proposed, and Proposed data may not become part of the canonical chain.","instead":"Use safe or finalized commitments when the product requires stronger assurance.","severity":"high"},{"pattern":"Remove reconciliation from a real-time feed","why":"Speculative execution can expose a proposal that later changes or is abandoned.","instead":"Track block ids and update the UI when commitment changes.","severity":"high"},{"pattern":"Use a full-page wait for every transaction","why":"A product can often show the receipt while it waits for a stronger commitment, but the correct state still needs to remain visible.","instead":"Use inline status with a clear commitment label and an action-specific gate.","severity":"medium"}],"vocabulary":[{"use":"Submitted","avoid":"Confirmed","why":"Submission says that the endpoint received the transaction, not that it was included or finalized."},{"use":"Included in a Proposed block","avoid":"Canonical","why":"A Proposed block has not yet reached the Finalized commitment."},{"use":"Execution succeeded","avoid":"Finalized","why":"A receipt outcome and block finality are separate facts."},{"use":"Finalized","avoid":"Finalized in one step","why":"The product should report the commitment it observed rather than promise a universal timing path."},{"use":"Provisional","avoid":"Permanent","why":"Speculative data can change until the containing block reaches the chosen commitment."}],"onMonad":[{"aspect":"Commitment mapping","ethereum":"Ethereum-compatible JSON-RPC APIs define latest, safe, and finalized commitment tags.","monad":"Monad maps latest to Proposed, safe to Voted, and finalized to Finalized. Verified is a later delayed-root state.","designImplication":"Use the commitment label that matches the action's assurance requirement."},{"aspect":"Receipt and finality","ethereum":"Products often wait for a block result before showing execution outcome.","monad":"Execution data can arrive from a Proposed block before the block is known to be canonical.","designImplication":"Show receipt outcome and Finalized as separate states, with a provisional label when needed."},{"aspect":"Real-time data","ethereum":"Polling and subscriptions commonly focus on canonical block results.","monad":"Real-time feeds can expose speculative execution and later commitment updates.","designImplication":"Track block id and reconcile provisional data when commitment changes."}],"keyTakeaways":["Current Monad documentation lists 300 ms blocks and a 600 ms full-finality protocol figure.","Separate Submitted, Included, the execution receipt or outcome, and Finalized.","Latest, safe, and finalized map to different Monad block commitments.","A Proposed-block receipt can be useful and still be provisional.","Use Verified only when the product needs the delayed-root distinction.","Treat timing figures as network context, not per-transaction promises."],"technicalNotes":"Current performance documentation lists 300 ms mainnet block time, speculative finality after one slot, and full consensus finality after two slots (600 ms). These figures describe network consensus, not the complete wallet-to-app interaction, and network schedules can differ. Monad documents four block states: Proposed, Voted, Finalized, and Verified. Latest maps to Proposed, safe maps to Voted, and finalized maps to Finalized in the JSON-RPC interface. Because execution can run speculatively for a Proposed block, receipts and execution events can precede Finalized. Verified is later, when a delayed Merkle root confirms prior execution output. Choose the commitment level per product action and expose enough context for users to understand it.","relatedStandards":[{"id":"MONAD-ASYNC","relationship":"Asynchronous execution explains why execution outcome and block finality can appear at different times."},{"id":"MONAD-PARALLEL","relationship":"Parallel execution affects how work is performed, while block commitment determines what the product can treat as canonical."}]},"sources":[{"label":"Official documentation","url":"https://docs.monad.xyz/monad-arch/consensus/block-states","type":"official-doc"},{"label":"Monad architecture: speculative real-time data","url":"https://docs.monad.xyz/monad-arch/realtime-data/spec-realtime","type":"official-doc"},{"label":"Monad performance and commitment context","url":"https://docs.monad.xyz/introduction/why-monad","type":"official-doc"},{"label":"Monad developer changelog","url":"https://docs.monad.xyz/developer-essentials/changelog","type":"official-doc"}],"urls":{"canonical":"https://www.eipsfordesigners.com/standards/MONAD-FINALITY","markdown":"https://www.eipsfordesigners.com/standards/MONAD-FINALITY/content.md","agent":"https://www.eipsfordesigners.com/standards/MONAD-FINALITY/agent.md","api":"https://www.eipsfordesigners.com/api/standards/MONAD-FINALITY","official":"https://docs.monad.xyz/monad-arch/consensus/block-states"},"freshness":{"lastReviewed":"2026-09-21","lastUpdated":"2026-09-21"}}