An Ethereum transaction receipt status answers a narrow question: did the top-level execution succeed or fail? Under EIP-658, status 1 means success and status 0 means failure. That result needs to be read alongside the requested action, execution costs and block state before an interface tells a user that a payment or other task is complete.

Submission is the beginning of the record

A transaction is a signed instruction to change Ethereum’s state. The Ethereum developer documentation describes a lifecycle in which a transaction is broadcast, enters a pool of pending transactions and is selected for inclusion in a block.

A transaction hash identifies the submitted instruction. It does not, by itself, establish the eventual execution result. A product that records the hash has evidence about which transaction it is following; it still needs to follow the result.

This distinction matters when a customer sends a support message containing a hash. The useful next question is what happened to that transaction on the intended network, rather than whether the customer can produce a screenshot of its submission.

What the receipt’s status records

EIP-658, created June 30, 2017, defines the receipt status for blocks from the Byzantium fork onward. It replaced the earlier intermediate state-root field with a success or failure code for the top-level call.

Status Meaning in EIP-658 What to investigate next
1 Top-level execution succeeded Did the executed action match the intended recipient, asset and business task?
0 Top-level execution failed What failure information is available, and what did execution cost?

The last column is an editorial reading checklist, not another status field defined by the EIP. The standard gives an execution outcome. A merchant’s fulfillment process or a service’s account-crediting rules require additional evidence from that system.

A successful instruction directed at the wrong address does not become the intended payment because its execution succeeded. Similarly, a successful contract call needs to be interpreted in the context of what function was requested. The Ethereum documentation distinguishes transfers to ordinary accounts from transactions that execute contract code.

Why gas usage cannot replace status

A tempting shortcut is to call a transaction failed only when it consumed all the gas provided. EIP-658 explains why that shortcut stopped being sufficient after the introduction of REVERT.

EIP-140 defines REVERT as a way to stop execution, roll back state changes and return error data without consuming all remaining gas. A failed transaction therefore need not use its whole gas allowance.

The inverse reading is also unsafe: unused gas does not establish success. Read the outcome field instead of deriving it from a cost pattern. This is precisely the ambiguity that EIP-658 set out to remove.

Reverting an action and paying for computation

Ethereum charges for the computation used to execute a transaction. Its developer documentation distinguishes the gas limit from the actual work and says unused gas is refunded.

EIP-140 explains that the rollback itself does not consume all gas. The contract still pays the memory cost associated with the REVERT instruction. It also specifies that insufficient gas for that instruction, or a stack underflow, produces an out-of-gas-style exception that consumes all gas.

These rules explain why “the action failed” and “nothing was spent on execution” are not interchangeable statements. A wallet should show the failed result separately from the execution charge rather than encouraging users to read one as the other.

This guide does not quote a current fee or recommend a gas setting. Costs depend on the transaction and network conditions; the protocol’s mechanics do not supply a universal dollar amount.

An error reason is a separate piece of evidence

REVERT can return data that the caller interprets as an error code or message. EIP-140 deliberately does not define the content of that memory section. A receipt status of 0 is therefore not a full explanation of why an application rejected an action.

When writing support copy, keep the layers visible. The execution failed; a provider or contract may expose a reason; the application then decides how to explain that reason to the user. Avoid replacing a missing explanation with an invented diagnosis such as “insufficient balance.”

A reason that appears in a simulation or diagnostic tool should also be identified as such. It is not interchangeable with a result confirmed for the submitted transaction.

Inclusion and finality answer another question

The Ethereum documentation describes a block progressing through justification and finalization after inclusion. That progression concerns confidence in the chain’s record. Receipt status concerns whether the instruction’s top-level execution succeeded.

A product can consequently need both an execution check and a block-state check. Its own fulfillment or crediting policy determines what additional conditions it requires. This article does not prescribe a confirmation count or claim that every exchange uses the same threshold.

The interface can keep its wording precise: submitted, included with successful execution, included with failed execution, and awaiting the service’s separate completion step describe different evidence. A generic “done” label obscures those distinctions.

A practical reading sequence

Start with the network and transaction identifier. Check inclusion and the execution status. Compare the requested recipient and contract action with what the user intended. Read any available failure explanation with its source attached, and examine execution costs separately.

For a service that credits an account or supplies goods after an on-chain action, follow that service’s completion criteria as well. The chain’s execution record and the service’s customer record are connected, but one does not contain every fact about the other.

Our analysis of moving money on-chain examines the wider cost question. The Crypto research desk follows wallets and digital-asset infrastructure without promising transaction recovery or investment returns.

Reporting & Sources

Official documents inspected October 9, 2026. This is an evergreen explanation, not a new protocol announcement or a report of live transaction tests.