In this answer (https://ethereum.stackexchange.com/a/6010/1529) it seems to say that the status field will always be '1' unless the transaction failed, in which case it will be '0'.

In the summary section of this answer (https://ethereum.stackexchange.com/a/28078/1529), it seems to imply that the status field is only set to zero when 'revert' was called.

What is the exact meaning of the status field?

Does receipt.status of '0' indicate errors of all kinds or only reverts?

Does receipt.status of '1' always indicate a successful transaction?

Here's an example of a transaction with a 'Fail' status (i.e. '0') and an 'out of gas' reported error: https://etherscan.io/tx/0xeec4ccd13fe05907f9d732a8ad245bcb7f918217157b89baaa23895c12eb329a. What happened here?

Related question: Does the new receipt status field report all errors all the way down the call chain?

  • I will award the bounty to the most thorough (and most correct) answer. Commented Oct 28, 2017 at 21:27

1 Answer 1


This was described by EIP 658 which was implemented in the Byzantium fork. The text of the EIP is here, though strangely it doesn't seem to have been formally finalised before the fork.

In any case, the relevant text is this:

For blocks where block.number >= METROPOLIS_FORK_BLKNUM, the intermediate state root is replaced by a status code, 0 indicating failure (due to any operation that can cause the transaction or top-level call to revert) and 1 indicating success.

In terms of your question, then, 1 always equals success. I'm pretty certain that "revert" here doesn't mean "resulting from the revert opcode", but means, essentially, any conditition that causes the state to be reverted - including all the conditions that were formerly called "throws".

Now, note that EIP 658 is also called EIP 98, and is also described here

EIP98 is authored by Vitalik:

Option 3 (update 2017.07.28: we are going with this one): For blocks where block.number >= METROPOLIS_FORK_BLKNUM, the intermediate state root parameter in the receipt should be set to a \x01 byte if the outermost code execution succeeded, or a zero byte if the outermost code execution failed.

This confirms that failed transactions (whatever the failure mode) result in 0, only successful should result in 1. It applies only to the "outermost code execution".

Finally, for the ultimate authority, see the Yellow Paper update by Yoichi (not yet merged).

It defines a status code, s'.

It's a bit difficult to read in that form, but I think the relevant definition of the status code is this:

Line 775:

The account's associated code (identified as the fragment whose Keccak hash is $\boldsymbol{\sigma}[c]_c$) is executed according to the execution model (see section \ref{ch:model}). Just as with contract creation, if the execution halts in an exceptional fashion (i.e. due to an exhausted gas supply, stack underflow, invalid jump destination or invalid instruction), then no gas is refunded to the caller and the state is reverted to the point immediately prior to balance transfer (i.e. $\boldsymbol{\sigma}$).

Line 782 I think says, if the state is thus reverted, then s' is zero:

+s' & \equiv & \begin{cases}
+0 & \text{if} \quad \boldsymbol{\sigma}^{**} = \varnothing \\
+1 & \text{otherwise}

Other references to s' are in there, and may shed more light.

  • I feel confident that this answers the question. The first part (EIP658) is, I think, the source of the problem. That should be made more clear, I think. The second part, option 3, of EIP 98, is way more clear, and the text from the Yellow paper is very clear that it includes all failure modes. I'll leave this bounty out for a while to see if anyone contradicts and then award the bounty in a couple of days. Thanks for the answer. Commented Oct 29, 2017 at 2:24
  • @ThomasJayRush Thanks. I do feel that the EIP process could be improved somewhat. It's not good that there are unmerged documents with ambiguous numbering; that the main EIP page links to docs that are not normative, that there doesn't seem to be a canonical up-to-date PDF version of the YP around. It is all a bit sloppy, really. Commented Oct 29, 2017 at 7:12
  • It's pretty messy. Do you participate in the process? I would, but I don't really know how. Commented Oct 29, 2017 at 11:51
  • @ThomasJayRush The pre-release EIP process is easy enough to contribute to - it's all run on the Ethereum GitHub and anyone can comment. But the "formalisation" process seems quite casual. EIPs are discussed on the fortnightly All Core Devs call, and agreement emerges; documenting that agreement formally looks to be a weak point. Yoichi is doing a great job on the YP, but no-one is merging his PRs to keep it updated. Commented Oct 29, 2017 at 12:04

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.