Dynamic Pricing for Arbitrum chains

Dynamic pricing: a new pricing algorithm introduced in ArbOS 51 Dia

Arbitrum chains support a new gas pricing algorithm that uses multiple-gas targets, as part of the ArbOS 51 upgrade, to reduce the frequency and severity of child-chain gas price spikes. This is the first optimization of many towards Dynamic Pricing.

• This change is backward compatible. Setting new gas targets is not mandatory; if no new configuration is set, the legacy gas pricing algorithm with a single gas target remains active.
• Additional details: For those interested in how these values are derived, refer to the Gas and fees page as it provides the underlying parameters used to calculate the new gas targets and adjustment windows.

note

The upgrade to ArbOS 51 doesn't require activation of these new gas targets. The new targets are completely opt-in, so you can choose when to enable them.

Purpose

This improvement aims to reduce the severity, frequency, and duration of high L2 gas prices during periods when demand exceeds the gas target.

Detailed information on the purpose of this upgrade can be found in the AIP for implementing improvements to the pricing algorithm.

What does this improvement NOT help with?

• L1 gas fee spikes on Ethereum
• Data availability pricing

info

For more information about Effective block gas limit, refer to the Gas and fees page.

How to set multiple gas targets

You can call SetGasPricingConstraints on the ArbOwner precompile with an array of gas targets (the code refers to these targets as "constraints"), where each constraint contains [gasTargetPerSecond, adjustmentWindowSeconds, startingBacklogValue].

// Example: Set short-term and long-term constraints
// Define constraints: [gasTargetPerSecond, adjustmentWindowSeconds, startingBacklogValue]
const shortTerm = [30_000_000, 1, 800_000]; // Reacts to immediate spikes [cite: 10, 18]
const longTerm = [15_000_000, 600, 1_600_000]; // Ensures price stability [cite: 13, 18]
// Call ArbOwner precompile to set the constraints
await arbOwner.setGasPricingConstraints([shortTerm, longTerm]);

Refer to the definitions below to understand what each parameter means:

• gasTargetPerSecond is the target gas processing rate for your Arbitrum chain. It's the amount of gas the system aims to process each second under normal conditions. Any demand above this target will trigger a gas price increase to economically disincentivize usage until it falls back to the target.
• adjustmentWindowSeconds is the time period within which the system will measure average gas demand/usage to determine whether or not the gas price needs to be adjusted, relative to the gas target. A larger window results in more stable, predictable pricing, while a smaller window reacts aggressively to traffic spikes.
• startingBacklogValue is the initial amount of gas the system uses to set prices the exact moment the gasTargetPerSecond and adjustmentWindowSeconds get changed.
  • Ideally, the backlog value should be set to the existing backlog of the chain when the function call to setGasPricingConstraints is made. Given this is not always easy, using 0 is a common practice (the same will be done on Arbitrum One).
  • However, using 0 means that the system assumes that the demand is 0, causing the gas price to adjust to the minimum. L2 base fee (0.02 gwei/gas). After which, the system will resume tracking the backlog based on demand to price gas.

How to calculate the values for your chain

Offchain Labs has developed a script to help calculate pricing constraints, which takes in certain parameters to find the most optimized gas targets to use for your chain. The script takes in the following params:

• long_term_gas_target is the desired long-term average gas throughput for the chain. A higher gas target means that your chain can handle more TPS before the gas begins to spike. However, a higher gas target also leads to faster state growth and requires more powerful hardware.
  • State size limits: Guidance for setting your chains gas target
  • State growth guidance: Impact of high gas targets on state growth and its consequences
• node_throughput is the sustainable maximum throughput that the nodes can maintain without any issues. It is highly dependent on your specific hardware and the workload of your chain. Offchain Labs will soon publish testing frameworks and tools to benchmark the throughput your nodes can handle across various workloads.
• gas_limit is the theoretical max block size limit. With the introduction of the MaxTxGasLimit in ArbOS 51, the effective block gas limit is twice the MaxBlockGasLimit. We recommend using an in-between value of MaxBlockGasLimit and Effective Block Gas Limit (MaxTxGasLimit + MaxBlockGasLimit) for this parameter.
• max_rate_of_increase_percent_per_second is the maximum allowed rate of increase in the fee per second when the chain is working at the maximum capacity.
• long_term_adjustment_window_seconds is the maximum timeframe over which gas prices adjust. This window specifically applies to the lowest gas target to ensure price stability during low-demand periods.

The values listed below are used for calculating the gas targets for Arbitrum One. These values have been calculated based on various UX and research considerations.

Parameter	Arbitrum One Config
long_term_gas_target	10 Mgas/s
node_throughput	80 Mgas/s
gas_limit	128 Mgas/s
max_rate_of_increase_percent_per_second	20%
long_term_adjustment_window_seconds	86400 sec

Recommendation for Arbitrum chains

Arbitrum chain teams can use the following recommended values for the script parameters. The script will generate the optimized gas targets and adjustment windows for your chain, which you can then use to enable the new pricing system.

Parameter	Arbitrum One Config	Recommendation
long_term_gas_target	10 Mgas/s	Configure based on resource management considerations or the same as Arbitrum One.
node_throughput	80 Mgas/s	Same as Arbitrum One
gas_limit	128 Mgas/s	Based on the block limit for the chain, which by default is 32 million gas and assumes a 250ms block time. Can be set to (MaxBlockGasLimit + MaxEffectiveGasLimit) / 2
max_rate_of_increase_percent_per_second	20	Same as Arbitrum One
long_term_adjustment_window_seconds	86400 sec	Same as Arbitrum One