![\"MetaMask](\"https:\/\/lh3.googleusercontent.com\/sitesv\/AG8ngQVpiG_gCoxCrkK7kBjJZcpiS4sEKestKFVAvtqA9AlgXx91fZBAKbyKpVXX5u8WLj7hHh3tjou_npy25mnTFB8WdEXLNVNqLsQY-0Dqz0NQ6jXOHnYR3WlzHwzBl_Cngot0TQAQWT1537iJC8HIdE3K2D9IKmhAW-3_U1FhcdFwJOta2aTQYVddqm7yczeHCpLtw8W0KorKAu5V1Vi8Ddc\")
<\/p>\nA user submits a transaction through MetaMask to interact with a decentralized application\u2014perhaps swapping tokens, depositing into a protocol, or claiming rewards. The transaction appears to be processing. Then, minutes or hours later, it either fails with a cryptic error message or disappears from the user’s activity feed entirely. The wallet shows the balance unchanged, but no clear explanation of what went wrong. This silent failure pattern occurs constantly in blockchain applications, and the root cause determines how the user should respond.<\/p>\n
The confusion stems from two fundamentally different failure modes that users and even experienced developers sometimes conflate. A reverted smart contract\u2014where the contract’s logic explicitly rejects the transaction\u2014is categorically different from an out-of-gas error, where the transaction runs out of computational resources before completion. One is a logic failure; the other is resource exhaustion. MetaMask’s simulation tools and transaction logs contain the diagnostic information needed to distinguish them, but that information is often overlooked or misinterpreted. Understanding the difference is essential for anyone using a crypto wallet to interact with blockchain applications, because the solution to one problem makes the other worse.<\/p>\n
A smart contract reversion occurs when the contract’s logic executes but encounters a condition that causes it to stop and reject the transaction. This could be an explicit require() statement that fails, an assertion that is false, a division by zero, an out-of-bounds array access, or any other operation that the contract code determines is invalid. When reversion happens, all state changes made during that transaction are rolled back\u2014the blockchain records that the transaction was attempted, but the contract’s variables remain unchanged. The user’s funds are not transferred; the protocol’s internal balances do not update.<\/p>\n
Common examples clarify this distinction. A decentralized exchange contract might revert if a user tries to swap tokens but the slippage tolerance is exceeded\u2014the output would be less than the minimum acceptable, so the contract’s logic refuses the swap. A lending protocol might revert if a user tries to withdraw more assets than their account holds. A governance contract might revert if a user tries to vote twice on the same proposal. In each case, the contract evaluated the transaction, found a condition that violated its rules, and stopped execution. This is intentional behavior; the contract is working as designed by rejecting invalid states.<\/p>\n
The key insight is that a reverted transaction consumes gas, which means it consumes the user’s funds. Gas is paid for the computational work that the blockchain performs, whether that work results in a state change or not. If a user specifies a gas limit of 100,000 units and the contract reverts after consuming 80,000 units of gas, those 80,000 units are charged at the current gas price. The user pays for the failed attempt. This is why a revert is not a \u00ab\u00a0free\u00a0\u00bb error\u2014the wallet has deducted the transaction fee from the user’s balance, even though the intended action did not occur.<\/p>\n
Detecting a revert in MetaMask depends on when the failure is discovered. If the revert is caught before the transaction is broadcast to the network, the wallet’s simulation process detected it and the transaction never left the user’s device. If the revert happens after broadcast, the user will see the transaction in their activity history marked as \u00ab\u00a0failed\u00a0\u00bb with the gas spent recorded. The error message may be generic or specific depending on whether the contract code included a descriptive revert reason. The MetaMask wallet stores this information locally, and a user can view detailed logs by opening the browser console or checking the transaction on a block explorer.<\/p>\n
An out-of-gas error occurs when a transaction specifies a gas limit, the contract begins executing, and the actual computational cost exceeds that limit before the transaction completes. Unlike a revert, which is a deliberate rejection by contract logic, running out of gas is a resource constraint. The transaction does not finish; the operation is interrupted partway through. The blockchain still records the attempt and charges the user for all the gas units specified in the transaction limit\u2014not just the units consumed, but the full limit.<\/p>\n
This distinction has immediate practical consequences. If a user sets a gas limit of 50,000 units but the transaction actually needs 80,000 to complete, the transaction will run out of gas at 50,000 units. The user is charged for all 50,000 units, but the operation is incomplete. Any state changes made before the gas ran out are reverted just as they would be after a contract reversion, meaning the user pays for nothing. However, if the user then increases the gas limit to 100,000 and retries, they will be charged again for the second attempt.<\/p>\n
The confusion arises because both failures result in the same visible outcome: an incomplete transaction, gas spent, and no state change. But they have different causes and require different solutions. A reverted contract will fail again at the same gas limit because the rejection is not about resources\u2014it is about logic. Increasing the gas limit will not help if the contract is explicitly refusing the transaction. Conversely, an out-of-gas error will not be resolved by changing the contract parameters or the transaction data; it requires allocating more gas.<\/p>\n
Detecting an out-of-gas error is sometimes straightforward: MetaMask may display \u00ab\u00a0out of gas\u00a0\u00bb explicitly. But often the error message is generic or absent. The most reliable diagnostic is to check whether the transaction consumed exactly the amount of gas specified in the limit. If a transaction set a 100,000-unit limit and consumed exactly 100,000 units, it likely ran out of gas. If it consumed fewer units\u2014say, 60,000 of a 100,000 limit\u2014it more likely reverted, because the contract execution stopped early.<\/p>\n
MetaMask does not send transactions directly to the blockchain; it runs a simulation first. When a user approves a transaction in the wallet, MetaMask calls a node’s eth_call or eth_estimateGas method, which executes the transaction against the current blockchain state without actually modifying anything. This simulation allows the wallet to predict whether the transaction will succeed, estimate the gas cost, and detect obvious failures before the user pays fees.<\/p>\n
The simulation process is surprisingly powerful. It executes the smart contract code, checks require() statements, validates balances, confirms allowances, and traces through the contract’s logic. If the simulation detects a revert, it can often capture the revert reason\u2014a text message embedded in the contract to explain why it rejected the transaction. The user sees this in the MetaMask interface before clicking \u00ab\u00a0confirm.\u00a0\u00bb This is why a user might see \u00ab\u00a0execution reverted: insufficient balance\u00a0\u00bb or \u00ab\u00a0execution reverted: slippage exceeded\u00a0\u00bb during the approval phase, before any gas is spent.<\/p>\n
However, the simulation has limitations. It executes against the state at the time the simulation is run, but the blockchain state changes constantly. A transaction simulated successfully at block 17,999,999 might fail at block 18,000,000 if another transaction modified the relevant contract state or the user’s balance. This is especially common in decentralized applications where multiple users interact with the same contract simultaneously. The user approves a transaction based on a successful simulation, but by the time the transaction is mined, conditions have changed and it reverts on-chain.<\/p>\n
The second limitation is that MetaMask’s simulation cannot predict gas cost perfectly for complex contracts. The estimateGas call returns an estimate, but the actual gas consumed during mining may differ. This is why MetaMask adds a buffer\u2014usually a percentage on top of the estimate\u2014to reduce the risk of out-of-gas errors. A user who manually lowers the gas limit below this estimate is taking on additional risk.<\/p>\n
When a transaction fails, the information exists in multiple places. MetaMask displays a summary in the activity history, but detailed logs require additional steps. In the browser extension, users can open the Developer Console (F12 or right-click \u2192 inspect \u2192 Console), then look for messages from the MetaMask script. These logs may show revert reasons, call stack information, or error codes. The information is technical, but the presence of a revert message\u2014even a cryptic one\u2014distinguishes a contract logic failure from other errors.<\/p>\n
A more reliable approach is to examine the transaction on a block explorer such as Etherscan or the equivalent for the relevant blockchain network. The user copies the transaction hash from MetaMask and pastes it into the explorer. The explorer displays the transaction’s status, gas used, gas limit, and\u2014critically\u2014any error message or revert reason returned by the network. Etherscan labels reverted transactions as \u00ab\u00a0failed\u00a0\u00bb and displays the reason in red text. If a transaction is marked as \u00ab\u00a0success\u00a0\u00bb on the explorer but the user did not receive the expected outcome, the failure likely occurred at the application level rather than the contract level.<\/p>\n
The transaction receipt provides another diagnostic. The receipt includes the gasUsed field, which shows how many gas units were actually consumed. Comparing this to the gasLimit set by the user reveals whether the transaction ran out of gas. If gasUsed equals gasLimit, out-of-gas is likely. If gasUsed is significantly lower, the transaction reverted before exhausting the limit. Some block explorers display this comparison directly; others require the user to click into the advanced details.<\/p>\n
Users can also interact directly with nodes using Web3 libraries such as ethers.js or web3.py to retrieve detailed transaction information, but this requires a technical setup and is generally unnecessary. The block explorer provides the essential information in a readable format, and the official MetaMask site<\/a> documents how to interpret common error messages and how to configure the wallet for debugging.<\/p>\n The practical consequence of misdiagnosing a failure can be expensive. If a user assumes a transaction failed due to insufficient gas and increases the gas limit, then resubmits, they will pay transaction fees twice\u2014once for the original failed attempt and once for the retry. If the actual problem was that the contract reverted due to logic failure, increasing the gas limit solves nothing. The transaction will reverted again at the higher gas limit, wasting additional funds.<\/p>\n Conversely, if a transaction failed due to insufficient gas and the user assumes it was a contract logic error, they might modify the transaction parameters\u2014adjusting slippage, amounts, or addresses\u2014without addressing the actual problem. They might even conclude that the decentralized application is broken or that their wallet is malfunctioning, when the issue is simply a resource constraint.<\/p>\n The correct remediation sequence is therefore: first, determine whether the failure is a revert or out-of-gas. Second, understand the reason for the specific failure\u2014what contract condition was not met, or why did the computation exceed the gas estimate. Third, implement the appropriate fix. For a revert, this usually means changing transaction parameters (reducing slippage, increasing allowances, adjusting amounts) or waiting for network conditions to change. For out-of-gas, it means increasing the gas limit and retrying, with the understanding that a failed retry will consume gas again.<\/p>\n A third scenario worth considering is that the transaction might be pending rather than failed. A transaction that appears stuck in MetaMask for hours has not necessarily failed; it may be waiting in the memory pool to be mined. Network congestion, insufficient gas price relative to current conditions, or other factors can cause delays. In this case, the user can view the transaction on a block explorer to confirm its status. If the transaction is truly pending, the user can accelerate it by using MetaMask’s \u00ab\u00a0speed up\u00a0\u00bb feature, which resubmits the same transaction with a higher gas price.<\/p>\n The most reliable failure prevention strategy is to treat MetaMask’s simulation as the authoritative source of truth. If the wallet displays an error message during the approval phase\u2014before the user presses \u00ab\u00a0confirm\u00a0\u00bb\u2014that error is likely real. Ignoring the warning or trying to proceed anyway usually results in spending gas on a failed transaction. Conversely, if the simulation shows \u00ab\u00a0success,\u00a0\u00bb the transaction is likely to succeed unless blockchain state changes between the simulation and the mining.<\/p>\n Practical verification includes several habits. First, review the simulation output carefully. MetaMask displays the transaction data, the estimated gas cost, and any alerts. Confirm that the receiving address is correct, the amount is correct, and the token or asset is correct. A single typo in an address can result in permanent loss; the transaction will succeed from a gas perspective, but the funds will be sent to the wrong place. MetaMask does not protect against address mistakes because the contract has no way to verify intent.<\/p>\n Second, monitor gas prices before submitting. MetaMask shows the current gas price and the total fee estimate, but conditions change rapidly during high-traffic periods. A user who approves a transaction at a low gas price but waits several minutes to click \u00ab\u00a0confirm\u00a0\u00bb may find that the gas price has increased significantly. Resubmitting with a new estimate is safer than hoping the old estimate is still valid.<\/p>\n Third, start with small transactions when interacting with unfamiliar protocols or contracts. A user interacting with a new decentralized application for the first time should test with a small amount first, verify that the transaction succeeds and produces the expected result, then attempt larger transactions. This approach limits the impact of contract bugs, unexpected behavior, or misunderstandings about how the application works.<\/p>\n MetaMask provides \u00ab\u00a0standard,\u00a0\u00bb \u00ab\u00a0fast,\u00a0\u00bb and \u00ab\u00a0max\u00a0\u00bb gas price presets, along with the ability to set custom gas limit and gas price. Understanding these controls is essential for avoiding both out-of-gas errors and overpaying for transactions. The gas price (measured in gwei) determines how quickly the transaction is mined; higher price means higher priority in the memory pool. The gas limit determines the maximum amount of computational work the transaction can perform.<\/p>\n Lowering the gas limit below MetaMask’s recommendation increases the risk of out-of-gas errors, particularly for complex transactions involving multiple contract interactions or state changes. A user who manually sets a gas limit of 21,000 units to swap tokens on a decentralized exchange will almost certainly fail; the actual cost is often 100,000 or more units. MetaMask’s recommendation exists because the wallet has simulated the transaction and knows the estimated cost.<\/p>\n Conversely, setting the gas limit higher than the estimate does not waste funds\u2014the user only pays for the gas actually consumed, not the limit specified. If a transaction uses 80,000 gas out of a 100,000 limit, the user pays for 80,000. The unused 20,000 is not charged. This means there is no penalty for using a generous gas limit; it only protects against running out of gas if the estimate was low.<\/p>\n The gas price parameter requires more active judgment. During low-congestion periods, a low gas price is economical and will eventually get the transaction mined. During high-congestion periods, a low gas price may mean the transaction waits hours or never mines at all. MetaMask’s presets are helpful, but the user should check current network conditions\u2014available via gas price APIs or block explorer frontends\u2014to confirm whether the proposed gas price is competitive. Paying slightly more to ensure fast confirmation is often cheaper than the opportunity cost of waiting.<\/p>\n A user whose transaction failed should follow a systematic debugging process. First, note the transaction hash from MetaMask’s activity feed. Second, copy that hash into a block explorer for the relevant blockchain. Third, check the transaction status\u2014\u00a0\u00bbsuccess,\u00a0\u00bb \u00ab\u00a0reverted,\u00a0\u00bb or \u00ab\u00a0pending.\u00a0\u00bb Fourth, if reverted, note the revert reason displayed. Fifth, compare the gasUsed to gasLimit; if they are equal or very close, out-of-gas is likely.<\/p>\n If the diagnosis is a revert, examine the contract code or documentation to understand what condition was not met. Many blocks explorers display the contract code for verified contracts, and the relevant require() statement or error message often points to the issue. Common reasons include insufficient balance, missing approval, slippage exceeded, or conditions not matching the transaction parameters.<\/p>\n If the diagnosis is out-of-gas, the user should increase the gas limit by a percentage\u2014typically 10-20% more than the previous attempt\u2014and retry. The original failed transaction has already consumed gas, so the retry is an additional cost. Some users set the gas limit significantly higher (e.g., 200% of the estimate) to be conservative, accepting a slightly higher fee in exchange for certainty.<\/p>\n If the diagnosis is unclear\u2014the transaction status is marked as success on the block explorer but the intended outcome did not occur\u2014the failure is likely at the application layer. The contract executed successfully, but the application’s logic produced an unexpected result. This might be due to incorrect parameters, timing issues, or a mismatch between what the user expected and what the contract does. In this case, the user should review the application’s documentation or seek support, rather than retrying the same transaction.<\/p>\n Yes. Gas is charged for computational work performed by the blockchain, regardless of whether the transaction succeeds or fails. When a smart contract reverts, the state changes are rolled back, but the gas consumed up to the point of reversion is not refunded. The user pays for the failed attempt. This is why checking the simulation before approving a transaction is important.<\/p>\n<\/p><\/div>\n Check the transaction on a block explorer and compare the gasUsed to the gasLimit. If they are equal or very close, the transaction ran out of gas. If gasUsed is significantly lower than gasLimit, the transaction reverted during contract execution. The revert reason may also be displayed on the explorer or in MetaMask’s transaction details. You can also check the browser console for error messages.<\/p>\n<\/p><\/div>\n A reverted transaction fails because the smart contract’s logic explicitly rejects it\u2014for example, due to insufficient balance, slippage exceeded, or an unmet condition\u2014not because of insufficient computational resources. Increasing the gas limit provides more resources, but if the contract is rejecting the transaction for a logical reason, it will reject it again at any gas limit. The fix is to change the transaction parameters, not the gas allocation.<\/p>\n<\/p><\/div>\n<\/div>\n <\/p>\n","protected":false},"excerpt":{"rendered":" A user submits a transaction through MetaMask to interact with a decentralized application\u2014perhaps swapping tokens, depositing into a protocol, or claiming rewards. The transaction appears to be processing. Then, minutes or hours later, it either fails with a cryptic error message or disappears from the user’s activity feed entirely. The wallet shows the balance unchanged, but no clear explanation of what went wrong. This silent failure pattern occurs constantly in blockchain applications, and the root cause determines how the user should respond. The confusion stems from two fundamentally different failure modes that users and even experienced developers sometimes conflate. A reverted smart contract\u2014where the contract’s logic explicitly rejects the transaction\u2014is categorically different from an out-of-gas error, where the transaction runs out of computational resources before completion. One is a logic failure; the other is resource exhaustion. MetaMask’s simulation tools and transaction logs contain the diagnostic information needed to distinguish them, but that information is often overlooked or misinterpreted. Understanding the difference is essential for anyone using a crypto wallet to interact with blockchain applications, because the solution to one problem makes the other worse. What happens when a smart contract reverts A smart contract reversion occurs when the contract’s logic executes but encounters a condition that causes it to stop and reject the transaction. This could be an explicit require() statement that fails, an assertion that is false, a division by zero, an out-of-bounds array access, or any other operation that the contract code determines is invalid. When reversion happens, Continue Reading →<\/a><\/p>\n","protected":false},"author":3,"featured_media":0,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[1],"tags":[],"class_list":["post-8993","post","type-post","status-publish","format-standard","hentry","category-non-classe"],"_links":{"self":[{"href":"https:\/\/garage-durieux.fr\/index.php?rest_route=\/wp\/v2\/posts\/8993","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/garage-durieux.fr\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/garage-durieux.fr\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/garage-durieux.fr\/index.php?rest_route=\/wp\/v2\/users\/3"}],"replies":[{"embeddable":true,"href":"https:\/\/garage-durieux.fr\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=8993"}],"version-history":[{"count":0,"href":"https:\/\/garage-durieux.fr\/index.php?rest_route=\/wp\/v2\/posts\/8993\/revisions"}],"wp:attachment":[{"href":"https:\/\/garage-durieux.fr\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=8993"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/garage-durieux.fr\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=8993"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/garage-durieux.fr\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=8993"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}Why distinguishing the failure type matters for remediation<\/h2>\n
Preventing failures through simulation and verification<\/h2>\n
The role of custom gas settings and when to use them<\/h2>\n
Practical workflow for debugging failed transactions in MetaMask<\/h2>\n
\nFrequently asked questions<\/h2>\n
\nIf a transaction reverts, do I lose the gas I paid?<\/h3>\n
\nHow can I tell whether a failed transaction was an out-of-gas error or a revert?<\/h3>\n
\nWhy does increasing the gas limit not fix a reverted transaction?<\/h3>\n