In this track: From send to settlement
beginner · 3 MIN READ

Why a transaction may fail

Rejection before inclusion differs from a revert during execution.

LET’S PICTURE IT

An office can refuse a malformed application at the door, or process a valid application and find that its requested action is not allowed.

SEE IT FOR YOURSELF
Follow a revert and decode its error dataStep 1 / 4
Follow a revert and decode its error dataRequested actionTransfer 100 raw unitsExample inputsAvailable balance40 raw unitsCheck the ruleA deliberately failing local scenario, not a live transactionCondition fails100 > 40Request rejectedRollbackNo successful transferConsumed gas still mattersTop-level failure and a caught nested failure have different contextsError selector0x08c379a04 bytesMessage tailNot enough tokensDynamic string encodingCustom errors and Panic use different selectors and schemasDecoded messageNot enough tokensA diagnostic clueFurther evidenceCaller and code pathRelevant stateError bytes can be constructed by code; decoding is not authentication

This fictional call requests a transfer of one hundred raw units while the relevant balance is forty.

Animated local teaching model. No wallet, RPC or live blockchain data. Some labels and hashes are abbreviated for readability.

Some requests are not valid transactions

Bad encoding, invalid authorization or unmet transaction-validity conditions can prevent inclusion. This is different from a valid transaction whose contract execution eventually reverts. Error messages from a provider may describe different stages.

Execution can revert

A contract might reject the caller, require a balance it does not have, or encounter another runtime problem. A top-level revert rolls back execution’s state changes, while already consumed gas remains chargeable.

Running out of gas is also failure

The gas limit bounds execution resources. If the computation cannot complete within the allowed gas, its intended state changes do not complete successfully. A larger limit is not a universal repair for a failed permission or logic check.

Collect the right evidence

Read the receipt’s status, inspect available revert bytes, and identify the failing call context. Our revert decoder interprets supplied error data; it cannot fetch a real trace or infer every failure from a transaction hash.

TURN UNDERSTANDING INTO PRACTICEOpen the Revert decoder →
QUICK CHECK · NO PRESSURE

Does every failed transaction mean its gas limit was too small?

Your progress stays in this browser.
Keep exploring the original referenceSolidity documentation ↗

Original explanations by EtherTools. Examples are educational and source-linked; this site is independent of the Ethereum Foundation. Our approach.