Fund the fee cap

The transaction has a native-ETH gas budget, an assumed base fee and a completion deadline. Its maximum fee must cover the assumed base fee; the gas budget must fund the full fee-cap reserve. Choose a fee cap, then check those two conditions and the separately entered timing schedule.

Every mission compares policies using the same starting resources and shared conditions. The public browser engine calculates the results from entered assumptions, without an account or live market feed.

The decision to compare

Which maximum fee fits the same native-token budget?

• Keep the reference cap. Repeat the entered cap to inspect its reserve requirement and conditional charge.
• Set a different fee cap. Change the maximum total fee. Keep the native balance, assumed base fee, tip and timing schedule fixed.

Asset identity and cash access

Asset identity, price and usable cash are separate questions in this mission.

Asset identity

ETH is the native gas asset in this EIP-1559-style illustration. The budget covers gas only; the model does not send token principal or native value.

Reserve versus charge

The fee cap determines the upfront reserve. The eventual conditional charge uses the entered gas consumption, base fee and capped priority fee.

Timing evidence

Completion time is the entered queue wait plus the entered confirmation count multiplied by seconds per block. These values are assumptions.

What can change

Only the maximum fee cap changes between plans. A higher cap cannot accelerate the entered schedule in this model.

A calculated reference example

A 21,000 gas limit and 60 gwei maximum fee require 0.00126000 ETH upfront. The 0.00200000 ETH gas budget covers that reserve. Entered gas consumption and the capped tip produce a conditional charge of 0.00088200 ETH ($2.65 at the assumed ETH price). A zero charge when the cap blocks inclusion does not mean a free transaction. The entered timing totals 24 seconds against a 60-second deadline. The reference passes the declared conditions; neither inclusion nor finality has been observed.

The worked example uses the published default inputs and Go model yieldguard-experiments-1.2.0. The scenario starts on 2026-01-01; that date is an illustrative calendar origin, not a market observation date.

Sources and interpretation limits

The deadline result is conditional on the entered timing. Confirmation blocks are not a finality guarantee. Changing base fees, mempool ordering, reorgs and execution failure are not simulated. A conditional charge is not proof that an underfunded transaction ran.

Primary documentation explains mechanisms and product distinctions. The documentation does not verify these inputs or identify the illustration as a named product.

• EIP-1559: fee cap and gas accounting
• Ethereum: consensus and finality

• Illustrative user assumptions; no live market data or calibrated forecast.
• Results apply only to the declared mechanisms, horizon and search bounds.
• EIP-1559-style accounting: reserve gas limit times max fee; if eligible, charge gas used times base fee plus the capped tip. No native value transfer is included.
• Timing is deterministic only under the entered block interval and waiting-time assumptions. Blocks are not a guarantee of finality. Mempool ordering, reorgs, execution failure and changing base fees are excluded. Source: https://eips.ethereum.org/EIPS/eip-1559

Continue the investigation

Read the related calculation, controls and limits, or compare another mission using its own declared mechanism.

• A peg is not payroll cash — Trade the price discount against the payment deadline.
• Keep what the yield earns — Measure the same assumed yield after entry, gas and exit costs.