Execution constraint
A worst-case execution ceiling of ~100 Mgas/s, frozen in place by the transfer cap. Push past it and validators can't keep up with the slot.
Hegota upgrade · gas repricing
Scaling Ethereum to 450M gas, anchored to the ETH transfer
The 21,000-gas ETH transfer can't get more expensive without breaking hardware wallets, so it becomes the fixed reference point for how far blocks can safely scale across execution and bandwidth. This is a guide to the EIPs that turn that idea into a concrete path to 450M.
450M
Target gas limit
symmetric optimum ≈ 422M
D = 6s
PTC deadline
~25% exec / ~11% prop buffer
21,000
The anchor
ETH-transfer gas, by design fixed
~4.44 MB
Payload at the limit
569ms + 0.443ms/KB to propagate
The analysis
One immovable point, two competing constraints
The anchor analysis treats the ETH transfer as irreducible by design and asks: given that fixed point, how large can a block get before either execution time or network propagation becomes the bottleneck?
Bandwidth constraint
Block propagation modelled as t = 569 + 0.443·KB ms. Bigger blocks
take longer to reach the network, the binding limit for large payloads.
The feasible optimum
Where the two windows meet, with 25% safety buffers, lands at 450M gas at a PTC deadline of D = 6s: a ~25% execution buffer and an ~11% propagation buffer.
The catch: mixed blocks
A plain transfer block is the densest-but-smallest case, about
0.01052 bytes/gas. The danger is mixed blocks that
combine cheap calldata (16 gas/byte) with cold SLOADs: these reach
2.25× the transfer line's byte density and would force the limit
back down. Closing that gap, cleanly and without repricing the transfer itself, is
what the repricing EIPs below are for.
The minimal path
Three EIPs to reach 450M
The smallest set of changes that safely unlocks the higher limit. Each one closes a specific hole between the gas a block charges and the resources it actually consumes.
1 EIP-8131 Draft
Unified Transaction Content Floor
Prices every user-controlled byte in a transaction at a single flat floor rate, so the worst-case block size is a predictable function of the gas limit.
- 64 gas / byte, uniform
- Replaces EIP-7976, 7981, 7702/4844 gaps
- +3.56% network gas
- <4% of txs hit the floor
2 EIP-8279 Draft
Block Access List Byte Floor
Meters the bytes that opcodes add to the Block Access List at runtime and folds them into the transaction floor, closing the "mixed block" bypass left open by EIP-8131.
- Prices BAL bytes at 64 gas / byte
- Worst case 1.55 MB → 0.89 MB
- ~42% block-content reduction
- +4.06% gas on 3.79% of txs
3 EIP-8311 Draft
Increase Calldata Floor Cost to 96
Raises the calldata floor from 64 to 96 gas per byte so that a block full of calldata is no denser than a block of ETH transfers, removing calldata as the bandwidth bottleneck.
- Floor 64 → 96 gas / byte
- Standard 4/16 rate preserved
- Aligns to ~0.0104 bytes/gas
- Unblocks the higher limit
Take any one away and the bandwidth or state-growth constraint reasserts itself. Together, they're the minimal viable bundle.
No EIP yet
One more knob: recalibrate EIP-8037's CPSB parameter
Raising the limit also means revisiting the CPSB (cost per state byte) parameter from EIP-8037, which meters state growth. There's no EIP for this yet; we first want to see how users respond to the current value in Glamsterdam before committing to a new one.
To hold the same 120 GiB/year state-growth target as the block does 3× more work, a simple linear scaling from the 150M reference limit suggests:
1,530gas/byte today → ~4,590gas/byte at 450M
A deliberate omission
Why not reprice compute?
A natural question: shouldn't we also reprice the compute operations that are overpriced? The analysis says it's low leverage. There are roughly 62 mispriced operations and getting them all right is risky and requires a lot of testing and benchmarking work.
The payoff is small: throughput loss falls from about 12.4% to 2.6%, which works out to only around a 10% gain in average throughput. A lot of surface area to change, for a modest average improvement.
See the analysis ↗Interactive breakdown of per-opcode mispricing on misilva73.github.io/hegota-compute-repricing.
The comprehensive alternative
EIP-7999: more complexity, far more upside
The minimal set is the smallest safe path to 450M. EIP-7999 can scale further: by giving execution and bandwidth independent limits, it lets execution climb toward its own ceiling instead of being capped by the bandwidth-bound single limit, and makes resource control self-tuning, at the cost of a deeper, riskier change.
EIP-7999 Draft
Unified Multidimensional Fee Market
One fee market for everything: users pay a single max_fee in ETH while the protocol meters execution, data, state, and blobs as separate resources with their own base fees.
- One max_fee, four resources
- Adds data & state-growth gas
- DATABASEFEE / STATEBASEFEE opcodes
- Exact long-run state control
The real trade is scope for leverage: 7999 subsumes the data-pricing work of 8131/8279 as its “data resource” and adds a self-tuning state resource, so future scaling needs no floor or CPSB re-tuning, at the cost of a deeper, riskier change to the fee market itself.
Minimal set vs. EIP-7999
| Minimal set | EIP-7999 | |
|---|---|---|
| What it buys you | ||
| Execution vs. bandwidth | One coupled limit | ✅ Independent limits |
| Long-run state growth | Manually tuned, prone to errors | ✅ Target-based, exact average |
| User-facing fees | Multiple markets | ✅ One max_fee in ETH |
| What it costs | ||
| Scope of change | A few gas constants | ⚠️ The whole fee market |
| Fee estimation | Per-market, familiar | ⚠️ Predict usage across resources |
| Risk / maturity | Lower, small changes | ⚠️ Higher, one bundle |
Tuning the budget split to scale execution further
With independent limits, the PTC deadline becomes a dial. The
attestation deadline is fixed at 3s, so an earlier PTC deadline D
shrinks the propagation window (less data) and lengthens the execution window
(more execution). At the same 25% safety buffer the anchor
analysis uses:
PTC deadline D | Exec window | Prop window | Max execution | Max data |
|---|---|---|---|---|
| 4.0s | 8.0s | 1.0s | 600M gas | 0.41 MB · 7M data-gas |
| 4.5s | 7.5s | 1.5s | 562M gas | 1.26 MB · 20M data-gas |
| 5.0s | 7.0s | 2.0s | 525M gas | 2.10 MB · 34M data-gas |
| 5.5s | 6.5s | 2.5s | 488M gas | 2.95 MB · 47M data-gas |
| 6.0s | 6.0s | 3.0s | 450M gas | 3.79 MB · 61M data-gas |
Execution limit is 0.75 · 100 Mgas/s · (12 − D); data is the bytes that
fit t = 569 + 0.443·KB ms within 0.75·(D − 3), priced at 16
gas/byte. The coupled single limit caps at ~361M at D = 6s under a true
25% propagation buffer — 450M only came from thinning that buffer to ~11%. Independent
limits let execution take the whole window: 450M at D = 6s, up to
600M at D = 4s, while data stays bounded on its own.