{"kind":"chain-guide","id":"MONAD-ASYNC","name":"Asynchronous execution on Monad","searchAliases":["Asynchronous Execution"],"status":null,"chain":"monad","category":{"id":"infrastructure","name":"Infrastructure","description":"Foundational patterns enabling other standards"},"journeyStages":[{"id":"status","name":"Status & Confirmation","description":"Waiting for and confirming outcomes"}],"uxImpact":"Monad's asynchronous execution is a protocol-level separation between consensus and execution. Consensus can agree on the ordered transactions without executing them first, while execution runs in a separate, slightly lagged lane. Nodes may speculatively execute a Proposed block before it finalizes, but consuming that data is optional, so a receipt or execution outcome and finality are separate product states.","officialUrl":"https://docs.monad.xyz/monad-arch/consensus/asynchronous-execution","lastReviewed":"2026-09-21","lastUpdated":"2026-09-21","hasDetailedContent":true,"content":{"id":"MONAD-ASYNC","specConstraints":[{"id":"newly-funded-account-readiness","constraint":"A newly funded account that previously had zero balance needs the funding transfer to reach the consensus balance view before sending.","appliesTo":"application","normativity":"normative","specQuote":"Because consensus runs slightly ahead of execution, newly-funded accounts which previously had zero balance cannot send transactions until the transfer that credits them with tokens is `D` blocks old.\n\nIn practice, this means that if you send tokens from account `A` into an account `B` (which has 0 balance), then you should wait until seeing the transaction receipt (indicative that that block has reached [`Proposed`](/monad-arch/consensus/block-states#proposed) state), and then wait another 1.2 seconds.","specSection":"Finer details / Transactions from newly-funded accounts","specUrl":"https://docs.monad.xyz/monad-arch/consensus/asynchronous-execution#transactions-from-newly-funded-accounts","designImplication":"Distinguish a received funding receipt from readiness for the next transaction. Follow the network's current block/state guidance and retry handling; the snapshot's timing guidance is not a guaranteed wallet-to-wallet completion time."}],"sources":[{"label":"Monad architecture: asynchronous execution","url":"https://docs.monad.xyz/monad-arch/consensus/asynchronous-execution","type":"official-doc"},{"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 developer changelog","url":"https://docs.monad.xyz/developer-essentials/changelog","type":"official-doc"}],"lastReviewed":"2026-09-21","lastUpdated":"2026-09-21","summary":"Monad's asynchronous execution is a protocol-level separation between consensus and execution. Consensus can agree on the ordered transactions without executing them first, while execution runs in a separate, slightly lagged lane. Nodes may speculatively execute a Proposed block before it finalizes, but consuming that data is optional, so a receipt or execution outcome and finality are separate product states.","designerTakeaways":["Separate Submitted, Included, the execution receipt or outcome, and Finalized. These states answer different questions.","If a data source reports a proposed block, label the result as speculative or provisional and reconcile it when the block's commitment changes.","Use the endpoint's commitment labels instead of a fixed confirmation timer. Network, node, and data-source conditions affect when each state becomes visible.","Keep an explicit recovery path for a proposed block or execution result that does not progress to the commitment level the product requires.","Treat eth_call and eth_estimateGas results against speculative state as simulations, not guarantees of inclusion, execution success, finality, or verification."],"chainContext":{"behavior":"Monad decouples consensus and execution by default. Consensus determines the official transaction order without first calculating the resulting state, while execution runs in a separate, slightly lagged lane. Nodes can execute a Proposed block speculatively, but consuming Proposed execution data, using safe or finalized RPC commitments, and gating product actions on those states are integration choices.","whenRelevant":["A transaction interface needs to show execution outcome separately from inclusion and block commitment.","A real-time feed or indexer consumes Proposed execution data and must reconcile it when a block progresses or loses to another proposal.","A product uses a commitment threshold to enable a follow-up action.","A simulator or gas estimator reads a speculative state and needs to explain what that result does and does not establish."],"pitfalls":["Treating asynchronous execution as an application feature that must be enabled, or as automatic finality.","Treating a receipt, revert, or speculative simulation as proof that a block is Finalized or Verified.","Assuming a Proposed or Voted block is already on the canonical blockchain.","Assuming a failed proposal emits an explicit abandonment event; a competing block at the same height can implicitly replace it."]},"prototypeFirst":[{"screen":"Commitment-aware transaction status","why":"Asynchronous execution makes execution evidence and consensus commitment observable at different points.","covers":["Submitted","Included","Execution receipt or outcome","Finalized","Verified when needed"],"include":["Transaction hash","Block and commitment label","Success or revert outcome","Provisional label for speculative data","Finality confirmation and recovery path"]},{"screen":"Speculative activity feed","why":"Fast data can arrive from execution of a proposed block that may not become canonical.","covers":["Proposed data","Commitment update","Reconciliation"],"include":["Provisional badge","Block id and block number","Update when the block is Voted or Finalized","Clear handling for an abandoned proposal"]},{"screen":"High-assurance action gate","why":"Some actions need a stronger commitment than an execution result from a proposed block.","covers":["Low-risk early update","Finality-gated action","Failure recovery"],"include":["Product-defined commitment threshold","A reason for waiting","Reconciliation if the proposal changes","Retry or support path"]}],"mentalModel":[{"label":"Consensus determines order","description":"Monad consensus agrees on the official ordering of transactions without first executing them to calculate the resulting state."},{"label":"Execution runs in a separate lane","description":"Execution follows consensus in a slightly lagged lane, which gives nodes more time to execute a block."},{"label":"Proposed data can be speculative","description":"A node may execute a proposed block before it knows that the block will finalize. Data from that execution may later be abandoned."},{"label":"Outcome is not commitment","description":"A receipt or execution result reports what the node observed for a block. It does not by itself say that the block is Finalized."},{"label":"Commitment levels are explicit","description":"Monad maps latest to Proposed, safe to Voted, and finalized to Finalized. Verified describes later delayed state-root agreement."}],"statesToDesign":[{"state":"Submitted","trigger":"The application sends a signed transaction to an RPC endpoint.","userNeed":"Know that the request was sent and can be tracked.","designResponse":"Show Submitted with the hash. Do not imply that a block contains it."},{"state":"Included","trigger":"The selected data source reports the transaction in an observed block.","userNeed":"Know that the transaction appears in a block candidate or committed block.","designResponse":"Show Included with the block's Proposed, Voted, or Finalized commitment label. Mark Proposed data as provisional."},{"state":"Execution receipt or outcome","trigger":"The execution client reports a receipt, logs, or a success or revert outcome.","userNeed":"Know what the transaction did according to the observed execution.","designResponse":"Show success or revert separately from the block commitment. Explain when the result is speculative."},{"state":"Finalized","trigger":"The containing block reaches the Finalized commitment level.","userNeed":"Know that the block is part of the canonical chain under MonadBFT.","designResponse":"Show Finalized after the RPC or data source reports the finalized state. Keep execution outcome and Verified state separate."},{"state":"Verified","trigger":"A later block carries the delayed Merkle root that verifies prior execution output.","userNeed":"Know that a higher-assurance execution state has been verified when the product needs it.","designResponse":"Use Verified only for products that consume this distinction. Do not merge it with Finalized."},{"state":"Proposal abandoned or outcome changed","trigger":"A competing block at the same height 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 the UI by block id, mark the provisional result as abandoned, and offer the next safe action."}],"designDecisions":[{"question":"Should the product show an execution result before finality?","recommendation":"Show it only when the data source and product risk policy support provisional results, and label the commitment clearly.","rationale":"Monad can execute a proposed block before consensus finalizes it."},{"question":"What does the success checkmark mean?","recommendation":"Define whether it means an execution outcome, block inclusion, or Finalized commitment, then label the state in the UI.","rationale":"Users need to know whether the UI is reporting what ran, what was included, or what is canonical."},{"question":"When should a follow-up action be enabled?","recommendation":"Choose a commitment threshold per action. Allow reversible early updates only when the product can reconcile them.","rationale":"A trade, transfer, game move, or administrative action can have different consequences if a proposal is abandoned."}],"problemsSolved":[{"problem":"The UI treats a receipt as finality","oldWay":"Execution result and final confirmation use one status.","newWay":"The UI separates inclusion, receipt or outcome, and Finalized commitment.","impact":"critical"},{"problem":"Speculative data looks canonical","oldWay":"A proposed block updates balances and activity without a provisional label.","newWay":"The UI shows the block commitment and reconciles data when the proposal progresses or is abandoned.","impact":"high"},{"problem":"A fixed timing promise hides endpoint and network variation","oldWay":"Every transaction is presented as reaching the same state after a fixed delay.","newWay":"The UI reports the observed state instead of completing on a timer, and keeps a recovery path for delays or replacement proposals.","impact":"high"},{"problem":"Users cannot tell what a fast success indicator means","oldWay":"Confirming and confirmed describe several protocol events at once.","newWay":"The product names Submitted, Included, execution outcome, Finalized, and Verified where needed.","impact":"medium"}],"uxPatterns":[{"name":"Commitment-aware transaction status","description":"Show the transaction path and the strongest commitment that the selected endpoint has reported.","mockup":"concept/tx-status","components":["TransactionStatus","CommitmentBadge","ExecutionOutcome","RecoveryAction"],"userFlow":["Submit the transaction","Show Submitted","Show Included with the observed block state","Show the receipt or execution outcome","Show Finalized when the endpoint reports it"]},{"name":"Speculative feed reconciliation","description":"Let a real-time feed show early execution while making provisional status and later reconciliation explicit.","components":["ProvisionalBadge","BlockId","CommitmentTimeline","ReconciliationNotice"],"userFlow":["Receive data from a Proposed block","Mark it as provisional","Update the commitment label when consensus progresses","Reconcile or remove data if the proposal is abandoned"]}],"uiComponents":[{"name":"AsyncStatusIndicator","description":"Shows transaction execution evidence and block commitment separately.","states":["submitted","included","receipt-success","receipt-reverted","finalized","verified","failed"],"props":["currentState","commitment","isSpeculative","transactionHash"]},{"name":"CommitmentTimeline","description":"Shows Proposed, Voted, Finalized, and Verified as distinct block commitments.","states":["proposed","voted","finalized","verified","abandoned"],"props":["blockId","commitment","observedAt"]},{"name":"SpeculativeDataBadge","description":"Marks data that comes from a block before the product's chosen commitment threshold.","states":["hidden","provisional","reconciled","abandoned"],"props":["commitment","message","onReconcile"]}],"antiPatterns":[{"pattern":"Describe asynchronous execution as automatic finality","why":"The architecture separates consensus and execution, but endpoint timing and commitment still vary.","instead":"Report the observed state and choose a product-specific commitment threshold.","severity":"high"},{"pattern":"Treat a speculative receipt as finalized","why":"Execution can run for a Proposed block that later fails to become canonical.","instead":"Label speculative data and reconcile it when the block's commitment changes.","severity":"critical"},{"pattern":"Use one Confirmed label for receipt, inclusion, and finality","why":"Those states carry different assurance and product consequences.","instead":"Name Submitted, Included, execution outcome, Finalized, and Verified separately where they matter.","severity":"high"},{"pattern":"Disable recovery because a proposed result looks successful","why":"A proposal can be abandoned and a provisional state can change.","instead":"Keep reconciliation, retry, and support paths for actions that depend on stronger commitment.","severity":"medium"},{"pattern":"Treat speculative simulation as a guarantee","why":"eth_call and eth_estimateGas can run against a speculative state that may not become canonical.","instead":"Label the state used for simulation and keep inclusion, execution outcome, commitment, and verification as separate evidence.","severity":"high"}],"vocabulary":[{"use":"Submitted","avoid":"Executing","why":"A submitted transaction may not yet appear in an observed block."},{"use":"Included in a proposed block","avoid":"Finalized","why":"A Proposed block has not yet become canonical."},{"use":"Execution succeeded","avoid":"Transaction is final","why":"A receipt reports execution outcome, while finality is a separate block commitment."},{"use":"Finalized","avoid":"Confirmed immediately","why":"The product should report the commitment level it observed rather than promise a universal slot count."},{"use":"Provisional","avoid":"Permanent result","why":"Speculative execution can produce data before the block's final commitment."}],"onMonad":[{"aspect":"Consensus and execution","ethereum":"Consensus and execution are commonly interleaved in the block production path.","monad":"Consensus can determine transaction order without first executing the transactions, while execution runs in a separate lagged lane.","designImplication":"Explain state and commitment separately instead of presenting one confirmation phase."},{"aspect":"Execution data","ethereum":"Products often wait for a block result before showing execution data.","monad":"Real-time feeds can expose execution data from a Proposed block before it is known to be canonical.","designImplication":"Mark early data as provisional and reconcile by block id and commitment state."},{"aspect":"Commitment labels","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, with Verified as a later delayed-root state.","designImplication":"Use the commitment label that matches the product's assurance requirement."}],"keyTakeaways":["Consensus determines order without requiring execution first.","Execution can run speculatively for a Proposed block.","Separate Submitted, Included, the execution receipt or outcome, and Finalized.","Label provisional real-time data and reconcile it by block id.","Use commitment evidence instead of a fixed latency promise."],"technicalNotes":"Monad's asynchronous execution moves execution out of the consensus hot path. Consensus agrees on an ordered transaction list, and nodes execute the block in a separate, slightly lagged lane. A node may speculatively execute a Proposed block before it knows whether the block will finalize. The same speculative state can be used by eth_call or eth_estimateGas, so those results can be more current without proving inclusion, execution success, finality, or Verified state. Monad's block-state documentation maps latest to Proposed, safe to Voted, and finalized to Finalized; Verified is a later state-root check based on the delayed Merkle root. A receipt or execution result therefore needs a separate commitment label.","relatedStandards":[{"id":"MONAD-FINALITY","relationship":"Async execution explains why receipt, commitment, finality, and verification need separate UX states."},{"id":"MONAD-PARALLEL","relationship":"Async staging and parallel execution are separate architecture changes that can both affect data timing."}]},"sources":[{"label":"Official documentation","url":"https://docs.monad.xyz/monad-arch/consensus/asynchronous-execution","type":"official-doc"},{"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 developer changelog","url":"https://docs.monad.xyz/developer-essentials/changelog","type":"official-doc"}],"urls":{"canonical":"https://www.eipsfordesigners.com/standards/MONAD-ASYNC","markdown":"https://www.eipsfordesigners.com/standards/MONAD-ASYNC/content.md","agent":"https://www.eipsfordesigners.com/standards/MONAD-ASYNC/agent.md","api":"https://www.eipsfordesigners.com/api/standards/MONAD-ASYNC","official":"https://docs.monad.xyz/monad-arch/consensus/asynchronous-execution"},"freshness":{"lastReviewed":"2026-09-21","lastUpdated":"2026-09-21"}}