Failed transactions: measure gas spent per successful action
An application can spend gas on attempts that never complete its intended economic action. Researching cost efficiency therefore requires both transaction receipts and a defined success outcome. Counting only successful receipts hides failed-attempt expenditure, while counting every receipt as successful activity overstates completed work.
The Ethereum gas documentation explains payment for computational work and gas accounting. This worksheet uses actual charged gas for included transactions. Requests rejected before inclusion are another population; do not assign them an onchain fee without evidence that one was charged.
Define success before calculating a ratio
Specify the target contracts, action type, interval and economic success rule. A transaction status is one input, not always the whole answer. A successful wrapper call may contain an inner action that failed or was deliberately skipped. Inspect the relevant event or resulting state before classifying completed economic work.
For each attempt, preserve transaction hash, receipt status, gas used, effective gas price and application result. Compute execution cost from receipt fields, not the maximum gas limit. Reversion rolls back relevant execution changes but does not mean computation already performed was free.
Choose a cost boundary. A narrow measure can cover execution gas at the target network. Other fees, sponsored payments and multi-step operations may require additional columns. State who paid. Gross system cost and direct user cost differ when a sponsor absorbs the fee.
Hypothetical failed-attempt burden
Assume a fictional application has 90 successful one-action transactions and ten reverted transactions during a day. Each success uses 100,000 gas, while each revert uses 50,000. Assume every transaction pays an effective 20 gwei per gas.
Successful transactions consume 9,000,000 gas and cost 0.18 ETH. Failed transactions consume 500,000 gas and cost 0.01 ETH. Total expenditure is 0.19 ETH.
| Measure | Hypothetical result |
|---|---|
| Cost per included attempt | 0.19/100 = 0.0019 ETH |
| Successful-only cost per success | 0.18/90 = 0.002 ETH |
| All-attempt cost per completed action | 0.19/90 ≈ 0.002111 ETH |
| Failed share of expenditure | 0.01/0.19 ≈ 5.26% |
The last two measures reveal the failure burden. A ten-percent transaction failure rate does not mean ten percent of gas was wasted, because attempts consume different amounts. Every number here is hypothetical.
Now assume some successful transactions complete two actions each. The denominator must become the actual completed-action count, not 90 by habit. Save transaction and action counts so a change in batching does not appear as an unexplained efficiency improvement.
Diagnose change without assigning blame
Break failed expenditure down by documented error class, contract version and observed conditions. A higher failure share may reflect protective checks, incompatible inputs, market movement, user mistakes or defects. A revert message narrows the investigation but does not prove a single causal explanation.
Compare cohorts using the same action definition and fee boundary. If unit gas use falls while gas prices rise, ETH cost can still increase. Show resource-use and price changes separately. If a sponsor stops paying for some attempts, direct user cost may rise while aggregate application cost remains unchanged.
Keep retries linked where supported, but do not assume every repeated call is an accidental duplicate. Include incomplete multi-step workflows in a distinct category. Approval transactions can incur costs even if the intended later action never happens; including them depends on the announced workflow boundary.
Check a handful of transactions manually, including successes, reverts and conditional wrappers. Reconcile the sum of transaction costs to the aggregate expenditure before interpreting ratios. A correct division cannot repair missing receipts or an economic-action denominator assembled from a different contract population.
The final record is a cost-per-outcome bridge with failure expenditure visible. It is not an exchange order-state guide or a claim that an application is defective. Recheck when logic, bundling, sponsorship or the success definition changes.
Separate economic value from resource cost. A reverted transfer may move no token principal while still producing a fee; recording zero transferred value is consistent with nonzero expenditure. Also avoid treating every protective rejection as preventable waste. The measured cost exists, but whether it was avoidable requires a separate comparison with a feasible alternative execution path.
FAQ
Does a reverted transaction always cost zero?
No. An included transaction can be charged for gas consumed even when execution reverts. Use actual receipt costs.
Is receipt success enough to count a completed action?
Not always. For wrappers, bundles and conditional calls, verify the application-specific outcome and corresponding action count.