Package Mempool Acceptance

Overview

Package mempool acceptance treats a dependency-connected group, such as a low-fee parent and higher-fee child, as one candidate for policy evaluation. This can enable fee assessment that individual transaction review would reject.

The node checks transaction validity, dependency order, combined fees, conflicts, size, and ancestor or descendant limits. Exact package rules depend on node software and version. Acceptance is local relay policy, not a consensus rule or promise of mining. Wallets using child-pays-for-parent must understand which package shapes peers support and whether the parent is already known. Testing through a local node can predict its own decision but not every peer’s. Monitoring should track both transactions because replacement, eviction, or invalidation of an ancestor affects the entire package. Repeated callbacks, node disagreements, reorganization, and delayed receipts must not create duplicate credits or irreversible state transitions before the required network evidence is available. Systems need idempotent processing keyed to stable transaction and business identifiers.

Operational records should retain the raw transaction, network identifier, sender and destination, asset and amount, block reference, execution status, and observed timestamps. These records allow a later rescan to reconstruct the result when an endpoint, webhook, or local index becomes unreliable. Unknown, pending, included, failed, replaced, and finalized conditions need separate handling, together with a recovery procedure for transactions whose observed state conflicts across providers. Customer-facing status should describe what is known without overstating settlement.

Practical implication: Package acceptance can evaluate combined economics, but support is local policy and does not guarantee propagation or confirmation.

Package mempool acceptance evaluates related unconfirmed transactions together when deciding whether a node will admit them to its local mempool.