Summary
The L2 fee vault is the mechanism by which L2 sequencers price L1 data availability (DA) costs into transaction fees. The framing from a 2026 analysis treats this as a control theory problem: the fee vault is a controller that sets transaction fees based on the current L1 cost signal, with different rollup implementations corresponding to different controller types (feedforward, proportional, integral, derivative). This framing enables systematic comparison and optimization.
Problem
L2 sequencers must post transaction data to L1 (for security). The cost of posting is denominated in ETH and fluctuates with L1 gas prices and blob fees. The L2 sequencer needs to:
- Charge users enough to cover L1 posting costs
- Not overprice (hurting user experience)
- Not underprice (subsidizing users at sequencer’s expense)
This is a dynamic pricing problem with noisy input signals (L1 gas oracle) and a desire for smooth output (stable L2 transaction fees).
Controller Types
The analysis maps rollup fee mechanisms to control theory primitives:
Feedforward (FF) — OP Stack Base
- Sets L2 fee = f(current L1 fee estimate)
- No feedback from actual L1 posting costs
- Simple but can’t correct systematic errors
- Used by: OP Stack (base mechanism)
Proportional (P)
- Fee adjustment ∝ error between target revenue and actual L1 cost
- Responds to current errors but can overshoot
- Formula:
fee_t = base + k_p × (actual_cost_t - target_cost_t)
Proportional-Integral (PI)
- Adds integral term: corrects for persistent bias
- Formula:
fee_t = k_p × e_t + k_i × Σe_t - Eliminates steady-state error (won’t permanently undercharge if L1 costs are systematically higher than estimate)
Proportional-Feedforward (P+FF)
- Combines current L1 estimate (FF) with error correction (P)
- Better than FF alone; smoother than pure P
Derivative (PD) — Arbitrum-Style
- Adds derivative term: corrects for rate-of-change of L1 costs
- Formula:
fee_t = k_p × e_t + k_d × Δe_t - Responds quickly to spikes; can be noisy
- Used by: Arbitrum’s fee oracle approach
Simulation Comparison
The paper simulates each controller against historical L1 gas price data (including the Fusaka blob scaling period with 96.5% fee collapse):
| Controller | Tracking accuracy | Smoothness | Recovery from blob collapse |
|---|---|---|---|
| FF only | Good normally | High | Fails without recalibration |
| P | Moderate | Low (oscillates) | Slow |
| PI | Good | Moderate | Handles systematic errors |
| P+FF | Good | High | Needs FF recalibration |
| PD (Arbitrum) | Very good | Low during spikes | Fast spike response |
Key finding: No single controller dominates. PI is best for steady-state accuracy; PD is best for rapid adjustment; FF is best for smoothness.
The Fusaka Blob Fee Collapse Problem
After Fusaka (Dec 2025) expanded blob capacity:
- Blob fees dropped ~96.5% as blob supply exceeded demand
- FF-based systems using old L1 estimates significantly overcharged users
- Systems without an integral term couldn’t self-correct to the new equilibrium
This was a real-world test of controller robustness that revealed the limitations of pure FF approaches.
ETH Fee Denominated vs. USD-Stabilized
An important distinction:
- L1 costs are denominated in ETH (or gwei)
- Users often think in USD terms
- ETH price volatility creates a mismatch: L2 fees stable in ETH terms can be wildly variable in USD
Some L2s (e.g., using oracle-based pricing) attempt to stabilize fees in USD terms, introducing a currency conversion step. This adds a second control loop with its own stability requirements.
Relationship to L1 Protocol Changes
- EIP-1559 blobs (EIP-4844/Fusaka): blob base fees are a second input signal; L2 fee vaults need to track both calldata and blob costs
- EIP-8037 multidimensional fees: if state and burst resources are priced separately, L2 fee vaults need to aggregate multiple cost signals
- ePBS (Glamsterdam): relay-level costs disappear; sequencer-to-builder direct costs become the relevant L1 signal
Implementation Notes
OP Stack’s current fee scalar:
l2_fee = tx_gas × l2_base_fee + l1_fee_scalar × l1_gas_price × tx_calldata_size
The l1_fee_scalar is updated periodically by the sequencer. It’s effectively a slow-moving FF controller with manual recalibration.
Arbitrum uses a more sophisticated oracle that tracks recent L1 batch posting costs and adjusts fees dynamically — closer to the PD controller model.
Open Questions
- Should L2 fee vaults be part of the L2 protocol spec (standardized across the OP stack) or left as sequencer-discretion?
- How should fee vaults handle the case where L1 posting costs are temporarily zero (e.g., blob fees at floor) but could spike suddenly?
- Is a USD-stabilized fee mechanism desirable, and how does it interact with ETH volatility?
Related Pages
- Bridge Finality Risks and Pre-Finality Actions — Bridge confirmation practices that interact with L2 fee design
- Ethereum Economic Zone (EEZ) and Cross-Chain Composability — Cross-chain composability framework
- Fee Markets: EIP-1559, Multidimensional Pricing, and Minimum Base Fee — L1 fee markets that L2 vaults must track
- Ethereum Protocol Roadmap 2026 — Fusaka blob scaling; ePBS; impacts on L2 costs
Key Sources
- The L2 Fee Vault: Pricing L1 Costs with Feedback Control (2026) — control theory framing; FF/P/PI/P+FF/PD comparison; simulation results