Mempool Eviction

Overview

Nodes evict transactions to control memory use and maintain a useful pool of likely block candidates. Low-fee transactions may be removed when capacity fills, while confirmed conflicts, invalidated dependencies, expiration rules, or reorganizations can trigger other removals. Eviction is local and does not cancel the transaction everywhere. Another node or miner may still retain and confirm it. A wallet that creates a replacement must follow network rules and avoid assuming the original can never reappear. Applications should track transaction status across several states, including seen, dropped, replaced, conflicted, and confirmed. Re-broadcast or fee-bumping logic must verify inputs and nonces first. Operators should expose eviction metrics and current minimum fee so users understand why an accepted transaction disappeared.

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. Mempool Eviction should be represented as a sequence of observable states rather than one success flag. Systems need idempotent processing keyed to stable transaction and business identifiers. Repeated callbacks, node disagreements, reorganization, and delayed receipts must not create duplicate credits or irreversible state transitions before the required network evidence is available.

These records allow a later rescan to reconstruct the result when an endpoint, webhook, or local index becomes unreliable. Operational records should retain the raw transaction, network identifier, sender and destination, asset and amount, block reference, execution status, and observed timestamps. Implementation note: Mempool eviction is a local retention decision, not network-wide cancellation, so dropped transactions can remain live or later confirm.