Algorithmic Perspective on L2 Transaction Pricing: Revenue, Fees, and Protocol Impact
TechFlow Selected TechFlow Selected
Algorithmic Perspective on L2 Transaction Pricing: Revenue, Fees, and Protocol Impact
The first step for an L2 token to achieve value accrual is decentralized sequencing, which is not easy but allows L2 token holders to participate in the value generated through the block construction and proposal process.
Navigating Web3 tides with focused insightsAuthors: 0xMlze, Salve Boccaccio & 0xMunehisa
Compiled by: TechFlow
Layer 2 Solutions
The Ethereum mainnet currently processes an average of 12 transactions per second. During peak network activity, transaction costs have reached levels unacceptable to most users. This scalability issue arises because every node in the network must store and validate all transactions occurring on the network.
To address this problem and scale Ethereum, Layer 2 (L2) solutions were invented. Layer 2 is a separate blockchain that extends Ethereum while inheriting its security guarantees. Essentially, Layer 2 is an independent blockchain where users conduct transactions off the main chain (Ethereum). Each Layer 2 solution has its own security assumptions and trade-offs. On Ethereum, the most popular form of Layer 2 scaling is Rollups (Arbitrum, Optimism, zkSync).
Rollups
Rollups are L2 solutions that process transactions from L1 before sending them back to L1. A standard Ethereum transaction is typically 156 bytes, with signatures being the most data-intensive part. Therefore, Rollups process multiple transactions within an L2 execution environment, bundle them into a single transaction, and submit it to L1 for regular state validation. Bundling multiple transactions reduces the gas fee paid per transaction, as the cost is shared across many transactions rather than borne by just one. However, not all Rollups are the same—there are several different types:
-
Smart Contract Rollups: Optimistic Rollups (Arbitrum, Optimism), Zero-Knowledge Rollups (Matic’s zkEVM, zkSync, Scroll);
-
Celestiums;
-
Enshrined Rollups;
-
Sovereign Rollups.
Smart Contract Rollups
In Smart Contract Rollups, users send funds to a Rollup smart contract on L1, which then manages transactions and state changes.
A key component of Rollups and blockchains is the Merkle tree. The Merkle tree is a data structure that stores the state of everyone's funds and recorded transactions, allowing L1 to verify the state on L2 without downloading the entire state. In simple terms, users interact and transact on L2 (thus changing the state), and L2 periodically sends the Merkle root of the state to L1 so that L1 can verify the chain’s state.
In addition to publishing the Merkle root to L1, L2 must also publish sufficient Merkle tree change data so users can fully reconstruct the Merkle tree. If, for any reason, L2 stops operating and this data is not provided, users would be trapped on L2. Therefore, the L1 smart contract includes an "emergency function" allowing users to withdraw their funds from the smart contract Rollup if L2 ceases operation.
L1 requires some form of proof to ensure that the Merkle root sent by L2 is valid—this is where the two main types of Smart Contract Rollups differ. The two primary proofs used are fraud proofs and zero-knowledge proofs.
Optimistic Rollup
Optimistic Rollups like Arbitrum and Optimism use fraud proofs to finalize state updates. Fraud proofs work as follows:
-
An L2 node posts the Merkle root along with a small bond to the L1 smart contract.
-
The L1 smart contract trusts the L2 node by default—this is what “Optimistic” means: L1 takes an optimistic view toward L2 updates.
-
However, this state change is not finalized for seven days.
-
During these seven days, anyone can submit a proof showing that the submitted Merkle root is fraudulent, which will revert the update and penalize the L2 node by transferring its bond to the person who reported the fraudulent update.
-
The reporter proves fraudulence by verifying all transactions involved in the state root change and confirming that each signature on those transactions is valid. This is possible because the L2 node publishes both the Merkle root and enough Merkle change data to reconstruct the Merkle tree.
-
If no challenge is raised during the 7-day dispute period, the update is finalized and considered immutable.
ZK Rollup
ZK Rollups use zero-knowledge proofs. They operate as follows:
-
An L2 node submits the Merkle root along with a proof to the L1 smart contract, demonstrating that L2 correctly processed the transactions and generated a new Merkle root.
-
If an L2 node attempts to submit a fraudulent update, it cannot generate a valid zero-knowledge proof, so the L1 smart contract will reject the new Merkle root.
-
Once the zero-knowledge proof is verified, the state update is immediately finalized.
Sequencers
A sequencer is the mechanism by which L2 collects and posts transactions back to Ethereum's base layer. In their current centralized form, they work as follows:
-
Users submit transactions on L2—DeFi, NFTs, sending/receiving, etc.
-
These transactions are collected by a centralized sequencer.
-
The sequencer (block builder) then orders these transactions (calldata/state diffs) sequentially into a single block or batch of transactions.
-
Currently, L2 sequencers use a First-In-First-Out (FIFO) method to order these transactions.
-
The sequencer then submits this batch of transactions back to the Ethereum mainnet for inclusion in a block.
Currently, Rollup sequencers are centralized and controlled by a single entity (Offchain Labs for Arbitrum and Optimism PBC for Optimism). This centralization creates a single point of failure for Rollups, potentially leading to liveness issues (and lack of censorship resistance)—if the sequencer fails, the L2 cannot function properly.
For example, in early June, Arbitrum’s sequencer encountered a bug causing batches to roll back on-chain, resulting in lost gas costs for batch submissions. For a short time, batch submitters ran out of gas and could not correctly send transactions to Ethereum.
L2 Gas Fees
Now let’s examine how these two main types of Smart Contract Rollups calculate the gas fees users pay and the implications for centralized sequencers.
On Arbitrum and Optimism, users pay two types of fees when conducting transactions:
-
L2 Gas / Execution Fees;
-
L1 Calldata / Security Fees.
L2 Gas / Execution Fees
L2 gas fees are similar to Ethereum gas fees. Every transaction on L2 requires a gas/execution fee equal to the amount of gas used multiplied by the current gas price attached to the transaction.
L1 Calldata / Security Fees
L1 calldata fees cover the cost of posting transactions back to Ethereum. This fee exists because the sequencer or batch submitter must pay L1 gas fees to post transactions onto Ethereum.
Sequencer Revenue Model
In their current form, Optimistic Rollups (ORUs) generate revenue through the operation of a single centralized sequencer. In the future, ORUs are expected to eventually decentralize, opening the door to additional revenue streams via MEV (Maximal Extractable Value) or requiring sequencer operators to stake native tokens/share revenue.
But for now, in its simplest form, we can think of the sequencer charging ORU users L2 transaction fees (sequencer revenue), while needing to pay L1 gas fees to batch-submit user L2 transaction data to the Ethereum network (Cost 1), plus operational costs of running the sequencer (Cost 2).
More specifically, we can break down revenue and costs into concrete components. While different ORUs (e.g., Arbitrum, Optimism) do not have identical pricing formulas, they follow a common framework:
Revenue (L2 Gas Fees)
Fees = L1_gas_price_estimate * (L1_calldata_size + L1_buffer) + L2_gas_price * L2_gas_used
Costs
Costs = L1_actual_gas_price * L1_calldata_size + Sequencer_operational_costs
L2 Fee Pricing
Across all ORUs, L2 fee pricing is a function of L1 computation scale, L1 computation cost, L2 computation scale, and L2 computation cost.
Since all L2 sequencers incur costs when posting batches/proofs to the L1 mainnet, it makes sense to pass on the dynamic settlement costs of the mainnet to users when executing L2 transactions.
Arbitrum and Optimism price L2 fees differently. One critical difference between them lies in how they calculate L1 computation costs. Arbitrum uses an oracle to price L1 computation, meaning—unless changed via governance vote—the oracle prices L1 computation the same way as before EIP-4844. In contrast, Optimism includes a dynamic overhead (scalar) variable in its L1 computation cost that can be adjusted by the Optimism team to tune L1 cost calculations.
Arbitrum
Arbitrum’s L2 fee pricing implements the concept of “two-dimensional gas pricing,” where the gas limit is a function of L2 gas units used, L1 gas units used, and estimated L1 gas price.
From this, we can conclude:
-
The L2 gas limit decreases as the L2 gas price increases.
-
The L2 gas limit increases with higher L2 computation, L1 gas price, and L1 computation.
Optimism
Similar to Arbitrum, Optimism’s transaction fees account for both L1 and L2 computation costs. Optimism refers to these as L2 execution fees and L1 data/security fees.
Note:
-
The dynamic_overhead variable is set by the Optimism team to ensure their sequencer is adequately compensated when submitting transaction batches back to the L1 network to cover incurred gas costs.
-
It is currently set at 0.684, indicating the sequencer is subsidizing gas costs.
-
Historically, this value was mostly set above 1, meaning the sequencer charged extra fees to maintain an L1 settlement gas buffer.
Dynamic Management Fees Over Time / L1 Scalar Fees
EIP-4844
Currently, Optimistic Rollups have low costs for L2 execution and storage, but publishing data to Layer-1 remains expensive for users due to data availability requirements.
Data is published to Ethereum L1 using the calldata opcode, so both Arbitrum and Optimism implement calldata compression algorithms such as Zlib and Brotli. This data publication cost is high and accounts for 80–90% of the transaction fees paid by L2 users.
However, between October 2023 and February 2024, the highly anticipated Ethereum Improvement Proposal (EIP-4844, Proto-danksharding) is scheduled to launch. EIP-4844 proposes adding a new transaction type to Ethereum that allows accepting “data blobs.” These “data blobs” are deleted or pruned after about two weeks, unlike existing calldata which is stored permanently. The size of these blobs is designed to be small enough to reduce storage overhead on the mainnet chain.
High transaction fees on Ethereum L1 are the primary cost for L2 Rollups when posting batches and proofs. The impact of EIP-4844 is a significant reduction in L1 cost overhead, while still allowing batch data to remain available long enough to publish any fraud proofs. Current estimates suggest this cost saving ranges from 10x to 100x compared to current L1 batch publishing costs.
High-Level Overview of Impact on Sequencer Revenue
Before diving into the changes we expect to see in Arbitrum and Optimism, it's important to consider the differences between Arbitrum and Optimism in L1 computation pricing (as explained in the earlier L2 fee pricing section). Given Arbitrum’s L1 pricing oracle, we know it will likely pass 100% of savings directly to users (unless altered by a governance vote). This is not the case for Optimism, as they still control the dynamic overhead variable.
The table below provides potential outcomes post-EIP-4844.
Arbitrum
Considering Arbitrum’s current financial situation outlined above, we explore possible changes in Arbitrum’s valuation under certain assumptions. With significantly lower costs expected post-EIP-4844, profit and profit margins are expected to increase if revenues remain constant.
Based on this, we created a table showing various possible outcomes, including different combinations of savings passed to users (Y-axis) and EIP-4844 cost reduction factors (X-axis, larger numbers = greater savings from EIP-4844).
We shaded the combinations we believe are most likely to occur post-EIP-4844.
If 100% of savings are passed to users, we can assume this cost reduction may increase transaction volume on Arbitrum (new dApp types, more users).
Making some assumptions:
-
Maintaining the current P/E ratio;
-
Assuming a 10x cost reduction;
-
Transaction volume growth driven by fee savings.
We can calculate the impact of these changes on ARB and OP prices. For instance, if transaction volume grows by 40%, and only 90% of fee savings are passed to users, ARB’s price would reach $2.10.
Optimism
Performing the same calculation for Optimism yields the following results.
L2 Token Economics and Valuation
Currently, the only value accrual for Arbitrum and Optimism is governance—the sole utility of ARB and OP tokens. However, value accrual for ARB and OP could come from two other sources: transaction fees and MEV.
In their current state, both L2 solutions heavily rely on their centralized sequencers, with all profits from centralized block building and proposing flowing to the Arbitrum Foundation and Optimism Foundation. However, both projects have committed to moving toward decentralized sequencer mechanisms, where foundations are no longer the sole entities building and proposing L2 blocks. The first step for L2 tokens to achieve value accrual is sequencer decentralization—which is challenging but would allow L2 token holders to participate in and capture value generated through the building and proposing process.
Sequencer decentralization will likely be achieved via a PoS mechanism, where users stake the native L2 token. Stakers who fail to perform duties or act maliciously will be slashed. Stakers could earn a portion of transaction fees in the form of native tokens, MEV (in a post-FIFO world), or staking rewards.
The importance of decentralized sequencers lies in the fact that centralized sequencers may lead to user transaction censorship, excessive rent extraction, or harmful MEV, negatively impacting users.
Join TechFlow official community to stay tuned
Telegram:https://t.me/TechFlowDaily
X (Twitter):https://x.com/TechFlowPost
X (Twitter) EN:https://x.com/BlockFlow_News
@asxn_r
