What it means
Contracts check conditions before acting. When a check fails, the contract executes a revert, which stops execution and undoes every state change made so far. EIP-140, which introduced the instruction, describes it as a way to stop execution and revert state changes without consuming all the provided gas, and with the ability to return a reason.
Etherscan puts the user-facing consequence plainly: for a transaction marked as reverted, the transaction did not execute and all state was returned to how it was beforehand. Your balances are unchanged apart from the fee.
Why it happens
A missing or insufficient token approval
Contracts that move your tokens need an allowance first. If none exists, or it is smaller than the amount, the transfer reverts. See token approvals.
A slippage or deadline condition failed
Swaps specify a minimum acceptable output and often a deadline. If the price moves beyond your tolerance, or the transaction confirms too late, the contract reverts rather than giving you a worse result than you agreed to. This is the protection working.
A balance or eligibility check failed
Sending more tokens than you hold, claiming something already claimed, or interacting with a paused or closed contract all produce reverts.
The conditions changed before inclusion
A transaction simulated successfully can still revert if the state it depended on changes before it executes.
How to fix it
- Open the transaction on a block explorer. Many reverts carry a reason string, and it is usually specific enough to act on.
- If the reason mentions an allowance, set or increase the approval and retry.
- If it mentions slippage, price or a deadline, retry with a wider tolerance — understanding that a wider tolerance means accepting a worse possible price.
- Check that you actually hold what the transaction assumes, on the network it is running on.
- If it reverts repeatedly with no clear reason, stop retrying. Each attempt costs another fee.
How to avoid it
Read what a transaction is asking for before signing, and prefer applications that surface the revert reason rather than a generic failure. Repeatedly resubmitting a reverting transaction is the expensive mistake: the fee is charged every time, because execution happened every time.
Frequently asked
Why was I charged for a reverted transaction?
Because the contract executed up to the point it decided to stop. The work was performed and the fee pays for it, even though the state changes were rolled back.
Are my tokens safe?
Yes. A revert rolls back every state change the transaction made, so balances are as they were before it ran, minus the fee.
How do I find the reason?
Look at the transaction on a block explorer. Where the contract supplied a reason string, it is usually shown alongside the failed status.
Does a revert mean the contract is broken?
Usually the opposite. A revert is a deliberate safety mechanism firing because a condition the contract requires was not met.
Sources & further reading
- EIP-140: REVERT instruction
Stopping execution and reverting state without consuming all gas, with a returned reason.
- Etherscan: reasons for failed transactions
How a reverted transaction is displayed and what state is rolled back.
- Solidity: expressions and control structures
How require and revert produce failure conditions and reason strings.
- MetaMask: transactions and failed transactions
How failed transactions are surfaced and what happens to the fee.
Sources checked on 18 September 2026. Network features and platform support can change; check the relevant provider before acting.
AI-assisted editorial content; no independent expert review is claimed. Error behaviour varies between wallets, networks and client versions. This is educational information, not investment advice. Read our editorial policy.