Fusaka, Blobs and Rollup Economics After the Upgrade

TL;DR

One blob on Ethereum mainnet cost between $0.004 and $0.009 on 14 September 2026, so a three-blob rollup batch cost about one and a half cents. I measured the blob base fee at 11,144,430 to 28,169,765 wei — 0.011 to 0.028 gwei, sitting between 0.87 and 1.11 times the reserve price EIP-7918 pins to the execution base fee. Across 120 consecutive blocks sampled at about 14:57 UTC, the mean was 7.28 blobs per block against a max of 21 set by Fusaka's second blob-parameter fork in January 2026, and 9 of those 120 blocks carried zero blobs. Blob space is running at roughly half the target and a third of the cap. Data availability is not the scaling constraint. Two other measured facts follow from the same sample: Ethereum's gas limit is still pinned to the 60,000,000 ceiling EIP-7935 shipped in Fusaka, with individual blocks measuring 59,941,351 to 60,000,000, despite the Ethereum Foundation saying in February 2026 it would move "toward and beyond 100M" during the year; and an L1 transfer costs cents, not the $1.10 that l2fees.info still quotes. If data is nearly free, the reason to launch a rollup is not cost.

What a Blob Actually Costs a Rollup in 2026

Start with the arithmetic, because most coverage skips it and quotes a vibe instead.

One blob is 131,072 blob gas. The cost of posting it is 131,072 × baseFeePerBlobGas wei. That is the whole formula.

On 14 September 2026 I measured baseFeePerBlobGas on Ethereum mainnet in a range of 11,144,430 to 28,169,765 wei across the 120 blocks ending at block 25,976,439, with a median of 15,808,567 wei. Run the multiplication at both ends, priced at ETH $2,504:

A rollup posting a three-blob batch therefore spends between $0.011 and $0.028 on data, about one and a half cents at the window's median blob base fee. A four-blob batch in the same window could not exceed $0.037, because the blob fee on a type-3 transaction is exactly the blob count times 131,072 times that block's baseFeePerBlobGas.

About one and a half cents. For the data of an entire batch of L2 transactions. If your rollup batches a thousand transactions into those blobs, the data cost per user transaction is under two thousandths of a cent.

This is the number that should reframe every "how do we reduce L2 data costs" conversation happening in 2026. The answer is that you already did. The engineering attention should be somewhere else.

The Three Forks That Set the Blob Target: Fusaka, BPO1, BPO2

The blob capacity came in three steps, not one, and the dates matter because plenty of coverage still describes Fusaka's activation figures as the current parameters.

From the Ethereum Foundation's Fusaka mainnet announcement↗:

Fusaka itself landed at slot 13,164,544. The two blob-parameter-only forks that followed are the mechanism introduced by EIP-7892, which lets the blob schedule move without a full hard fork.

The rest of the Fusaka EIP list, for completeness: 7594 (PeerDAS), 7823, 7825 (transaction gas cap), 7883, 7917, 7918 (blob base fee bounded by execution cost), 7934, 7939 (CLZ opcode), 7951 (secp256r1 precompile), 7642, 7892 (BPO forks), 7910 (eth_config) and 7935 (default gas limit 60M).

Almost all of the coverage went to 7594. PeerDAS is genuinely the load-bearing piece — it is what makes a 21-blob cap safe for nodes. But the story stopped at "Ethereum now has 21 blobs," and nobody went back nine months later to check how many were being used.

Since BPO2 in January 2026, no further blob increase has landed. The cap on mainnet is still 21.

Measured: 21 Blobs Available, 7.28 Used

I sampled 120 consecutive Ethereum mainnet blocks at approximately 14:57 UTC on 14 September 2026, with the tip at block 25,976,439.

Mean 7.28 against a target of 14 and a cap of 21. Blob usage is running at roughly half of target. The cap is hit sometimes — the blobGasUsedRatio of 1.0 shows full blocks do occur — but 9 blocks in 120 carried no blobs at all, and the average sits far below the level at which the fee mechanism starts pricing scarcity.

That is why blob demand is not pushing the fee up. But demand is not what sets the floor. EIP-7918, shipped in Fusaka, puts a reserve price under the blob base fee: when BLOB_BASE_COST * base_fee_per_gas exceeds GAS_PER_BLOB * base_fee_per_blob_gas, the update rule stops subtracting the target, so the blob base fee cannot decay below the execution base fee divided by 16. Across my 120-block window the measured blob base fee sat between 0.87 and 1.11 times that reserve. Blob space being half empty is why the fee is at the reserve rather than above it, but the reserve itself is set by execution demand, not by blob demand.

Two caveats on my numbers, stated plainly. This is a point sample of 120 blocks taken over roughly a 24-minute window on one afternoon, not a daily or monthly average. And a single sample cannot tell you about weekly cycles or about behaviour during a high-demand event. What it can tell you is that on an ordinary Monday afternoon in September 2026, blob space was not scarce, and that is not consistent with the framing that data availability is Ethereum's constraint.

What half-empty blob space means for your batching policy

If you operate a rollup, the fee floor inverts the batching tradeoff. When blob space is contested, you batch aggressively: wait, accumulate, post fewer and fuller blobs, and accept the latency because data is the dominant cost. At 0.011 to 0.028 gwei that logic stops holding. A blob costs about half a cent. Posting a partially filled blob early costs you roughly half a cent more than waiting to fill it.

So the real question becomes what a few seconds of confirmation latency is worth to your users, and for most consumer applications it is worth considerably more than a cent. In this fee environment I would tune batch cadence for latency and revisit only if the blob base fee climbs by an order of magnitude — which the eth_feeHistory call below tells you in a single request. Alert on the execution base fee alongside it: while EIP-7918's reserve price is binding, the blob base fee tracks base_fee_per_gas / 16, so an L1 congestion event raises your data cost even if no other rollup posts a single extra blob.

Measure It Yourself in Two Calls

Do not take my sample on trust. Two JSON-RPC calls reproduce the whole thing, and you can run them against any public endpoint.

First, the fee history, which gives you the blob base fee and the usage ratio in one response:

curl -s https://ethereum-rpc.publicnode.com \
  -H 'content-type: application/json' \
  -d '{"jsonrpc":"2.0","id":1,"method":"eth_feeHistory",
       "params":["0xc","latest",[]]}' \
  | jq '.result | {baseFeePerBlobGas, blobGasUsedRatio}'

baseFeePerBlobGas comes back as an array of hex wei values, one per block plus the next block's projection. blobGasUsedRatio is a float per block: 1.0 means the block used its full blob allowance, 0.143 means it used about a seventh of it.

Second, the blob count per block. Blob-carrying transactions are type 3, and each carries a list of versioned hashes — one per blob:

curl -s https://ethereum-rpc.publicnode.com \
  -H 'content-type: application/json' \
  -d '{"jsonrpc":"2.0","id":1,"method":"eth_getBlockByNumber",
       "params":["latest", true]}' \
  | jq '[.result.transactions[]
         | select(.type == "0x3")
         | (.blobVersionedHashes | length)] | add // 0'

Loop that over a few hundred blocks and you have the histogram. Then convert to money:

// One blob = 2^17 blob gas.
const BLOB_GAS_PER_BLOB = 131072n;

// Measured on Ethereum mainnet, 2026-09-14 ~14:57 UTC.
const baseFeePerBlobGas = 28169765n; // wei

const weiPerBlob = BLOB_GAS_PER_BLOB * baseFeePerBlobGas;
// 3,692,267,438,080 wei = 0.0000037 ETH
// At ETH $2,504 that is $0.0092 per blob.

Running your own measurement rather than quoting a dashboard is the habit that separates a correct 2026 article from an incorrect one, and it applies well beyond blobs. I use the same discipline to check adoption claims in the piece on account abstraction measured on-chain, where the cumulative counters everyone quotes turn out to overstate live usage by a wide margin.

The Gas Limit Has Not Moved Off 60,000,000

While measuring blobs I also recorded gasLimit across the same 120 blocks. Minimum 59,941,351, maximum 60,000,000. That upper figure is the EIP-7935 default that Fusaka shipped.

The Ethereum Foundation's February 2026 protocol priorities update↗ listed "Continuing to raise the gas limit toward and beyond 100M" among its aims for the year. Through the first three quarters of 2026, that did not happen. Mainnet is still at the Fusaka default.

Blocks are not full either. Block 25,976,439, mined at 14:56:59 UTC on 14 September 2026, used 31,846,115 gas — 53.1% of its limit — at a base fee of 0.205 gwei.

Put the three measurements side by side and the picture is consistent: blobs at half of target, execution gas at half of limit, both fee markets near their floors. Neither dimension of Ethereum's capacity was binding on that day.

I want to be careful about what this does and does not mean. It does not mean raising the gas limit is pointless — headroom is bought in advance of demand, not during it, and validator hardware and state growth are the real constraints on that decision. It does mean that if you are designing a system in 2026 around the assumption that L1 blockspace is scarce and expensive, your assumption is nine months out of date. That changes gas optimisation from a survival requirement to a cost optimisation, which is a different engineering priority even though the techniques are the same.

An L1 Transfer Costs Cents, and the Fee Trackers Are Stale

Here is where the measurement diverges most sharply from what is published.

The L1 base fee ran 0.183 to 0.436 gwei across my fee-history window on 14 September 2026, with a median of 0.252 gwei. A 21,000-gas transfer at that median, priced at ETH $2,504, is about $0.013. The single block I pinned had a base fee of 0.205 gwei, which puts the same transfer near a single cent. Both figures come from the same afternoon — L1 base fee moves fast within a session, and quoting one instant as "the" price is its own error.

For real transactions rather than a theoretical minimum, I measured the median fee at $0.39 across a sample of 36 L1 transactions, with a 10th percentile of $0.07 and a 90th percentile of $2.70. Thirty-six is a small enough sample that each tail percentile rests on three or four transactions, so read the spread as indicative rather than as a distribution. Those are real transactions doing real work, so they burn more than 21,000 gas each. The spread is wide, which is exactly what you would expect when the median transaction is a contract call and not a transfer.

Against all of that, l2fees.info quoted an L1 ETH send at $1.10 on the same date. That implies a base fee around 21 gwei, roughly eighty times the 0.252 gwei median I measured. I am not going to guess at why the tracker disagrees. What I will say is that I would not cite l2fees.info for 2026 numbers, and there is corroborating evidence it is not being maintained: it still lists Loopring in its live fee comparison table, and L2BEAT has Loopring archived with $2,000 of residual value on it.

If you are building a cost model for a client, measure the path your transactions actually take. Do not inherit a number from a comparison site.

The procedure I use takes about an hour. Pull eth_feeHistory over a few hundred blocks on every chain in scope. Take the 10th percentile, median and 90th percentile of the base fee rather than a single reading, because a single block can sit at either edge of the window: mine read 0.205 gwei against a window that ran 0.183 to 0.436 gwei. Multiply by the gas your actual contract calls consume, taken from a real receipt or a testnet trace, never from a bare transfer. Add the L1 data fee if the chain is OP-stack. Then present the 90th percentile, not the median, because the 90th percentile is what your users will complain about. A median makes a good headline and a bad budget.

L2 Execution Costs on 14 September 2026

The other half of the economics. I measured execution gas for a plain 21,000-gas transfer across eight chains at 14:58 UTC on 14 September 2026, priced at ETH $2,504.

Two caveats, and they are large enough that you should not quote the table without them. First, this is execution cost only. OP-stack chains add an L1 data fee per transaction which this does not include. I was rate-limited before I could get a clean all-in median for Base and Arbitrum; the one OP Mainnet sample I did complete gave a median all-in fee of $0.001115, which is about 22 times the execution-only figure for that chain. So treat the column as a floor, not a bill. Second, these are point samples, and unlike the L1 figures above they are not reproducible from this article: I have not published the per-chain gas price, block height or RPC endpoint behind each row, so treat the table as an ordering rather than as eight verifiable measurements.

Methodology matters enormously here. growthepie's transaction cost leaderboard↗ on the same date had Arbitrum Nova at $0.06 as its cheapest chain — three orders of magnitude above my execution-only figures, because it measures median real transaction cost across an actual mix of activity rather than a bare transfer. Both numbers are defensible. They answer different questions. Know which question you are asking before you pick a source, and say which one you used.

The practical read: across the major rollups the fee spread on a simple transfer is roughly two cents at the widest, and hundredths of a cent between most of them. Fee is no longer a differentiator between serious L2s. What differentiates them now is the risk profile, which I break down row by row in the guide to what Stage 1 and Stage 2 actually mean, and the chain-specific developer experience I compare in my four-chain L2 comparison.

If Data Is Nearly Free, Why Launch a Rollup?

This is the question the measurements force, and I have not seen anyone answer it honestly.

The 2021 to 2023 case for a rollup was arithmetic: L1 gas was expensive, so move execution off it and amortise the data cost across many users. That case is gone. L1 base fee at a 0.252 gwei median, blocks half empty, blob space at half of target, a three-blob batch costing about one and a half cents. If your application's entire reason for a dedicated chain was to escape L1 fees, the escape is no longer worth the engineering.

So what is the actual case in 2026? My read, stated as a read rather than as a sourced fact:

Distribution and the user relationship. A chain is a product surface. Whoever runs it controls onboarding, the default wallet experience, which assets are native, and what appears in front of a user first. Base holds $14.679B of value secured, 35% of the $42.05B across all 103 projects L2BEAT↗ tracked on 14 September 2026, and Base plus Arbitrum One is 64% of the total. That concentration did not come from cheaper data. It came from distribution.

Sequencer revenue. Even at hundredths of a cent per transaction, the operator captures the ordering and the fee flow. That is a business, and it is a business that exists whether or not the chain is cheap.

Policy and compliance boundaries. A dedicated chain lets an operator decide what runs on it. Robinhood Chain holds $2.740B and does not yet clear L2BEAT's Stage 0 requirements↗, with one issue still flagged on its stage checklist. That is a chain launched by an entity that already owns a user base, has not pursued the decentralisation ladder, and evidently does not need to for its purpose.

And the counter-case, which deserves equal weight. L2BEAT lists 65 archived Layer 2 projects with residual value still stranded on them, including dYdX v3 at $32.19M and Immutable X at $611K. Only nine of the 22 rollups L2BEAT tracks have reached Stage 1 or Stage 2; the rest, along with most of the 76 projects in its Others category, sit at Stage 0 or carry no stage assignment at all (L2BEAT summary↗). Total DeFi TVL fell 23% during 2026, from $114.4B on 1 January to $88.4B on 14 September, on DefiLlama's chain TVL series↗. Arbitrum's DeFi TVL more than halved over the same window, from $2.90B to $1.39B, while Base went $4.46B to $5.64B. The market is consolidating, not fragmenting.

So the honest summary I give clients who ask about launching a chain: if you already have users, a rollup is a distribution and monetisation decision and the data cost is a rounding error. If you do not already have users, a rollup is an expensive way to have an empty chain, and the archived list is 65 entries long.

The Fusaka EIP Nobody Covered: secp256r1

One more item from the Fusaka list that deserved far more attention than it got: EIP-7951, secp256r1 curve support, which shipped on 3 December 2025.

secp256r1 — P-256 — is the curve behind Apple's Secure Enclave, Android Keystore, WebAuthn and passkeys. Before Fusaka, verifying a passkey signature on-chain meant either a Solidity implementation costing roughly 300k gas or a trusted relayer doing the verification off-chain. With the precompile it is a cheap native call.

That is the difference between "passkey wallets are a demo" and "passkey wallets ship." It is what makes a passkey-signed account practical without a paymaster subsidising signature verification on every transaction. Combined with EIP-7702 delegation and EntryPoint v0.8, it is the first seedless wallet stack that works on mainnet without a trust assumption bolted to the side. I work through that stack end to end in the guide to passkey wallets that work on mainnet.

Fusaka coverage was overwhelmingly PeerDAS and blob counts. This line item barely appeared. It is, for wallet developers, the most consequential thing in the upgrade.

What Is Coming: Glamsterdam, Hegotá and the 2029 Deadline

Three things worth having in your planning, with the dates as the Foundation currently states them.

Glamsterdam slipped. The Foundation's February 2026 post scheduled it for H1 2026. Its September 2026 priorities post↗ now says December 2026, with Hegotá following. Quote both dates if you use either — the slip is real and it is the Foundation's own record. The public testnet, Platåberget↗, was announced on 17 August 2026 in a pre-fork state and forked to Glamsterdam rules on 20 August 2026, ahead of Sepolia and Hoodi. It is a months-long public testnet rather than a short devnet, which is a meaningful change in how upgrades get exercised. Headliners: EIP-7732 (enshrined proposer-builder separation) and EIP-7928 (block-level access lists).

Hegotá got graded. The Foundation evaluated all 62 candidate EIPs and published a unified tier list↗: 2 S-tier, 15 A-tier, 8 B-tier, 7 C-tier, 28 declined for inclusion, 2 undecided. Only two items are S-tier. FOCIL (EIP-7805, fork-choice enforced inclusion lists) is the consensus-layer headliner for censorship resistance. Frame Transactions (EIP-8141) is the execution-layer headliner and is the Foundation's chosen path for native account abstraction and post-quantum signatures. EIP-8182 (private ETH and ERC-20 transfers) was declined in favour of Frames-based alternatives.

The quantum deadline is stated as non-negotiable. The Foundation has committed to making L1 quantum-resistant across execution, consensus and data layers by December 2029, and says it will treat that self-imposed deadline as non-negotiable at least until January 2027, when it will reassess quantum progress with outside experts. Reaching the L fork by December 2029 requires an average cadence of 7.2 months across Hegotá and the four placeholder forks the Foundation labels I, J, K and L. A 9-month cadence reaches full post-quantum readiness one fork earlier, at K; a 12-month cadence reaches only the "minimum viable post-quantum" contingency milestone at J. The date is aligned to 2029 migration targets independently set by Google, Cloudflare and Microsoft. EIP-8365 (BLS withdrawal credential retirement) is graded A-tier in the Hegotá list, and it is the post-quantum groundwork item most likely to land in that fork. If you have contracts that will still be live in 2029, that timeline is your timeline too — I go through what it means for deployed systems in the post-quantum migration guide for blockchain teams.

One thing the Foundation's fast-finality goal does not have is a number. The post says the aim is to cut time-to-finality "from minutes to seconds" and publishes no numeric target. I would not build a design around an unquantified target.

Key Takeaways

• A blob cost $0.004 to $0.009 on 14 September 2026. The blob base fee measured 11,144,430 to 28,169,765 wei against a formula of 131,072 blob gas per blob, at ETH $2,504. A three-blob batch is about one and a half cents; four blobs in the same window could not exceed $0.037.
• Blob usage runs at half of target. Mean 7.28 blobs across 120 consecutive blocks, against a target of 14 and a cap of 21 set by BPO2 on 7 January 2026. Nine of those 120 blocks carried zero blobs.
• The gas limit has not moved off 60,000,000 — the EIP-7935 default Fusaka shipped — despite the Ethereum Foundation stating in February 2026 that it would move "toward and beyond 100M" during the year. Measured range across 120 blocks: 59,941,351 to 60,000,000.
• L1 is cheap and the trackers are stale. A base fee median of 0.252 gwei puts a 21,000-gas transfer near $0.013; l2fees.info quoted $1.10 on the same date, and still lists Loopring, which L2BEAT has archived at $2K.
• Fees no longer separate serious L2s. Execution cost for a 21,000-gas transfer ran $0.00001 on Scroll to $0.02104 on Linea. Add the L1 data fee before you quote it: the one all-in OP Mainnet median I measured was $0.001115.
• The 2026 case for a new rollup is distribution, not economics. Base holds 35% of the $42.05B in total L2 value secured and Base plus Arbitrum is 64% of it, while L2BEAT lists 65 archived chains.
• EIP-7951 was the sleeper in Fusaka. Native secp256r1 verification replaces a roughly 300k-gas Solidity verifier, which is what makes passkey-signed accounts practical on mainnet.

About the Author

I'm Uvin Vindula — a Web3 and AI engineer based between Sri Lanka and the UK. I build cost models for protocols that deploy on L1 and L2, and every figure in this article came out of my own RPC sampling rather than a dashboard, because the dashboards disagreed with the chain. You can see my work at iamuvin.com or reach out about a project at hello@iamuvin.com↗.

If you're deciding between deploying on L1, an existing rollup, or a chain of your own, and you want the cost model built from measurements instead of marketing, let's talk about your project.