Why
A single price for several resources always cross-subsidizes, and the subsidy runs toward whatever is hardest for the network to scale. One gas number covers computation, state growth and bandwidth at once, so somebody is overpaying and somebody is underpaying — and the underpayer is, by construction, the usage pattern the network would most like to discourage. Metering each resource separately is not a fee tweak; it is the network finally charging for what it actually spends.
This already happened once, which is why the card is not speculative. EIP-4844 gave blob data its own market, and the moment it did, rollup cost structure changed and designs that had been optimal stopped being optimal. Nobody had to be convinced by an argument — the bill changed. The proposals in this roundup point the same way for calldata and propagation.
Why it matters for this project in particular. An event or settlement market's on-chain footprint is mostly data — orders, attestations, resolution evidence — against a small amount of computation. That is precisely the profile a data-priced world reprices, and precisely the profile that looks cheapest today. The honest output is not a forecast of gas prices, which nobody can produce, but an elasticity: what share of this project's on-chain cost is bytes. That number is knowable now, and it decides how much attention the proposals deserve.
How it works
One number, five resources
| Resource | Metered today | What separate metering would change | Exposure here |
|---|---|---|---|
| Execution — opcodes | gas | Little; this is what gas was designed for | Thin — settlement logic is small |
| Calldata bytes | gas, at a fixed price per byte | Its own price, moving with demand | Heavy — orders and evidence are bytes |
| Blob data | Its own market since EIP-4844 | Nothing — this is the precedent, not the change | Already true |
| State growth | gas, and badly | The hardest to price honestly; the cost is permanent, the fee is one-off | Registries, position maps |
| Bandwidth / propagation | not metered at all | A dimension that does not exist yet | Large-payload transactions |
The measurement, and why it is small
One month of transactions, one split per transaction: bytes versus execution. That produces a single ratio, and the ratio answers the only question that matters before the proposals settle — is this project a data-heavy user or not. If it is, then every design choice that trades computation for calldata (posting evidence rather than recomputing it, storing an order rather than deriving it) is a bet on the current price of bytes staying where it is.
The state-growth footnote worth keeping
Of the five rows, state growth is the one with no honest price anywhere today: the cost is borne forever by every future node, and the fee is charged once. Any card in this catalogue that proposes an on-chain registry — the-record-is-not-the-path, position maps, resolution records — is quietly on the wrong side of that mismatch, and a repricing that fixes it would be aimed at exactly those designs.
Update (2026-09-07) — the blob target is the same decision, upstream
Blobs hit record usage on 2026-09-03 (~6.7 per block, 3-day average 5.9), and the 9/10 inclusion list closes with a quiet line under the FOCIL / 8141-vs-8130 headliners: whether to raise the blob target. Blob fees sit near zero below target and rise exponentially above it, so the two cheap years of data were not protocol generosity — they were demand shortfall. Raising the target is one parameter, but the content is a distribution decision: cheaper rollups, costlier nodes. It is the fourth row of the table above — bandwidth/propagation — finally being priced, and the honest thing to watch on the 9/10 list is not the headliner but how many teams put a blob-parameter proposal near the top. That count reads out rollup unit cost more precisely than any roadmap does.