Parent Transaction

Overview

A parent transaction precedes a child in a transaction dependency graph because the child references one of its outputs. Nodes must know and validate the parent before they can fully validate the child.

When both are unconfirmed, mempool policies evaluate ancestor counts, sizes, conflicts, and sometimes combined fees. A high-fee child can improve the package’s mining incentive through child-pays-for-parent. Replacing or invalidating the parent can invalidate every descendant. Wallets should preserve the parent transaction identifier, output index, value, and confirmation status. They must broadcast dependencies in a supported order and monitor the full chain rather than only the final child. A confirmed parent provides a stable input reference, but the child’s own validity and settlement still require separate verification.

Unknown, pending, included, failed, replaced, and finalized conditions need separate handling, together with a recovery procedure for transactions whose observed state conflicts across providers. User-facing status should describe what is known without overstating settlement. Parent Transaction should be represented as a sequence of observable states rather than one success flag. 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.

Repeated callbacks, node disagreements, reorganization, and delayed receipts must not create duplicate credits or irreversible state transitions before the required network evidence is available. Implementations need idempotent processing keyed to stable transaction and business identifiers. Practical implication: A child’s validity and fee behavior depend on its parent, so monitoring must cover the entire transaction chain.