Package relay
Package relay is a transaction-relay and mempool-acceptance policy in which a group of related transactions is evaluated together rather than one at a time. The usual case is a parent that pays little or no fee and a child that pays enough for both (child-pays-for-parent). Without package relay, a node that enforces a minimum relay feerate drops the parent and never learns about the child.
Bitcoin P2P transaction relay historically advertised one txid at a time. A peer who receives a transaction below minrelaytxfee rejects it. Contracting protocols that sign zero-fee or low-fee parents and bump them with a child therefore fail to propagate on nodes that have not already accepted the parent by other means. Local submitpackage allowed submitting a package to one node, but peers could not request packages from each other.
Package rules
A package is a list of transactions in topological order. Validation applies consensus rules to each transaction, then package-level policy: the package feerate must meet the mempool minimum, transactions must not conflict with one another, and for the limited 1-parent-1-child (1p1c) case the graph must be one parent and one child. The parent may be below the minimum relay feerate if the package as a whole is not.
Opportunistic relay
On the P2P network, when a node rejects a transaction as too low-feerate, it may remember the txid briefly. If a later child arrives that spends that txid, the node requests the parent again and validates the pair. Bitcoin Core 28.0 implemented this opportunistic 1p1c path and allowed TRUC parents to pay zero fee. Bitcoin Core 31.0 extended zero-fee parents to non-TRUC 1p1c packages. A child may have additional parents that are already in the mempool. A child with several unconfirmed missing parents is not covered by this limited P2P feature.
Full peer-to-peer package negotiation (sometimes discussed as BIP 331 style package relay) would let nodes announce and request packages explicitly. Bitcoin Core's opportunistic path is narrower. It reconstructs a 1p1c package only when a low-feerate parent was recently rejected and a spending child later arrives. That is enough for many TRUC and ephemeral-anchor flows. It is not a general multi-parent package gossip protocol.
Wallets that need guaranteed local acceptance can still use submitpackage even when opportunistic P2P reconstruction fails on some peers.
Related policies
Package RBF (documented on Mempool) lets a package replace in-mempool transactions when the replacement is incentive-compatible. Ephemeral anchor constructions depend on package relay: a zero-fee parent with a dust pay-to-anchor output is not accepted alone and must arrive with its child.
Package acceptance interacts with cluster mempool limits and replace-by-fee rules. A package that would create an oversized cluster or that fails incentive-compatibility checks is rejected even if each transaction is consensus-valid. Wallet software that builds CPFP bumps should prefer topologies that match the 1p1c policy when targeting broad relay, or submit directly to miners and to local submitpackage when more complex graphs are required.