Skip to content
Financial Context Wiki

Mempools and transaction pools

A node-local guide to Ethereum transaction admission, pending and queued nonces, propagation, fee eligibility, replacement, private order flow, inclusion, eviction and reorganization.

Updated

For educational purposes only; not transaction or security advice. A mempool view is local, volatile and policy-dependent; verify the exact chain, client, nonce, fee caps, submission route, receipt and finality before treating a transaction as accepted or complete.

Direct answer

A mempool, or transaction pool, is a node’s temporary in-memory and sometimes persisted set of signed transactions that the node has accepted under its current validation and policy rules but that are not in its canonical chain. It is not a consensus object, a global queue or a promise of inclusion. Two honest nodes can hold different transactions because they received different gossip, run different clients or settings, restarted, evicted entries, or use different public and private submission paths.

On an Ethereum execution client, an executable transaction with the next account nonce is commonly described as pending; a later nonce blocked by a gap is commonly described as queued. These labels are client interfaces, not final protocol states. A transaction can be rejected before admission, propagated, replaced by another signed transaction with the same sender and nonce, evicted, dropped, included successfully, included and reverted, or reconsidered after a reorganization.

1
Create

A wallet constructs a transaction with destination, value, fee parameters, and replay-protection data such as spent inputs or a nonce.

How it works

  1. Pin the environment: chain ID, execution client and version, current head and base fee, transaction type, sender, nonce, value, calldata, gas limit, fee caps and submission route. Distinguish public gossip, a private relay or builder, and an ERC-4337 UserOperation path; they do not share one universal pool.
  2. Decode the signed bytes and perform pre-admission checks. Verify signature and sender, chain ID, type and encoding, intrinsic gas, nonce relation, balance for value plus maximum fee exposure, fee fields and any required blob sidecar. A rejection here is not an EVM REVERT and normally creates no receipt or onchain fee.
  3. Map the local pool policy. Record whether the client classifies the transaction as pending or queued, its per-account and global capacity, minimum fee filters, lifetime, local-account exemptions, replacement bump and persistence behavior. Geth’s flags and defaults document Geth, not Ethereum consensus or every provider.
  4. Observe propagation without inventing a global view. Compare the raw transaction hash and signed bytes across independent nodes, but treat absence as ambiguous: the node may not have received it, may reject it under local policy, may have evicted it, or may not expose its pool. A private route can bypass public gossip while sharing the transaction with its operators and builders.
  5. Model block eligibility and ordering at the candidate block. For a type-2 transaction, execution gas price is min(maxFeePerGas, baseFeePerGas + maxPriorityFeePerGas); if the base fee exceeds the maximum fee, the transaction is ineligible under that cap. Nonce dependencies, gas and blob limits, state validity, builder bundles and MEV can matter more than first-seen time.
  6. Manage the lifecycle deliberately. Wait, or submit a documented same-nonce replacement only after confirming the active chain, sender and replacement policy. A self-transfer with the same nonce is merely another replacement candidate, not a cancellation primitive. Never repeat a value transfer because one explorer stopped showing the original.
  7. Reconcile against consensus state. Preserve every signed hash and replacement lineage, then check the canonical receipt, block hash, status, gas used, logs, consumed nonce and account or contract state at the required confirmation or finality level. If a reorganization removes the block, a still-valid transaction may return to some local pools, but that behavior is client- and state-dependent.

Worked examples

  • Fee-cap eligibility. A type-2 transfer has gasUsed = 21,000, baseFeePerGas = 32 gwei, maxPriorityFeePerGas = 3 gwei and maxFeePerGas = 34 gwei. Its effective price is min(34, 32 + 3) = 34 gwei, so the actual tip is 2 gwei. The fee is 21,000 * 34 = 714,000 gwei = 0.000714 ETH, split into a 0.000672 ETH base-fee burn and 0.000042 ETH tip. If the candidate block’s base fee rises to 35 gwei, the 34 gwei cap is insufficient for that block.
  • Nonce gap. The canonical account nonce is 10. A local pool receives transactions with nonces 10 and 12, but none with 11; it can classify 10 as pending and 12 as queued. After nonce 10 is included, the canonical nonce becomes 11, and 12 remains blocked until a valid nonce-11 transaction is included. Seeing nonce 12 in a pool does not make it independently executable.
  • Policy-specific replacement. Under a teaching Geth configuration with txpool.pricebump = 10, an old transaction has maxFeePerGas = 40 gwei and maxPriorityFeePerGas = 2 gwei. A replacement threshold computed as a 10% bump is 44 gwei and 2.2 gwei. A proposal with 43 gwei and 3 gwei can still be rejected because one cap misses the configured bump; 44 gwei and 2.2 gwei reaches both teaching thresholds. Exact integer rounding, transaction type and acceptance logic are version-specific, and another node may retain a different candidate.
  • No global pool. Node A reports 120,000 distinct transaction hashes, node B reports 100,000, and their intersection is 80,000. Their union is 120,000 + 100,000 - 80,000 = 140,000; the Jaccard overlap is 80,000 / 140,000 = 57.1428571429%. There are 40,000 hashes visible only to A and 20,000 only to B. Neither count proves what a builder, private relay or the rest of the network can see.

Risks

  • Signing or broadcasting on the wrong chain ID or network.
  • Trusting a malicious, stale or misconfigured RPC endpoint.
  • Invalid signature, transaction type, encoding or blob sidecar.
  • Insufficient balance for value plus maximum fee exposure.
  • Intrinsic-gas or calldata rules causing pre-admission rejection.
  • A nonce that is already consumed or too low.
  • A nonce gap leaving later transactions queued.
  • A same-nonce replacement rejected as underpriced by local policy.
  • A maximum fee below the candidate block’s base fee.
  • Low effective priority or resource constraints delaying inclusion.
  • Client, provider, version or configuration policy mismatch.
  • Pool capacity, expiry, restart or eviction removing a transaction.
  • Poor peer propagation, eclipse or selective relay behavior.
  • Private-relay leakage, censorship, outage or builder nonparticipation.
  • Public-order-flow frontrunning, sandwiching or other MEV.
  • Builder reordering, bundles or private transactions changing execution state.
  • Simulation becoming stale before inclusion.
  • Blind duplicate submission or loss of replacement lineage.
  • Included REVERT, out-of-gas or caught subcall failure despite pool acceptance.
  • Reorganization, finality confusion or treating an ERC-4337 alternate mempool as the ordinary txpool.

Common misconceptions

  • The mempool is one globally synchronized first-in, first-out queue.
  • A transaction hash proves that the network accepted or propagated the transaction.
  • Pending means included, successful, irreversible or paid to the recipient.
  • A sufficiently high fee guarantees inclusion and successful execution.
  • A private submission route is automatically confidential, censorship-resistant and guaranteed to land.

Sources

Navigation

Search the wiki...