Dropped Transaction

Overview

A dropped transaction has disappeared from the active transaction pool observed by a node or provider without entering the canonical chain. This differs from an explicit execution failure: a dropped transaction normally has no confirmed receipt because it was never included. It also differs from a merely unconfirmed transaction that is still accepted and waiting in a mempool. Common causes include a fee below a node’s current relay threshold, mempool eviction under resource pressure, expiry rules, a missing parent transaction, a conflicting replacement, an invalid nonce sequence, or provider-specific policy. Nodes do not necessarily share identical pools. One endpoint can report “not found” while another still holds and propagates the signed transaction.

Diagnosis should query multiple appropriate sources, inspect the sender nonce or spent inputs, search canonical blocks, and look for replacements. The record should preserve the original hash, signed-payload reference, first and last observation times, provider responses, fee settings, dependencies, and any conflict. A single unsuccessful lookup is not enough to declare the transaction permanently dead. If recovery requires rebroadcasting through transaction broadcasting, the service can often resend the identical signed payload without creating a new transfer. Creating a new transaction is riskier because the original may still confirm. Account-based systems must examine nonce state; UTXO systems must confirm that the inputs remain unspent. Customer and ledger status should stay pending or under review until the system establishes one of three outcomes: the original confirmed, a linked replacement confirmed, or the original became impossible under authoritative chain state. This approach prevents duplicate payments and preserves evidence for reconciliation when providers disagree or a delayed transaction reappears.