Transaction error messages explained: what each one means and how to fix it

When a transaction fails, the message you get is usually written for a machine, not a person: "intrinsic gas too low", "execution reverted", "replacement transaction underpriced". This is a key to the ones you actually see, grouped by what went wrong, each with what it means and how to fix it. If you only remember one thing: the error almost always tells you exactly what happened, once it is translated.

Gas and fee errors (it never really ran)

intrinsic gas too low

The gas limit you set is below the minimum the transaction needs just to be accepted, before any contract logic runs. Raise the gas limit. Most wallets estimate it for you, so this usually means a manual limit was set too low.

out of gas

The transaction ran but hit the gas limit partway through and reverted. This is about the gas LIMIT, not your ETH balance: you can hold plenty of ETH and still run out. Raise the gas limit in your wallet's advanced settings and resubmit.

gas required exceeds allowance, or always failing transaction

The node's own gas estimate came out higher than the cap you allowed, usually because the transaction would revert if it ran. Do not just raise the limit blindly: find out why it would revert first, because forcing it through only pays gas to fail.

insufficient funds for gas * price + value

You do not have enough of the native coin (ETH, BNB, and so on) to cover the amount you are sending plus the maximum gas fee. Top up the native coin, or lower the amount or the gas fee.

max fee per gas less than block base fee

The maximum fee you offered is below the network's current base fee, so the transaction cannot be included. Increase the max fee, or wait for the base fee to fall in quieter conditions.

transaction underpriced

The gas price is too low for the mempool to accept the transaction right now. Increase the gas price and resubmit.

Mempool and nonce errors (it will not broadcast, or it is stuck)

nonce too low

The nonce has already been used: either the transaction was already mined, or a transaction with that nonce is already pending. Often the action already went through. Let the wallet pick the next nonce automatically rather than setting one by hand.

nonce too high

There is a gap: an earlier nonce is still unconfirmed, so this one cannot be processed yet. Resolve or cancel the earlier pending transaction first, then this one can go through.

already known, or known transaction

The exact transaction is already sitting in the mempool. Nothing is wrong: wait for it to mine rather than resubmitting the same one.

replacement transaction underpriced

You tried to speed up or cancel a pending transaction, but the replacement was not priced high enough. A replacement has to raise the fee by roughly 10% or more. Bump the gas price and try again.

Contract reverts (it ran, and the contract said no)

execution reverted, or warning! error encountered during contract execution [execution reverted]

The contract rejected the call. That block-explorer phrasing means a require() check failed, often with no attached message. The useful next step is to decode the actual reason: replaying the transaction reveals the revert string, custom error or panic behind it. This is exactly the translation an on-chain support agent does automatically.

ERC20: transfer amount exceeds balance

You tried to move more of a token than the wallet holds. Check the balance and the amount, remembering token decimals.

ERC20: transfer amount exceeds allowance, or insufficient allowance

You have not approved the spender (a router, a staking contract) to move enough of your token. Approve the token for at least the amount first, then retry the action. This is the single most common reason a first swap or stake fails.

STF

A Uniswap safe-transfer-from failure, almost always a missing or insufficient token approval. Approve the token for the router and retry.

Too little received, or INSUFFICIENT_OUTPUT_AMOUNT

Slippage. The price moved beyond the tolerance you set between submitting and mining, so the contract refused to fill the trade at a worse rate. Raise the slippage tolerance a little, or retry when the market is calmer.

EXPIRED

The transaction carried a deadline and did not mine before it passed, usually because the gas price was too low. Retry with a fresh deadline and an adequate gas price.

Custom errors and Solidity panics (modern contracts)

reverted with custom error 'SomeError(...)'

Modern contracts use named custom errors instead of message strings because they are cheaper on gas. To read one in plain English you need the contract's ABI, or a tool that decodes it for you. The name usually says what happened, for example SlippageTooHigh() or DeadlinePassed().

A raw hex selector such as 0x8199f5f3

The same thing as above, but the explorer does not know the contract's ABI, so it shows the four-byte selector instead of the name. Look the selector up against a signature database, or decode it with the ABI.

reverted with panic code 0x11 (or 0x12, 0x32, 0x01)

A panic is an automatic Solidity safety check, not a message the developer wrote. 0x11 is arithmetic overflow or underflow, 0x12 is division by zero, 0x32 is an array index out of bounds, and 0x01 is a failed assert(). A panic almost always means the contract reached a state it did not expect, so if your inputs look right it can point to a contract issue rather than anything you did.

Wallet warnings (before you even sign)

cannot estimate gas; transaction may fail or may require manual gas limit

The node simulated the transaction and it reverted, so the wallet cannot estimate its gas. Treat this as a stop sign, not an inconvenience: do not force a manual gas limit to push it through, because it will most likely fail and cost you gas. Find out why it would revert first.

This transaction will likely fail

The same signal in friendlier words. The wallet ran the transaction against current state and it did not succeed. The fix is upstream: a missing approval, wrong network, insufficient balance, or a contract condition not met.

The faster way to read any of these

This key covers the common messages, but the real answer to "why did this fail" is always in the transaction itself: the decoded revert, the gas used against the limit, the approval that was missing, the price the swap needed. TxID reads that for a user automatically, on the chain, and answers in plain English with the specific fix, so nobody has to match their error against a list by hand.