Skip to main content
This guide shows how to check and adjust the fee-related parameters on your chain’s SystemConfig contract, and when each adjustment makes sense. It applies to the Jovian and following hardforks. On an OP Stack chain a transaction’s Total Fee is made of three main components: Total Fee = L2 Fee + L1 Fee + Operator Fee Fees are gathered in dedicated contract fee vaults that collect the different fee components (for example BaseFeeVault, SequencerFeeVault, etc.). See the fee vault operations guide for how to manage and withdraw from these vaults.

​
Before you start

Only the SystemConfig owner can change these parameters.
Export the values used by all the commands below:

​
Tune the L2 fee

The L2 fee is the EVM execution cost: gasUsed * (baseFee + priorityFee). The baseFee is computed with the EIP-1559 mechanism and is collected in the BaseFeeVault (not burned) on OP Stack. You can tune L2 fee dynamics on the SystemConfig via:
  • eip1559Denominator: EIP-1559 max-change denominator, it appears in the denominator of the per-block base fee delta. Lower = faster response, so base fee adjusts faster but results in more volatility.
  • eip1559Elasticity: elasticity multiplier, sets the target relative to gasLimit. As gas_target = gasLimit / elasticity, a smaller gas target (larger elasticity) means the base fee will start increasing at a lower block gas usage (i.e., base fee increases sooner under load).
  • gasLimit: max gas per block. Lower gasLimit = less available gas per block (less supply), which makes base fees more sensitive to demand and can cause the base fee to move more easily.
  • minBaseFee: minimum floor on base fee, in wei (it can be 0). See setting the minimum base fee.

​
Check current values

​
Set values

​
Tune the L1 fee

The L1 fee charges for posting L2 data to L1: the transaction’s estimated compressed (FastLZ) size is multiplied by a scalar-weighted L1 price. See the fee parameters reference for the formula. Reasons to tweak it:
  • Modify margin charged on top of expected costs
  • Adjust FastLZ estimates to reflect costs
  • Differentiate charges for per-byte vs per-blob costs to reflect actual L1 pricing
The knobs:
  • basefeeScalar: scales the l1BaseFee contribution to the L1 data fee (per-byte).
  • blobBaseFeeScalar: scales the l1BlobBaseFee contribution (per-blob).

​
Check current values

​
Set values

​
Tune the operator fee

The operator fee is a discretionary, non-standard fee charged per transaction: (gasUsed * operatorFeeScalar * 100) + operatorFeeConstant. See setting the operator fee for a dedicated guide.
  • operatorFeeScalar: per-gas operator margin.
  • operatorFeeConstant: flat per-transaction operator fee, in wei.
Any non-zero operator fee makes the chain configuration non-standard.

​
Check current values

​
Set values

​
Tune the DA footprint limit

The daFootprintGasScalar is an in-protocol limit on estimated DA usage to prevent DA spam and priority fee auctions. See how the DA footprint block limit works for the concept and the DA footprint setup guide for a dedicated walkthrough.
  • Default value is 400
  • A value of 0 is treated as 400
  • Setting it to 1 effectively disables DA footprint limiting

​
Check current value

​
Set value

​
Example scenarios

​
Normal traffic / below EIP-1559 target

What you’ll see
  • If blocks stay below the EIP-1559 target, baseFee trends toward the minBaseFee floor.
  • When L1 data usage is low, the L2 execution fee (gasUsed * (baseFee + priorityFee)) is typically the largest cost component.
  • The L1 data fee remains low/steady if calldata per transaction is small.
What to tweak
  • Usually nothing.
  • If you need a revenue floor set/increase minBaseFee.
Tradeoff
  • Pros: minBaseFee prevents prolonged low base fees and provides a predictable minimum (can be left at 0 to improve UX).
  • Cons: If set too high, it raises inclusion cost for low-value transactions and can negatively impact UX/accessibility.

​
Busy blocks / congestion

What you’ll see
  • baseFee rises when blocks exceed the target: gas_target = gasLimit / eip1559Elasticity
  • Transactions with low priority tips may experience slower inclusion during congestion.
What to tweak
  • eip1559Elasticity and eip1559Denominator :
    • To increase responsiveness: decrease eip1559Denominator and/or increase eip1559Elasticity (smaller target → baseFee increases sooner).
    • To decrease volatility: increase eip1559Denominator and/or reduce aggressiveness in eip1559Elasticity.
Tradeoff
  • Pros: Faster base fee response better captures demand; elasticity provides direct control over the gas target.
  • Cons: Smaller denominator and/or aggressive elasticity increases per-block swings and increases fee volatility.

​
Calldata-heavy transactions

What you’ll see
  • L1 data fee becomes a larger share of total cost for calldata heavy transactions (the L1 fee scales with compressed calldata size).
  • Increasing basefeeScalar increases the per-byte L1 charge, making calldata heavy transactions more expensive.
What to tweak
  • basefeeScalar and blobBaseFeeScalar:
    • Increase them if you need to recover more L1/DA posting costs from data heavy transactions.
    • Decrease them if you want to reduce user cost for calldata/blob-heavy workloads.
Tradeoff
  • Pros: Enables proportional recovery of L1/DA posting costs.
  • Cons: Penalizes calldata/blob-heavy dapps/users. Aggressive values can impact UX and reduce activity.

​
Predictable operator revenue

What you’ll see
  • Introducing or increasing operatorFeeScalar raises the per-gas operator charge and increases predictable revenue per transaction.
  • operatorFeeConstant adds a flat per-transaction fee regardless of gas usage.
What to tweak
  • operatorFeeScalar and operatorFeeConstant:
    • Use when you want direct, predictable operator revenue independent of congestion and L1 fee dynamics.
Tradeoff
  • Pros: Direct and predictable revenue per transaction.
  • Cons: May discourage low-value transactions and changes transaction economics; should be used carefully. Any non-zero operator fee makes the chain configuration non-standard.

​
DA-heavy workloads / DA-spam resistance

What you’ll see
  • DA footprint can limit how much transaction data fits into a block through scaled accounting of compressed DA usage.
  • Increasing daFootprintGasScalar raises the gas charged per DA-byte footprint, reducing DA capacity for the same byte footprint and deterring DA-heavy patterns.
What to tweak
  • daFootprintGasScalar:
    • Default is 400, and 0 is treated as the default.
    • Setting it to 1 disables the DA footprint limiting behavior.
Tradeoff
  • Pros: Deters DA spam and makes DA costs explicit in block accounting.
  • Cons: Increasing it reduces DA capacity and may throttle the batcher or exclude legitimate DA-heavy workloads if set too aggressively.

​
Summary

  1. Make sure to check your current hardfork, this doc applies to Jovian and following hardforks.
  2. Check the current fee parameters on your SystemConfig contract (see the fee parameters reference for the expected values on OP Mainnet).
  3. Make small changes and observe: vault balances, inclusion times, dropped txs, DA throttling, etc.
  4. Extensively test all changes on a staging/testnet.
  5. Communicate changes to dapp/wallet teams (gas estimation will change).

​
References