In this track: Write and read Solidity
advanced · 4 MIN READ

Require, revert and assert

Failure mechanisms express different conditions and error shapes.

LET’S PICTURE IT

A form can fail a user requirement or reveal a violated internal rule; both stop the operation but carry different diagnostic meaning.

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.

Require checks a condition

A require condition can reject an operation when a required property is false. Its message or custom error syntax depends on the source and compiler features being used.

Revert signals an explicit failure

A revert can return an error encoding, including a custom error with typed arguments. State changes in the affected call are rolled back, while consumed work still has gas consequences.

Assert expresses an internal invariant

An assertion is intended for properties that should hold if the program’s logic is correct. A failed assertion has a panic form rather than being a substitute for every user-input check.

Decode, then investigate

The error name identifies a byte shape. The actual cause still needs the code path and state. A malicious contract can construct misleading error bytes, so decoding is not authentication.

Read the example

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.20;

contract LearningExample {
    function half(uint256 x) external pure returns (uint256) {
        require(x % 2 == 0, "Use an even number");
        return x / 2;
    }
}

Odd input intentionally reverts with a readable Error(string).

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

Does a successful error decode prove the emitting contract told the truth?

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.