EIP-8477: Recent Block Bound Delegation Authorizations

EIPs EIPs core
1

Discussion topic for EIP-8477: Recent Block Bound Delegation Authorizations.

Motivated by the recent EIP-7702 sweeps that happened on Binance 16 this proposal in essence prevents long term storage of EIP-7702 signatures for later playback.

This proposal limits the delayed use of unused EIP-7702 authorizations. Each authorization signs a recent execution block number and its block header hash, in addition to the existing chain ID, delegation address, and nonce.

For inclusion in execution block N, the signed block must be one of its preceding 256 ancestors and its hash must match that ancestor. An anchor exactly 256 blocks behind remains eligible; one 257 blocks behind is ineligible. The current block and future blocks are excluded.

Freshness is checked during native authorization processing, before signature recovery or authority-specific state access. An expired or mismatched anchor skips that authorization using EIP-7702’s existing skip-on-failure behavior. It does not consume the authority’s nonce through that entry or clear an existing delegation. Structurally malformed authorizations invalidate the transaction.

The draft applies the same freshness requirement to installation, replacement, and zero-address revocation. Installed delegations remain in effect after their authorization’s anchor expires. The proposal limits the inclusion window of an unused signature; it does not expire installed delegation or prevent an attacker with live signing access from promptly using a fresh signature.

The change requires a coordinated network upgrade. At activation, legacy six-field authorizations are rejected and the extended eight-field format becomes mandatory. The draft retains transaction type 0x04 and signing prefix 0x05, subject to review.

Update Log

External Reviews

No external technical reviews recorded as of 2026-10-30. Editorial feedback is available in the pull request review.

Outstanding Issues

  • 2026-10-30: Evaluate whether the fixed 256-block window provides sufficient inclusion headroom for wallet, relayer, replacement, and recovery workflows across chains; see the draft PR.
  • 2026-10-30: Benchmark additional authorization bytes, ancestor lookups, and processing costs before retaining the existing authorization charges; see the draft PR.
2

Zero address revocations could take an exception without bringing the sweep problem back. A replayed revocation can only clear code, and only while the authority nonce still matches the one signed, so it can’t install a delegate or move funds. Accounts run through relayers barely move their EOA nonce, which makes a revocation signed ahead of time and kept offline a realistic recovery path for when a delegate gets a disclosed bug and the key isn’t at hand. The anchor rule ends that. If the reason for no exception is griefing, someone clearing a live account at a bad moment, it would help to say so in the Rationale, since Backwards Compatibility only mentions recovery procedures in passing.

On chain_id = 0, two different chains don’t share an ancestor inside 256 blocks unless one just forked from the other, so in practice a zero chain id authorization becomes single chain. Wallets that sign one to set the same delegation on every chain will need per chain signatures after activation, and that could be stated directly instead of as “can be usable on multiple chains”.