Why does my wallet say "Transaction failed" but I still paid a gas fee?

Understanding Failed Transactions in Blockchain Networks

1. A transaction labeled as 'failed' means the Ethereum Virtual Machine (EVM) or equivalent execution environment rejected the operation before completing its intended logic. This rejection occurs during the execution phase, not before submission.

2. Gas fees are consumed for every computational step, including validation checks, storage access, and opcode execution. Even if a contract reverts or runs out of gas, those executed steps are irreversible and non-refundable.

3. The network does not distinguish between 'successful intent' and 'executed work'. Miners or validators are compensated for processing time and resources used, regardless of whether the final state change occurred.

4. Common causes include insufficient balance, incorrect function parameters, failed require() or revert() statements in smart contracts, and integer overflows that trigger explicit reverts.

5. Users often misinterpret the failure as a network-level error, when in fact it reflects deliberate contract behavior designed to preserve integrity and prevent invalid state transitions.

Gas Fee Mechanics in EVM-Compatible Chains

1. Gas is priced per unit and multiplied by the total units consumed. The fee is deducted from the sender’s account at transaction submission, not upon success.

2. All gas used up to the point of failure is permanently spent — no partial refunds occur unless a specific revert with reason string is triggered and gas remains after the revert instruction.

3. If a transaction runs out of gas, 100% of the specified gas limit is consumed. If it reverts explicitly (e.g., via revert() or require(false)), unused gas is refunded — but the base cost for calling the function and executing prior opcodes remains non-refundable.

4. Transaction simulation tools like Tenderly or Blocknative can preview gas usage and potential reverts before broadcast, yet they cannot guarantee identical outcomes due to dynamic on-chain conditions.

5. Wallet interfaces rarely display the exact revert reason unless the node supports eth_call tracing or the transaction was simulated locally with full debug output.

Smart Contract Revert Behavior and Its Impact

1. Solidity’s revert(), require(), and assert() statements halt execution and roll back state changes, but they do not eliminate gas consumption for operations performed before the revert.

2. A revert with a custom error message (introduced in Solidity 0.8.4+) still incurs gas costs for encoding and emitting that message — often adding 100–300 gas units beyond baseline execution.

3. Contracts deployed before Istanbul hardfork may behave differently under revert conditions due to changes in how gas refunds are calculated post-revert.

4. Third-party libraries such as OpenZeppelin’s SafeERC20 or ReentrancyGuard introduce additional checks that increase gas overhead and expand the surface area for early reverts.

5. External calls to untrusted contracts compound risk: even if your transaction logic is sound, a called contract’s revert will cascade back and cause your entire transaction to fail with consumed gas.

Wallet Interface Limitations and User Misinterpretation

1. Most consumer wallets rely on eth_getTransactionReceipt to determine success status, interpreting status == 0x0 as “failed” without exposing underlying revert data.

2. The phrase “Transaction failed” is a UI abstraction — it does not indicate network congestion, RPC failure, or wallet bug unless accompanied by specific error codes like “insufficient funds” or “nonce too low”.

3. Some wallets suppress low-level EVM errors to avoid overwhelming users, replacing technical messages like “execution reverted: ERC-20 transfer amount exceeds balance” with generic labels.

4. Transaction hashes remain valid and visible on explorers even after failure, allowing users to inspect trace logs, storage reads, and stack traces — though this requires technical familiarity and external tooling.

5. Hardware wallet integrations sometimes add latency or signature mismatches that result in silent pre-execution failures indistinguishable from on-chain reverts in wallet UIs.

Frequently Asked Questions

Q: Can I get my gas fee back if a transaction fails?Gas is never refunded in full. Only unused gas after an explicit revert() or require() is returned. Base execution costs and gas spent before the revert remain deducted.

Q: Why does MetaMask show “Failed” but Etherscan shows “Success”?This discrepancy usually stems from caching delays or mismatched RPC endpoints. Etherscan displays the canonical receipt; MetaMask may reflect a stale or forked view until confirmation depth increases.

Q: Does a failed transaction affect my wallet nonce?Yes. Every signed transaction increments the sender’s nonce, whether successful or reverted. Subsequent transactions must use the next sequential nonce to be accepted.

Q: How do I find the exact reason my transaction reverted?Use a block explorer with trace functionality (e.g., Tenderly, Blockscout), or replay the transaction using hardhat-node or foundry’s cast send with --debug flag to inspect internal calls and revert strings.