An October 28 revision to Ethereum's proposed RESERVOIR opcode clarifies how contracts would measure gas across child calls. The added guidance says to compare the combined GAS + RESERVOIR budget before and after a call, because a refill can move between those counters when the child returns.
EIP-8455 proposes exposing state gas that the existing GAS reading does not include. Its pull request was opened October 23 and remained open and unmerged when checked October 28. The specification is marked Draft. This revision describes proposed behavior; it does not activate an opcode on Ethereum.
Why the combined reading matters
Under the draft's reservoir model, state creation draws from a separate reservoir first, then from gas_left if that reservoir is exhausted. When a successful child call returns, the merge step can transfer a refill back into gas_left.
The versioned specification adds a concrete two-call example: one child creates a storage slot and another clears it. If the reservoir originally funded the slot, the refill appears in the caller's RESERVOIR reading. If gas_left funded it, the caller's GAS reading rises instead, while RESERVOIR can stay unchanged. Looking at only one counter can therefore miss part of the budget change.
The revision also adds corresponding documented cases and an execution-specification test filler. Their presence establishes proposed expectations, rather than an independently reproduced test result.
Measurement still has boundaries
GAS and RESERVOIR remain separate instructions. Their combined reading is not atomic, and sampling has execution-gas overhead. The draft also covers EIP-8141 frame transactions, where RESERVOIR would expose the frame's separate state-gas balance.
A refill can make measured consumption negative. The proposal distinguishes measuring that budget change from deciding how a bundling protocol allocates charges and credits among users. It leaves GAS and the underlying state-accounting rules unchanged.