EIP-8477: Recent Block Bound Delegation Authorizations

What it is

EIP-8477 is a draft change to EIP-7702 (ethereum/EIPs PR #12601, 30 October 2026). It is motivated by the EIP-7702 sweeps on Binance 16. It stops a stored, unused authorization from being replayed later by requiring each one to commit to a recent block.

How it works

Each authorization adds a recent execution block number and that block's header hash to the existing chain ID, delegation address and nonce. That makes the authorization tuple eight fields instead of six.

For inclusion in block N, the signed block must be one of the 256 preceding ancestors, and the hash must match that ancestor. An anchor exactly 256 blocks back is valid, and 257 back is not. The current block and future blocks are excluded.

The check runs during native authorization processing, before signature recovery or any state access for the authority. A failed check skips that entry under EIP-7702's existing skip-on-failure rule. The authority's nonce is not consumed and an existing delegation is not cleared. A structurally malformed authorization invalidates the whole transaction.

The same freshness rule covers installation, replacement and zero-address revocation.

Preconditions / Affected

The change needs a coordinated network upgrade. At activation, legacy six-field authorizations are rejected and the eight-field format becomes mandatory. Wallets, relayers and any tooling that builds or stores authorizations would have to produce anchored signatures. The draft keeps transaction type 0x04 and signing prefix 0x05, subject to review.

Caveats

• Installed delegations stay in force after their anchor expires.
• An attacker with live signing access can still use a fresh signature immediately.
• No external technical review was recorded as of 30 October 2026. Only editorial feedback exists, in the PR.
• Two open issues are listed. One is whether a fixed 256-block window leaves enough inclusion headroom for wallet, relayer, replacement and recovery workflows across chains. The other is that the extra authorization bytes, ancestor lookups and processing costs still need benchmarking before the existing authorization charges are kept.