Failed Transactions: Why You Still Pay for Them

A failed transaction is included in a block, executed, and reverted. The execution consumed computational resources, validators performed the work, and the fee compensates for that work regardless of the result.

This is not a penalty. It is the same fee you would have paid had it succeeded, for the portion of the work actually done.

The five causes, in order of frequency

1. Out of gas. The gas limit you authorised was lower than the transaction required. Execution proceeds until the limit is reached, then reverts. You pay for everything consumed.

Usually caused by manually lowering the limit to save money, or by conditions changing between estimation and execution.

2. Slippage exceeded. A swap specifies a minimum acceptable output. If the price moves beyond that between submission and execution, the contract reverts deliberately, which is the protection working as designed.

More common on volatile assets and thin pools.

3. Insufficient allowance. Attempting to move tokens a contract has not been approved to move. The approval was forgotten, was for a smaller amount, or was revoked.

4. Contract-level rejection. The contract’s own logic refused. A mint that sold out, a claim already used, a sale blocked by a malicious contract.

5. Nonce conflict. Another transaction with the same nonce was included first.

What the gas limit actually does

The limit is the maximum gas you authorise, not the amount you pay. A successful transaction consumes what it needs and refunds nothing because nothing extra was taken.

A failed transaction consumes everything up to the point of failure. If it failed because it hit the limit, it consumed the entire limit.

So raising the limit does not cost anything on a successful transaction and protects against this failure mode. Lowering it saves nothing and creates it.

How to reduce failures

Do not manually lower the gas limit. The wallet’s estimate includes a margin for a reason.

Increase slippage tolerance during volatility, carefully. A tolerance too tight fails repeatedly; too wide invites a worse fill. For volatile assets in thin pools, a higher tolerance is often correct, with the understanding of what you are accepting.

Check the approval before swapping. Most failures on a first interaction with a contract are missing allowances.

Simulate first where the wallet supports it. Several wallets now simulate transactions before signing and warn about likely reverts.

Avoid competitive events. Mints with limited supply produce large volumes of failed transactions by design, because many people compete for few slots and the losers still pay.

The cost of repeated failures

This is where it becomes expensive. Someone attempting a swap four times during a volatile period, failing on slippage each time, pays four fees and receives nothing.

On mainnet during congestion, that can exceed the value of the intended trade. The rational response after two failures is to stop, wait for conditions to change, and reconsider whether the operation needs to happen on that chain at all.

Is any of it recoverable

No. The transaction is on-chain, the fee was paid to the network, and there is no mechanism for reversal. Exchanges cannot help because no exchange was involved.

The only exception is when a platform’s own interface caused the failure and the platform chooses to compensate as a customer service matter. That is a business decision rather than a technical one, and it is another reason the quality of a venue’s support process is worth weighing. A withdrawal handled by venues that quote the network fee separately shows you the network fee before you commit, which at least removes the surprise.