Two Ethereum gas commits and a stateless-account pitch land back to back

August 20 produced two commits in the Ethereum EIP repository — one touching calldata pricing arithmetic, the other shuffling the contents of a bundle EIP — and then the following morning, EIP-8387 opened on the Ethereum Magicians forum with something more structural: a proposal to change what an Ethereum account actually is.

The calldata commit first. The August 20 update to EIP-8141 adds a floor_tokens_in(data) function, defined as len(data) * 4. Content-blind, fully uniform, applied to every charged byte without inspecting what those bytes hold. That contrasts with the existing tokens_in function, which weights bytes differently based on their value — a distinction that traces back to EIP-7976. Run floor_tokens_in on 100 bytes and you get 400. Every time. For rollup developers or anyone building data-heavy applications, the immediate benefit is that worst-case gas estimates stop being a function of what’s in the payload. To be clear, this isn’t a ceiling: tokens_in can still produce higher values for particular byte patterns. What it gives you is a defined lower bound you can calculate before you deploy.

The second August 20 commit went to EIP-8081, which bundles multiple EIPs for coordinated activation. EIP-8268 came out. EIP-8077, EIP-8094, and EIP-8372 went in. The GitHub log offers no explanation. Bundle reshuffles at this stage of upgrade planning tend to follow shifting dependencies, but what specifically drove the swap — and what the three additions actually cover — isn’t in the available commit material. Anyone trying to trace the full dependency chain is working with a gap here.

EIP-8387 is operating in a different register entirely. The forum post, dated August 21 and titled “Stateless Accounts,” proposes adding stateless account creation to EIP-8130 as part of Ethereum’s longer-term privacy and statelessness work. The model described would let accounts exist without permanent on-chain storage — architecturally different from how things work today, where every externally owned account or contract occupies a slot in global state from the moment of creation. The proposal argues this opens possibilities for light client designs and privacy-preserving transaction flows that the current model forecloses. That’s a structural departure from a foundational assumption, not a parameter tweak.

Who actually has to act if any of this lands depends on decisions nowhere near being made. Rollup teams and wallet developers would need to revise gas estimation logic if EIP-8141’s floor function makes it into a network upgrade. Projects building on EIP-8130 would need to account for the stateless model EIP-8387 proposes — but the proposal is at discussion stage, its relationship to EIP-8130 remains unresolved, and no activation deadline exists for any of the three proposals covered here.

Two EIPs referenced in related discussions — EIP-7773 and EIP-8386 — don’t appear in the August 20 or 21 source material. Details on APPROVE failure modes and whatever covers a “Transaction Events View” are similarly absent from available documentation.

No activation timeline for any of these proposals had been made public at the time of writing.