Each crypto transaction has two life stages. The first starts when a user clicks “send,” and the second when the transaction gets on-chain and becomes recorded in history forever. What occurs between the two is known as the mempool and users typically perceive it as a queue but that’s not the case. It is a live auction for block space and having a conceptualization of this will alter how any user treats any transaction they send.
What the mempool actually is
Mempool, which stands for memory pool, exists on every full node of the network. A transaction you send to the network will not be sent to the blockchain directly; instead, it will be broadcast to the peer-to-peer network, and each of the nodes that received the transaction will have it placed in its mempool until it is picked by some miner or validator that checks if that needs to be added to the block or not.
There is not one master mempool, but every node holds its own version of the pending transactions. Nodes geographically spread throughout the world can potentially contain differing transaction sets, based on what they have seen and propagated. The network being distributed in nature causes certain asymmetries. Participants with a good vantage point in the network will see transactions earlier and, in some situations, will have an opportunity to execute based on this earlier knowledge.
The fee priority mechanism
The most important misunderstanding about the mempool is that it operates first-in, first-out. It does not.
The incentive to mine (on a proof of work chain) or validate (on a proof of stake chain) is purely economic. Block producers choose to include the set of transactions in their block that are going to generate them the most money. This means they order transactions based on the fee they offer, not on when the transaction was submitted. The transaction that arrived 2 hours earlier may still be sitting in the mempool because it did not offer a high enough fee, while a transaction that arrived 30 seconds ago will be in the next block because the fee offered was higher.
This process has been formalized on Ethereum as EIP-1559. Each block contains a base fee, set by the protocol and determined by how full the prior block was. The base fee is burned instead of being sent to the validator. Users can include an optional priority fee, a tip, in addition to the base fee that is paid directly to the validator. This tip is the bid and the higher it is, the sooner the user’s transaction will likely be confirmed.
In high-congestion states, the base fee can experience extreme increases. This is because the protocol increases the base fee programmatically to curb congestion. At points of high congestion, like during the 2021 NFT boom,Ethereum’s base fee went above 500 gwei on several occasions. Users who kept the tip very conservative ended up with stuck transactions for hours in the mempool, while others were able to win over the transaction finality process.
For Bitcoin, it’s easier to see how the mechanism works. Transactions pay for the privilege of being included in a block at a fee rate specified in satoshis per byte of the transaction. Larger transactions pay more, on an absolute scale. The miners prioritize the highest fee-rate transactions when filling each block. In the height of the Ordinals inscription movement in late 2023, fee rates exceeded 300 satoshis per byte, as inscriptions vied with regular transfers for a position in block space.
How the mempool fills and clears
In normal circumstances, the mempool is quite shallow, transactions should only take a few blocks to be confirmed and the pending number should be small. If there is high demand on blocks, the mempool grows. Each node can store only a limited number of unconfirmed transactions; this limit for Bitcoin Core nodes is at the default of 300 MB. Once this limit is reached, each incoming transaction should replace an existing one. Transactions are kicked out based on their fee rates-the one with the lowest one will be evicted.
And that becomes a real issue for the user who thinks that congestion is not as bad as it really is. If a user submitted a transaction 1 hour ago with a high enough fee that would guarantee a place in the pool but not as much as to pass the minimum once the pool grows, the transaction gets kicked out. Not an explicit fail, it just vanished from the mempool with no error, no confirmation, and no on-chain entry to say it ever existed. To wallets that do not make it very transparent, the user thinks the transaction is just waiting when, in fact, it does not exist on the network anymore.
The solution is transaction replacement. A user may resubmit their transaction to Ethereum with the same nonce and a greater fee. The new transaction will replace the old one in the mempool. This relies on nonce ordering: an Ethereum address maintains a nondecreasing sequence of numbers, and all transactions submitted from that address must confirm in increasing order of nonce. Once the transaction with nonce 47 gets stuck, all transactions with higher nonces submitted from the same address are blocked until nonce 47 eventually confirms or expires.
MEV: the mempool’s most critical mechanic
MEV stands for Maximal Extractable Value. MEV is profit gained by influencing block construction through front-running, back-running, or sandwiching pending transactions.
The mempool is where MEV originates. All unconfirmed pending transactions can be seen and bots can therefore systematically comb them for profitable strategies. A standard tactic is the sandwich attack. The searcher looks for a large swap pending on a DEX, places a buy order right before the victim’s swap. This allows the victim’s swap to execute at a bad rate. The searcher then immediately makes a sell order and takes the difference. The front and back runs are submitted with a sufficient tip so that they are guaranteed to sandwich the target transaction in the block.
