Mempool Policy

Overview

Mempool policy protects node resources and encourages transactions that can propagate and confirm efficiently. Rules may cover standard script forms, minimum fees, package limits, replace-by-fee, ancestor counts, data size, nonce gaps, and expiry. Policy is not consensus. A block containing a transaction that violates ordinary relay policy can still be valid if the transaction meets consensus rules. Software versions and operator configuration can therefore produce different mempool behavior across nodes.

Wallet developers should test against widely deployed policy and interpret rejection codes precisely. Node operators should change defaults only with clear capacity and network-impact analysis. Payment services must not label a policy rejection as proof of an invalid payment, and should monitor upgrades that alter relay or replacement behavior.

Submission, peer acceptance, block inclusion, execution, confirmation, and finality provide different evidence, and a transaction can advance, stall, be replaced, or disappear from the canonical chain between those stages. Mempool Policy should be represented as a sequence of observable states rather than one success flag. Operational systems need idempotent processing keyed to stable transaction and business identifiers. Repeated callbacks, node disagreements, reorganization, and delayed receipts must not create duplicate credits or irreversible state transitions before the required network evidence is available.

These records allow a later rescan to reconstruct the result when an endpoint, webhook, or local index becomes unreliable. Operational records should retain the raw transaction, network identifier, sender and destination, asset and amount, block reference, execution status, and observed timestamps. Practical implication: Mempool policy governs local unconfirmed handling beyond consensus, creating legitimate differences among nodes, versions, and relay paths.