Only part of an L2 transaction's cost scales with L1 gas price. The rest is local execution and, for zk-rollups, proof-generation compute — both roughly flat regardless of L1 congestion. That split is why choosing an L2 for a fee-sensitive app isn't just "which is cheapest today" but "which stays cheap when L1 spikes."
Cost at your monthly volume
Same transaction type and L1 gas price, scaled to your monthly transaction count.
| Network | $/tx | $/mo at your volume | vs L1 direct |
|---|
Sensitivity — same transaction, rising L1 gas price
Watch how much less each network's cost moves compared to L1 direct as congestion rises. zkSync moves the least — its cost is more compute-bound than data-bound.
| L1 gwei | L1 direct | Arbitrum | Base/Optimism | zkSync Era |
|---|
Why "cheapest L2 today" is the wrong question
Every L2 fee comparison you'll find is a snapshot — a table of dollar amounts captured at whatever L1 gas price happened to be live when the page loaded. That's fine until L1 gas actually moves, which it does constantly and sometimes violently during NFT mints, token launches, or market stress. The useful question for a dApp choosing a deployment network isn't "which L2 is cheapest right now" — it's "which L2 stays cheap when L1 gets congested," because that's exactly the moment your users are most price-sensitive and most likely to abandon a transaction over a fee spike.
The data-availability split, and why it matters
Since the March 2024 Dencun upgrade, rollups post transaction data to L1 via blobs rather than calldata — a change that cut data-posting costs by roughly 90%. What's left of an L2 transaction's bill splits into a data-availability (DA) portion that scales with L1 blob/gas pricing, and a local-execution portion that's set by the rollup's own sequencer and barely moves with L1 conditions. Optimistic rollups like Arbitrum, Base and Optimism skip cryptographic proof generation and lean more heavily on that DA-posting cost, so a larger share of their bill still tracks L1 gas. zkSync Era and other ZK-rollups spend real compute generating a validity proof for every batch — a cost paid to provers, not to L1 — so a larger share of their bill is flat regardless of L1 congestion. That's the structural reason the sensitivity table above shows zkSync's line barely bending while Arbitrum and Base still climb, just far more slowly than L1 itself.
What this means for a deployment decision
For a fee-insensitive, low-volume internal tool, the cheapest-today number is probably good enough. For a consumer-facing app with unpredictable L1 conditions and price-sensitive users — a wallet, a game, a social app — the sensitivity curve matters more than the baseline: a network that's merely "cheap" at 15 gwei but tracks L1 closely can become "not cheap enough" during exactly the congestion events that also drive the most user traffic. For the underlying API/infra cost side of running a backend behind your dApp, see the serverless function cost calculator; for hosting comparisons unrelated to on-chain gas, see Railway vs Render vs Fly.io.