{"kind":"chain-guide","id":"MONAD-PARALLEL","name":"Parallel execution on Monad","searchAliases":["Parallel Execution"],"status":null,"chain":"monad","category":{"id":"infrastructure","name":"Infrastructure","description":"Foundational patterns enabling other standards"},"journeyStages":[{"id":"executing","name":"Executing Transactions","description":"Performing on-chain actions"},{"id":"status","name":"Status & Confirmation","description":"Waiting for and confirming outcomes"}],"uxImpact":"Monad executes transactions in parallel by default while preserving the serial semantics of a linearly ordered block. The execution system checks dependencies and merges state updates in block order, so parallel execution is not a user-controlled ordering feature. A feed's arrival order does not prove execution order, and network capacity does not promise a result or latency for one consumer.","officialUrl":"https://docs.monad.xyz/monad-arch/execution/parallel-execution","lastReviewed":"2026-09-21","lastUpdated":"2026-09-21","hasDetailedContent":true,"content":{"id":"MONAD-PARALLEL","sources":[{"label":"Monad architecture: parallel execution","url":"https://docs.monad.xyz/monad-arch/execution/parallel-execution","type":"official-doc"},{"label":"Monad for users: ordering and execution","url":"https://docs.monad.xyz/introduction/monad-for-users","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 architecture: block states","url":"https://docs.monad.xyz/monad-arch/consensus/block-states","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 executes transactions in parallel by default while preserving the serial semantics of a linearly ordered block. The execution system checks dependencies and merges state updates in block order, so parallel execution is not a user-controlled ordering feature. A feed's arrival order does not prove execution order, and network capacity does not promise a result or latency for one consumer.","designerTakeaways":["Use the canonical block number and transaction index for activity ordering. Do not use UI event arrival as proof of execution order.","Show execution outcome and block commitment separately. A Proposed-block result can be provisional even when execution has completed.","Describe throughput as network capacity or an observed metric with a source, network, and measurement basis. Do not turn it into a per-user transaction promise.","Use inline status and action continuity to reflect the chain's responsiveness, while keeping retry, revert, and reconciliation states available."],"chainContext":{"behavior":"Monad executes transactions in parallel optimistically by default, then checks dependencies and merges their state updates in the block's linear order. Wallets and ordinary transactions keep Ethereum-compatible serial semantics. Consuming Proposed speculative data or selecting safe and finalized commitments is an integration choice; it does not turn parallel execution on or off.","whenRelevant":["An activity feed or explorer must order entries by block number and transaction index even when events arrive out of order.","A product shows transaction outcome separately from inclusion and block commitment.","An indexer or real-time interface consumes Proposed data and needs block-id-based reconciliation.","A dashboard or performance explanation presents capacity or observed throughput with its measurement basis."],"pitfalls":["Treating parallel execution as a user-controlled race or ordering feature.","Using feed arrival order as execution or canonical block order.","Treating a Proposed result as settled history, or using a block number without a block id while the block is still proposed.","Presenting network capacity or observed throughput as an individual confirmation or latency promise."]},"prototypeFirst":[{"screen":"Commitment-aware transaction status","why":"Parallel execution changes how work is performed, while the product still needs clear inclusion, outcome, and finality states.","covers":["Submitted","Included","Execution outcome","Finalized"],"include":["Transaction hash","Block and transaction index","Execution success or revert","Commitment label","Retry and reconciliation path"]},{"screen":"Canonical activity feed ordering","why":"A stable feed should use block order and transaction index rather than whichever event arrived first at the client.","covers":["Same-block transactions","Stable order","Provisional updates"],"include":["Block grouping","Transaction index","Block id for proposed data","Reconciliation when commitment changes"]},{"screen":"Speculative data reconciliation","why":"Execution events can come from a proposed block before consensus makes that block canonical.","covers":["Proposed data","Voted or finalized update","Abandoned proposal"],"include":["Provisional badge","Commitment timeline","Block id","Clear replacement or removal state"]},{"screen":"Network metrics with evidence","why":"Performance context needs a measurement basis and network scope so users do not read it as a personal outcome promise.","covers":["Capacity metric","Observed metric","Measurement date"],"include":["Source link","Network label","Capacity or observed basis","Gas or transaction assumptions","No per-transaction promise"]}],"mentalModel":[{"label":"Parallel work","description":"Monad starts transactions in parallel and tracks the state each transaction read while executing."},{"label":"Serial block semantics","description":"A Monad block is a linearly ordered set of transactions, and the state updates are merged in that order so the result matches serial execution."},{"label":"Block order is not feed order","description":"The order in which a client receives execution events or indexer updates does not establish canonical execution order."},{"label":"Provisional versus canonical data","description":"A Proposed block can produce speculative execution data before it reaches a stronger commitment."},{"label":"Throughput is context","description":"A capacity or observed throughput metric describes a network measurement. It does not predict one user's confirmation time or transaction result."}],"statesToDesign":[{"state":"Submitted","trigger":"The application sends a signed transaction.","userNeed":"Know that the request was sent.","designResponse":"Show Submitted with the transaction hash. Do not imply that parallel execution has completed."},{"state":"Included","trigger":"A selected data source reports the transaction in an observed block.","userNeed":"Know where the transaction appears.","designResponse":"Show the block number, transaction index, and Proposed, Voted, or Finalized commitment."},{"state":"Execution outcome","trigger":"The execution client reports success, logs, or a revert.","userNeed":"Know what the transaction did.","designResponse":"Show the outcome separately from inclusion and commitment. Mark it provisional when the block is not Finalized."},{"state":"Finalized","trigger":"The containing block reaches the Finalized commitment level.","userNeed":"Know that consensus has finalized the block. This does not mean its execution output has reached Verified.","designResponse":"Show Finalized after the endpoint reports that commitment, and keep execution outcome and any later verification state separate."},{"state":"Feed reordered or reconciled","trigger":"Events arrive in a different order than the block's transaction indices or a proposed block changes commitment.","userNeed":"Understand why the feed changed.","designResponse":"Sort by canonical block and transaction index, track proposed data by block id, and explain reconciliation."},{"state":"Execution reverted","trigger":"The transaction is included but its requested execution returns a failure.","userNeed":"Know what can be fixed or retried.","designResponse":"Show the revert as an execution outcome and offer a safe next action."}],"designDecisions":[{"question":"Should the product explain parallel execution in the send flow?","recommendation":"Keep the main flow in ordinary transaction language. Put the execution model in technical help or advanced details.","rationale":"Users need an accurate status and outcome. They do not need to reason about worker scheduling."},{"question":"How should an activity feed choose order?","recommendation":"Use the block number and transaction index for canonical order. Use block id and commitment labels for proposed data.","rationale":"Parallel execution does not change the serial semantics of a Monad block, and event arrival can vary by data source."},{"question":"How should throughput appear in product copy?","recommendation":"Show capacity or observed metrics only with source, network, date, and measurement basis. Keep them separate from transaction confirmation copy.","rationale":"Network capacity is not a unilateral promise about one user's transaction."},{"question":"How long should a status view wait?","recommendation":"Choose the wait and recovery behavior from the product's commitment policy and endpoint evidence, not a fixed chain-wide timer.","rationale":"Execution, inclusion, RPC observation, and finality are different events."}],"problemsSolved":[{"problem":"A feed implies that event arrival is execution order","oldWay":"Transactions are sorted by the order that websocket or indexer events reach the client.","newWay":"The feed uses block order and transaction index, with commitment context for proposed data.","impact":"critical"},{"problem":"Users see a speculative result as settled history","oldWay":"Parallel execution is used as a reason to omit commitment and reconciliation states.","newWay":"The UI labels Proposed data, tracks it by block id, and updates or replaces it as the block reaches later commitment states or a competing proposal wins.","impact":"high"},{"problem":"Throughput marketing becomes a transaction promise","oldWay":"A network capacity number is shown beside a user's confirmation as if it predicts the result.","newWay":"Metrics show their source, scope, basis, and date, while transaction UI reports observed status.","impact":"high"},{"problem":"A parallel execution explanation makes the product sound like a race","oldWay":"Users are told that transactions compete or can reorder themselves.","newWay":"The product says that execution runs in parallel and results follow the block's linear order.","impact":"medium"}],"uxPatterns":[{"name":"Commitment-aware transaction status","description":"Show transaction outcome and canonical commitment separately from the execution mechanism.","mockup":"concept/tx-status","components":["TransactionStatus","BlockOrder","ExecutionOutcome","CommitmentBadge"],"userFlow":["Submit the transaction","Show Included with block and transaction index","Show the execution outcome","Show Finalized when the endpoint reports it"]},{"name":"Canonical activity feed","description":"Group and sort activity by canonical block order, while marking proposed entries as provisional.","components":["FeedList","BlockGroup","TransactionIndex","ProvisionalBadge"],"userFlow":["Receive transaction events","Group entries by block","Sort entries by transaction index","Update or remove provisional entries as commitment changes"]},{"name":"Evidence-backed network metrics","description":"Present capacity or observed throughput as network context with its basis and measurement scope.","components":["MetricCard","SourceLink","NetworkLabel","MeasurementNote"],"userFlow":["Open network information","Read the metric and its basis","Check network and measurement date","Return to the product flow without treating the metric as a transaction promise"]}],"uiComponents":[{"name":"ParallelStatusIndicator","description":"Shows ordinary transaction states while preserving commitment and execution context.","states":["submitted","included","receipt-success","receipt-reverted","finalized","provisional","failed"],"props":["transactionHash","blockNumber","transactionIndex","commitment"]},{"name":"CanonicalOrderLabel","description":"Shows the block and transaction index used to order an activity item.","states":["canonical","proposed","reconciled","abandoned"],"props":["blockNumber","blockId","transactionIndex","commitment"]},{"name":"NetworkMetricCard","description":"Shows a throughput or capacity metric with its source and measurement basis.","states":["capacity","observed","stale","unavailable"],"props":["value","basis","network","measuredAt","sourceUrl"]}],"antiPatterns":[{"pattern":"Use UI event arrival as transaction order","why":"Different feeds and clients can observe execution events at different times.","instead":"Sort canonical activity by block number and transaction index, and track proposed data by block id.","severity":"critical"},{"pattern":"Describe parallel execution as a transaction race","why":"Monad preserves a linearly ordered block and serial state semantics.","instead":"Explain parallel work and ordered state updates when technical detail is needed.","severity":"high"},{"pattern":"Show network throughput as a confirmation promise","why":"Capacity or observed throughput does not predict one consumer's execution, endpoint observation, or finality.","instead":"Show the metric with source, basis, network, and date, then report transaction evidence separately.","severity":"critical"},{"pattern":"Hide commitment because execution is fast","why":"A Proposed-block execution result can be provisional.","instead":"Show execution outcome and commitment as separate states with reconciliation.","severity":"high"},{"pattern":"Use a fixed timer as the only recovery rule","why":"RPC observation and commitment can vary by endpoint and network conditions.","instead":"Use evidence-backed status, refresh, retry, and support paths.","severity":"medium"}],"vocabulary":[{"use":"Canonical order","avoid":"Arrival order","why":"Client event timing does not establish block order."},{"use":"Execution outcome","avoid":"Parallel confirmed","why":"The user needs the transaction result, not an implementation label."},{"use":"Included","avoid":"Won the race","why":"Monad blocks have a linear transaction order."},{"use":"Provisional","avoid":"Settled","why":"Proposed-block data can change before a stronger commitment."},{"use":"Network capacity","avoid":"Your transaction will confirm at this rate","why":"A network metric is not a per-transaction promise."}],"onMonad":[{"aspect":"Execution semantics","ethereum":"Transactions are commonly described as executing serially in block order.","monad":"Transactions execute in parallel, then their state updates are checked and merged in the block's linear order.","designImplication":"Keep ordinary serial transaction language in user flows and reserve parallel detail for technical context."},{"aspect":"Activity ordering","ethereum":"Block number and transaction index provide canonical order.","monad":"The same canonical fields provide order even when execution events arrive at different times.","designImplication":"Sort by block and transaction index, not by UI event arrival."},{"aspect":"Real-time data","ethereum":"A feed may focus on canonical results.","monad":"Real-time feeds can expose execution from Proposed blocks and later commitment updates.","designImplication":"Mark provisional data and reconcile it by block id."},{"aspect":"Performance metrics","ethereum":"Throughput and latency vary with network load and transaction work.","monad":"Monad publishes capacity and observed performance context, but transaction UX still depends on the endpoint and transaction.","designImplication":"Keep network metrics separate from individual confirmation copy."}],"keyTakeaways":["Parallel execution preserves the serial semantics of a linearly ordered block.","Sort activity by block number and transaction index, not by feed arrival.","Separate Included, execution outcome, and Finalized.","Label Proposed-block data as provisional and reconcile it.","Treat throughput as sourced network context, not a consumer promise."],"technicalNotes":"Monad's parallel execution starts transactions concurrently, tracks the inputs each transaction used, and re-executes when a dependency check detects a mismatch. State updates are merged in the original block order, so the result matches serial execution. Monad blocks remain linearly ordered. The real-time data documentation warns that execution events from Proposed blocks may later be abandoned, so feeds need block ids, commitment labels, and reconciliation. Throughput metrics describe network capacity or observations and should not become per-transaction latency promises.","relatedStandards":[{"id":"MONAD-ASYNC","relationship":"Asynchronous staging can expose execution data before the containing block reaches Finalized."},{"id":"MONAD-FINALITY","relationship":"Finality and commitment determine when a parallel execution result is canonical for product purposes."}]},"sources":[{"label":"Official documentation","url":"https://docs.monad.xyz/monad-arch/execution/parallel-execution","type":"official-doc"},{"label":"Monad for users: ordering and execution","url":"https://docs.monad.xyz/introduction/monad-for-users","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 architecture: block states","url":"https://docs.monad.xyz/monad-arch/consensus/block-states","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-PARALLEL","markdown":"https://www.eipsfordesigners.com/standards/MONAD-PARALLEL/content.md","agent":"https://www.eipsfordesigners.com/standards/MONAD-PARALLEL/agent.md","api":"https://www.eipsfordesigners.com/api/standards/MONAD-PARALLEL","official":"https://docs.monad.xyz/monad-arch/execution/parallel-execution"},"freshness":{"lastReviewed":"2026-09-21","lastUpdated":"2026-09-21"}}