L1-pricing

Arbitrum DAO proposed a constitutional amendment today to update two L1-pricing parameters on Arbitrum One and Arbitrum Nova in response to Ethereum’s Glamsterdam upgrade, which changes the gas costs of posting batches to Ethereum. The adjustment keeps user fees aligned with what batch posters actually spend.

• Proposal updates parentGasFloorPerToken and perBatchGasCharge parameters via ArbOwner precompile
• Changes reflect post-Glamsterdam batch costs; requires no Nitro or ArbOS software upgrade
• Execution blocked until Glamsterdam is live on Ethereum; proposal proceeds to temperature check vote

The Arbitrum DAO constitutional AIP targets a narrow technical fix: Arbitrum’s L1-pricing system estimates the Ethereum gas cost of each batch posted to the main chain, then passes that cost to users as an L1 fee. Glamsterdam changes Ethereum’s calldata pricing, so the old estimates no longer track real costs. The proposal says “Updating these two parameters is the smallest change that keeps the L1 fee paid by Arbitrum users in line with what the batch posters spend after Glamsterdam.”

How Arbitrum’s L1-pricing algorithm works

Arbitrum One and Nova users pay an L1 fee that reflects the cost of posting their transactions to Ethereum as part of a batch. The system uses two parameters to estimate that cost. parentGasFloorPerToken mirrors Ethereum’s minimum gas charge for calldata, the cheapest way to post data. perBatchGasCharge represents a fixed overhead per batch, accounting for gas spent on batch management itself.

The existing values were set for Ethereum’s pre-Glamsterdam cost structure. Glamsterdam changes Ethereum’s gas accounting in ways that break those estimates. The proposal updates both parameters based on measured post-Glamsterdam batch costs.

What the proposal does and does not change

The AIP does not upgrade Nitro node software, change transaction-execution rules, or increment the ArbOS version. It uses existing governance controls (the ArbOwner precompile) to modify two numerical parameters on two chains only, Arbitrum One and Arbitrum Nova. Arbitrum Sepolia and independently governed Arbitrum chains are unaffected.

The proposal does not address a known edge case: it may underestimate gas paid for zero-bytes in calldata. The document notes this effect is minimal because zero bytes are rare and both chains post blobs instead. A future ArbOS version could address it.

Execution gated to Glamsterdam activation

The proposal includes an onchain check (GlamsterdamForkGateAction) that blocks execution until Glamsterdam is active on Ethereum. Any earlier attempt to execute reverts. This prevents the new parameters from taking effect before the fork changes gas costs, which would break the accuracy of L1 fees in the opposite direction.

The proposal authorizes targeted updates to the live parameters through the ArbOwner precompile. It does not introduce an ArbOS software upgrade or change the underlying L1-pricing algorithm.

Arbitrum DAO constitutional AIP

What remains open

The document states the proposed values “may be revisited if posting costs or the L1-pricing system changes” but does not specify what triggers a reassessment or who monitors actual versus estimated costs post-launch. It is also unclear whether this mechanism will be used for future Ethereum upgrades that affect calldata pricing, or if each requires a new proposal.

The CCS read. This is a clean parameter update that keeps Arbitrum’s fee model honest after Ethereum moves the goalpost. It costs nothing, touches no code, and fixes a real problem: if posting costs change and fees don’t, batch posters absorb losses or users overpay. The gatecheck ensures no miscalculation window. The open question is whether Arbitrum’s governance can move fast enough when Ethereum forks again.

The proposal proceeds to a Snapshot temperature check, then third-party audit and onchain vote if approved. Execution begins only after Glamsterdam is live on Ethereum, which the document does not date.