<p>Each node maintains a separate, individual mempool. While the default limits its size to 300 MiB, each node operator can set their own value. Note that the mempool size limit does not pertain to the serialized data or the transaction weight of the queued transactions (which is what is written to the block and what you see listed on a mempool monitors respectively), but to the actual memory usage of the deserialized transaction data on the node. This memory usage is platform dependent. In result, transactions start getting dropped when mempool monitors reach a block depth of about 80-95 blocks.</p>
<p>When a node's mempool limit is reached, it will drop the transactions with the lowest feerate and increase its <code>minMempoolFeeRate</code>. It will communicate its new <code>minMempoolFeeRate</code> to its peers, basically telling peers not to forward transactions below that feerate for the time being. Note that every node does this individually, so a node with a larger mempool or different architecture may drop transactions earlier or later. Nodes will keep a copy of transactions that are relevant to their own wallet. Even if all other nodes have dropped a transaction, the sender and recipients of a transaction would retain a copy. The sender can either force his node to drop the original transaction and send another conflicting transaction to update it, or their node will continue to try to broadcast the transaction so that it will eventually get relayed on the network again once the queue has receded.</p>
<p>After the queue decreases under the 300 MiB limit and with some added delay, a node will lower their <code>minMempoolFeeRate</code> and start accepting transactions again that it previously expelled.</p>
<p>You can currently observe this happening e.g. on <a href="https://jochen-hoenicke.de/queue/#1,24h" rel="nofollow noreferrer">Johoe's mempool monitor</a>¹: <a href="https://i.sstatic.net/U5oJP.png" rel="nofollow noreferrer"><img src="https://i.sstatic.net/U5oJP.png" alt="Last 24h of BTC (default mempool)" /></a></p>
<p>As you can see, the 1-2 sat/B band dropped around 7am that morning when the node's mempool exceeded its limit.</p>
<hr />
<p><sup>¹Note that there are two BTC views and the linked and relevant in this case is <code>BTC (default mempool)</code>)</sup></p>

CC BY-SA 4.0
2020-05-21T19:08:18.443Z
2024-03-20T20:11:25.190Z
2024-03-20T20:11:25.190Z
Murch
<p>Firstly, there is no "the bitcoin mempool". Each node on the Bitcoin network maintains its own mempool and each node can have different settings and rules for allowing transactions into its mempool.</p>

<p>The default mempool maximum size is 300 MB. When the maximum is reached (regardless of what it is), a node will begin to evict lower priority (i.e. transactions paying a lower fee rate) and increase its minimum acceptable fee rate. It does this to keep the mempool size at or under the configured size and will remove transactions and raise the minimum fee rate as needed to maintain this.</p>

<p>Since most nodes are probably using the default of 300 MB, many transactions that pay a low transaction fee probably will not be confirmed and will need to be rebroadcast at a later date when fees are not so high. Or those transactions can be replaced with a conflicting one that has a higher fee rate.</p>

CC BY-SA 4.0
2020-05-21T18:53:07.320Z
2020-05-21T18:53:07.320Z
Ava Chow
<p>The bitcoin mempool size is at 108 MB and still climbing according to chain.so. It is slowly approaching 300 megabytes, which is said to be the mempool limit for BTC. What happens after 300 MB?</p>

<mempool>
What if the mempool exceeds 300 MB?
Number File
# What if the mempool exceeds 300 MB?

(Asked by: username_0 on 2020-05-21)

The bitcoin mempool size is at 108 MB and still climbing according to chain.so. It is slowly approaching 300 megabytes, which is said to be the mempool limit for BTC. What happens after 300 MB?

**Tags:** mempool


---

## 2 answers

### Answer by username_1 on 2020-05-21. Score: 13

Each node maintains a separate, individual mempool. While the default limits its size to 300 MiB, each node operator can set their own value. Note that the mempool size limit does not pertain to the serialized data or the transaction weight of the queued transactions (which is what is written to the block and what you see listed on a mempool monitors respectively), but to the actual memory usage of the deserialized transaction data on the node. This memory usage is platform dependent. In result, transactions start getting dropped when mempool monitors reach a block depth of about 80-95 blocks.

When a node's mempool limit is reached, it will drop the transactions with the lowest feerate and increase its `minMempoolFeeRate`. It will communicate its new `minMempoolFeeRate` to its peers, basically telling peers not to forward transactions below that feerate for the time being. Note that every node does this individually, so a node with a larger mempool or different architecture may drop transactions earlier or later. Nodes will keep a copy of transactions that are relevant to their own wallet. Even if all other nodes have dropped a transaction, the sender and recipients of a transaction would retain a copy. The sender can either force his node to drop the original transaction and send another conflicting transaction to update it, or their node will continue to try to broadcast the transaction so that it will eventually get relayed on the network again once the queue has receded.

After the queue decreases under the 300 MiB limit and with some added delay, a node will lower their `minMempoolFeeRate` and start accepting transactions again that it previously expelled.

You can currently observe this happening e.g. on [Johoe's mempool monitor](https://jochen-hoenicke.de/queue/#1,24h)¹: [![Last 24h of BTC (default mempool)](https://i.sstatic.net/U5oJP.png)](https://i.sstatic.net/U5oJP.png)

As you can see, the 1-2 sat/B band dropped around 7am that morning when the node's mempool exceeded its limit.

---

¹Note that there are two BTC views and the linked and relevant in this case is `BTC (default mempool)`)


---

### Answer by username_2 on 2020-05-21. Score: 5

Firstly, there is no "the bitcoin mempool". Each node on the Bitcoin network maintains its own mempool and each node can have different settings and rules for allowing transactions into its mempool.

The default mempool maximum size is 300 MB. When the maximum is reached (regardless of what it is), a node will begin to evict lower priority (i.e. transactions paying a lower fee rate) and increase its minimum acceptable fee rate. It does this to keep the mempool size at or under the configured size and will remove transactions and raise the minimum fee rate as needed to maintain this.

Since most nodes are probably using the default of 300 MB, many transactions that pay a low transaction fee probably will not be confirmed and will need to be rebroadcast at a later date when fees are not so high. Or those transactions can be replaced with a conflicting one that has a higher fee rate.


---

