{"kind":"chain-guide","id":"MONAD-MEMPOOL","name":"Transaction submission and mempools on Monad","searchAliases":["Local Validator Mempools"],"status":null,"chain":"monad","category":{"id":"transaction-friction","name":"Transaction Friction","description":"Reducing clicks, signatures, and mental overhead"},"journeyStages":[{"id":"executing","name":"Executing Transactions","description":"Performing on-chain actions"},{"id":"status","name":"Status & Confirmation","description":"Waiting for and confirming outcomes"}],"uxImpact":"Monad has no global mempool: an RPC owner node checks and forwards valid transactions to upcoming leaders, while validators keep local mempools and the owner tracks inclusion. This can reduce propagation overhead and time to inclusion, but transactions can still wait, be evicted, be included with a reverted execution, or face application-specific market and MEV risk. Monad does not provide a network-wide pending lookup through the documented `newPendingTransactions` subscription.","officialUrl":"https://docs.monad.xyz/monad-arch/consensus/local-mempool","lastReviewed":"2026-09-21","lastUpdated":"2026-09-21","hasDetailedContent":true,"content":{"id":"MONAD-MEMPOOL","specConstraints":[],"sources":[{"label":"Monad architecture: local mempool","url":"https://docs.monad.xyz/monad-arch/consensus/local-mempool","type":"official-doc"},{"label":"Monad architecture: block states","url":"https://docs.monad.xyz/monad-arch/consensus/block-states","type":"official-doc"},{"label":"Monad architecture: real-time data sources","url":"https://docs.monad.xyz/monad-arch/realtime-data/data-sources","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 has no global mempool: an RPC owner node checks and forwards valid transactions to upcoming leaders, while validators keep local mempools and the owner tracks inclusion. This can reduce propagation overhead and time to inclusion, but transactions can still wait, be evicted, be included with a reverted execution, or face application-specific market and MEV risk. Monad does not provide a network-wide pending lookup through the documented `newPendingTransactions` subscription.","designerTakeaways":["Treat local mempool architecture as a propagation detail. Keep MEV, quote, and slippage controls when the route, asset, or user risk calls for them.","Choose slippage from the quote, liquidity, volatility, route, and user risk policy. Monad supplies no universal slippage default.","Model the status path you can observe: submitted, awaiting inclusion, included, execution outcome, and finalized when the endpoint exposes that commitment.","A local mempool is not a global pending feed. Monad's documented `newPendingTransactions` subscription is unsupported, and the `pending` block tag is not a consensus state."],"chainContext":{"behavior":"On Monad by default, the selected RPC owner checks submitted transactions, forwards valid transactions through consensus to upcoming leaders, and tracks their hashes while validators maintain local mempools. Monad has no single network-wide pending pool: the documented `newPendingTransactions` subscription is unsupported, and `pending` is not a consensus state. Submission visibility therefore comes from the owner node or a selected data endpoint, not from a complete network-wide inventory.","whenRelevant":["Transaction submission, retry, and status UX on Monad.","Explorers, indexers, and activity views that need to explain what their selected endpoint has observed.","DeFi flows where quote expiry, slippage, route risk, or transaction ordering still affect the user.","Multichain products that assume an Ethereum-style pending lookup or global mempool."],"pitfalls":["Assuming no global mempool means immediate inclusion, no eviction, or no pending state.","Treating a returned transaction hash as proof that the transaction was included in a block.","Treating a receipt as proof of canonical or Finalized inclusion; it establishes an execution outcome in an observed block, while a Proposed-block receipt can still be provisional.","Promising a network-wide pending transaction list when the endpoint only tracks the submitted hash or selected feed.","Claiming local forwarding removes sandwich, quote, relay, ordering, or other application-specific MEV risk.","Hard-coding a slippage value without the quote, route, liquidity, volatility, and user-risk inputs that determine it."]},"prototypeFirst":[{"screen":"Swap quote and risk controls","why":"Reduced global transaction visibility does not remove quote movement or application risk.","covers":["Quote age","User slippage tolerance","Route-specific risk"],"include":["Current quote and expiry","User-editable slippage tolerance","MEV or route warning when the route requires it","A clear failed-swap recovery path"]},{"screen":"Commitment-aware transaction status","why":"Forwarding to local mempools can shorten inclusion without making inclusion or finality immediate.","covers":["Submitted","Awaiting inclusion","Included","Execution outcome","Proposed or other observed commitment","Finalized or retry"],"include":["Transaction hash","Block and commitment label when available","Success and revert as separate outcomes","Refresh and retry guidance"]},{"screen":"Cross-chain source risk","why":"A bridge transaction has separate source and destination transaction paths.","covers":["Source-chain submission","Destination-chain inclusion","Different quote and MEV conditions"],"include":["Source and destination network labels","Separate status and risk explanations","No claim that Monad changes the source chain"]},{"screen":"Local propagation explanation","why":"Advanced users may need to understand why a pending transaction is tracked by an owner node rather than a public global feed.","covers":["Owner-node tracking","Local validator mempools","Resubmission or eviction","No network-wide pending lookup"],"include":["Plain-language help text","Observed status and timestamp","A note that `newPendingTransactions` is unavailable and `pending` is not a consensus state","A link to the transaction lifecycle details"]}],"mentalModel":[{"label":"No global mempool","description":"Monad does not gossip one public pending pool across the network. Each validator keeps a local mempool."},{"label":"Forward to leaders","description":"The RPC and consensus processes forward valid transactions to upcoming leaders for possible inclusion."},{"label":"Reduced visibility is not zero risk","description":"Local propagation can reduce a global pre-inclusion view, but it does not remove quote movement, relay delay, failed inclusion, or application-specific MEV risk."},{"label":"Slippage is application policy","description":"The protocol does not choose a safe slippage value for a swap. The route, liquidity, volatility, and user risk policy still matter."},{"label":"Status comes from evidence","description":"Use the transaction hash, receipt, block state, and endpoint commitment level to decide what the UI can claim. A receipt from a Proposed block can be provisional."},{"label":"Endpoint visibility","description":"A wallet or app may add provider-specific pending feeds, hash polling, block-state subscriptions, private orderflow, or resubmission. These integrations expose selected data or behavior; they do not create a global mempool."}],"statesToDesign":[{"state":"Submitted","trigger":"The RPC owner node accepts the transaction for tracking.","userNeed":"Know that the request reached an endpoint.","designResponse":"Show Submitted with the transaction hash. Do not claim inclusion yet."},{"state":"Awaiting inclusion","trigger":"The owner node has not observed the transaction in a block.","userNeed":"Know whether to wait, refresh, or use a recovery path.","designResponse":"Show Awaiting inclusion and a retry or support path. Do not call this a stuck public-mempool state."},{"state":"Included","trigger":"An observed block contains the transaction.","userNeed":"Know where the transaction entered the chain.","designResponse":"Show the block and the endpoint's commitment level when available."},{"state":"Execution outcome","trigger":"The receipt or execution event reports success or a revert.","userNeed":"Know whether the requested action took effect.","designResponse":"Show execution success and inclusion separately. A reverted transaction can still be included."},{"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 endpoint reports that commitment."},{"state":"Not included or evicted","trigger":"The owner node does not observe inclusion after its forwarding or resend path, or a validator removes the transaction locally; the app may not be able to distinguish those causes.","userNeed":"Understand why the action did not complete.","designResponse":"Explain what the product can verify, then offer a safe retry or transaction-support path."}],"designDecisions":[{"question":"Should a Monad swap hide MEV or route-risk controls?","recommendation":"Keep controls when the route, asset, quote, or user risk policy requires them.","rationale":"A local mempool reduces global gossip but does not make swaps risk-free."},{"question":"What should the default slippage be?","recommendation":"Derive it from the quote, route, liquidity, volatility, and product risk policy, then let the user adjust it.","rationale":"Monad has no protocol-level slippage default, and one fixed value cannot fit every market."},{"question":"How should pending status be described?","recommendation":"Track submitted hashes through the selected endpoint, use Submitted and Awaiting inclusion, then show Included, the execution outcome, and Finalized as separate evidence-backed states.","rationale":"Monad's local propagation model does not provide a network-wide pending lookup or remove waiting, eviction, failed inclusion, or commitment differences."}],"problemsSolved":[{"problem":"A binary status hides whether a transaction was included or executed successfully","oldWay":"Submitting changes directly to Included or a generic failure.","newWay":"Show Submitted, Awaiting inclusion, Included, execution outcome, and Finalized when observed.","impact":"high"},{"problem":"Users are told that local propagation removes MEV risk","oldWay":"The swap hides route, quote, and slippage controls on Monad.","newWay":"The product keeps route-appropriate controls and explains the local mempool boundary.","impact":"critical"},{"problem":"One fixed slippage value is presented as a Monad rule","oldWay":"Every Monad swap starts at a fixed percentage regardless of market conditions.","newWay":"The product uses quote and risk inputs and keeps the tolerance editable.","impact":"high"},{"problem":"A product depends on a pending transaction feed that Monad does not provide globally","oldWay":"The interface assumes every node sees the same public pending pool.","newWay":"The owner node tracks the hash and the product explains what its endpoint has observed.","impact":"medium"}],"uxPatterns":[{"name":"Risk-aware Monad swap","description":"Use current quote and market context to choose a slippage tolerance, while keeping route-appropriate risk controls visible.","components":["QuoteAge","SlippageControl","RouteRiskNote","SwapButton"],"userFlow":["Open a swap on Monad","Review the current quote and expiry","Review or change slippage tolerance","Confirm the swap","Show execution success or revert separately from inclusion"]},{"name":"Commitment-aware transaction status","description":"Track the transaction by hash and disclose the strongest commitment the endpoint has observed.","mockup":"concept/tx-status","components":["TransactionStatus","CommitmentBadge","ExecutionOutcome","RetryAction"],"userFlow":["Submit the transaction","Show Submitted","Show Awaiting inclusion while the owner node tracks it","Show Included and the receipt outcome","Show Finalized when the endpoint reports it"]},{"name":"Endpoint-aware pending status","description":"Explain what the selected RPC or data provider can observe instead of implying a network-wide pending feed.","components":["SubmissionStatus","VisibilityNote","ObservedAt","ResubmitAction"],"userFlow":["Submit the transaction and retain its hash","Explain that the product tracks endpoint-observed status rather than every validator's local mempool","Poll or subscribe to block and commitment updates","Offer a safe retry or support path when inclusion is not observed"]}],"antiPatterns":[{"pattern":"Claim that local mempools remove MEV risk","why":"Local validator mempools reduce global gossip but do not remove every route, quote, relay, or application risk.","instead":"Keep route-appropriate protections and describe the local propagation model precisely.","severity":"critical"},{"pattern":"Use a fixed percentage as a protocol default","why":"Slippage depends on the asset, route, liquidity, volatility, and user risk policy.","instead":"Derive the tolerance from current market data and let the user adjust it.","severity":"high"},{"pattern":"Collapse Submitted directly into Included","why":"A transaction can wait, be evicted, fail inclusion, or be included with a reverted execution.","instead":"Show inclusion, execution outcome, and finality as separate states.","severity":"high"},{"pattern":"Promise a global pending transaction view","why":"Monad uses local validator mempools; its documented `newPendingTransactions` subscription is unsupported, and `pending` is not a consensus state.","instead":"Track the transaction through the owner node or selected provider and disclose endpoint limits.","severity":"medium"},{"pattern":"Treat an observed receipt as finality","why":"Real-time data can describe a Proposed block before the block reaches Finalized.","instead":"Label the observed commitment and reconcile the result as the block progresses.","severity":"high"}],"vocabulary":[{"use":"Submitted","avoid":"Inclusion is assured","why":"Submission confirms an endpoint received the request, not that a block contains it."},{"use":"Awaiting inclusion","avoid":"Stuck in the public mempool","why":"Monad does not maintain one global public pending pool."},{"use":"Included","avoid":"Mined from the mempool","why":"Inclusion is a block observation, and local mempool propagation is not a global mining queue."},{"use":"Execution reverted","avoid":"Failed to enter the chain","why":"A transaction can be included even when its requested execution reverts."},{"use":"Slippage tolerance","avoid":"MEV protection buffer","why":"Slippage tolerance is an application and user risk setting."},{"use":"Endpoint-observed pending status","avoid":"Network-wide pending transaction","why":"The product may track a submitted hash or provider feed, not every validator's local mempool."},{"use":"Proposed block","avoid":"Finalized","why":"Monad's latest real-time data can come from a block that has not reached the Finalized commitment."}],"onMonad":[{"aspect":"Mempool model","ethereum":"A global gossip-based pending pool is common.","monad":"Validators keep local mempools, and RPC nodes forward transactions to upcoming leaders.","designImplication":"Explain the propagation difference without removing security controls or promising inclusion."},{"aspect":"Swap risk","ethereum":"Route and market risk still determine the tolerance a swap needs.","monad":"The same application and market inputs still determine the tolerance. Local propagation does not choose it.","designImplication":"Use network-aware copy without hard-coding a Monad-wide slippage value."},{"aspect":"Transaction status","ethereum":"Products often distinguish pending, included, receipt outcome, and finality.","monad":"Products still need those distinctions, with block commitment states available through Monad's RPC and real-time data paths.","designImplication":"Use the strongest state the selected endpoint can verify, and keep retry and failure paths visible."},{"aspect":"Pending lookup","ethereum":"A product may encounter provider-specific pending feeds, but a feed is still an endpoint capability rather than proof of canonical inclusion.","monad":"Monad does not support the documented `newPendingTransactions` subscription, and `pending` is not a consensus state; the owner node can still track hashes and expose later block updates.","designImplication":"Design around submitted-hash tracking and endpoint disclosure instead of promising a complete pending inventory."}],"technicalNotes":"Monad's local mempool architecture has no global mempool. The RPC process performs static checks, the consensus process performs further validity checks, and valid transactions are forwarded to upcoming leaders. The owner node monitors later blocks and may resend when it does not observe inclusion; validators can evict transactions from local mempools. Monad's real-time data documentation says the `newPendingTransactions` subscription is not supported, and its block-state documentation says `pending` is not a consensus state. A Proposed block may be speculatively executed before Finalized. None of this removes application-specific slippage, quote movement, execution reverts, transaction-ordering, or MEV risk.","relatedStandards":[{"id":"MONAD-PARALLEL","relationship":"Local transaction propagation and parallel execution are separate parts of Monad's architecture."},{"id":"ERC-7683","relationship":"Cross-chain flows still have separate source-chain and destination-chain transaction paths."}]},"sources":[{"label":"Official documentation","url":"https://docs.monad.xyz/monad-arch/consensus/local-mempool","type":"official-doc"},{"label":"Monad architecture: block states","url":"https://docs.monad.xyz/monad-arch/consensus/block-states","type":"official-doc"},{"label":"Monad architecture: real-time data sources","url":"https://docs.monad.xyz/monad-arch/realtime-data/data-sources","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-MEMPOOL","markdown":"https://www.eipsfordesigners.com/standards/MONAD-MEMPOOL/content.md","agent":"https://www.eipsfordesigners.com/standards/MONAD-MEMPOOL/agent.md","api":"https://www.eipsfordesigners.com/api/standards/MONAD-MEMPOOL","official":"https://docs.monad.xyz/monad-arch/consensus/local-mempool"},"freshness":{"lastReviewed":"2026-09-21","lastUpdated":"2026-09-21"}}