You press send on a crypto transaction and nothing happens. The wallet says pending. The block explorer shows your transaction floating in limbo, unconfirmed, with no clear indication of when, or whether, it will land.

Most people meet the mempool for the first time in exactly this moment of mild panic, and most of the advice they find assumes they already know what a mempool is. This guide starts from zero.

The mempool, short for memory pool, is the waiting room where every blockchain transaction sits between the moment you broadcast it and the moment a miner or validator writes it into a block. It is one of the least glamorous components of a public blockchain and one of the most consequential. The mempool decides how much you pay in fees, how long you wait, and, on some networks, whether a trading bot gets to see your order before it executes and profit at your expense. Understanding it turns confirmation delays from a mystery into a readable market signal.

This guide explains what the mempool actually is, why blockchains need a waiting room at all, how transactions move through it step by step, how fee markets decide who gets confirmed first, why there is no single mempool but thousands of slightly different ones, what happens when the queue overflows, how the mempool became the hunting ground for extractive trading bots, why Solana took the radical step of removing the public mempool entirely, and what practical steps you can take when your own transaction gets stuck.

What a mempool actually is

A mempool is a database of unconfirmed transactions that every full node on a blockchain network maintains in its working memory. When you sign a transaction in your wallet and hit send, the transaction does not travel to some central server for processing, because no such server exists. Instead, your wallet hands the signed transaction to a node, and that node begins spreading it to its peers, who spread it to their peers, until most of the network has a copy. Each node that receives the transaction runs a series of checks and, if the transaction passes, places it in its local mempool to wait.

The word itself is a contraction of memory and pool, and the memory part matters. Nodes keep the mempool in RAM instead of writing it to disk, because speed is the point. When a miner assembles a candidate block, it needs to sort thousands of pending transactions by fee and select the most profitable set in a fraction of a second. When a new block arrives from elsewhere on the network, a node can validate it faster if most of the block’s transactions are already sitting in its own mempool, checked and ready.

The mempool is a staging area, a buffer between the chaotic, continuous stream of user activity and the rigid, periodic heartbeat of block production.

Why blockchains need a waiting room

A traditional payment processor confirms transactions the instant they arrive because a single company controls the ledger and can simply write the entry. A public blockchain has no such authority. Thousands of independent nodes must agree on a single history, and they reach that agreement in discrete steps, one block at a time. Between blocks, the network needs a shared, informal picture of what users want to happen next, and the mempool provides it.

The waiting period also does critical security work. Before a node admits a transaction to its mempool, it verifies that the digital signature is valid, that the sender actually controls the funds being spent, that the transaction is correctly formatted, and that the same coins are not being spent twice. This last check matters more than it sounds. It is entirely possible for two conflicting transactions, both spending the same coins, to enter the network at the same time from different points. Some nodes see one first, some see the other. Each node rejects whichever conflicting transaction arrives second, and the conflict is finally settled when a miner includes one of the two in a block. The mempool is where these races are held and resolved.

The mempool also functions as the network’s early warning system. A rapidly filling mempool signals a surge of demand, a panic, an airdrop claim window, or a fee spike before any of it shows up in confirmed blocks. Traders, miners, and wallet fee estimators all read the mempool the way meteorologists read pressure systems.

The life of a transaction, step by step

Following a single transaction through the pipeline makes the mechanics concrete. First comes creation: your wallet constructs the transaction, specifying the amount, the recipient, and the fee you are willing to pay, and signs it with your private key. The signature proves ownership without revealing the key itself.

Second comes broadcast. The wallet sends the signed transaction to one or more nodes, which begin relaying it across the peer to peer network. Propagation to most of the network typically takes a few seconds, and nothing about this step requires trust in the first node, since every subsequent node re-validates the transaction independently before passing it along.

Third comes validation. Every node that receives the transaction independently checks it. Invalid transactions, bad signatures, insufficient funds, malformed data, are dropped on the spot and never reach a mempool.

Fourth comes the wait. The transaction now sits in thousands of mempools across the network, visible to anyone running a node or using a public mempool explorer. How long it waits depends almost entirely on the fee attached relative to everyone else’s fees.

Fifth comes selection. A miner on a proof of work chain, or a validator on a proof of stake chain, assembles a candidate block by picking pending transactions from its mempool, almost always sorting by fee density so the block earns the maximum reward.

Sixth comes confirmation. The block is mined or proposed, propagated, and accepted by the network. Every node removes the block’s transactions from its mempool, and your transaction is now part of the chain. Each additional block built on top adds another confirmation and makes reversal exponentially harder.

How the fee market decides who goes first

Block space is scarce and demand fluctuates, so blockchains ration space by auction. On Bitcoin, fees are measured in satoshis per virtual byte, a unit of transaction data size, so a transaction’s fee rate depends on both what you pay and how much space the transaction occupies. On Ethereum, the fee is gas, with a base fee that the protocol burns and a priority tip that goes to the validator. In both systems the logic is identical: block producers are profit maximizers, so they fill blocks with the highest paying transactions first.

This means your position in the queue is not fixed. A transaction that looked competitively priced at noon can be hopelessly underpriced by evening if demand surges. Wallets estimate fees by reading the current mempool, looking at what pending transactions are offering and how full recent blocks have been, then suggesting a rate likely to confirm within your chosen time window. Those estimates are educated guesses, not guarantees, and they go stale quickly during volatile markets. A fee that clears in the next block during a quiet Sunday can leave you waiting hours during a liquidation cascade, because everyone else’s willingness to pay moved while yours stood still. The auction never closes, and it reprices continuously.

When you underpay, most networks offer escape hatches. Bitcoin supports replace by fee, which lets you rebroadcast the same transaction with a higher fee that supersedes the original. A related trick, child pays for parent, attaches a high fee follow up transaction that spends the stuck one’s output, giving miners an incentive to confirm both together. Ethereum wallets let you resubmit a transaction with the same nonce and a higher gas price, which replaces the pending version. Knowing these tools exist converts a stuck transaction from an emergency into an inconvenience.

There is no single mempool

People say the mempool as if one canonical queue existed somewhere, but the reality is messier and more interesting. Every node maintains its own mempool, and no two are exactly identical. Transactions reach different nodes at different times, nodes apply slightly different acceptance policies, and each node manages its own memory limits. What we call the mempool is really the loose statistical overlap of thousands of private ones.

In practice the overlap is large, because most node operators run default settings. A typical Bitcoin node caps its mempool around 300 megabytes, keeps transactions for up to two weeks, and refuses anything paying less than a minimum relay fee of roughly one satoshi per virtual byte. When the pool exceeds its size cap, the node evicts the lowest fee transactions first and raises its minimum acceptance rate, which is why very cheap transactions can vanish entirely during congestion instead of merely waiting. Once evicted everywhere, a transaction is effectively cancelled, and the funds simply remain unspent in the sender’s wallet.

The distributed nature of the mempool has a subtle consequence: pending status is not a promise. A transaction shown as pending in an explorer exists only as a claim in some nodes’ memory. It can be evicted, replaced, or double spent until it lands in a block. Merchants who accept zero confirmation payments learn this lesson the hard way, and it is exactly the mechanism a 51% attack exploits at chain level, where an attacker rewrites recent blocks and dumps the reversed transactions back into the mempool as if they had never confirmed. The 2025 reorganization attacks on Monero pushed more than one hundred confirmed transactions back into the pending queue in exactly this way.

Policy, standardness, and why nodes reject valid transactions

Consensus rules define what a blockchain will accept in a block. Mempool policy defines what an individual node will hold and relay, and the two are not the same thing. A transaction can be perfectly valid under consensus rules and still be refused by most mempools because it violates what Bitcoin developers call standardness: informal policy rules that filter dust outputs, oversized scripts, absurdly low fees, and exotic transaction shapes that could burden the network. Policy is a node level immune system, a first line of defense that keeps the shared queue usable.

This distinction produces real world confusion. A transaction rejected by public mempools can still be mined if it reaches a miner directly, which is why services exist that accept nonstandard transactions out of band and submit them straight to mining pools. It also means the mempool you observe through an explorer reflects that node’s policy, not some universal truth. Two explorers can disagree about whether your transaction is pending simply because their nodes apply different filters.

Policy also evolves faster than consensus. Nodes have tightened and loosened relay rules around data inscriptions, dust limits, and replacement behavior repeatedly over the years, each change reshaping what the pending queue looks like without touching consensus at all. For users the practical takeaway is simple: if a wallet warns that a transaction is nonstandard, the problem is usually the transaction’s construction, not the funds behind it.

The mempool also has a quieter institutional audience. Exchanges watch pending deposits to credit accounts faster, compliance teams screen incoming transactions before confirmation, and payment processors estimate risk on zero confirmation transfers by checking how well a transaction is propagating and whether any conflicting spend is circulating. A transaction that most of the network’s mempools agree on is far less likely to be double spent than one propagating poorly, and firms price that difference.

Congestion, spam, and what a full mempool feels like

Mempool congestion is the network catching its breath. Demand exceeds block space, the queue grows, and the fee needed for timely confirmation climbs. Users experience it as expensive transactions and long waits. Bitcoin’s late 2017 mania, the DeFi summer of 2020, NFT minting waves, and the ordinals inscription craze of 2023 each produced mempool backlogs measured in days, with hundreds of thousands of transactions queued and fee rates multiplying overnight. During the worst stretches, low fee transactions waited more than a week, and node operators watched their mempools hit size limits and begin shedding the cheapest traffic.

Congestion can also be manufactured. Spam attacks flood the network with masses of low value transactions to clog the queue and degrade service for everyone else, a cheap form of denial of service. Networks defend themselves with the minimum relay fee, with eviction policies, and ultimately with economics, since sustained spam costs the attacker real money in fees. The 2017 spam attack on an Ethereum test network showed how effective flooding could be against a chain with weak fee pressure, and it pushed fee market design higher up the research agenda.

Congestion is also information. A swollen mempool alongside rising fees signals urgent demand, often around exchange runs, liquidation cascades, or major market moves. Sophisticated observers watch mempool depth the way bond traders watch yields, and several analytics firms sell exactly that feed.

The dark forest: MEV and the watchers in the pool

The mempool’s defining feature, total transparency, is also its greatest vulnerability. Every pending transaction is public before it executes, which means anyone can read your intentions and act on them first. On smart contract chains this gave rise to an entire extractive industry built around maximal extractable value, or MEV, the profit available to whoever controls transaction ordering.

The canonical attack is the sandwich. A bot spots your large pending swap on a decentralized exchange, buys the same token first to push the price up, lets your trade execute at the worse price, then immediately sells for a profit carved directly out of your execution. Front running, back running, and liquidation sniping follow the same principle: see the pending transaction, position around it, capture the difference. One researcher famously described the public mempool as a dark forest, a place where anything visible gets hunted. Researchers estimate that MEV extraction on Ethereum alone has run into the billions of dollars since 2020.

The defense industry that grew in response is now substantial. Private transaction relays, such as Flashbots Protect, let users submit transactions directly to block builders, skipping the public mempool entirely so bots never see the order. Batch auction exchanges settle many trades at a single clearing price, removing the ordering advantage. Wallets increasingly route large trades through protected channels by default. None of this eliminates MEV, but it changes who can be hunted. The economics are straightforward: the value of hiding an order grows with its size, so large traders now treat mempool privacy the way traditional funds treat dark pools, as basic operational hygiene. Retail users moving small amounts face far less risk, but a single large swap through the public queue on a thin trading pair can pay a triple digit toll to a sandwich bot in a matter of seconds.

Solana’s answer: delete the mempool

Solana made the most radical design choice of any major network: it has no public mempool at all. Instead of gossiping pending transactions across the whole network, Solana’s Gulf Stream protocol forwards transactions directly to the validator scheduled to produce the next block, called the leader. The leader schedule is known in advance, so wallets and nodes know exactly where to send traffic. Transactions go from user to leader with almost no public waiting period.

The design serves speed above all, and it removes the classic observation window that sandwich bots depend on, since pending transactions are never broadcast for public inspection. It did not eliminate MEV, which instead matured into a private auction economy where searchers pay tips through infrastructure such as Jito to have their transaction bundles placed favorably by leaders. The lesson generalizes: ordering has value on any blockchain, and removing the public queue changes where that value is captured, not whether it exists.

Other networks are converging on middle paths. Encrypted mempools hide transaction contents until ordering is locked. Proposer builder separation on Ethereum splits the job of choosing transactions from the job of proposing blocks, pushing MEV into a more transparent auction. The mempool of 2030 will likely look very different from the open bazaar of 2020. What will not change is the underlying constraint: some component of every blockchain has to hold transactions between creation and confirmation, and whoever can observe or influence that component holds power over everyone who cannot.

Reading the mempool yourself

You do not need to run a node to watch the queue. Public mempool explorers visualize pending transactions, fee distributions, and projected confirmation times in real time, and they are the fastest way to answer the two questions every stuck user asks: how busy is the network, and what fee actually clears right now.

When your own transaction is stuck, the diagnosis is almost always the same: your fee is below the going rate. Your options, in rough order of preference, are to wait for congestion to ease, to bump the fee using replace by fee or a nonce replacement, to use child pays for parent where supported, or, on Bitcoin, simply to wait for eviction if the payment no longer matters. What you should not do is panic. The funds are not lost. An unconfirmed transaction either confirms or effectively ceases to exist, and in the latter case the coins never left your wallet.

It also helps to understand what explorers actually display. The fee histogram shows how much pending volume sits at each fee level, which tells you where the clearing price is right now. The projected blocks view shows which transactions would fill the next several blocks if they were produced immediately, which tells you how deep the queue runs ahead of you. And the purge line, on Bitcoin explorers, shows the fee rate below which nodes are actively evicting transactions, the effective floor of the market. Ten minutes spent learning these three readouts pays for itself the first time fees spike.

One final habit worth adopting: check the mempool before you transact, not after. Thirty seconds of looking at current fee rates saves both overpaying during quiet periods and underpaying during storms. The queue is public. Very few people bother to read it, which is exactly why the ones who do have an edge. It is the same reason a network upgrade that splits the chain, covered in our guide to hard forks and soft forks, always produces a flurry of mempool drama, as wallets and nodes on both sides of the split sort out which pending transactions belong where.

Frequently asked questions

This article is for educational purposes only and does not constitute financial or investment advice. Network rules, fee mechanics, and default node policies change over time. Details are accurate as of July 14, 2026.