EIP-8477 proposes 256-block bounds for unused 7702 authorizations

EIP-8477 targets a specific gap in EIP-7702: authorization signatures that get stored unused and replayed later. The proposal is documented on Ethereum Magicians, and its stated motivation ties directly to recent EIP-7702 sweeps on Binance 16.

Only unused authorizations are affected. Each would need to sign a recent execution block number and that block’s header hash alongside the existing chain ID, delegation address, and nonce. For inclusion in execution block N, the signed block must fall within the preceding 256 ancestors.

The boundary is exact. An anchor 256 blocks back clears the check. An anchor 257 blocks back gets rejected. The current block and any future blocks are excluded too, so the valid window is precisely those 256 prior ancestors.

That narrowing is the core security change: a stored EIP-7702 authorization can only sit around so long before it’s too stale to use. The draft says existing EIP-7702 functionality didn’t address long-term storage and later playback of unused signatures, and the Binance 16 sweeps are the specific event the proposal names as motivation.

Freshness gets checked during native authorization processing — before signature recovery or any authority-specific state access. If the block anchor has expired or its hash doesn’t match, that authorization is skipped under EIP-7702’s existing skip-on-failure behavior. A structurally malformed authorization takes a different path: it invalidates the whole transaction.

The same freshness rule applies to all three operations. Installing a delegation, replacing one, and revoking one with a zero address would all go through the same check. That covers both first authorizations and later changes once the upgrade activates, which matters for anyone building protocol or wallet workflows on top of 7702.

One thing the draft is explicit about: an installed delegation stays in effect after its authorization anchor expires. EIP-8477 limits delayed use of an unused signature. It does nothing to a delegation that’s already sitting on-chain.

Activation would require a coordinated network upgrade, at which point legacy six-field authorizations get rejected outright and the extended eight-field format becomes mandatory. The draft retains transaction type0x04 and signing prefix0x05, though both remain subject to review.

That’s a hard migration point. After it, the six-field format is gone. The proposal doesn’t name an activation date.

The draft also flags the open questions honestly — whether 256 blocks actually gives enough headroom for wallet, relayer, replacement, and recovery workflows across different chains, and what the added costs of extra authorization bytes, ancestor lookups, and processing work out to in practice.

As of October 30, 2026, the proposal’s forum record showed no external technical reviews, and both implementation cost and operational headroom remain unresolved.