Monero's Mempool: How Pending Transactions Work and Why It Matters

What Is the Monero Mempool?

Every cryptocurrency network needs a waiting room for transactions that have been broadcast but not yet included in a block. In Monero, this waiting room is called the mempool, short for memory pool. It is a critical component of the network that directly affects how quickly your transactions confirm and how the network handles periods of high demand.

When you send XMR from your wallet, the transaction does not instantly appear on the blockchain. Instead, it first enters the mempool, where it waits alongside other unconfirmed transactions until a miner picks it up and includes it in the next block. Understanding this process helps you make better decisions about fees, timing, and privacy when using MoneroSwapper or any other Monero service.

How Transactions Enter the Mempool

The journey of a Monero transaction begins in your wallet software. When you initiate a send, your wallet constructs the transaction locally. This involves selecting decoy outputs for the ring signature, generating a one-time stealth address for the recipient, computing the range proof for the encrypted amount, and signing everything with your private spend key.

Once constructed, the wallet broadcasts the transaction to the Monero peer-to-peer network. The first node that receives it performs several validation checks before accepting it into its local mempool:

• Syntax validation — The transaction must be properly formatted according to the Monero protocol rules
• Ring signature verification — The cryptographic signatures must be valid, proving the sender has authority to spend the referenced outputs
• Key image check — The key images must not already exist on the blockchain or in the mempool, which would indicate a double-spend attempt
• RingCT verification — The range proofs must be valid, confirming that encrypted amounts are positive and the inputs equal the outputs plus the fee
• Fee check — The transaction must include at least the minimum required fee based on its size in bytes

After passing these checks, the node adds the transaction to its mempool and relays it to other connected nodes. Through this gossip protocol, the transaction propagates across the entire network within seconds, reaching miners who can include it in their next block.

Dandelion++ and Transaction Propagation

Monero uses an enhanced propagation method called Dandelion++ to protect the sender's IP address. Instead of immediately broadcasting the transaction to all peers, Dandelion++ first sends it through a random chain of nodes in a "stem phase" before entering the normal "fluff phase" of broad propagation. This makes it significantly harder for network observers to determine which node originated the transaction.

This privacy feature means there can be a slight additional delay before your transaction appears in the mempool on public block explorers. The stem phase typically adds only a few seconds, but it provides meaningful protection against network-level surveillance.

Mempool Size and Transaction Limits

Unlike Bitcoin, which has a somewhat fixed block size limit that creates predictable mempool congestion, Monero uses a dynamic block size mechanism. The maximum block size adjusts automatically based on the median size of the last 100 blocks. If demand increases, blocks can grow to accommodate more transactions, though miners pay a penalty for creating blocks larger than the current median.

The mempool itself has a configurable size limit on each node. By default, the Monero daemon allocates a certain amount of memory for the mempool. When this limit is approached, the lowest-fee transactions may be dropped to make room for higher-fee ones. In practice, the Monero mempool rarely reaches its limits because the dynamic block size mechanism absorbs demand spikes effectively.

Key parameters that affect mempool behavior include:

• Minimum relay fee — Transactions below this fee rate will not be relayed by nodes, preventing spam
• Transaction age limit — Transactions that remain unconfirmed for an extended period (typically 72 hours) are eventually dropped from the mempool
• Size limit per transaction — Individual transactions cannot exceed a maximum size, which limits the number of inputs and outputs

Fee-Based Priority and Transaction Ordering

When miners construct a new block, they select transactions from the mempool to maximize their fee revenue. Transactions are ranked by their fee per byte ratio, not their absolute fee amount. A small transaction paying 0.0001 XMR might have a higher priority than a large transaction paying 0.001 XMR if the smaller one has a better fee-to-size ratio.

Monero wallets calculate fees based on a priority system with four levels:

• Default (x1) — Standard fee, suitable for normal transactions with typical confirmation in the next block
• Low (x1) — Same as default in most conditions; transactions confirm within a few blocks
• Medium (x5) — Five times the base fee, for faster confirmation during congestion
• High (x20) — Twenty times the base fee, virtually guaranteeing inclusion in the next block

Under normal network conditions, even the default fee level results in confirmation within one or two blocks (approximately two to four minutes). The fee market only becomes relevant during unusual spikes in transaction volume.

The Backlog Scenario

A backlog occurs when transactions are being created faster than they can be included in blocks. While Monero's dynamic block size helps mitigate this, extreme demand spikes can still cause temporary congestion. During a backlog, several things happen:

First, the mempool grows as transactions accumulate. Users may notice longer confirmation times for transactions sent with default fees. The dynamic block size mechanism kicks in, allowing miners to create larger blocks. Miners are incentivized to include more transactions because the additional fees can offset the block reward penalty for exceeding the median block size.

Second, a fee market emerges where transactions with higher fee rates confirm faster. This is a self-correcting mechanism because as fees rise, some users delay non-urgent transactions, reducing demand. Meanwhile, the expanding block size accommodates more throughput until equilibrium is reached.

Historical Backlog Events

Monero has experienced notable mempool congestion events, often caused by spam attacks or sudden surges in legitimate usage. During these events, the network demonstrated its resilience through the dynamic block size adjustment. Blocks temporarily grew larger, fees increased modestly, and the backlog cleared within hours to days. These events have informed ongoing protocol improvements to handle demand more gracefully.

How Monero's Mempool Differs from Bitcoin's

The most significant difference between Monero's mempool and Bitcoin's is the privacy implication of mempool analysis. In Bitcoin, mempool watchers can extract substantial information from unconfirmed transactions because amounts, addresses, and transaction graphs are fully visible.

Bitcoin mempool analysis allows observers to:

• Track the flow of funds before they confirm
• Link inputs to outputs to build address clusters
• Identify the likely sender and receiver of a payment
• Detect consolidation transactions and estimate wallet balances
• Front-run transactions by observing pending trades

In Monero's mempool, none of this is possible. Each transaction in the mempool reveals only key images (which prevent double spending), encrypted amounts (hidden by RingCT), one-time stealth addresses (unlinkable to real addresses), and ring signatures (which obscure which output is actually being spent). An observer watching Monero's mempool sees transactions flowing through but cannot determine who is paying whom or how much.

Monitoring the Mempool

Several tools allow you to monitor the state of Monero's mempool in real time. These can be useful for estimating confirmation times, checking whether your transaction has been broadcast, and understanding current network conditions.

Popular Mempool Monitoring Tools

• xmrchain.net — The most popular Monero block explorer, featuring a dedicated transaction pool page showing current mempool size, transaction count, and individual pending transactions
• moneroblocks.info — An alternative explorer with clean mempool visualization and historical data
• Local daemon — Running your own Monero node gives you direct access to mempool data through RPC commands like get_transaction_pool and get_transaction_pool_stats
• P2Pool observers — If you mine with P2Pool, the observer pages show mempool statistics relevant to mining

When checking the mempool on a block explorer, remember that you are viewing data from that specific node. Due to network propagation delays and Dandelion++, a transaction might appear in one node's mempool slightly before or after another. If your transaction does not appear immediately after sending, wait thirty seconds and refresh.

What Users Should Know About Pending Transactions

For everyday Monero users and those swapping through MoneroSwapper, here are the practical takeaways about the mempool and pending transactions:

Confirmation times are predictable. Under normal conditions, Monero transactions confirm within two minutes on average. The two-minute block time means most transactions are included in the very next block after they enter the mempool.

Default fees are almost always sufficient. Unlike Bitcoin, where fee estimation is a complex art, Monero's default fee level works well for the vast majority of transactions. You only need to increase fees during rare congestion events.

Your privacy is protected even while pending. Unlike Bitcoin, where unconfirmed transactions in the mempool leak extensive information, Monero transactions reveal nothing useful to observers even before they confirm. Your amounts, addresses, and transaction graph remain hidden from the moment you hit send.

Transaction ID is safe to share. You can share your Monero transaction hash with a recipient or support team without compromising your privacy. The hash alone reveals nothing about the sender, receiver, or amount. It simply confirms that a transaction exists.

Stuck transactions are rare but recoverable. If a transaction remains in the mempool for an extended period, it will eventually be dropped and the funds returned to your wallet. You can also use the "rescan blockchain" feature in most wallets to recover funds from dropped transactions.

Conclusion

The mempool is a fundamental component of Monero's architecture that balances transaction throughput, fee markets, and privacy. Its design reflects Monero's core philosophy: even at the network infrastructure level, user privacy is protected. Whether you are making a simple transfer or executing a swap through MoneroSwapper, understanding how the mempool works helps you transact with confidence and realistic expectations about confirmation times and fees.