Ethereum Receipt Status: Success Is Not a Transfer
Read Ethereum transaction receipt status correctly, distinguish execution success from token movement, and test failed and empty-log cases.
Overview
When translating these concepts into an integration, keep the scope described by the wallet history api with the result. The examples in wallet transaction history and smart contract event logs show how the same distinction affects neighbouring data questions.
A successful transaction receipt says that top-level execution completed successfully. It does not say which business action happened or whether an expected token transfer occurred. Applications need both execution evidence and a rule for interpreting that evidence.
Read the receipt before interpreting events
A receipt can include status, gas used, block references and logs. Status zero signals failure for modern Ethereum receipts; status one signals success. A successful call may only update configuration or emit no relevant event. A failed transaction can still consume gas, so excluding it from every accounting view loses an economic cost.
Worked example: approving instead of paying
A customer submits an approval transaction. Its receipt succeeds, but the token Transfer event expected by a payment monitor is absent. Marking the invoice paid from status alone is wrong. The monitor must validate the intended token contract, recipient and amount using appropriate transfer evidence and a confirmation policy.
Test the uncomfortable cases
Keep separate fields for execution outcome and interpreted activity. Test a reverted call with a fee, a successful call with no logs, a transaction not yet included and a receipt that moves out of the accepted chain. A null receipt should remain unresolved rather than becoming either a failed payment or a zero-value transfer.
A practical acceptance test
Use four fixtures: null receipt, status-zero receipt with gas cost, status-one receipt with no relevant logs, and status-one receipt with a validated transfer. Assert distinct outcomes. In particular, only the final fixture should satisfy a token-payment rule, while the failed fixture still retains its execution fee and the null fixture remains unresolved.
Questions about the topic
Frequently asked questions
Can a failed transaction have a fee?
Yes. Execution can fail after consuming gas.
Does every successful token transaction emit Transfer?
No. A token-related call can perform another action, such as granting an allowance.
Standards & technical documentation
