A failed call can return no diagnostic bytes at all.
LET’S PICTURE IT
A process can stop without handing back a written explanation.
SEE IT FOR YOURSELF
Follow a revert and decode its error dataStep 1 / 4
This fictional call requests a transfer of one hundred raw units while the relevant balance is forty.
This fictional call requests a transfer of one hundred raw units while the relevant balance is forty.The contract rejects this request. State changes in the reverted call are rolled back, while work already consumed can still cost gas.A common Error(string) begins with selector 08c379a0. This example then encodes the message Not enough tokens.A decoder can recognize the supplied error shape. Identifying the true cause and source still needs the call context, code and state.
Animated local teaching model. No wallet, RPC or live blockchain data. Some labels and hashes are abbreviated for readability.
Separate failure from its payload
The call outcome and returned byte sequence are different pieces of information. A failure with empty data remains a failure; empty bytes do not imply success.
Recognize possible causes
Code can deliberately revert with no data. Exceptional execution such as running out of gas can also leave no usable explanation, depending on where the failure occurs.
Avoid inventing a reason
A decoder cannot recover an absent message from an empty sequence. Present the lack of revert data and keep the original call context available for further investigation.
Inspect additional evidence
A local trace, gas conditions, inputs and matching code can narrow the cause. The receipt alone may not expose the exact internal operation that failed.
Inspect the example
Low-level outcome: success = false
Returned bytes: 0x
No selector or arguments are available to decode.
A data decoder cannot determine the missing reason from 0x alone.