← Back to overview
Comprehensive alternative Status: Draft

EIP-7999

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 resourcesAdds data & state-growth gasDATABASEFEE / STATEBASEFEE opcodesExact long-run state controlDeprecates EIP-7623 floor pricing
View the specification ↗

EIP-7999 is the more ambitious alternative to the minimal set. It is more complex, touching the fee market itself rather than just a few gas constants, in exchange for structural benefits the minimal set can’t reach. Whether that trade is worth it is the real question, so this page lays out both sides. (It tracks the latest revision in ethereum/EIPs#11835.)

The idea

Today a user juggles separate fee markets: EIP-1559 for execution, EIP-4844 for blobs, floor rules for calldata. EIP-7999 replaces that with a single multidimensional fee market. Each transaction specifies one max_fee in ETH, the maximum it will pay for inclusion, and the protocol treats that ETH as fungible across every resource it consumes, guaranteeing it can pay for all of them.

Four metered resources

Gas becomes a 4-element vector [execution, blob, data, state]:

ResourceWhat it coversNotes
ExecutionTraditional EVM computeTarget : limit ratio of 2:1
BlobEIP-4844 blobsBlock blob count; unconditional under EIP-7805
Data (new)Tx content bytes (EIP-8131) + BAL bytes (EIP-8279)16 gas/content byte; its own base fee
State (new)State growth (EIP-8037 metering)Target only, no hard cap; own base fee

Block headers carry gas_limits for execution/blob/data and gas_used / excess_gas vectors that also include state. A single BASE_FEE_UPDATE_FRACTION drives every resource, with excess normalized by each resource’s limit (or its target, for state, which has no limit).

New opcodes

  • DATABASEFEE (0x4b): current block’s data base fee
  • STATEBASEFEE (0x4c): current block’s state base fee

Both follow the EIP-7516 pattern established for the blob base fee.

What it buys you

The extra machinery pays for a few things the minimal set structurally cannot give you.

1. Scale execution and bandwidth independently. This is the big one. The whole anchor analysis exists because one gas limit has to satisfy two unrelated constraints: execution time and block propagation. The minimal set keeps that coupling. It bounds the worst-case block size as a function of the single gas limit (gas_limit / floor), so holding propagation safe means holding the whole limit down, which also caps execution. EIP-7999 gives data its own limit. The worst-case propagation block is then bounded by the data limit directly, and execution can scale toward its own hardware ceiling without being dragged down by the bandwidth constraint. It doesn’t raise the physical ceilings; it stops execution headroom from being spent to satisfy a bandwidth bound.

Concretely, the two limits are governed by the two sequential windows of the slot. With the attestation deadline fixed at 3s, the PTC deadline D splits a 12s slot into a propagation window (3s → D) that bounds the data limit and an execution window (D → 12s) that bounds the execution limit. Sliding D earlier shifts budget from data to execution. Holding the same 25% safety buffer on both windows that the anchor analysis uses:

PTC deadline DExec windowProp windowMax execution limitMax data limit
4.0s8.0s1.0s600M gas0.41 MB · 7M data-gas
4.5s7.5s1.5s562M gas1.26 MB · 20M data-gas
5.0s7.0s2.0s525M gas2.10 MB · 34M data-gas
5.5s6.5s2.5s488M gas2.95 MB · 47M data-gas
6.0s6.0s3.0s450M gas3.79 MB · 61M data-gas

Execution limit is 0.75 · 100 Mgas/s · (12 − D); the data limit is the bytes that fit t = 569 + 0.443·KB ms within 0.75·(D − 3), priced at 16 gas/byte. Under the coupled single limit, a true 25% propagation buffer caps the whole block at ~361M at D = 6s — 450M was only reachable by thinning the propagation buffer to ~11%. Decoupling lets execution take the full execution window (450M at D = 6s, or 600M at D = 4s) while data is bounded on its own, so tightening the deadline buys execution headroom instead of stalling on bandwidth.

2. Resource control becomes self-tuning. The minimal path steers two resources with hardcoded constants that have to be reset by hard fork every time the limit moves: the state cost-per-byte from EIP-8037 (roughly 1,530 → 4,590 gas/byte on the way to 450M) and the calldata floor from EIP-8311 (64 → 96). Each is a price chosen as a stand-in for a quantity we actually care about, and each must be recomputed and re-ratified socially whenever anything changes. EIP-7999 replaces both with independent base fees that equilibrate against a limit (data) or a target (state) through the EIP-1559 mechanism. You set the quantity you want to bound; the price follows. It isn’t zero-parameter, since you still pick the target and update fraction, but it trades a recurring re-pricing chore for a one-time choice of the thing you actually care about.

3. Precise control over long-run state growth. Because state equilibrates around a target rather than a fixed gas multiplier, you get tight control over average state growth, the quantity that actually governs sync time and disk, while still allowing temporary spikes many times today’s limit. It also sidesteps the failure modes of pricing state as a gas multiplier. The honest caveat: state has a target but no hard cap. Sustained demand can hold growth above target (only the price climbs), and worst-case single-block growth isn’t bounded the way a cap would bound it, a deliberate trade of certainty for flexibility.

4. One fee for users. A single max_fee in ETH, fungible across every resource, mirrors how people actually think about paying for Ethereum, instead of reasoning about three coupled markets. (The simplicity is in what the user expresses; estimating it is harder, as noted below.)

Two smaller wins come for free: data and state are unconditional under EIP-7805 (FOCIL), so inclusion-list transactions can’t be censored by resource stuffing; and block-level pricing avoids the rebate secondary markets that transaction-level floor pricing (EIP-7623) creates, which EIP-7999 deprecates outright.

What it costs

  1. A much larger blast radius. EIP-7999 changes the fee market itself: a new transaction type, new opcodes, and multidimensional gas accounting, where the minimal set is three localized gas-schedule changes. Wallets, RPC providers, fee estimators, indexers, and explorers all have to absorb the new model. This is the single biggest reason to be cautious.
  2. Block building gets harder. Multidimensional pricing turns block packing from “sort by gas price” into a multidimensional packing problem, with builders optimizing across resources that each carry their own base fee. That adds builder complexity and is worth watching for centralization pressure.
  3. Fee estimation moves under the hood. “One max_fee” is simpler to express but harder to estimate: a wallet now has to predict a transaction’s usage across resources and several base fees to set a value that won’t fail. Fungibility guarantees the transaction can pay, but the final cost can surprise when one dimension spikes.
  4. No hard cap on state (see benefit 3): worst-case state growth is controlled by price, not bounded outright.
  5. Less settled. It tracks an open PR and is still moving, whereas the minimal EIPs are more concrete and can be shipped and tested individually. Bundling everything into one mechanism raises the stakes of getting it wrong.

Why it pairs well with frame transactions

EIP-7999 needs a new transaction type to carry the ETH-denominated max_fee. EIP-8141 (frame transactions) also introduces a new transaction format. If the two land in the same fork, the multidimensional fee fields can fold into the frame transaction type, so the ecosystem absorbs one new transaction type instead of two, amortizing the biggest cost above. The flip side: it couples 7999’s schedule and risk to 8141’s, so it’s only a win if both are genuinely fork-aligned.

Minimal set vs. EIP-7999

These are alternative paths, not add-ons. The minimal set (8131 + 8279 + 8311) is the smallest safe route to 450M: lower risk, localized impact, shippable piece by piece. EIP-7999 can scale past it. By decoupling the limits it lets execution climb toward its own ceiling rather than topping out at the bandwidth-bound single limit, and it restructures the fee market so future scaling needs no floor or CPSB re-tuning and state growth is precisely controllable, subsuming the data-pricing work of 8131/8279 as its “data resource.” The trade is scope for leverage: a deeper, riskier change now, in exchange for more headroom and not re-pricing resources by hand every time Ethereum scales again.