The Memory Pool: Architecture, Eviction, and Fee Floor Dynamics

The Memory Pool (or Mempool) represents a node's in-memory waiting area for validated, unconfirmed transactions. It forms the transactional staging layer where transactions reside before they are compiled into a candidate block by a miner.

Rather than being a single, unified global network database, the mempool is entirely localized. Each node on the network independently manages its own transaction cache according to its local policies, system memory limits, and fee criteria.

---

🏗️ 1. Transaction Admission and the Mempool Lifecycle

Before any transaction can enter a local node's mempool, it must pass a series of strict consensus validation checks and policy filters.

                      TRANSACTION VALIDATION AND MEMPOOL PATHWAY

                       ┌──────────────────────────────────┐
                       │  Incoming Raw Transaction Bytes │
                       └────────────────┬─────────────────┘
                                        │
                                        ▼
                       ┌──────────────────────────────────┐
                       │     Consensus validation Engine   │
                       │  • Are inputs unspent? (UTXO)    │
                       │  • Are signatures correct? (Sig) │
                       │  • No double-spends in chain?    │
                       └────────────────┬─────────────────┘
                                        │ (Pass)
                                        ▼
                       ┌──────────────────────────────────┐
                       │      Policy Filter (Standard)    │
                       │  • Is size below 100,000 vBytes? │
                       │  • Feerate >= minrelaytxfee?     │
                       │  • Non-standard scripts rejected?│
                       └────────────────┬─────────────────┘
                                        │ (Pass)
                                        ▼
                       ┌──────────────────────────────────┐
                       │      Admission to Local RAM       │
                       │  (Propagated to connected peers) │
                       └──────────────────────────────────┘

The Three Ingestion Pathways

• Local Node Submission: A transaction generated directly by the node's native wallet or pushed externally via the sendrawtransaction or submitpackage JSON-RPC commands.
• P2P Network Propagation: Received from connected peer nodes via P2P network gossip. The announcing peer sends an inv (inventory) message containing the transaction hash; if the receiving node does not have it, it requests the full transaction data using a getdata message.
• Chain Reorganization Recovery: When a node disconnects blocks during a chain fork to follow a longer Proof of Work chain, any transactions from the disconnected blocks that are not included in the new chain are recycled back into the mempool so they can be re-broadcast and mined in future blocks.

---

📈 2. Volatile RAM Management and Size-Based Evictions

Because the mempool must be parsed and searched in real time during peer transaction validation, it is hosted entirely in system RAM rather than on non-volatile disk storage.

                       RAM MEMORY VS. SERIALIZED PAYLOAD SIZES

      ┌─────────────────────────────────────────────────────────┐
      │  Serialized Transaction Bytes on P2P Wire (e.g. 100 MB) │
      └────────────────────────────┬────────────────────────────┘
                                   │
                                   ▼  [Inflated via Database Overhead]
      ┌─────────────────────────────────────────────────────────┐
      │  Local RAM Database Allocation in Node (e.g. 300-400 MB) │
      │  • Tx Indexes & UTXO Lookups                            │
      │  • Ancestor / Descendant Tree Metadata (DAG)            │
      │  • Multi-index sorting structures                       │
      └─────────────────────────────────────────────────────────┘

• Serialized vs. Real Memory Footprint: A raw transaction may represent only $250$ bytes of serialized network data, but inside the node's RAM, it consumes roughly $1,000$ bytes of memory. This is due to the C++ class structures, indexing pointers, ancestor/descendant tracking structures, and search maps required to maintain the database.
• The default limit (maxmempool): By default, Bitcoin Core limits total RAM allocation to $300\text{ MB}$ (configurable with maxmempool=<n> in bitcoin.conf). If a node runs out of memory, it does not crash; instead, it triggers the Mempool Eviction Pipeline.

---

📉 3. The Dynamic Eviction Pipeline

When the real RAM utilization of a node's mempool exceeds the maxmempool setting:

1. Sorting and Slicing: The node evaluates the eviction scoring of all unconfirmed transactions. Scoring is based on the Descendant Feerate of each transaction package.
2. Trimming the Tail: The node identifies the transaction package with the absolute lowest scoring feerate and evicts it completely from RAM, along with all of its descendant transactions.
3. Elevating the Minimum Floor (mempoolminfee): Once evictions occur, the minimum acceptable fee floor for new transaction admission is dynamically elevated: $$\text{mempoolminfee} = \max(\text{minrelaytxfee}, \text{Feerate of evicted package} + \text{incrementalrelayfee})$$
4. Rejection of New Low-Fee Transactions: Any incoming transaction whose feerate is lower than the updated mempoolminfee is immediately rejected.
5. Linear Fee-Floor Decay: Over time, as transactions get mined and memory pressure decreases, the dynamic fee floor slowly decays. It halves approximately every $12\text{ hours}$ of idle time until it returns to the base static configuration level of $1\text{ sat/vB}$ (minrelaytxfee).