EIP-3198 & EIP-7516: letting the EVM read its own fee market
EIP-1559 made the base fee a first-class protocol value — computed every block and burned. But a contract couldn't read it: GASPRICE only shows the fused base-plus-priority price the sender paid. EIP-3198 adds BASEFEE; EIP-7516 does the same for blobs. Two tiny opcodes that make the fee market legible on-chain.
- EIP-1559 (the fee market)
- EIP-4844 (blobs)
London, August 2021 (and Cancun, March 2024). EIP-1559 turned the gas price into a real protocol variable: every block, the network computes a base fee, and it’s burned. It’s canonical, deterministic, on-chain — and yet, the moment it shipped, a contract had no way to actually read it. That sounds like an oversight, and the fix is almost embarrassingly small; but it’s a clean illustration of a recurring EVM theme — a value can exist in the protocol without existing in the EVM — and it happened twice, once for gas and once for blobs. EIP-3198 and EIP-7516 are the two little reads that close the gap. Let’s derive them together.
The problem: the base fee was computed, burned — and invisible to contracts
After EIP-1559, the price a transaction pays splits in two: the burned base fee and the priority tip to the proposer. The only fee value a contract could observe was GASPRICE The opcode (0x3a) returning tx.gasprice — the effective gas price the transaction paid. After EIP-1559 that's base fee + priority tip fused into one number; there was no opcode to recover the base fee component by itself. — which returns the effective price the sender paid, i.e. base fee + tip combined. There was no way to read the base fee on its own. That blocks a surprising amount: a meta-transaction relayer A contract (or smart account) that pays gas on a user's behalf and is reimbursed. To reimburse the exact cost it must know the base fee, not just the fused effective price — otherwise it over- or under-charges. reimbursing a user’s gas needs the base fee to compute the true cost; an on-chain gas oracle wants the base fee as a congestion signal; any contract adapting to network load needs to see it. And later, EIP-4844 introduced a second such value — the blob base fee, with its own EIP-1559-style market — equally computed by the protocol and equally unreadable from the EVM.
→ Step 2: surface each fee as its own opcode.
The fix: two one-instruction reads
Because the values already exist in the block, exposing them is trivial. BASEFEE Opcode 0x48 (EIP-3198, shipped with London alongside EIP-1559): pushes the current block's base fee onto the stack. A single, cheap read of a value the protocol already computes. (0x48), added by EIP-3198 alongside 1559 in London, pushes the current block’s base fee. Later, BLOBBASEFEE Opcode 0x4a (EIP-7516, shipped with Cancun alongside EIP-4844): pushes the current block's blob base fee, the blob-market analogue of BASEFEE. (0x4a), added by EIP-7516 alongside 4844 in Cancun, does exactly the same for the blob base fee. Each is a single, cheap instruction that reads a value the block header already carries — no computation, no new mechanism, just a window into a number that was always there.
→ Step 3: what becomes possible once contracts can see the fees.
The payoff: contracts that understand the fee market
With the base fee readable, relayers and smart accounts can compute gas reimbursements accurately instead of guessing from the fused effective price — important for account abstraction, where a contract front-runs a user’s gas and must be repaid to the wei. On-chain gas oracles and congestion-aware contracts get a first-class signal to key off. And with BLOBBASEFEE, rollup data-availability pricing Rollups post their compressed transaction data as blobs. Reading BLOBBASEFEE lets a rollup contract price its data-availability costs on-chain — passing accurate L1 blob costs through to L2 users. becomes possible on-chain: a rollup can read the current blob base fee and price its data-availability costs precisely, passing real L1 costs through to L2 users. Neither opcode is glamorous — but together they finish the job EIP-1559 and EIP-4844 started, making the fee market not just a protocol mechanism but something the EVM can reason about.