How to Fix an "Execution Reverted" Error on Ethereum

24 October 2026

The "execution reverted" error means the Ethereum transaction you tried to send was not completed because the smart contract it called refused to process it. The transaction data was valid, the gas was sufficient in theory, but the contract's code decided to stop and reverse any state changes. The fix depends on the cause, which is usually one of a few things: an invalid input, a failed internal condition, or a mismatch between the contract's expected state and what you are asking it to do. You cannot "retry" the same transaction and expect a different result - you must change something about the request.

Why a transaction reverts

A revert is the Ethereum equivalent of a function throwing an exception. When a contract executes a require(), revert(), or assert() statement that fails, the EVM undoes every change the transaction made up to that point, returns the unused gas (minus the gas already consumed), and marks the transaction as failed. The transaction still pays for the gas it used up to the revert point. Common triggers include:

• Supplying a token address that does not match the expected one.
• Trying to swap an amount that exceeds the contract's available liquidity.
• Calling a function that requires a specific role or permission you do not hold.
• Passing a zero address where a valid address is required.
• The contract has a circuit breaker or pause mechanism that is active.

Step 1: Read the Error Message in Your Wallet

Most modern wallets display a reason string when a transaction reverts. In MetaMask, Rabby, or a block explorer like Etherscan, the transaction details will show a "Revert reason" field. Common examples:

• "execution reverted: ERC20: transfer amount exceeds balance"
• "execution reverted: UniswapV2: INSUFFICIENT_OUTPUT_AMOUNT"
• "execution reverted: Ownable: caller is not the owner"

If the reason string is missing, the contract did not provide one. You can still investigate using a block explorer: open the transaction on Etherscan, click the "Click to see more" link under the transaction status, and look for the decoded input or internal transactions. If the error is generic, proceed to Step 2.

Step 2: Check the Transaction Parameters

Review what you are sending. If the transaction involves a token swap, ensure the input token address, output token address, and amount are correct. A common mistake is pasting the wrong token contract address from a copy-paste error. If you are calling a function that requires a specific parameter format (like a bytes32 value or an encoded signature), verify the data you are submitting matches what the contract expects.

If the transaction is a simple ETH transfer to a contract address, the contract may not have a receive() or fallback() function that accepts ETH. Sending ETH directly to a contract that does not expect it will revert. The solution is to use the contract's intended deposit function instead.

Step 3: Check the Contract's State and Your Balance

The contract may fail because of conditions that are not obvious from the error message alone. For example:

• Liquidity or supply limits: A decentralized exchange pool may have too little liquidity for your trade size. Reduce the amount or split the trade.
• Allowance failures: If the transaction involves spending an ERC-20 token, the contract needs an allowance from your address. Even if you previously set an allowance, it may be insufficient for the current amount. (This site has a separate page on fixing insufficient allowance errors - see that for details.)
• Paused or deprecated contracts: Some contracts have an emergency stop. Check the project's official documentation or social media to see if the contract is paused, undergoing maintenance, or has been migrated to a new address.
• Ownership or permission checks: If the function requires admin rights or a specific role, and your address is not listed, the transaction will revert. You cannot fix this unless you obtain the required role.

Step 4: Adjust Gas or Slippage

A revert is not a gas issue in the normal sense - the contract fails deliberately - but some DApps simulate the transaction using a default slippage tolerance. If your trade triggers a large price impact, the contract may revert because the output amount falls below the minimum you set. Increase the slippage tolerance in your wallet or DApp interface (typically 0.5% to 1% for common pairs, higher for illiquid ones). Be aware that higher slippage increases your vulnerability to frontrunning or sandwich attacks.

Gas limits rarely cause reverts. If the transaction runs out of gas, the error will be "out of gas," not "execution reverted." However, if you manually set a gas limit that is too low for a complex contract call, the transaction may revert due to gas exhaustion mid-execution. Use the wallet's estimated gas limit, which is usually accurate.

Step 5: Simulate the Transaction Before Sending

Use a tool like Tenderly, the "Simulate Transaction" feature in MetaMask (if available), or the "Debug" tab on Etherscan to run the transaction without actually sending it. The simulation will show whether the contract's conditions pass or fail, and often returns the exact revert reason. This is the most reliable way to diagnose a generic revert before spending gas.

When to contact support

If you have checked the parameters, the contract state, and your inputs, and the transaction still reverts with no clear reason, the problem may be a bug in the contract, a network issue, or a mismatch between the contract version and the interface you are using. Look for the project's official support channels - Discord, Telegram, or a help desk. Do not share your seed phrase or private keys with anyone claiming to help.

Summary Checklist

• Did the error include a reason string? Read it.
• Is the token or contract address you entered correct?
• Is the contract paused or migrated?
• Do you have sufficient balance and allowance?
• Is your slippage tolerance high enough?
• Have you simulated the transaction to see the failure?

Once you identify the cause, adjust the input or condition and resend the transaction. The same transaction will always revert; the fix is always in the data you submit.

Back to ethereum