On Ethereum, a type-2 transaction's max fee caps its total price per gas, including the base fee and tip. The max priority fee caps only the tip, which can shrink when the base fee approaches the total cap. The final execution charge is gas used multiplied by the effective gas price. A large max fee is an authorization ceiling, not an automatic charge.
Two numbers in a wallet can therefore tell an incomplete story. You also need the inclusion block's base fee and the quantity of gas charged. This guide follows ordinary sender-paid Ethereum layer 1 type-2 transactions under EIP-1559. All numerical scenarios are hypothetical, with no blob charges, sponsorship or additional service fees.
Read the caps in the right units
Ethereum's transaction documentation distinguishes the total per-gas cap from the priority cap. Neither is a gas quantity or a total ETH amount.
| Item | Meaning | Unit in this guide |
|---|---|---|
Max fee, maxFeePerGas | Highest total price authorized per gas | Gwei per gas |
Priority cap, maxPriorityFeePerGas | Highest tip authorized per gas | Gwei per gas |
| Base fee | Protocol price for the inclusion block | Gwei per gas |
| Gas limit | Maximum gas provided to the transaction | Gas units |
| Receipt gas used | Gas charged to this included transaction | Gas units |
The base-fee portion is burned. The tip is the remaining paid component; calling the entire execution fee a validator payment would include the burned amount. Ethereum's gas overview explains that split and the conversion: one gwei equals one-billionth of an ETH.
Wallet interfaces can abbreviate these labels. In an RPC request, check the actual field names. For example, Geth's transaction-call object reference defines maxFeePerGas as the total per-gas limit and maxPriorityFeePerGas as the tip limit. A value entered into one cannot stand in for the other.
The base fee takes room inside the total cap
Let F be the max fee, P the priority cap and B the inclusion block's base fee, all expressed in the same per-gas unit. First check that F is at least B and at least P. Then calculate:
actual tip = min(P, F − B)
effective price = B + actual tip
Equivalently, the effective price is the smaller of F and B + P. These are the fee checks and capped-tip calculation in EIP-1559's specification. Other transaction-validity requirements still apply.
Suppose F is 40 gwei and P is 3 gwei. The full 3-gwei tip fits while B is at most 37 gwei. Above that threshold, the total cap squeezes the tip. At a 39-gwei base fee, only 1 gwei remains available for it.
Raising P to 10 gwei in that last situation still leaves an actual tip of 1 gwei. The unchanged 40-gwei total cap is binding. Conversely, at a 22-gwei base fee, raising F from 40 to 60 gwei leaves the effective price at 25 gwei when P stays at 3. More authorization does not automatically create a larger payment.
At B = F, the fee rules allow a zero tip. That says nothing about whether a block producer will choose the transaction. Fee eligibility is one condition for inclusion, not a reserved place in a block.
One candidate, three alternative outcomes
Consider a hypothetical contract call with these signed settings:
- Gas limit: 100,000 units.
- Max fee: 40 gwei per gas.
- Priority cap: 3 gwei per gas.
- Attached ETH value: zero.
Assume all other validity requirements are met. In each included scenario, stipulate a final receipt showing 64,000 gas used. Holding that quantity constant isolates the price effect; a real contract's execution path can change between blocks.
These are alternative outcomes for one candidate, not three transactions that all incur charges.
| Scenario | Block base fee | Paid tip | Effective price | Execution fee |
|---|---|---|---|---|
| A: full tip fits | 22 gwei | 3 gwei | 25 gwei | 0.001600 ETH |
| B: total cap binds | 39 gwei | 1 gwei | 40 gwei | 0.002560 ETH |
| C: base exceeds cap | 41 gwei | — | — | No included execution in this scenario |
For A, multiply 64,000 by 25 to obtain 1,600,000 gwei, or 0.001600 ETH. Its base-fee portion is 64,000 × 22 = 1,408,000 gwei. Its tip is 64,000 × 3 = 192,000 gwei. Those two amounts sum to the execution charge.
For B, 64,000 × 40 gives 2,560,000 gwei, or 0.002560 ETH. The split is 0.002496 ETH burned and 0.000064 ETH in tips. The transaction costs more than A even though its paid tip is smaller: the base-fee increase outweighs the squeezed tip.
For C, stop before calculating a tip. A 40-gwei cap cannot cover a 41-gwei base fee. Substituting those values into the formula and reporting a negative tip would skip the eligibility check. The candidate has no receipt for execution in that block. It could become eligible for a later block with a lower base fee; this scenario does not establish permanent failure or cancellation.
Where the unspent ceiling goes
The signed gas-fee ceiling is 100,000 × 40 gwei = 0.004000 ETH. For this ordinary sender-paid transaction, EIP-1559's affordability check requires enough ETH to cover that ceiling plus attached value. Having enough for A's eventual 0.001600 ETH charge alone does not satisfy that check.
The specification's reference flow charges provided gas at the effective price, then credits unused gas at that price. Fee-cap headroom above the effective price is not charged in that calculation. This distinction explains two different sources of unspent budget:
| Part of the 0.004000 ETH ceiling | Scenario A | Scenario B |
|---|---|---|
| Final execution charge | 0.001600 ETH | 0.002560 ETH |
| Price headroom never charged | 0.001500 ETH | 0 ETH |
| Unused gas returned at effective price | 0.000900 ETH | 0.001440 ETH |
| Sum | 0.004000 ETH | 0.004000 ETH |
For A, the 15-gwei price gap applies to 100,000 provided units: 100,000 × (40 − 25) = 1,500,000 gwei. The unused quantity is 36,000 gas, credited at 25 gwei for another 900,000 gwei. Subtract both from the ceiling to recover the 0.001600 ETH charge.
For B, there is no price gap because the effective price reaches the cap. The unused 36,000 gas is credited at 40 gwei, leaving 0.001440 ETH unspent.
“Refund” in a wallet explanation can refer broadly to spending less than the displayed maximum. Do not expect a separate transfer of 0.002400 ETH in A. That amount is the difference between the ceiling and final charge; the table explains its components. Reconcile the final native-currency charge before interpreting a wallet's activity labels.
Change the setting that addresses the problem
A transaction can wait or fail for several reasons. The numbers above help distinguish a price constraint from an execution problem.
The base fee is above the total cap. A larger priority cap alone cannot fix C. Reassess the total authorization against the base fee and your spending limit, or wait. A new estimate is an observation, not a promise about the eventual inclusion block.
The priority cap is squeezed. In B, increasing the priority cap alone changes nothing. Check both caps together before approving a fee edit. If replacing a pending transaction, follow the submitting client's actual replacement policy; the protocol's capped-tip equation does not specify a universal replacement bump.
The gas quantity is inadequate. A price increase buys no extra gas units. Check the call and estimation assumptions before changing the gas limit. Ethereum's gas-limit documentation distinguishes rejection before inclusion from running out of gas during execution. Included failed execution can still incur a charge. The failed-swap gas ledger covers how to account for that attempt alongside a later retry.
The call has a permission or state problem. Fee settings do not grant an ERC-20 spender permission; approve and allowance address that separately. The access-list versus token-allowance comparison separates a transaction's access declarations from spending authorization. If the contract conditions still fail, a larger fee budget can simply produce another paid failure.
Check the signed budget, then settle from the receipt
Use this worksheet for a particular candidate rather than choosing settings from an isolated gas-price headline.
| Check | Record | Decision it supports |
|---|---|---|
| Transaction scope | Chain ID, sender, type, destination, calldata and attached value | Confirm which action and fee model you are authorizing |
| Gas quantity | Estimate context and chosen gas limit | Assess the execution allowance separately from its price |
| Total ceiling | Gas limit × max fee, converted to ETH | Confirm the gas budget and funding requirement |
| Tip headroom | Priority cap and max fee minus each tested base fee | Identify where the full tip fits, shrinks or becomes ineligible |
| Pending identity | Hash, nonce and any replacement hashes | Reconcile the existing candidate before a fresh submission |
| Final charge | Receipt gas used and effective gas price | Book actual execution cost after inclusion is verified |
For the last row, Ethereum's receipt reference defines gasUsed for the individual transaction and effectiveGasPrice for the paid per-unit price. Do not use cumulativeGasUsed, which accumulates gas within the block. Preserve the receipt's block hash and check the inclusion block rather than using today's base fee.
Calculate the execution charge in integer wei, then convert for display. If you reconstruct the split, subtract that block's base fee from the effective price to obtain the paid tip. Never add the priority cap on top of an already effective price. A pending candidate has no available receipt, so keep its cost unresolved instead of booking the maximum as an expense.
Verify the intended contract result separately. For token activity, the storage-slot versus token-balance guide explains why a raw state reading needs the right interpretation. Paying for execution does not by itself verify the intended token outcome.
Finally, apply this worksheet only to its stated execution-fee scope. Blob fees and L2 gas belong to different resource and payer breakdowns. Before signing, save the ceiling and the base-fee scenarios it tolerates. After inclusion, replace the estimate with the receipt-based charge and explain the difference in gas quantity and paid price.