Guidance for Arbitrum chains gas target
What is the gas target on an Arbitrum chain?
The parameter that governs an Arbitrum chain's throughput limit is known as the gas target.
The gas target is measured in gas per second and is used as a threshold for increasing gas prices.
For example, when cumulative usage on Arbitrum One and Arbitrum Nova exceed a certain amount of gas per second, the L2 base fee rises to increase the amount of gwei charged per unit of gas. This happens using a similar approach to Ethereum's EIP-1559 pricing algorithm.
You can read more about how gas fees are calculated on Arbitrum in this explainer
Why do we have throughput limits on blockchains?
The effect of raising gas prices at the gas target is to curb user demand when the chain is congested. Doing so protects the chain's underlying infrastructure from being overloaded.
This is because blockchain nodes have computation constraints that should not be exceeded. Charging more during congested periods ensures that high-priority transactions can still be processed while deterring users and apps from submitting low-priority transactions until a lower activity period.
The gas target, therefore, is fundamentally a protective mechanism. If the chain load exceeds what a Nitro validator node can process, then a chain risks halting due to validator downtime. It's important to note here that the security and liveness of an Arbitrum chain are always maintained through its parent chain contracts, but undoubtedly, the best user experience requires the validators and sequencer to be online.
What are the risks of increasing my gas target?
An increase in the speed target allows users and apps to perform more onchain actions without incurring additional costs. This makes it possible for a chain's nodes to experience higher and unexpected loads. When faced with high, sustained demand, the additional load could eventually lead to undesirable increases in infrastructure costs, cause nodes to lag behind the chain, and risk halting if the demand exceeds the resources of validator nodes.
Refer to the State Growth article for more information.
How to set the gas target
You set the gas target by calling the precompile ArbOwner at address 0x0000000000000000000000000000000000000070. Only a chain owner can call it. Calls from any other account revert.
Before you change anything, find out which pricing model your chain runs. The model decides which method takes effect:
| Pricing model | Method that sets the target | How to read the current value |
|---|---|---|
| Single gas target | ArbOwner.setSpeedLimit(uint64 limit) | ArbGasInfo.getGasAccountingParams() |
| Multiple gas targets | ArbOwner.setGasPricingConstraints(uint64[3][]) | ArbGasInfo.getGasPricingConstraints() |
Call ArbGasInfo.getGasPricingConstraints() first (available from ArbOS 51 onward; on earlier versions the call reverts and your chain always uses a single gas target). If it returns an empty array, your chain uses a single gas target and setSpeedLimit applies. If it returns one or more constraints, your chain uses multiple gas targets.
From ArbOS 51 Dia onward, setSpeedLimit writes only the single gas target value. It does not change a multiple gas target configuration. On a chain with constraints configured, the call succeeds and the stored value changes, but gas prices do not respond. To move such a chain back to a single gas target, call setGasPricingConstraints with an empty array, then call setSpeedLimit.
Parameters that only the single gas target model uses
setSpeedLimit is one of four ArbOwner methods that configure the single gas target model. If your chain uses multiple gas targets, all four write a stored value that has no effect on pricing:
| Method | What it sets | Default | How to read the current value |
|---|---|---|---|
setSpeedLimit(uint64 limit) | The gas target, in gas per second | 7,000,000 | ArbGasInfo.getGasAccountingParams() |
setL2GasPricingInertia(uint64 sec) | How slowly the base fee responds to backlogged gas. Higher values react more slowly | 102 | ArbGasInfo.getPricingInertia() |
setL2GasBacklogTolerance(uint64 sec) | The backlog ArbOS forgives before it raises the base fee, in seconds | 10 | ArbGasInfo.getGasBacklogTolerance() |
setGasBacklog(uint64 backlog) | The accumulated backlog directly, bypassing normal accounting | 0 | ArbGasInfo.getGasBacklog() |
To tune the equivalent behavior on a chain that uses multiple gas targets, set the adjustmentWindowSeconds and startingBacklogValue fields of each constraint instead. Refer to how to configure dynamic pricing for your chain.
These four parameters control how the chain prices congestion. They do not control what the chain charges for posting data to the parent chain. For that, refer to tune parent chain data fee pricing.
Set a single gas target
The gas target is measured in gas per second. The default is 7,000,000 gas per second as of ArbOS 6, up from 1,000,000 in ArbOS 0.
To raise the target to 10,000,000 gas per second:
cast send --rpc-url $ORBIT_RPC --private-key $OWNER_KEY 0x0000000000000000000000000000000000000070 "setSpeedLimit(uint64)" 10000000
Confirm the new value:
cast call --rpc-url $ORBIT_RPC 0x000000000000000000000000000000000000006c "getGasAccountingParams()"
getGasAccountingParams() returns the gas target, the pool size, and the block gas limit. Check that the first value matches what you set.
Raise the target in small steps and watch your nodes between each step. Refer to monitoring your Arbitrum chain for the metrics to watch, and to configure and optimize gas for the other gas parameters you can tune.
Set multiple gas targets
Multiple gas targets smooth price transitions and are the recommended configuration from ArbOS 51 Dia onward. To configure them, refer to how to configure dynamic pricing for your chain.
For the full list of ArbOwner methods, refer to the precompiles reference.
Is Offchain Labs working on software improvements to allow Arbitrum chain owners to safely raise their chain's speed target?
Yes. Offchain Labs is currently working on several key initiatives to improve the core Nitro node software that would result in a safe and formally endorsed increase in the speed targets for Arbitrum chains. These initiatives include migrations to PathDB and PebbleDB (alongside their respective optimizations for Arbitrum chains) and alternative execution layer client implementations for Nitro (e.g., Reth). We will share updates and news on these initiatives when we have them––stay tuned!