A gas fee is the billable amount of work performed on-chain multiplied by the effective price per unit. For ordinary Ethereum mainnet transactions, the upfront funding check uses the gas limit and maximum fee rate; the actual fee is checked against the transaction receipt, the record of execution. Ethereum.org’s Gas and fees explains this distinction. An estimate guarantees neither inclusion nor success, and a failed transaction must first be classified as rejected before inclusion or reverted during on-chain execution.
Your wallet says to have 0.0032 ETH, Ethereum’s native coin, available, yet the final charge is only 0.001404 ETH. Where did the difference go? Another transaction failed, so why did it still cost money? Mixing up limits, usage, and failure stages can lead to two opposite mistakes: assuming a higher limit always means a higher charge, or assuming failure always means a refund.
We will separate the units, calculate both the funding requirement and the actual fee from one set of teaching inputs, then change one condition at a time to examine pending and failed outcomes. Understanding the fields is more useful than immediately choosing the fastest option.
Separate Gas Usage from the ETH Fee
Gas measures computational work; the ETH fee is what you pay for that work. A price per unit connects them. The gas limit is not an amount of ETH, and the price alone does not establish whether an entire operation is inexpensive.
This article calculates only the execution fee for ordinary EIP-1559 transactions on Ethereum mainnet. EIP-1559 is the fee mechanism that distinguishes the base fee, priority fee, and maximum fee rate. The sending account pays its own fees in our example; third-party fee sponsorship is outside its assumptions. For the full transfer sequence, start with the crypto wallet guide.
Gas Limit Caps the Work; Gwei Expresses the Unit Price
Gas Limit is the maximum gas the transaction may use. Gas Used is the amount ultimately counted toward its fee. Gwei is a small denomination of ETH: 1 Gwei equals one-billionth of an ETH. If usage is 50,000 gas and the effective price is 20 Gwei, the fee is 50,000 × 20 ÷ one billion, or 0.001 ETH.
More complex operations may require more work; greater network demand may change the price. Ethereum.org’s Gas and fees explains these two sources of cost. A simple ETH transfer, a token transfer, and a multistep contract interaction should not all be assigned one fixed limit. If estimation fails, forcing the number lower does not make the operation safely cheaper.
Maximum Fee and Priority Fee Are Different Caps
Base Fee is the protocol-set base price per gas. Max Priority Fee caps the additional priority price you are willing to pay per gas. Max Fee caps the overall price per gas. In EIP-1559, the latter two correspond to maxPriorityFeePerGas and maxFeePerGas. Do not add the two caps together as another total that can be charged.
The original EIP-1559 specification first requires Max Fee to be at least the block’s Base Fee and at least Max Priority Fee. Only then does the following effective-price formula apply. The effective priority fee is the smaller of the priority cap and Max Fee minus Base Fee. Add the base fee to obtain the effective price. If little room remains under the overall cap, the full requested priority fee cannot necessarily be paid. We checked the specification’s formula on October 27, 2026; the example below substitutes values step by step.
Calculate the Funding Requirement, Then Check the Receipt
Check available funds against the transaction’s caps, and calculate the actual charge from its receipt after inclusion. Assume an account holds 0.004 ETH and submits a token-contract interaction with zero native ETH being sent. Fix Gas Limit at 80,000, Max Fee at 40 Gwei, and Max Priority Fee at 2 Gwei. Assume the inclusion block has a Base Fee of 25 Gwei and final Gas Used is 52,000. These are all teaching inputs, with no actual broadcast or real receipt.
Step 1: Fix the Inputs for One Contract Interaction
Before submission, calculate the fee cap: 80,000 × 40 Gwei equals 0.0032 ETH. Our account has 0.004 ETH and sends zero native ETH, so it passes this funding check. If the transaction also sends ETH, add that amount to the required funds; checking only the fee is insufficient.
This calculation answers whether funds cover the capped requirement. It does not establish the final charge or guarantee inclusion. Gas estimates also depend on execution state. If estimation fails, or the contract or operation is unclear, investigate first instead of removing safety margins just to fit the balance.
Step 2: Use the Smaller Value to Find the Effective Price
Subtract the base fee from the maximum price: 40 − 25 leaves 15 Gwei. Compare that with the priority cap of 2 and take the smaller value, 2. The effective price is therefore 25 + 2 = 27 Gwei, rather than 40 + 2 or the full 40.
Written out: effective priority fee = min(2, 40 − 25) = 2, followed by effective price = 25 + 2 = 27. Here, min means the smaller value. The base fee of 25 is an assumed condition of the inclusion block. An earlier screenshot cannot guarantee the same value when a real transaction is included later.
Step 3: Calculate the Charge from Actual Gas Usage
Assume the transaction succeeds and its receipt reports Gas Used of 52,000 and an effective price of 27 Gwei. The actual execution fee is 52,000 × 27 ÷ one billion = 0.001404 ETH. With no other ETH movements under our assumptions, the remaining account balance is 0.002596 ETH.
The 0.0032 figure is the advance cap; 0.001404 is the assumed actual fee. Their difference is 0.001796 ETH. Subtracting them does not establish a separate refund transaction. The protocol has settlement rules for unused gas and related charges, and wallet displays may differ. Reconcile the receipt and actual balance instead of treating the entire cap as money already deducted and the difference as another completed transfer.
Split the same fee into its components: 52,000 × 25 Gwei gives a base-fee portion of 0.0013 ETH, while 52,000 × 2 Gwei gives an effective priority-fee portion of 0.000104 ETH. They still total 0.001404. These are two parts of the same charge, not extra amounts to add on top of it.
We can subtract the fee directly from the initial 0.004 ETH because no native ETH is sent in this example. If you also pay someone in ETH, subtract that transfer separately. Check token balances separately too; gas fees are not the token trade’s profit or loss.
Step 4: Change One Field and See What Changes
First, raise only Gas Limit to 120,000 while keeping the assumed actual usage of 52,000 and effective price of 27 Gwei. The funding cap rises to 0.0048 ETH, exceeding the fixed 0.004 ETH balance. This branch must stop: it cannot be recorded as a transaction that can be submitted or has completed. As a separate arithmetic comparison, 52,000 × 27 Gwei still equals 0.001404 ETH. That multiplication does not make an underfunded transaction executable. Raising a work limit differs from actually performing more work.
Now return to the 80,000 limit and change only the assumed Base Fee to 39 Gwei. Just 1 Gwei remains under the maximum price, so the effective priority fee becomes min(2, 1) = 1 and the effective price becomes 40. At the same 52,000 gas usage, the fee is 0.00208 ETH. This is a separate scenario, not a replacement for the earlier 27 Gwei result.
If a prospective inclusion block has a Base Fee of 41 while Max Fee remains 40, the transaction does not meet that block’s price conditions. Check the original transaction, estimate, and wallet behavior. Increasing Gas Limit cannot fix an insufficient price cap, and changing one field does not guarantee immediate inclusion.
First Identify Where a Transaction Failed
Rejection before block inclusion and failure during execution have different fee consequences. Ethereum.org’s Gas and fees distinguishes validation rejection from running out of gas during execution. A red failure message alone does not identify the applicable charging rule.
Rejection Before Inclusion Differs from an On-Chain Revert
A transaction rejected before inclusion because it fails validity requirements has no on-chain execution usage to charge. This statement concerns on-chain execution fees, not whether a platform separately charges a service fee. Check for a transaction receipt and inclusion record rather than relying on one wallet notification.
If a contract executes after inclusion and then reverts, or encounters REVERT, the intended operation’s state changes are rolled back, but computational resources already used may still be charged. At our effective price of 27 Gwei, a separate assumption of 30,000 billable gas produces a fee of 0.00081 ETH. Failing to obtain the intended outcome does not mean no computation occurred.
Running Out of Gas and Reverting Use Different Example Charges
If execution exhausts the 80,000 gas limit—Out of Gas—the fee at the same 27 Gwei is 0.00216 ETH. This and the earlier 30,000-gas revert are separate hypothetical failure branches. Do not add both charges to one transaction or claim every failure consumes the entire gas limit.
Before retrying, identify whether the problem is insufficient gas, unmet contract conditions, insufficient funds, or an inapplicable fee rate. Raising Gas Limit cannot make an operation satisfy contract rules it otherwise violates. Repeated attempts may create additional charges.
Why the Lowest Displayed Fee Is Not Enough
Compare prices for the same network, operation, and acceptable waiting conditions. Choosing only the smallest figure may change the receiving route or turn a workable operation into one likely to fail.
Low Limits, Changing Estimates, and Waiting Conditions
A gas limit that is too low may prevent completion. A fee cap that fails inclusion requirements may prevent inclusion. These limits use different units, so identify the field before changing it. If a submitted transaction is pending, inspect the original rather than immediately making a second payment for the same purpose.
An estimate for the same operation may change with network demand or contract state. Preserve the conditions at the time of comparison instead of using today’s lower rate as yesterday’s supposed cost. The teaching values here are not current quotes either.
Recheck the Entire Fee Model on Another Network
Ethereum mainnet’s single execution-fee formula is not a complete total-cost formula for every layer-2 network. A layer 2 helps expand mainnet processing capacity. OP Mainnet’s official Transaction fees documentation separately lists data fees and operator fees under applicable configurations; we checked it on October 27, 2026. Compare the full estimate for the network, not just one Gwei field.
A lower-cost network must also be supported by the recipient for the same asset and route. A network mismatch can create problems larger than the fee difference. Continue with transfer networks and receipt checks to verify the receiving conditions too.
Reduce Unnecessary Costs Without Breaking the Plan
Avoiding unnecessary duplicate operations is a better starting point than blindly lowering every limit. Understand what you need to accomplish, then decide which signatures and transactions are required. Saving one fee is not a reason to accept permissions you do not understand.
Understand Whether an Approval Is Needed
Some applications require token approval followed by a separate spending operation, so there may be multiple transactions. Whether each step requires an on-chain fee depends on its mechanism. For example, an EIP-2612 Permit can be submitted on-chain later by another party if the signature, nonce, deadline, and other conditions are valid. No gas charge at signing time does not make it an ordinary login.
Conversely, avoiding another approval is not a reason to grant an unknown spender an unlimited allowance. Cost and permission are separate decisions. See token approvals and revocation; a fee calculation does not endorse what you are signing.
Record Estimates, Caps, and Actual Charges Separately
For each transaction, record the pre-submission estimate, gas and fee caps, transaction identifier or TxID, and the actual usage and effective price after inclusion. Then reconcile the ETH balance. If no receipt is available, leave the actual charge unconfirmed. Unknown is not zero, and the maximum funding requirement is not an actual expense. Our sequence reads: balance 0.004, cap 0.0032, assumed actual fee 0.001404, and settled balance 0.002596. The first is the starting point, the second is an advance constraint, and the last two belong only to the assumed completed branch. While the transaction is pending, retain the first two and the original transaction identifier; do not fill in the completed balance in advance.
When checking a receipt, match its identifier, network, and success status to the original operation. A transaction with a similar fee is not necessarily yours. Actual gas usage and effective price must come from the same included transaction. If the wallet shows only an estimate and no verifiable inclusion result is available, retain the pending status instead of entering this article’s assumed values in your records.
This article explains fee mechanics through teaching calculations and is not investment advice. All amounts and rates are hypothetical. Real networks, operations, and sponsorship arrangements may differ; estimates guarantee neither inclusion, success, nor a fixed cost.