Gas and Fees
Arbitrum uses gas to track the execution cost on an Arbitrum Nitro chain. It works the same as Ethereum gas, in the sense that every EVM instruction costs the same amount of gas as it would on Ethereum.
There are two parties a user pays when submitting a transaction:
- Poster: if reimbursable, for the parent chain resources such as the parent chain calldata needed to post the transaction.
- Network fee account: will cover the child chain's resources, including computation, storage, and other burdens that child chain nodes must bear to service transactions.
The parent chain component is the product of the transaction’s estimated contribution to its batch’s size—computed using Brotli on the transaction alone—and the child chain’s view of the parent chain data price. This value dynamically adjusts over time to ensure the batch poster is ultimately fairly compensated.
The child chain component consists of the traditional fees Geth would pay to bonders in a vanilla parent chain, such as the computation and storage charges that apply to the State Transition Function (STF). ArbOS charges additional fees for executing its child-chain-specific precompiles, whose fees are dynamically priced based on the resources used during execution.
The following sections will detail how to calculate parent and child chain fees. If you do not need precise calculations or a technical understanding, refer to the Parent chain to child chain messaging page.
Parent chain gas pricing
ArbOS dynamically prices the parent chain gas, with the price adjusting to ensure that the amount collected in the parent chain gas fees is as close as possible to the costs that must be covered, over time.
Parent chain costs
There are two types of parent chain costs: batch posting costs and rewards.
Batch posting costs reflect the actual cost a batch poster pays to post batch data on the parent chain. Whenever a batch is posted, the parent chain contract that records it will send a special “batch posting report” message to the child chain ArbOS, reporting who paid for the batch and the parent chain basefee at the time. This message is placed in the chain’s delayed inbox so that it will be delivered to the child chain ArbOS after some delay.
When a batch posting report message arrives at the child chain, ArbOS computes the cost of the referenced batch by multiplying the reported basefee by the batch’s data cost. (ArbOS retrieves the batch’s data from its inbox state and computes the parent chain gas the batch would have used by counting the number of zero bytes and non-zero bytes in the batch.) The pricer records the resulting cost as funds due to the party who is reported to have submitted the batch.
The second type of parent chain cost is an optional (per chain) per-unit reward for handling transaction calldata. In general, the reward might be paid to the Sequencer, or to members of the Data Availability Committee in an AnyTrust chain, or to anyone else who incurs per-calldata-byte costs on behalf of the chain. The reward is a fixed number of wei per data unit, and is paid to a single address.
The parent chain pricer keeps track of funds due to the reward address based on the number of data units processed so far. This amount is updated whenever a batch posting report arrives at the child chain.
Parent chain calldata fees
The parent chain calldata fees exist because the Sequencer, or the batch poster that posts the Sequencer’s transaction batches on Ethereum, incurs parent chain gas costs to post transactions on Ethereum as calldata. Funds collected in the parent chain calldata fees are credited to the batch poster to cover its costs.
Every transaction that comes in through the Sequencer will pay a parent chain calldata fee. Transactions that come in through the delayed inbox do not pay this fee because they don’t add to batch posting costs—but these transactions pay gas fees to Ethereum when they are put into the delayed inbox.
The parent chain pricing algorithm assigns a parent chain calldata fee to each Sequencer transaction. First, it computes the transaction’s size, an estimate of how many bytes the transaction will add to the compressed batch it is in; the formula includes an estimate of the transaction's compressibility.
Second, it multiples the computed size estimate by the current price per estimated byte to determine the transaction’s parent chain calldata wei in wei. Finally, it divides this cost by the current child chain basefee to convert the fee into child chain gas units. The result is reported as the “poster fee” for the transaction.
The price per estimated byte is set by a dynamic algorithm that compares the total parent-chain calldata fees collected to the total fees actually paid by batch posters and tries to bring the two as close to equality as possible. If batch poster costs are less than fee receipts, the price will increase; if they exceed fee receipts, the price will decrease.
Parent chain fee collection
A transaction is charged for the parent chain gas if and only if it arrived as part of a sequencer batch. This means that someone would have paid for the parent chain gas to post the transaction on the parent chain.
The estimated cost of posting a transaction on the parent chain is the product of the transaction’s estimated size and the current parent chain gas basefee. This estimated cost is divided by the current child-chain gas used for the parent-chain operation (see this article for more information.
The estimated size is measured in the parent chain gas. It is calculated as follows: first, compress the transaction’s data using the Brotli-zero algorithm, then multiply the size of the result by 16 (because the parent chain charges 16 gas per byte—the parent chain charges less for bytes that are zero, but that doesn’t apply here).
Brotli-zero is used to reward users for posting compressible transactions. Ideally, we would like to reward for posting transactions that contribute to the compressibility (using the Brotli compressor) of the entire batch, but that is a difficult notion to define and, in any case, would be too expensive to compute at the child chain. Brotli-zero is an approximation that is cheap to compute.
Parent chain gas fee funds collected from transactions are transferred to a special L1PricerFundsPool account, so that account’s balance represents the funds collected and available to pay for costs.
The parent chain pricer also records the total number of “data units” (the sum of the estimated sizes, multiplied by 16) received.
Child chain gas pricing
The child chain gas price on a given Arbitrum chain has a set floor, which can be queried via ArbGasInfo's getMinimumGasPrice method.
Estimating child chain gas
Calling the Arbitrum Node’s eth_estimateGas RPC returns a value sufficient to cover the full transaction fee at the given child chain gas price; i.e., the value returned from eth_estimateGas multiplied by the child chain gas price tells you how much total ETH is required for the transaction to succeed.
Note that this means that, for a given operation, the value returned by eth_estimateGas will change over time (as the parent chain's calldata price fluctuates). (See 2-D fees and How to estimate gas in Arbitrum for more.)
Child chain gas fees
Child chain gas fees work similarly to Ethereum: a transaction consumes gas, which is multiplied by the current basefee per gas (e.g., gwei) to determine the child chain transaction fee (denominated in gwei).
The basefee is set by a pricing algorithm that governs fees across multiple adjustment windows. This algorithm uses several gas targets, each paired with its own adjustment window. Higher targets with shorter windows (for example, 60 Mgas/s over nine seconds) absorb transient demand spikes without triggering aggressive fee increases. Lower targets with longer windows address slower traffic, with the lowest target measured over 86,400 seconds (one day), establishing the chain’s long-term capacity.
From the users’ perspective, this means that the network will charge an increasing amount for each additional amount of gas consumed above the target. For example, a 10% fee is levied for going 1% over the target. The fee rises to 15% if you go to 2% over the target, and so on.
The algorithm tracks a gas backlog for each target. Whenever a transaction consumes gas, that gas is added to the backlog. Each second, the corresponding gas target is subtracted from its backlog (the backlog cannot go below zero). If the backlog grows, the basefee increases exponentially to discourage usage; if the backlog shrinks, the basefee decreases to incentivize more demand. This behavior is intended to bring the chain's usage to an equilibrium defined by the long-term gas target.
This layered structure creates a dampening effect: overlapping windows smooth volatility at their respective timescales, reducing peak gas prices during congestion while preserving responsiveness to genuine capacity constraints.
For more details on how gas targets affect chain security and validator assumptions, see the gas target section below.
Child chain Tips
The sequencer prioritizes transactions on a first-come, first-served basis. Because tips do not make sense in this model, they are ignored. Arbitrum users always pay the basefee regardless of the tip they choose.
Gas estimating retryables
When a transaction schedules another, the cost of the subsequent transaction’s execution [will be included]will be included in the gas estimation via the node’s RPC. A transaction’s gas estimate, then, can only be found if all the transactions succeed at a given gas limit. This is especially important when working with retryables and scheduling redeem attempts.
when estimating gas via the node's RPC. A transaction's gas estimate, then, can only be found if all the transactions succeed at a given gas limit. This is especially important when working with retryables and scheduling redeem attempts.
Because a call to redeem donates all of the call’s gas, doing multiple calls requires limiting the amount of gas provided to each subcall. Otherwise, the first will take all the gas and force the second to fail, irrespective of the estimation’s gas limit.
Gas estimation for retryable submissions is possible via the NodeInterface and similarly requires the auto-redeem attempt to succeed.
The gas target
The security of Arbitrum Nitro chains depends on the assumption that one validator creates an assertion, other validators check it, and respond with a correct assertion or a challenge if it is wrong.
This requires that the other validators have the time and resources to check each assertion and issue a timely challenge quickly. The Arbitrum protocol takes this into account in setting deadlines for assertions.
This sets an effective gas target for executing an Arbitrum Nitro chain: in the long run, the chain cannot make progress faster than a validator can emulate its execution. If assertions are published faster than the gas target, their deadlines will get farther and farther into the future. Due to the limit enforced by the Rollup protocol contracts on how far in the future a deadline can be, this will eventually slow down new assertions, thereby enforcing the effective gas target.
Setting the gas target accurately depends on estimating the time required to validate an assertion with some accuracy. Any uncertainty in estimating validation time will force us to set the gas target lower, to be safe. And we do not want to set the gas target lower, so we try to enable accurate estimation.
Total fee and gas estimation
The total fee charged to a transaction is the child chain basefee multiplied by the sum of the child chain gas used and the parent chain calldata charge.
As on Ethereum, a transaction will fail if it does not supply enough gas or specifies a basefee limit below the current basefee. Ethereum also allows a “tip,” but Nitro ignores this field and never collects any tips.
Allocating funds and paying what is owed
When a batch posting report is processed in the child chain, the pricer allocates some of the collected funds to cover costs incurred. To allocate funds, the pricer considers three timestamps:
currentTimeis the current time, when the batch posting report message arrives at the child chainupdateTimeis the time at which the reported batch was submitted (which will typically be around 20 minutes beforecurrentTime)lastUpdateTimeis the time of submission for the previous reported batch
The pricer computes an allocation fraction F = (updateTime-lastUpdateTime) / (currentTime-lastUpdateTime) and allocates a fraction F of funds in the L1PricerFundsPool to the current report. The intuition is that the pricer knows how many funds have been collected between lastUpdateTime and currentTime, and we want to figure out how many of those funds to allocate to the interval between lastUpdateTime and updateTime. The given formula is correct if we assume that funds arrived at a uniform rate over the interval between lastUpdateTime and currentTime. The pricer similarly allocates a portion of the total data units to the current report.
Now the pricer pays out the allocated funds to cover the rewards due and the amounts due to batch posters, thereby reducing the balance due to each party. If the allocated funds aren't sufficient to cover everything that is due, some amount will remain due. If the amount due is covered with the allocated funds, any remaining funds are returned to the L1PricerFundsPool.
Getting parent chain fee info
The parent chain gas basefee can be queried via ArbGasInfo.getL1BaseFeeEstimate. To estimate the parent chain fee, use either the transaction NodeInterface.gasEstimateComponents() or NodeInterface.gasEstimateL1Component() method.
Arbitrum transaction receipts include a gasUsedForL1 field that shows the amount of gas used on the parent chain, in units of the child chain's gas.
Adjusting the parent chain gas basefee
After allocating funds and paying what is owed, the parent chain Pricer adjusts the parent chain Gas basefee. The goal of this process is to find a value that, over time, causes the amount collected to equal the amount owed.
The algorithm first computes the surplus (funds in the L1PricerFundsPool, minus total funds due), which might be negative. If the surplus is positive, the parent chain gas basefee is reduced, so that exactly the surplus will reduce the amount collected over a fixed future interval. If the surplus is negative, the base fee is increased so that the shortfall is eliminated over the same fixed future interval.
A second term is added to the parent chain gas basefee, based on the derivative of the surplus (surplus at present, minus the surplus after the previous batch posting report was processed). This term, which is multiplied by a smoothing factor to reduce fluctuations, will reduce the basefee if the surplus is increasing, and increase the basefee if the surplus is shrinking.
Effective block gas limit
Post Fusaka, changes have been made to the Block Gas Limit and how transactions are filtered. Instead of using a hard limit of 32M (Arbitrum One), a new “Effective Block Gas Limit” has been introduced.
Filtering
ArbOS 51 also introduces a MaxTxGasLimit. The State Transition Function (STF) will be relaxed to allow the final transaction in a block to use up to the MaxTxGasLimit even if it would cause the block to exceed the MaxBlockGasLimit.
The MaxTxGasLimit is set by implementing EIP-7825 from the Fusaka hard fork.
This means that the “Effective Block Gas Limit” is really MaxBlockGasLimit + MaxTxGasLimit (64M for Arbitrum One). In previous versions of ArbOS, the STF would skip transactions from the sequencer feed if the transaction’s GasLimit (set by the user) minus the L1 data posting gas exceeded the gas remaining in the block (without executing the transaction to see how much L2 gas it actually used).
This means that the “Effective Block Gas Limit” is really MaxBlockGasLimit + MaxTxGasLimit (64M for Arbitrum One). In previous versions of ArbOS, the STF would skip transactions from the sequencer feed if the transaction’s GasLimit (set by the user) minus the L1 data posting gas exceeded the gas remaining in the block (without executing the transaction to see how much L2 gas it actually used).
The new algorithm is more efficient because the STF doesn’t need to continually search the transaction queue for one that fits in the remaining block gas, and can just keep adding transactions until the unused block gas is 0.
This change does not affect the GasTarget, and therefore does not affect how much overall gas per second the chain will use—only how transactions using that gas could be divided between different blocks.
This change does not affect the GasTarget, and therefore does not affect how much overall gas per second the chain will use—only how transactions using that gas could be divided between different blocks.