Mempool Admission

Overview

Mempool admission occurs when a node evaluates a received transaction for temporary storage and possible relay. Checks commonly include syntax, signatures, available inputs or nonce, fee rate, standardness, ancestor limits, replacement rules, and current chain state. Admission policy can be stricter than consensus validity. A transaction rejected from one node’s mempool might still be mineable in a block or accepted by a differently configured peer. Results also change as fees, conflicts, and chain state evolve.

Clients should capture structured rejection reasons and avoid treating a generic broadcast response as confirmation. They may use multiple well-managed endpoints while preventing unsafe duplicate construction. Operators should tune policy cautiously, because overly permissive settings expose memory and CPU resources, while excessive restrictions reduce useful propagation. Unknown, pending, included, failed, replaced, and finalized conditions need separate handling, together with a recovery procedure for transactions whose observed state conflicts across providers. Status labels should describe what is known without overstating settlement.

Mempool Admission 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. Systems need idempotent processing keyed to stable transaction and business identifiers. Settlement consideration: Mempool admission applies local relay and resource policy beyond consensus, so acceptance can differ across nodes and change over time.