Transaction Pool

Overview

When a node receives a transaction, it checks basic protocol validity and local relay policy before adding it to the pool. The transaction may then be announced to peers and considered by miners, validators, builders, or sequencers.

Pool management becomes important during congestion. Nodes can prioritize transactions by fee, age, dependency, or policy and may evict low-priority entries when memory limits are reached. Account-based pools must also track nonce order, while UTXO pools reject conflicting spends.

Replacement rules allow a sender to submit a competing transaction with the same inputs or nonce under specified fee conditions. Different nodes can prefer different versions temporarily. This is why payment systems should not treat one mempool observation as final.

Transaction pools support fee estimation and early payment detection, but they create privacy and reliability concerns. Observers can analyze transaction propagation, and a node can be isolated from relevant transactions.

Applications should monitor whether a transaction is pending, dropped, replaced, or included. Recovery logic should query multiple sources when necessary. The pool is a staging area for candidate transactions, not a shared authoritative ledger or guaranteed queue.

Pool monitoring can reveal congestion, fee pressure, and replacement activity, but it should not expose sensitive transaction intent unnecessarily. Private or institutional transactions may use relays that bypass the public pool entirely. Fee estimators should therefore combine mempool data with recent block inclusion. Nodes that run in block-only or restricted-relay modes cannot provide a complete pending view and should not be the sole source for time-sensitive payment detection.