What Is a Mempool?

Introduction

Mempool is the name commonly used for a node’s pool of valid but unconfirmed transactions. When you send a transaction, it does not jump straight into a block. It is first broadcast across the network, checked by nodes against their local rules, and then held in this staging area until a block producer chooses to include it. That gap between submitted and confirmed is where much of blockchain’s real-time behavior lives: fee competition, replacement, ordering, congestion, and often MEV.

The key thing to understand is that there is no single global mempool floating above the chain. There are many mempools, one per node or client, each representing that node’s current view of which pending transactions are valid and worth keeping. Nodes usually converge on similar views, but they do not have to match exactly. Different peers hear about transactions at different times, apply different local policies, and may be following slightly different recent chain histories. So when people say “the mempool,” they usually mean either the general network-wide set of pending transactions or the local transaction pool on a specific node, depending on context.

That distinction explains a puzzle many newcomers notice. If blockchains are supposed to be globally shared systems, why is the waiting area not globally shared too? The answer is that confirmation is a consensus problem, but pending state is mostly a networking and local-policy problem. Consensus tells everyone what is already in the chain. The mempool is about what might go into the chain next.

Why do blockchains need a mempool?

A blockchain needs a place to hold work that has been proposed but not yet finalized. Without such a buffer, a node would have to either ignore transactions until the exact instant it was building a block or forward every transaction without remembering it. Neither works well. Block producers need a ready set of candidate transactions to assemble blocks quickly, ordinary nodes need to validate and relay transactions before confirmation, and wallets need some observable “pending” state so users can tell that a transaction has at least reached the network.

So the mempool solves a coordination problem created by asynchronous networks. Users submit transactions continuously, but blocks are created only at discrete times. The mempool bridges that mismatch. It stores pending transactions, lets nodes relay them onward, and gives miners or validators a menu from which to construct blocks.

That mechanism has consequences. Because block space is scarce, the mempool becomes the place where transactions compete for inclusion. Fees matter here not as an abstract property, but because a block producer facing limited space must choose among alternatives. In Ethereum-style systems this often means choosing transactions with more attractive gas parameters. In Bitcoin-style systems it means preferring higher feerate transactions, subject to dependency rules. In either case, the mempool is where the fee market becomes concrete.

How does a mempool act as a node's waiting room and a fee price signal?

A good starting model is this: a mempool is a node-local waiting room for transactions that have passed initial checks and are waiting for inclusion. The waiting room is limited in size, so it cannot keep everything forever. It therefore needs answers to four practical questions: *should this transaction be admitted, where should it sit relative to others, when should it be removed, and what happens if the chain tip changes? *

Those four questions define most mempool behavior across chains.

Admission means the node checks whether the transaction is valid enough to keep. Some checks come from consensus or the ledger rules: valid signature, acceptable format, inputs that exist, correct nonce or sequence behavior, sufficient balance, current blockhash or recentness conditions, and so on. Other checks are local policy: minimum relay fee, size limits, replacement policy, resource caps, or anti-spam heuristics. A transaction can therefore be perfectly valid in principle yet still be rejected from a particular node’s mempool because that node is unwilling to store or forward it.

Ordering means the node needs some notion of priority. In the simplest case, this is just arrival order. Tendermint documents this explicitly: absent application-level constraints, there is no ordering beyond the order transactions arrived. Other systems build stronger internal ordering around fees, dependencies, or account nonces. The more economically valuable block space is, the more pressure there is to make that ordering reflect expected block revenue.

Removal happens for several reasons. The best reason is confirmation: once the transaction is included in a block, it is no longer pending. But transactions can also leave because they are replaced, evicted under memory pressure, invalidated by a chain reorganization, or expire under chain-specific freshness rules. Solana, for example, ties processability to the age of a recent blockhash. Polkadot distinguishes a ready queue from a future queue, where some transactions are not yet valid but may become valid later, such as a transaction with a nonce that is currently too high.

Revalidation is necessary because pending validity depends on the chain tip. Cardano states this very directly: the mempool stores transactions valid on top of the latest selected ledger state, and a change in chain selection should trigger prompt revalidation. This is not a corner case. A transaction that was valid a moment ago can become invalid if a competing transaction spends the same UTxO, if a nonce gap appears, or if the underlying chain history shifts during a reorg.

Why don’t all blockchains use the same mempool design?

Different blockchain architectures create different pending-state problems.

In a UTxO system, the central question is often whether a transaction’s inputs are still spendable and whether it conflicts with other pending transactions. That naturally creates a graph of dependencies: if transaction B spends an output created by transaction A, then B cannot be included before A. Bitcoin Core’s mempool explicitly models these parent-child relationships, along with recursively defined ancestors and descendants, because miners care about package value, not just isolated transaction fees.

In an account-based system, the central constraint is often per-account sequencing. Ethereum transactions from the same account have nonces, so a transaction with nonce 12 cannot really proceed before nonce 11. Geth’s txpool API reflects this structure: pending and queued transactions are grouped by originating address and then by nonce, and there may be multiple candidate transactions for the same account and nonce if the user broadcast replacements with different fee settings.

The common idea is the same: pending transactions are not independent objects. They interact through shared inputs, shared accounts, ordering constraints, and local resource limits. A useful mempool design has to model those interactions, not just hold a bag of transactions.

How does a mempool process, validate, and relay a new transaction?

Suppose you broadcast a transaction from your wallet. A node receives the bytes over its network interface and begins a pipeline of checks. Some chains make these stages explicit. Solana’s validator pipeline, for example, describes receiving transaction bytes over UDP or QUIC, verifying signatures in a dedicated stage, sanitizing the transaction’s structure, checking recent blockhash age or durable nonce behavior, and validating fee payment before execution can proceed. Even if a chain’s documentation is less procedural, some form of this pipeline exists everywhere.

If the transaction passes the necessary checks, the node stores it in its local mempool and relays it to peers. At that point the transaction is pending: it is known to at least some part of the network, but not yet part of the canonical chain. Other nodes that receive it repeat broadly similar checks, though not always with identical policy. This is why two block explorers or two RPC providers can disagree briefly about whether a transaction is pending, dropped, or replaceable.

Now imagine a block producer preparing the next block. It does not search the whole internet for candidate transactions at the last second. It looks at its local transaction pool. That is why local mempool policy matters so much: what a producer has admitted, ordered, or evicted shapes what it can include.

A concrete Bitcoin-style example makes this clearer. Imagine Alice broadcasts transaction A, which spends a confirmed output and pays a moderate feerate. Then she broadcasts transaction B, which spends an output created by A and pays a high feerate. A miner cannot include B by itself because B depends on A. If the miner evaluated transactions independently, it might wrongly ignore B or misprice the pair. Bitcoin Core therefore tracks transaction relationships as a graph and reasons about groups of related transactions. The important object is not just “which single transaction pays more,” but “which valid set of transactions yields more fees per unit of block space while respecting dependencies.” That is the mechanism behind ancestor and descendant tracking.

Bitcoin Core’s current mempool design goes further by modeling the mempool as a directed graph whose connected components are called clusters. A cluster contains transactions connected by spending relationships. Each cluster is linearized into a topologically valid order, then conceptually partitioned into chunks whose feerates decrease monotonically along the ordering. This ordering is used at both ends of mempool management: miners select from the front when building blocks, and the node evicts from the back when it needs to free space. The deep idea is elegant: the same ordering that says “best things to include first” also says “worst things to discard first.”

That design also explains why mempool policy is not just about storage. It is partly an optimization problem. Computing good orderings becomes harder as dependency clusters get larger, so Bitcoin Core enforces cluster size limits. According to the design documentation, transactions must not create clusters exceeding 64 transactions or 101 kvB. The point is not arbitrary neatness. It bounds computational cost, keeps block assembly near-optimal, and prevents a small incoming transaction from forcing a node to reconsider an unmanageably large dependency structure.

How do mempool admission policies differ from consensus validity?

A smart reader often assumes that if a transaction is valid under consensus, every node must accept it into its mempool. That is false.

Consensus rules determine whether a transaction can appear in a valid block. Mempool policy determines whether a node is willing to keep and relay that transaction before it is in a block. These are related but distinct layers. A chain can have very strict consensus validity and still allow nodes considerable policy discretion about pending transactions.

Bitcoin Core makes this distinction explicit in implementation and documentation. Admission is staged through structures that can check mempool policy limits before acceptance. The mempool also maintains indexes for spent outpoints so it can detect conflicts quickly. If a new transaction spends an outpoint already spent by an in-mempool transaction, the node is not merely storing another candidate; it is evaluating a conflict that may trigger replacement logic.

Ethereum clients also separate transaction validity from pool status in practice. A transaction may be well-formed and correctly signed yet sit in a queued state because its nonce is too high relative to the account’s current executable sequence. Geth exposes this distinction directly via txpool_content, txpool_inspect, and txpool_status, separating pending transactions from queued ones. Pending means currently eligible for inclusion; queued means not yet executable, often because an earlier nonce is missing.

Polkadot uses a similar idea with ready and future queues. The future queue is not a trash can. It exists because some transactions are not invalid in an absolute sense; they are invalid for now given current state. A mempool therefore often needs more nuanced states than just yes-or-no admission.

How do replacements and conflicts (RBF) work in the mempool?

Because transactions are pending rather than final, users sometimes want to change them. Maybe a fee was set too low. Maybe a transaction needs to be canceled or superseded. That leads to replacement rules.

In Bitcoin, replace-by-fee depends on mempool policy. The basic conflict relation is straightforward: a transaction directly conflicts with an in-mempool transaction if they spend one or more of the same inputs. But accepting the new transaction is not just a matter of “higher fee wins.” Bitcoin Core’s policy requires, among other things, that the replacement pay at least the total absolute fee of the transactions it replaces and also pay enough additional fee to cover the node’s incremental relay feerate. Under the cluster mempool design, replacements are also evaluated by whether they strictly improve the mempool feerate diagram, a cluster-aware way of asking whether the replacement makes future block construction economically better.

That sounds abstract, but the intuition is simple. A mempool is trying to maintain a set of pending transactions that are attractive for future blocks. If a replacement merely shuffles conflicts around without improving expected fee yield, the node has little reason to accept the churn. Replacement policy is therefore both a user feature and a denial-of-service defense.

Ethereum has an analogous practical phenomenon even if the policy language differs by client. Geth’s txpool documentation notes that multiple transactions may exist for the same account and nonce, often with different gas allowances. That reflects the same underlying reality: a pending transaction is not fixed until confirmed, and the mempool is the arena in which competing versions are compared.

What happens when a mempool fills up and transactions are evicted?

A mempool is finite. When demand exceeds capacity, nodes must decide what to forget.

This is where the fee market stops being theoretical. If there is more pending demand than a node is willing to store, low-value transactions are pushed out. Bitcoin Core’s implementation trims the mempool by removing the worst chunk according to its transaction-graph ordering and raises a rolling minimum fee rate so similarly priced transactions cannot immediately re-enter and cause churn. That rolling minimum decays over time, which means congestion has memory but not permanence: when pressure subsides, the floor can fall again.

The mechanism matters because it shapes user experience. A transaction that looked safely broadcast during quiet conditions may become effectively nonviable during congestion if its feerate falls below the node’s current minimum for retention or relay. Wallets then speak of a transaction being “stuck,” but what that usually means is more precise: many nodes no longer consider it attractive enough to keep in their mempools, so the transaction has lost visibility to block producers.

Different chains express pressure differently. Cardano emphasizes a ledger-enforced back-pressure limit based on resource metrics such as transaction size and execution units rather than a raw transaction count. Solana constrains transactions by packet size and pipeline processing stages. Polkadot block authors weigh factors such as tip, weight, and length when prioritizing the ready queue. The shared principle is that a mempool is not just storage; it is resource management under uncertainty.

How does mempool visibility enable MEV and what are the trade‑offs?

Public mempools reveal intent before finalization. That is useful because it enables propagation and price discovery, but it also creates strategic behavior.

If pending transactions are visible, other actors can react before confirmation. In Decentralized Exchanges settings, that can mean frontrunning, backrunning, or sandwiching. More generally, it means searchers can inspect pending state changes and race to insert profitable transactions around them. This is why mempool design sits so close to the concept of MEV. The mempool is not the only source of MEV, but public pending visibility makes many forms of it much easier.

That pressure has produced private submission channels and private mempool-like systems. Flashbots, for example, describes products designed to mitigate negative externalities from MEV and offers submission flows intended to protect users from public-mempool frontrunning. The important conceptual point is not the brand or product detail. It is that once pending transactions become economically sensitive information, users and builders start looking for ways to route transactions outside the ordinary public waiting room.

This also reveals a tradeoff. Public mempools support openness, broad relay, and transparent fee discovery. Private flows can reduce some forms of predation, but they also change who gets to see pending order flow and who gets special access to block construction. There is no free design here; changing visibility changes power.

What do people commonly misunderstand about mempools?

The most common misunderstanding is treating the mempool as part of consensus. It is not, at least not in the same sense as blocks and state transitions. Nodes can disagree about their mempools while still fully agreeing on the blockchain.

Another misunderstanding is assuming pending means guaranteed. A transaction visible in a mempool is only a candidate for inclusion. It can be replaced, evicted, invalidated by reorg, or simply never chosen.

A third is assuming all chains have fee-sorted public mempools. Some do not. Tendermint’s documented semantics are arrival-based unless the application itself enforces ordering. Some systems maintain explicit executable and non-executable queues. Some prioritize by fee, some by account sequencing plus fee, and some expose only parts of their local ordering logic.

The last major misunderstanding is assuming mempool state is uniform across the network. In reality, the mempool is fragmented by latency, client behavior, and policy. That fragmentation is not a bug added on top of decentralization. It is a direct consequence of decentralized nodes making local decisions under incomplete information.

Conclusion

A mempool is a node’s local pool of valid but unconfirmed transactions, but that short definition hides the important part. The mempool is the mechanism that turns a blockchain from a static ledger into a live transaction market. It buffers asynchronous submission, lets nodes relay and remember pending transactions, gives block producers something to build from, and forces every network to answer hard questions about ordering, replacement, eviction, and visibility.

If you remember one thing tomorrow, remember this: **consensus decides what is already in the chain; the mempool decides what is competing to get in next. **

What should I understand about mempools before trading or sending crypto?

Understand how mempool behavior affects the safety and timing of on‑chain transfers and Market Order, then use Cube Exchange to execute transfers or trades with that context in mind. Before you move funds, check network congestion, set appropriate fee or gas parameters in the transfer flow, and choose an Order Types that matches your risk tolerance.

1. Check current mempool congestion and the median feerate for the target chain on a block explorer or analytics site.
2. Fund your Cube Exchange account with the on‑chain asset or fiat you need.
3. Open the on‑chain transfer or trade flow on Cube for the asset and network you plan to use.
4. Set fees or gas parameters based on the observed feerate (for nonce chains, include a priority/tip high enough to beat current congestion).
5. Submit the transfer or order and wait for an appropriate confirmation threshold (for example, ~6 confirmations for Bitcoin or the chain‑specific threshold you use for large value transfers).