How to find the reason a transaction reverted without an error message

05 September 2026

A transaction that reverts silently is the most frustrating kind. Etherscan will show you a red "Fail" with no reason string. The actual cause is still in the transaction trace, buried inside an opcode-level execution log. Two free tools can surface it: Tenderly's debugger and Phalcon's trace viewer.

Both are better than Etherscan's default display. Etherscan parses basic revert reasons - strings returned by require("reason") - but it stops there. Custom error selectors, nested reverts, and out-of-gas scenarios produce a blank "No error message" line. That is not information. That is a dead end.

Why the error message goes missing

Solidity offers two ways to revert. A require with a string emits that string as revert data. A require without a string, or a custom error like error InsufficientBalance(uint256 have, uint256 want), emits a 4-byte error selector followed by encoded arguments. Etherscan's tooltip logic only displays the string variant. If the project uses custom errors - and most modern ones do - the selector is all Etherscan shows.

You get a hex value like 0xcf479181 and nothing else. That selector still points directly to the failing logic. You just need a debugger that decodes it against the contract's ABI.

Using Tenderly's debugger

Go to the failed transaction on Tenderly's public transaction simulator. Paste the hash into the search bar at tenderly.co/tx/any-chain/mainnet. The page loads a gas profile and an opcode trace.

Click "Debug" in the top-right panel. A step-through interface opens. Each row is a single EVM instruction. The key column is "Stack" on the right. Look for the REVERT opcode. It will be near the bottom of the list, usually preceded by PUSH opcodes that pushed the revert data onto the stack. The revert data itself appears in the "Memory" or "Return" pane.

If the revert uses a custom error, Tenderly will attempt to decode it. You may see a line like Reverted with custom error 'InsufficientBalance(100, 50)'. That is the full explanation. If Tenderly cannot match the selector to a known ABI, you get the raw hex. In that case, take the 4-byte selector and search it on openchain.xyz or 4byte.directory.

Using Phalcon's trace view

Phalcon (phalcon.xyz) offers a similar trace viewer with a different layout. Paste the transaction hash. The default view shows a tree of internal calls. Look for the call that ended with failed. Click on it.

A side panel appears with "Stack", "Memory", and "Storage" tabs. The "Memory" tab holds the revert data at the moment of failure. You can copy the hex string and decode it manually. Phalcon also provides a "Decode" toggle for the trace. When enabled, it resolves known selectors to error names and parameters.

Phalcon's advantage is its nested call tree. If a transaction involves multiple contracts - a router calling a pair calling a token - the revert might happen deep inside an internal call. Etherscan shows only the top-level failure. Phalcon shows every level that failed, with the exact instruction and revert data at each step.

Decoding custom error selectors without a tool

When neither tool auto-decodes, you work with the raw bytes. The revert data starts with a 4-byte selector. Copy it. Go to openchain.xyz, paste the selector into the "Signature" field. If someone has submitted that interface to the database, you get the error name and parameter types back.

For the parameters themselves, the remaining bytes are ABI-encoded. Static types like uint256 are 32 bytes each. Dynamic types like string include an offset and a length. You can decode them manually using an ABI decoder, or use the "ABI Decode" feature on Etherscan's input data tab by pasting the full revert data and the error signature.

When no decode works

Some contracts revert with an empty data field - just 0x. That usually means an out-of-gas revert or a fallback function that rejected the call. For out-of-gas, the trace will show the opcode GAS or GASLIMIT near the failure. For a reject in a fallback, the trace shows REVERT with zero data. In both cases, the opcode trace gives you the location: the failing instruction inside the contract's bytecode. You can cross-reference that with the contract's verified source on Etherscan by finding the source line that maps to that program counter.

The practical workflow

• Start at Etherscan. If it shows a reason string, you are done.
• If not, paste the hash into Tenderly or Phalcon.
• Find the REVERT opcode. Read the revert data.
• If the data starts with a 4-byte selector, decode it on openchain.xyz.
• If the data is empty, look at the preceding opcodes for gas exhaustion.

That sequence covers every silent revert. The tools are free and take about thirty seconds per transaction. The alternative - guessing at require conditions - wastes more time than it saves.

Back to on-chain data