EIP-7778 — Block gas accounting without refunds

EIP-7778Block gas accounting without refunds

Runnable

Live on the hosted MCP — free on Amsterdam. Connect an agent and ask.

Amsterdam (Glamsterdam) vs FusakaRuns withrun_transactionrun_block

Website twin: exploration on feelyourprotocol.org

What became possible

I cleared storage and got a refund — why does the block still count the full gas?

EIP-7778 keeps the refund on the sender's bill. The block still counts the gas from before that refund. A storage clear that creates no new state shows two numbers on Glamsterdam (you pay less than the block counts) and one number on Fusaka.

Warm access and putting a slot back to its original value still reduce what the block counts. Those are cheaper work, not a refund subtracted after the fact.

Try asking your agent

The hosted MCP is live (Connect). Copy a prompt into your agent — each quote is self-contained.

Job

Amsterdam

Clear a nonzero storage slot on Glamsterdam — what do I pay, and what does the block count?

Look forgasUsed (what you pay) below txRegularGas (what the block counts)

Agent will likely call run_transaction

Lesson

Fusaka vs Amsterdam

Clear the same nonzero storage slot on Fusaka and on Glamsterdam — on Amsterdam, does what the sender pays differ from the block's regular-gas count?

Look forno txRegularGas on Fusaka; gasUsed equals txRegularGas on Amsterdam

Agent will likely call run_transaction

Check

Amsterdam

Run a lab block on Amsterdam with a transaction that clears storage and earns a refund — does the block header total still count the full gas for each transaction?

Look forheader.gasUsed against each transactions[].gasUsed

Agent will likely call run_block

What the server does

1. 1

   Discover support

   Confirm the 7778 catalog entry; tools include run_transaction and run_block.

2. 2

   Run transaction

   Paid gasUsed vs txRegularGas on Glamsterdam.

3. 3

   Run block

   header.gasUsed vs transactions[].gasUsed.

{
  "from": "0x0000000000000000000000000000000000000077",
  "to": "0x0000000000000000000000000000000000000078",
  "code": "0x600060045500",
  "accounts": [
    {
      "address": "0x0000000000000000000000000000000000000078",
      "storage": [{ "slot": "0x04", "value": "0x09" }]
    }
  ],
  "fork": { "baseHardfork": "glamsterdam" }
}

code writes 0 into slot 4. The slot must already be nonzero, and the transaction must not create new state — if state gas is the larger dimension, header.gasUsed hides the refund gap. On Glamsterdam, gasUsed (what you pay) is below txRegularGas (what the block counts). On Fusaka, txRegularGas is absent and gasUsed is both numbers.

A lab block with the same transaction reports the gap as header.gasUsed versus transactions[].gasUsed.

Fork caveat

Run the same transaction twice — fusaka (baseline), then glamsterdam (preview). Lead with paid gasUsed against the block count (txRegularGas or header.gasUsed). Receipt gas follows what the sender pays in this lab. The block count is the separate figure.

Twins and spec

Website exploration

EIP-7778 on feelyourprotocol.org

Canonical spec

EIP-7778

Spec date

2026-01-28

Status

Draft

Test release

tests-glamsterdam-devnet@v8.1.0

Coverage index

EIP catalogue

EIP-7778 MCP Catalogue Changelog

EIP-7778 MCP Catalogue Changelog

1. v0.12026-10-04Runnable twin — paid gas vs block count on a storage clear (run_transaction and run_block).