Mempool
Área em que um nó guarda as transações válidas ainda não confirmadas, aguardando serem incluídas em um bloco por mineradores ou validadores.
Key points
- Mempool is the area where each node keeps the valid transactions that have not yet been included in a block.
- It is the transactions' waiting room: they sit there until a miner or validator selects them for the next block.
- The size of the mempool and the fees offered influence how long a transaction takes to be confirmed.
What is the mempool?
Mempool is short for memory pool, the set of pending transactions that a node keeps in memory. When a user sends a transaction, it spreads across the network and is stored in each node's mempool, where it waits until it is included in a block. While it sits there, the transaction is considered unconfirmed and may still not go through.
How it works
When a node receives a transaction, it checks whether the transaction is valid and, if so, adds it to its mempool and forwards it to its peers. Since each node keeps its own copy, the mempool is not unique: it can vary from one node to another depending on what each has received. Miners and validators look at these pending transactions and choose which ones to include in the next block.
Selection usually prioritizes transactions that offer higher fees, since the space in each block is limited. During periods of high demand, the mempool grows, competition for space increases, and the fees needed for a quick confirmation rise. During quiet periods, the mempool shrinks and cheap transactions confirm without delay.
Transactions that sit in the mempool too long without being included may end up dropped by some nodes, requiring resubmission. That is why the fee offered is, in practice, a competition for priority within the mempool.
Why it matters
Understanding the mempool helps explain why a transaction takes time to confirm. For a company processing on-chain payments, monitoring the state of the mempool and adjusting fees according to demand reduces delays and avoids overpaying during quiet periods.
Risks and limitations
Since each node has its own mempool, there is no single, definitive view of pending transactions, which makes estimates imprecise. During congestion, low-fee transactions may get stuck for a long time or be dropped. The dynamics of the mempool also open room for strategies that exploit the order in which transactions are included. For this reason, monitoring the mempool requires looking at several nodes and services, without treating any single one as the sole, definitive source.