Skip to main content

​
How Do Network Fees on Base Work?

Every Base transaction consists of two costs: an L2 (execution) fee and an L1 (security) fee. The L2 fee is the cost to execute your transaction on the L2, and the L1 fee is the estimated cost to publish the transaction on the L1. Typically the L1 security fee is higher than the L2 execution fee. The L1 fee will vary depending on the amount of transactions on the L1. If the timing of your transaction is flexible, you can save costs by submitting transactions during periods of lower gas on the L1 (for example, over the weekend) Similarly, the L2 fee can increase and decrease depending on how many transactions are being submitted to the L2. This adjustment mechanism has the same implementation as the L1; you can read more in Coinbase’s guide to EIP-1559. For additional details about fee calculation on Base, please refer to the network fees specification. To pay gas in a token instead of ETH, see Paying Gas in Tokens. To diagnose CDP Paymaster errors, see CDP Paymaster Rejections.

​
Minimum Base Fee

As part of the Jovian upgrade, Base introduced a minimum base fee. This feature sets a floor for the L2 base fee, preventing it from dropping to extremely low levels during periods of low network activity. The minimum base fee for Base Mainnet is 5,000,000 wei (0.005 gwei). This value may be periodically adjusted as we gather data on how it affects the chain. For reference, a minimum base fee of 0.005 gwei results in an L2 execution fee of approximately $0.002 for a 200,000 gas transaction at an ETH price of $2000. This figure includes no priority fee and excludes the L1 security fee. To estimate the full cost of a specific transaction, see Estimating the Total Cost of a Transaction.

​
Benefits

  • Faster Transaction Inclusion: Previously, when low activity caused the base fee to drop very low, spikes in demand could lead to extended periods of congestion before fees rose enough to clear the backlog. With a minimum base fee, transactions are typically included more quickly without users needing to manually adjust priority fees.
  • More Predictable Fees: During normal operation, the base fee will remain at or near the minimum. During congestion, the base fee rises above the minimum. This creates a more predictable fee structure similar to surge pricing.
  • Spam Prevention: Extremely low fees can incentivize spam transactions that don’t provide value to the network. The minimum base fee helps price out such activity while keeping fees affordable for legitimate use.

​
Current Configuration

See the Configuration Changelog for a history of changes to the minimum base fee and other network parameters.

​
EIP-1559 Fee Parameters

Base uses its own implementation of EIP-1559, which controls how the L2 base fee adjusts in response to network demand. Two key parameters govern this behavior:

​
Elasticity Multiplier

The Elasticity Multiplier determines the maximum gas capacity of a block relative to the target gas usage. With an elasticity of 6, blocks can contain up to 6× the target gas, allowing the network to absorb sudden demand spikes.

​
Base Fee Change Denominator

The Base Fee Change Denominator controls how quickly the base fee adjusts. A larger denominator means slower, more gradual fee changes. With a denominator of 125, the base fee changes more smoothly compared to lower values.

​
Maximum Rate of Change

The maximum rate of base fee change per block is calculated as: Max increase per block = (Elasticity - 1) / Denominator With the current parameters (Elasticity = 6, Denominator = 125):
  • Maximum increase per block: (6 - 1) / 125 = 4%
  • Minimum time to double the base fee: 18 blocks × 2 seconds = 36 seconds
This gradual adjustment helps prevent extreme fee volatility during traffic spikes while still allowing the network to respond to sustained demand.

​
Current Configuration

​
Querying the L1 Fee

The GasPriceOracle predeployment at 0x420000000000000000000000000000000000000F (listed in Contract Addresses) lets you programmatically estimate the L1 fee component before signing and submitting a transaction. Use getL1FeeUpperBound when you need a quick estimate before the transaction is fully constructed. Use getL1Fee with the complete serialized transaction for an exact value before signing.

​
Estimating the Total Cost of a Transaction

The total cost of a USDC or B20 transfer depends on the gas the transfer uses, the size of the signed transaction, and current fee levels on Base and Ethereum. Estimate the cost for your own transaction using the steps below. The total fee for a transaction is:
Total Fee
To estimate it before you send a transfer:
  1. Call eth_estimateGas for the transfer to get gasUsed.
  2. Read the base fee from the latest block, and get a priority fee from eth_maxPriorityFeePerGas.
  3. Call getL1Fee on the GasPriceOracle with the serialized transaction to get l1Fee.
  4. Call getOperatorFee(gasUsed) on the GasPriceOracle to get operatorFee. It returns zero when the operator fee parameters are zero.
To convert the result to a fiat amount, multiply by an ETH price and record the price and time you used, since both the fees and the price change. To see what a transaction actually paid, read its receipt with eth_getTransactionReceipt. gasUsed * effectiveGasPrice is the L2 execution fee, and the l1Fee field is the L1 security fee.

​
How Cost Changes With Volume

Costs change with demand in three independent ways:
  • Activity on Base: When blocks use more gas than the target, the L2 base fee rises above the minimum base fee by up to 4% per block. It falls back as demand eases.
  • Data availability throttling: During DA throttling, transactions can be delayed regardless of priority fee.
  • Activity on Ethereum: The L1 fee follows the Ethereum base fee and blob base fee, as reported to Base by the L1Block predeploy.
The protocol does not apply volume discounts: each transaction pays its own fees at the rates in effect when it is included. To review recent fee levels, call eth_feeHistory, which returns per-block base fees and priority fee percentiles.

​
Validity Transactions

Validity Transactions use the normal fee rules for their transaction type. For EIP-1559 transactions, set maxFeePerGas and maxPriorityFeePerGas on the signed transaction. A validity transaction that is not included does not pay onchain execution fees. An included validity transaction pays normal execution fees, even if it reverts.