Why Did My Crypto Transaction Fail?

On 4 April 2024, 75.3% of non-vote transactions on Solana failed, a count that leaves out the validators' own consensus votes. The figure came from Dune data compiled by an analyst who posts as Scarn_eth, and Unchained reported it the next day, in the middle of a memecoin trading boom. Each of those failures had made it into a block, and each one paid its fee.

By Unchained's account most came from bots spamming arbitrage trades, for which a failed attempt is a running cost. When one of yours fails, it feels different, and the explorer page rarely explains much. Educational guide, not financial advice.

First, make sure this is the right kind of failure. A card purchase that was declined, a purchase that failed and is being refunded, a payout that bounced back and a transfer that still shows as pending are separate problems, and each has its own guide on this site. This one covers a narrower case: a transaction that reached the blockchain, was included in a block, ran, and then stopped.

A failed transaction is a finished one

On Ethereum, and on the other networks that run the same virtual machine (the EVM), the failure happens during execution. The transaction was picked up and placed in a block, the contract code started running, hit a condition it could not meet and halted, and every change it had made was rolled back. The fee stays spent.

Ethereum's developer documentation puts it in one line: the fee is paid whether a transaction succeeds or fails. The network did the computing, and the fee is the payment for that work.

How much you lose depends on how it stopped. The Byzantium upgrade of 16 October 2017 added an instruction called REVERT (EIP-140), which lets a contract abort, undo its changes and hand back a reason without eating the rest of the gas, so you pay only for the gas used up to that point. Running out of gas is harsher, because the whole gas limit you set is consumed.

The same upgrade added a status field to transaction receipts (EIP-658), the flag that tells an explorer whether a transaction succeeded. A transaction whose gas limit is below the bare minimum, say 20,000 for a plain ETH transfer that needs 21,000, is a different case: it is rejected before it reaches a block and costs nothing.

The usual causes, and the error each one prints

When a contract reverts, its reason usually appears on the explorer page, and it is the best clue you will get. These are the messages that turn up most often.

• Out of gas, when the gas limit was too low for the work the contract had to do, so a limit trimmed by hand can strand a call halfway with no reason from the contract and Etherscan's warning line then reads "Out of gas".

• Slippage exceeded, when the price moved further than your tolerance allowed before the swap ran, so Uniswap's v3 router stops with "Too little received", the older v2 router says "UniswapV2Router: INSUFFICIENT_OUTPUT_AMOUNT", and Uniswap's newer Universal Router reports the same problem as a coded error, V3TooLittleReceived.

• Deadline passed, because swaps carry an expiry time, so one that waited too long fails on arrival with "Transaction too old" on v3 or "UniswapV2Router: EXPIRED" on v2.

• No approval, where a contract tried to move tokens you had not authorised it to spend, so tokens built on older OpenZeppelin code report "ERC20: transfer amount exceeds allowance", later v4 releases say "ERC20: insufficient allowance", and version 5 returns a coded error, ERC20InsufficientAllowance.

• Contract rules, where the issuer has paused the token ("Pausable: paused" in OpenZeppelin's version 4 code), the sending address is on a blocklist (USDC answers "Blacklistable: account is blacklisted"), or a mint sold out between your click and the block.

That last group cannot be fixed by retrying. If the token is paused or your address is blocked, every new attempt fails the same way and costs another fee.

Tron burns TRX when energy runs out

Tron has its own version of the trap. Smart-contract calls, and a USDT transfer on Tron is one, consume a resource called energy. Whatever the sender's own energy does not cover is paid by burning TRX, and a ceiling the sender sets, called the fee limit, caps the energy the whole call may use.

Set that limit too low and the call stops partway with OUT_OF_ENERGY. Tron's developer documentation says plainly that energy already spent is not refunded, so the TRX burned up to the limit is gone while the USDT stays where it was. A contract that stops with REVERT is gentler: it charges only the energy used before the failure.

Bitcoin and Solana handle it differently

On Bitcoin, a failure that still costs money does not exist. There is no separate fee to charge: the fee is the gap between the coins a transaction spends and the coins it sends on, collected by the miner who puts it in a block. A transaction that breaks the rules never gets that far, because nodes refuse to pass it on, so it costs nothing. One with too low a fee sits and waits, which is a pending problem with its own guide.

Solana works more like Ethereum here, where the base fee is 5,000 lamports per signature (a lamport is a billionth of a SOL), it comes off before the transaction runs, and the official documentation says it is still charged if the transaction fails. So every one of those April 2024 failures cost its sender something. Not much each time.

Reading the explorer page

Pull the transaction up on the explorer for its chain, Etherscan for Ethereum or Tronscan for Tron. Take one real failure from 28 July 2025 as the example, because three lines on its Etherscan page tell most of the story.

The Status line reads "Fail with error 'Token payment failed'", with a warning underneath: "Error encountered during contract execution [execution reverted]". The words after "Fail with error" are the contract's own reason, and most failures carry one.

The Gas figure comes from the "Gas Limit & Usage by Txn" line, which shows 946,617 used out of a 960,000 limit. That is close to the ceiling, yet the warning names a revert. A transaction that really runs out shows "Out of gas" in that warning line, with usage at or near 100%.

The Fee shows up in the Transaction Fee row, which says what the failure cost: 0.00055850403 ETH, about $2.12 at that day's ether price. Of that, 0.000465 ETH was burned as the base fee and the rest went to the validator.

What to do next

Start with what did not happen, because the coins or tokens you meant to send never left your wallet, and Etherscan's own help pages say the same: when a transaction shows Fail, the funds stay with the sender and only the gas fee is deducted.

There is nothing to speed up or cancel either. Those tools work on transactions still waiting for a block, and a failed one is already in a block and final, with its fee gone for good.

So fix the cause and send a new transaction. Raise the gas limit or let the wallet estimate it, approve the token before swapping, refresh a swap that sat too long, and check whether the token still allows transfers at all. If the same error comes back twice, stop paying for attempts and read the contract's page on the explorer first.