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, covers the parent chain resources such as the parent chain calldata needed to post the transaction.
• Network fee account: Covers 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 detail how parent and child chain fees are calculated. For a practical guide on estimating gas for your transactions, see How to estimate gas in Arbitrum.

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.

Challenges in pricing parent chain resources

There are two main challenges in accurately pricing parent chain resources:

1. Apportioning batch costs among transactions

• Compression complexity: The data posted to the parent chain is compressed using a general-purpose compression algorithm (Brotli). The effectiveness of compression depends on shared patterns among transactions in a batch.
• Contribution estimation: It's difficult to determine how much a specific transaction contributes to the batch's overall compressibility.
• Ideal vs. practical: Ideally, transactions that enhance compressibility would get charged less, but there's no efficient way to calculate this precisely within the constraints of the STF.

2. Assessing parent chain fees at sequencing time

• Determinism requirement: The parent chain fee for a transaction must be known when the transaction is sequenced to maintain the STF's determinism.
• Future uncertainty: At sequencing time, the actual cost of the batch is unknown because it depends on the parent chain base fee at the future time of batch posting and the remaining contents of the batch (which affect its size and compressibility).
• Impossibility of exact charges: Charging based on future information is not feasible, so the system must rely on estimations.

Nitro's approach

To overcome these challenges, Arbitrum Nitro implements a two-fold strategy:

1. Estimated relative footprint: An estimated size is calculated for each transaction, measured in data units, to approximate its impact on batch size.
2. Adaptive fee per data unit: A dynamic fee per data unit adjusts over time to align collected fees with actual costs.

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.

Apportioning costs among transactions

To approximate each transaction's contribution to parent chain costs:

• Each transaction is individually compressed using the Brotli compressor at its lowest compression level (fastest setting). This reduces computational overhead within the STF.
• The size of the compressed transaction is multiplied by 16 (since Ethereum charges 16 gas per non-zero byte). This product represents the transaction's estimated footprint in data units.
• While not exact, this method approximates the transaction's size after full batch compression and is computationally efficient for real-time processing.

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 multiplies the computed size estimate by the current price per estimated byte to determine the transaction's parent chain calldata cost 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.

Adaptive pricing algorithm

To align collected fees with actual costs, Arbitrum uses an adaptive algorithm with two primary goals:

1. Cost alignment: Minimize the long-term difference between collected fees and the Sequencer's parent chain costs.
2. Stability: Avoid sudden fluctuations in the data price, ensuring a stable fee environment.

Pricer components

The pricer module within ArbOS tracks:

• Amount owed to the Sequencer: The cumulative parent chain costs incurred by the Sequencer for batch posting.
• Reimbursement fund: Collects all funds charged to transactions for parent chain fees. Acts as a pool to reimburse the Sequencer.
• Data unit count: The total number of recent data units processed, which increases with each transaction's estimated data units.
• Current parent chain data unit price: The adaptive fee per data unit expressed in wei.

Algorithm for price adjustment

When the Sequencer posts a batch to the parent chain inbox:

1. Batch posting report generation: The parent chain inbox inserts a "batch posting report" transaction into the chain's Delayed Inbox. After a delay, this report is processed by ArbOS's pricer module.

2. Processing the batch posting report:

   • Compute batch cost: ArbOS calculates the actual cost of posting the batch by retrieving the batch data from the inbox state and counting zero and non-zero bytes to determine parent chain gas usage. The cost is added to the amount owed to the Sequencer.

   • Update data units: Calculate the data units assigned to this update $(U_{\text{upd}})$:

     $$U_{\text{upd}} = U \times \frac{T_{\text{upd}} - T_{\text{prev}}}{T - T_{\text{prev}}}$$

     Where $U$ is total recent data units, $T$ is the current time, $T_{\text{upd}}$ is the time when the update occurred, and $T_{\text{prev}}$ is the time of the previous update. Subtract $U_{\text{upd}}$ from the total $U$.

   • Reimburse the Sequencer: Pay the Sequencer from the reimbursement fund. The amount paid is the lesser of the amount owed or the fund balance. Deduct the paid amount from both the reimbursement fund and the amount owed.

   • Compute surplus and derivative:

     Surplus ($S$):

     $$S = \text{Reimbursement Fund Balance} - \text{Amount Owed}$$

     Derivative of surplus ($D$):

     $D = \frac{S - S_{\text{prev}}}{U_{\text{upd}}}$ where $S_{\text{prev}}$ is the surplus at the previous update.

   • Compute derivative goal ($D'$): Establish a target derivative to eliminate surplus over time:

     $D' = -\frac{S}{E}$ where $E$ is the equilibration constant (time horizon for balancing surplus).

   • Adjust price ($\Delta P$): Calculate the change in the data unit price:

     $$\Delta P = \frac{(D' - D) \times U_{\text{upd}}}{\alpha + U_{\text{upd}}}$$

     Where $\alpha$ is a smoothing parameter to prevent abrupt changes.

     Update the price:

     $$P = \max(0, P_{\text{prev}} + \Delta P)$$

   • Outcome: The adaptive algorithm adjusts the parent chain data unit price to align collected fees with actual costs, ensuring that the Sequencer gets fairly reimbursed while avoiding surpluses or deficits.

Compression levels

Dynamic adjustments of compression levels are based on backlog size ($B$):

• Compression level ($CL$) (where $UC$ is the user-configured compression level):

  • For $B \leq 20$: $CL = \min(6, UC)$
  • For $20 < B < 60$: $CL = UC$
  • For $B > 60$: $CL = \min(4, UC)$

• Recompression level ($RL$):

  • For $B < 40$: $RL = UC$
  • For $B \geq 40$: $RL = \min(6, UC)$

Recompression of existing batch segments may occur if the batch exceeds maximum size limits or hasn't been properly closed.

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 Understanding Arbitrum 2-dimensional fees 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.

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-dimensional 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 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 in the gas estimation via the node's RPC. A transaction's gas estimate 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 when one validator creates an assertion, other validators check it and respond with a correct assertion or a challenge if it's wrong.

This requires that the other validators have the time and resources to check each assertion quickly enough to issue a timely challenge. The Arbitrum protocol takes this into account when 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:

• currentTime is the current time, when the batch posting report message arrives at the child chain
• updateTime is the time at which the reported batch was submitted (which will typically be around 20 minutes before currentTime)
• lastUpdateTime is 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 a transaction will use, call NodeInterface.gasEstimateComponents() or NodeInterface.gasEstimateL1Component().

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 basefee 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, the block gas limit and transaction filtering have changed. 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.

note

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

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.

note

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.