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.

​
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 a cost of approximately $0.002 for a typical 200,000 gas transaction at an ETH price of $2000.

​
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.

​
How the L1 Fee Is Passed Through

The L1 security fee covers the cost of posting your transaction’s data to Ethereum. Base charges it per transaction at inclusion time, from the sender’s ETH balance, on top of the L2 execution fee. It is not a separate transaction or a later settlement. The L1 fee is an estimate, not the actual cost of the batch your transaction lands in. It is computed from:
  • The FastLZ-compressed size of your signed transaction
  • The Ethereum base fee and blob base fee, as reported to Base by the L1Block predeploy
  • The baseFeeScalar and blobBaseFeeScalar values set by the chain operator
See the Fjord L1 fee formula for the exact calculation. Because the inputs are Ethereum’s fees and your transaction’s size, the L1 fee follows Ethereum fee levels rather than activity on Base. Each transaction receipt reports the charged amount in its l1Fee field, alongside l1GasPrice, l1GasUsed, l1BaseFeeScalar, and l1BlobBaseFeeScalar.

​
Where Fees Go

Base does not burn any part of the transaction fee. Unlike Ethereum, where EIP-1559 burns the base fee, each fee component on Base accrues in its own fee vault predeploy: The operator fee is set by the operator fee parameters in SystemConfig. When both parameters are zero, no operator fee is charged. You can read the current values with operatorFeeScalar() and operatorFeeConstant() on the L1Block predeploy at 0x4200000000000000000000000000000000000015. Once a vault holds enough ETH, its balance can be withdrawn to a fixed recipient address configured in the vault. See Fees in the execution engine specification for details.

​
Estimating the Total Cost of a Transaction

The total fee for a transaction, such as a USDC or B20 transfer, is:
Total Fee
To estimate it before you send:
  1. Call eth_estimateGas for the transaction to get gasUsed.
  2. Read the current base fee from the latest block and a priority fee from eth_maxPriorityFeePerGas.
  3. Call getL1Fee on the GasPriceOracle with the serialized transaction to get l1Fee.
To see what a transaction actually paid, use the receipt: gasUsed * effectiveGasPrice + l1Fee. Costs change with demand in two 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, and falls back as demand eases. During DA throttling, transactions can also be delayed regardless of priority fee.
  • Activity on Ethereum: The L1 fee follows Ethereum’s base fee and blob base fee.
To review recent fee levels, call eth_feeHistory, which returns per-block base fees and priority fee percentiles.

​
Paying Gas Without ETH

The protocol charges every fee in ETH, from the sender’s ETH balance. B20 tokens do not change this: there is no protocol-level fee token. To let users pay without holding ETH, use one of the following:
  • Paymaster sponsorship: With ERC-4337 smart accounts, a paymaster pays the gas in ETH on the user’s behalf. CDP Paymaster sponsors userOperations that match the gas policy you configure, including contract and method allowlists, and bills you for the sponsored gas.
  • ERC-20 gas payment: A paymaster can instead collect an ERC-20 token from the user and pay the gas in ETH. CDP Paymaster supports this for the tokens listed in its ERC-20 gas payments guide. pm_getAcceptedPaymentTokens returns the tokens a paymaster accepts. To accept a token that CDP Paymaster does not list, use an ERC-7677 paymaster that supports it.
  • Relayed payments: With x402, the facilitator submits the settlement transaction and pays its gas. The payer only signs an authorization. The settlement is a regular transaction from the facilitator, not a userOperation sent to your paymaster, so it does not draw on your paymaster’s sponsorship.
  • Native account abstraction (experimental): EIP-8130 transactions can name a payer that covers gas without a paymaster contract. EIP-8130 currently runs only on the vibenet devnet.
If CDP Paymaster rejects a request, see its error reference and troubleshooting guide. A -32002 error with the message request denied - no sponsorship and address can not pay with accepted token means your gas policy did not sponsor the userOperation and the sender cannot pay with an accepted ERC-20 token. If the sender is supposed to be sponsored, check that both the target contract and the called method, such as USDC’s transferWithAuthorization, are allowlisted in your Paymaster configuration in CDP Portal.