Insights on Crypto Payments, Infrastructure, and Operations

Package Mempool Acceptance

Pronunciation: PA-kuhj MEM-pool ak-SEHP-tuns

Definition

Package mempool acceptance evaluates related unconfirmed transactions together when deciding whether a node will admit them to its local mempool. 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. Package acceptance evaluates related unconfirmed transactions together, subject to the node's current relay rules.

Overview

Meaning and scope

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.

How it works

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. Systems need idempotent processing keyed to stable transaction and business identifiers.

Operational checks and limits

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 acceptance evaluates related unconfirmed transactions together, subject to the node’s current relay rules. A child with a suitable fee may help a low-fee parent become economical to mine.

Practical example

A Bitcoin wallet offers a parent and spending child as one package so nodes can assess their combined fee contribution.

Distinctions

Package policy differs from consensus validity and from the separate question of whether miners will ultimately include the package.

How to evaluate it

Fee and transaction handling policies can vary across nodes and over time; for Package Mempool Acceptance, evaluate the actual policy of the network and the submitting service instead of assuming that a theoretical transaction strategy will be accepted everywhere. When evaluating Package Mempool Acceptance, a business should keep the original transaction identifiers, replacement or child relationships, fee estimates, and confirmation outcome together so that one obligation is not counted twice. Related concepts: mempool.

Example

A Bitcoin wallet offers a parent and spending child as one package so nodes can assess their combined fee contribution.

Comparison

Package policy differs from consensus validity and from the separate question of whether miners will ultimately include the package.

Key Takeaway

Evaluate related unconfirmed transactions under the actual node policy.

Sources

  1. Bitcoin.org Documentation: P2P Network — Bitcoin.org (2026-07-30)
  2. Ethereum Foundation Documentation: Transactions — Ethereum Foundation (2026-07-30)
  3. Bitcoin Developer Guide: Transactions — Bitcoin.org (2026-07-30)