Every transaction error, explained

intrinsic gas too low

The gas limit set on the transaction is below the minimum the network requires just to accept it, before any contract logic runs. Every transaction has a base cost (21,000 gas for a simple transfer, more when data is attached), and this limit did not cover it.

out of gas

The transaction ran, consumed its entire gas limit partway through execution, and reverted. This is about the gas limit you authorised, not your coin balance: you can hold plenty of ETH and still run out of gas. You pay for the computation used up to the point it stopped.

gas required exceeds allowance

The node's own estimate of the gas needed came out higher than the cap you allowed, and in most cases that is because the transaction would revert if it actually ran. The estimate blows up because the simulated execution fails.

insufficient funds for gas * price + value

The wallet does not hold enough of the chain's native coin (ETH, BNB, POL, and so on) to cover the amount being sent plus the maximum possible gas fee. The check uses the maximum fee, not the likely fee, so it can trigger even when the eventual fee would have been affordable.

max fee per gas less than block base fee

The maximum fee you offered per unit of gas is below the network's current base fee, so no block can include the transaction. Base fee moves with congestion, and a fee that was fine an hour ago can be under the floor now.

transaction underpriced

The gas price on the transaction is below what the node's mempool will currently accept, so it refused to queue it at all. This is the node protecting itself from transactions that would sit forever.

max priority fee per gas higher than max fee per gas

The transaction's tip (priority fee) is set higher than its overall fee ceiling (max fee), which is contradictory: the tip is paid out of the ceiling. This comes from manually editing one field without the other.

exceeds block gas limit

The gas limit on the transaction is larger than the maximum a whole block can hold, so no block could ever include it. This is almost always a manually entered limit with too many zeros.

nonce too low

The transaction's nonce (its sequence number) has already been used: either an earlier transaction with that nonce was mined, or one is already pending. Very often the action you are retrying actually went through the first time.

nonce too high

There is a gap in the sequence: an earlier transaction from this address has not been mined yet, so this one cannot be processed. Transactions from one address must confirm in nonce order.

already known

The exact same signed transaction is already sitting in the node's mempool. Nothing failed: the node is telling you it has seen this one before, usually because a wallet or dapp resubmitted it.

replacement transaction underpriced

You tried to replace a pending transaction (a speed-up or a cancel reuses its nonce), but the replacement's fee is not enough of an increase. Nodes require roughly a 10% bump or more before they will swap one pending transaction for another.

transaction dropped and replaced

The network discarded the transaction, usually because another transaction with the same nonce confirmed first (a speed-up, a cancel, or simply a competing transaction), or because it sat unmined so long the mempool evicted it. A dropped transaction costs nothing: it never executed.

execution reverted

The transaction ran and the smart contract rejected it: a require() condition failed, an assertion tripped, or the contract explicitly reverted. Every state change was rolled back as if it never happened, but the gas used up to that point is spent. On its own this message does not say WHY, the specific reason is in the revert data.

ERC20: transfer amount exceeds balance

The transaction tried to move more of a token than the sending address holds. This also appears when a contract tries to move tokens on your behalf and the balance changed since you signed, or when token decimals made the amount larger than intended.

ERC20: transfer amount exceeds allowance

A contract (a router, a staking contract, a bridge) tried to pull your tokens, but you have not approved it to move that much. Token transfers by third parties require an explicit approval first, and the approval is per token, per spender.

insufficient allowance

The same failure as an ERC20 allowance revert, in its shorter modern form: the contract you called is not approved to move enough of your token. Newer token contracts emit this compact message instead of the long ERC20 prefix.

STF

A Uniswap V3 safe-transfer-from failure. The router tried to pull tokens from your wallet and the transfer returned false, which in practice means a missing or insufficient token approval, or a token with unusual transfer behaviour (fee-on-transfer, blocklists).

TRANSFER_FROM_FAILED

A low-level transferFrom call returned false instead of succeeding. Routers wrap token pulls in this check, so it fires when the approval is missing, the balance is short, or the token contract itself refused the transfer (paused, blocklisted, or non-standard).

TRANSFER_FAILED

A token transfer OUT of the contract failed: the pool or vault tried to send you tokens and the token contract refused. Common with tokens that have transfer restrictions, fees on transfer, or paused states.

INSUFFICIENT_OUTPUT_AMOUNT

Slippage protection fired. Between signing the swap and it being mined, the price moved, and the trade would have delivered less than the minimum you agreed to receive. The contract refused to fill at the worse price, which is the protection working, not a malfunction.

INSUFFICIENT_INPUT_AMOUNT

The swap reached the pool with a zero or too-small input amount. Usually a dapp bug or a stale quote rather than something you set: the route was built for an amount that no longer matches what the transaction carries.

INSUFFICIENT_LIQUIDITY

The pool does not hold enough of the tokens to fill the trade, mint the position, or cover the withdrawal at the size requested. Common on small or new pools, and on forgotten pools where liquidity has drained away.

EXPIRED

The swap carried a deadline and did not get mined before it passed. Deadlines protect you from a transaction sitting in the mempool for an hour and executing at a stale price. A too-low fee is the usual reason it missed the window.

UniswapV2: K

The pool's invariant check failed: after the swap, the pool would hold less value than before, which the contract forbids. In practice this almost always involves a token that takes a fee on transfer or otherwise misreports amounts, breaking the pool's arithmetic.

Ownable: caller is not the owner

The function you called is restricted to the contract's owner, and your address is not it. Regular users hitting this are almost always on the wrong function, the wrong contract, or following instructions meant for the protocol team.

Pausable: paused

The protocol has paused this part of the contract, usually during an incident, a migration, or maintenance. The revert is the pause doing its job: nothing about your wallet or transaction is wrong, and nothing moved.

ReentrancyGuard: reentrant call

The contract blocked a call that re-entered it before a previous call finished, which is the classic shape of an exploit attempt, but can also fire on legitimate complex interactions between contracts.

SafeMath: subtraction overflow

An older contract tried to subtract a larger number from a smaller one, which SafeMath blocks. In practice this is how pre-0.8 Solidity contracts say insufficient balance or insufficient allowance: the subtraction that failed was balance minus amount.

SafeERC20: low-level call failed

A contract used OpenZeppelin's safe wrapper to call a token, and the token call itself failed or returned nonsense. Fires with non-standard tokens, tokens that are not actually deployed at the address used, and tokens with transfer restrictions.

panic code 0x11

An arithmetic operation went above the maximum or below zero for its number type. Since Solidity 0.8 this check is automatic. For a user, the practical meaning is usually an amount that does not fit: subtracting more than a balance, or a calculation the contract did not expect.

panic code 0x12

The contract divided by zero. A user cannot normally cause this with inputs: it usually means the contract read a zero where it expected a value, an empty pool, a price feed returning zero, an uninitialised parameter.

panic code 0x32

The contract read past the end of an array: asking for item 5 of a list with 3 entries. From a user's seat this often means referencing something that does not exist, a position, a tier, an index from a stale interface.

panic code 0x01

An assert() check failed. Assertions guard conditions the developers believed could never be false, so a failing one signals a genuine bug or an extraordinary state, not a user mistake.

panic code 0x21

A value was converted into an enum (a fixed list of options) that does not contain it, like passing option 7 where only options 0 to 3 exist. Usually a dapp passing a bad parameter.

panic code 0x31

The contract tried to remove an item from an empty list. Like other panics, it points at contract state the developers did not expect rather than at your inputs.

panic code 0x41

The contract tried to allocate too much memory or build an oversized array, typically triggered by a parameter that is far larger than intended.

panic code 0x51

The contract called an internal function variable that was never set. This is purely a contract bug: no user input causes it.

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

Before asking you to sign, the wallet simulated the transaction against current chain state, and the simulation reverted, so no gas estimate exists. This is a preview of a failure, shown before you pay for it.

this transaction is likely to fail

The same pre-signing simulation, in friendlier words: the wallet ran the transaction and it did not succeed. The failure it saw is real, based on the chain as it is right now.

user rejected the request

The wallet reported back to the dapp that the signing prompt was declined. If you pressed reject, that is the whole story. If you never saw a prompt, the popup was blocked, opened behind the window, or timed out.

internal JSON-RPC error

A catch-all from the wallet's connection to the network node: the node returned an error the wallet could not translate. Sometimes it wraps a real revert, sometimes the node itself is unhealthy or rate limiting.

header not found

The RPC node was asked about a block it does not have yet, a sign the node is lagging behind the chain or load-balancing between out-of-sync servers. Your transaction and wallet are fine.