New EIP Would Add Code-Read Tracking to Ethereum's Access Lists

A proposal titled EIP-8496: Code Reads in Block-Level Access Lists was posted to the Ethereum Magicians forum on November 12, 2026, under the handle ef-magicians. The post proposes adding a code_hash field to EIP-7928's AccountChanges entry, recording the Keccak-256 hash of an account's pre-block bytecode whenever a block reads it.

What EIP-8496 adds to Block-Level Access Lists

EIP-7928 defines Block-Level Access Lists (BALs), a proposed Ethereum data structure that records which accounts and storage slots a block touches during execution. The goal of BALs is to let clients process a block without first re-deriving which parts of state it will need, which matters for stateless clients and for parallelizing execution.

EIP-8496 extends that structure specifically to cover bytecode. Per the forum post, the new code_hash field is populated with the Keccak-256 hash of an account's bytecode as it existed before the block executed, and left empty when the block makes no code read for that account. The accompanying GitHub pull request, Add EIP: Code Reads in Block-Level Access Lists (#12658), was opened by GitHub user LukaszRozmej on November 12, 2026, and shows the proposal adding 193 lines to the EIPs repository with no deletions.

The stated rationale in the forum post is that once code reads are named inside the BAL, a stateless or proving input can be assembled directly from three ingredients — the block itself, its BAL, and a state snapshot — without needing to execute the block first. That is a narrower but related aim to EIP-7928's broader objective of letting clients skip redundant state lookups.

Why code-read tracking matters for stateless clients

Ethereum's long-running push toward statelessness depends on being able to tell a client, in advance, exactly which pieces of state and code a block will touch. EIP-7928 covers account and storage access; EIP-8496's contribution is closing the remaining gap around contract bytecode, which a stateless client or a prover otherwise has no compact way to know it needs.

The proposal is newly filed and has not yet gone through the EIP editorial process that assigns it a formal status (Draft, Review, or later stages). No client team statements on implementation timelines accompany the forum post or the pull request as of this writing. Readers tracking Ethereum's core protocol roadmap, including work on statelessness and access lists, can follow ongoing coverage on CoinsCipher's Ethereum hub, where updates on EIPs affecting client architecture and the broader Layer 2 ecosystem are tracked as they move through the proposal process.