require/revert Without a Reason String

SAFE-0306 Best Practice Checked automatically by the scanner

What goes wrong

require()/revert() is used without a descriptive reason. Failures surface as opaque reverts, complicating debugging, off-chain monitoring, and user-facing error handling.

The vulnerable pattern

proof of concept — how it is exploited

// require(ok);   // reverts with no reason
// integrators and users see only 'execution reverted' — hard to diagnose
// which invariant failed during an incident.

How to fix it

the pattern that is safe

require(cond, "descriptive reason");
// or a custom error: error NotOwner(); if (msg.sender != owner) revert NotOwner();

◆

Use reason strings or custom errors on every revert.

Where this has happened

Largest recorded losses in the same failure class — related, not the same bug:

$69.3M · 2023 Curve Finance · Vyper compiler Compiler / toolchain + Reentrancy · 2023

Related vulnerabilities in Best Practice

SAFE-0076Use of Deprecated / Dangerous Constructs (selfdestruct, suicide, throw) medium · Best Practice SAFE-0079Outdated Compiler / Known Compiler Bug Exposure medium · Best Practice SAFE-0083Emergency Pause Missing / Pause Bypass medium · Best Practice SAFE-0075Missing Event Emission on Critical Action low · Best Practice SAFE-0077Dead Code / Unreachable or Unused Critical Variable low · Best Practice SAFE-0078Floating / Unlocked Pragma low · Best Practice SAFE-0097Assert/Require Misuse and Improper Error Handling low · Best Practice SAFE-0138Floating / Unlocked Pragma low · Best Practice

← PreviousReentrancy Guard Not Applied to Every External State-Changer Next →Custom Boolean Reentrancy Lock (Fragile)

Check your own contract for this

The SaferICO scanner runs 201 detectors over your Solidity source, SAFE-0306 among them. Paste an address or the source itself — a small per-scan fee, shown before you sign, or unlimited on any plan.

Run the scanner See how it is attacked Read the docs