Reverted Transaction

Overview

A transaction can revert because a contract explicitly rejects a condition, an assertion fails, a called contract reverts, execution runs out of gas, or another runtime rule prevents completion. The transaction can still appear in a valid block with a transaction hash and receipt.

Ethereum-style execution is atomic for the transaction’s state changes: when execution reverts, changes made in the failed call context are discarded according to call semantics. Gas already consumed is not refunded as if no work occurred, so the sender can lose fees without receiving the intended outcome.

The receipt status is the primary high-level indicator of success or failure. Debug traces or revert data can provide a reason, but providers may not retain or expose all traces. Logs from a failed top-level transaction should not be treated as completed payment evidence.

Payment systems should map a reverted transaction to a failed execution state rather than unpaid, missing, or confirmed success. A user may submit a replacement or a new transaction, so the order record should support multiple attempts without duplicating fulfillment.

Reversion is separate from a dropped transaction or chain reorganization. A reverted transaction executed in a canonical block; a dropped transaction was not included, and a reorganized receipt may cease to be canonical. Support tools should preserve these distinctions and the fees associated with each attempt.

In practice, a payment processor should record the failed receipt status, transaction and block hashes, gas charged, available revert data, and any replacement attempt. For example, if a token transfer reverts because the contract rejects the call, the order must remain unfulfilled even though the transaction is confirmed and a fee was paid. Preserving this evidence lets support and reconciliation teams reproduce the decision later.