Conflicting Transaction

Overview

A conflicting transaction competes with another transaction for mutually exclusive state. In a UTXO network, two transactions conflict when they spend the same output. In an account-based network, transactions using the same sender and nonce can conflict, often because one is intended to replace the other. Applications can also create business-level conflicts, such as two payout attempts allocating the same approved balance. A node may accept one candidate into its mempool and reject or later replace another according to local policy. Other nodes can temporarily observe a different candidate. Consensus resolves only what becomes valid canonical history; mempool presence, relay acceptance, or an API response is not a global decision. If neither candidate remains valid, both may ultimately disappear without confirmation.

Resolution starts by identifying the conflict key: spent output, sender and nonce, state version, idempotency key, or obligation identifier. Systems should retain every transaction hash, raw or signed payload reference, endpoint response, fee setting, observation time, block association, and replacement relationship. The canonical result must then be evaluated under the network’s transaction ordering and finality rules. For example, a wallet may deliberately submit a higher-fee transaction with the same nonce to accelerate or cancel a pending transfer. Treating the two hashes as independent payments would double-count the attempt, while treating the first as permanently failed before the replacement confirms can also be wrong. Payment operations should keep the customer order in a nonterminal state until the authoritative outcome is known. Fulfillment and accounting attach only to the winning canonical execution, while rejected, replaced, or expired candidates remain in the audit trail. Reorganizations require the conflict decision to be evaluated again rather than silently overwriting the earlier observation.