Skip to main content
what is memory pool
Blockchains

What is Memory Pool

Explore What is Memory Pool - key concepts, limitations, and risks.

Archived article · Original source date: 2024-08-02

This article is preserved from the previous Solana Bulls site as a historical archive. It reflects its original context; references to products, people, market conditions, eligibility, or rules may no longer be current.


Many blockchains use a memory pool, or mempool, to retain transactions that a node has accepted but that are not yet confirmed. Different nodes can hold different transactions because they receive traffic at different times and apply local policies.

What admission means

A node may check format, signatures, nonce or recent-block references, balances, fee rules, size, and conflicts before retaining or relaying a transaction. Passing those checks does not make the transaction legitimate in a broader sense or guarantee that a block producer will include it.

Selection and ordering

Block producers select from the transactions they can see according to protocol limits and local policy. Fees, dependencies, conflicts, arrival time, private order flow, and application-specific routing can affect ordering. A mempool is therefore neither a neutral first-in-first-out queue nor a fast lane by itself.

Expiration, replacement, and eviction

Pending transactions can expire, be replaced, conflict with confirmed state, be evicted under memory pressure, or remain unseen by the eventual producer. Wallets and applications need explicit retry, fee-bumping, cancellation, and confirmation behavior for the target network.

Privacy and MEV

Public transaction propagation can reveal intent before confirmation, creating front-running and other maximal-extractable-value risks. Private relays or direct producer connections change visibility and trust assumptions rather than eliminating ordering risk.

Solana is different

Solana transactions are commonly sent through RPC infrastructure and forwarded toward current or upcoming leaders, with recent blockhashes limiting processing age. It should not be described as having one conventional public mempool through which every transaction progresses. RPC retry behavior, leader forwarding, priority fees, account contention, blockhash expiration, and validator scheduling all affect landing.

Confirmation is separate

A pending or forwarded transaction has no commitment level. On Solana, processed, confirmed, and finalized describe observations about blocks and cluster votes after processing; clients should query signature status and handle expiration and dropped forks explicitly.