◷EELS to doupdate tests to EIP version af5ea766EIP diff
EELS v2.0.0 tests EIP commit e2fad38c; the EIP changed 1 time since, newest af5ea766 on 2026-11-05.
Spec changes and their tests newest first; each EIP commit, the EELS change that pinned it, its first release and the client runs on it
2026-11-05af5ea766Update EIP-7851: sync relevant EIP-8298 clarifications before archival (commit for EIP-7851, EIP-8298; it also edits this EIP)? untested
tests: not updated to this text. EELS v2.0.0 still tests the text from 2026-10-18 (e2fad38c).
2026-10-18e2fad38cUpdate EIP-8151: empty failure output and EIP-8038 access gas✓ EELS v2.0.0 implements this text
tests:EELS PR #3860 pinned this text on 2026-10-27, test files test_account_code.py, test_fork_transition.py, test_gas.py · first release v2.0.0 · run against it: Nethermind, Geth, Reth, ethrex
2026-08-281dd4443bUpdate EIP-8151: clarify code lifecycle and gas pricing– older
tests: no EELS release tests this text.
2026-07-27bf7a4067Update EIP-8151: restrict `ecRecover` by account code– older
tests: no EELS release tests this text.
2026-05-1443953c6dUpdate EIP-7851: use code-controlled delegation (commit for EIP-7851; it also edits this EIP)– older
tests: no EELS release tests this text.
2026-05-133010b58bUpdate EIP-7851: Few tweaks to 7851 and 8151 (commit for EIP-7851; it also edits this EIP)– older
tests: no EELS release tests this text.
2026-05-123f561dfbUpdate EIP-8151: align ecRecover with EIP-7851– older
open PRs in EIPs and execution-specs that name this EIP; shown for reference, they never change a verdict
EIPs#12605 Update EIP-8151: treat the 0xef0200 opt-out marker as an eligible EOA
Code and PRs
code merged: at least 2 files on the default branch name EIP-8151 in path or contents, or a merged PR whose title names it; spec changed since: a spec change after the last merged PR; PRs merged since 2026-09-07; a hint from names, it never changes a test verdict
no named code or PRno file on main and no PR title names the EIP
EIP-8151 · Nethermind
Account Code Restricted ecRecover
?374/3741 spec change untestedbogota-devnet-2
The run passed 374/374, but the EIP text changed 1 time since the version EELS implements, and 1 change has no proof yet. Likely test: test_permitted_code (64/64 pass here). It counts once a mutant that undoes the change makes one of its cases fail. Next: run `eipproof prove` with a mutant that undoes the change.
+ EOAs can use [EIP-7702](./eip-7702.md) as a bridge to post-quantum authorization. After migration, the account has regular deployed code instead of an EIP-7702 delegation indicator `0xef0100 || delegate_address`, so [EIP-3607](./eip-3607.md) disables protocol-level ECDSA transaction origination. However, `ecRecover` ignores account state. A quantum-capable attacker deriving the old ECDSA private key could still authorize token transfers through contracts, including [ERC-20](./eip-20.md) `permit` implementations ([ERC-2612](./eip-2612.md)). This EIP applies the same rule to `ecRecover`: recovery returns empty output when the account has non-empty raw code that is not a valid EIP-7702 delegation indicator. As a result, after the account has migrated to post-quantum authorization, the old ECDSA private key can no longer be used for contract authorization that relies on `ecRecover`.
EIPs#12605 Update EIP-8151: treat the 0xef0200 opt-out marker as an eligible EOA
EIP-8151 · Geth
Account Code Restricted ecRecover
?374/3741 spec change untestedbogota-devnet-2
The run passed 374/374, but the EIP text changed 1 time since the version EELS implements, and 1 change has no proof yet. Likely test: test_permitted_code (64/64 pass here). It counts once a mutant that undoes the change makes one of its cases fail. Next: run `eipproof prove` with a mutant that undoes the change.
+ EOAs can use [EIP-7702](./eip-7702.md) as a bridge to post-quantum authorization. After migration, the account has regular deployed code instead of an EIP-7702 delegation indicator `0xef0100 || delegate_address`, so [EIP-3607](./eip-3607.md) disables protocol-level ECDSA transaction origination. However, `ecRecover` ignores account state. A quantum-capable attacker deriving the old ECDSA private key could still authorize token transfers through contracts, including [ERC-20](./eip-20.md) `permit` implementations ([ERC-2612](./eip-2612.md)). This EIP applies the same rule to `ecRecover`: recovery returns empty output when the account has non-empty raw code that is not a valid EIP-7702 delegation indicator. As a result, after the account has migrated to post-quantum authorization, the old ECDSA private key can no longer be used for contract authorization that relies on `ecRecover`.
EIPs#12605 Update EIP-8151: treat the 0xef0200 opt-out marker as an eligible EOA
EIP-8151 · Reth
Account Code Restricted ecRecover
?374/3741 spec change untestedbogota-devnet-2
The run passed 374/374, but the EIP text changed 1 time since the version EELS implements, and 1 change has no proof yet. Likely test: test_permitted_code (64/64 pass here). It counts once a mutant that undoes the change makes one of its cases fail. Next: run `eipproof prove` with a mutant that undoes the change.
+ EOAs can use [EIP-7702](./eip-7702.md) as a bridge to post-quantum authorization. After migration, the account has regular deployed code instead of an EIP-7702 delegation indicator `0xef0100 || delegate_address`, so [EIP-3607](./eip-3607.md) disables protocol-level ECDSA transaction origination. However, `ecRecover` ignores account state. A quantum-capable attacker deriving the old ECDSA private key could still authorize token transfers through contracts, including [ERC-20](./eip-20.md) `permit` implementations ([ERC-2612](./eip-2612.md)). This EIP applies the same rule to `ecRecover`: recovery returns empty output when the account has non-empty raw code that is not a valid EIP-7702 delegation indicator. As a result, after the account has migrated to post-quantum authorization, the old ECDSA private key can no longer be used for contract authorization that relies on `ecRecover`.
EIPs#12605 Update EIP-8151: treat the 0xef0200 opt-out marker as an eligible EOA
EIP-8151 · ethrex
Account Code Restricted ecRecover
?374/3741 spec change untestedbogota-devnet-2
The run passed 374/374, but the EIP text changed 1 time since the version EELS implements, and 1 change has no proof yet. Likely test: test_permitted_code (64/64 pass here). It counts once a mutant that undoes the change makes one of its cases fail. Next: run `eipproof prove` with a mutant that undoes the change.
+ EOAs can use [EIP-7702](./eip-7702.md) as a bridge to post-quantum authorization. After migration, the account has regular deployed code instead of an EIP-7702 delegation indicator `0xef0100 || delegate_address`, so [EIP-3607](./eip-3607.md) disables protocol-level ECDSA transaction origination. However, `ecRecover` ignores account state. A quantum-capable attacker deriving the old ECDSA private key could still authorize token transfers through contracts, including [ERC-20](./eip-20.md) `permit` implementations ([ERC-2612](./eip-2612.md)). This EIP applies the same rule to `ecRecover`: recovery returns empty output when the account has non-empty raw code that is not a valid EIP-7702 delegation indicator. As a result, after the account has migrated to post-quantum authorization, the old ECDSA private key can no longer be used for contract authorization that relies on `ecRecover`.
EIPs#12605 Update EIP-8151: treat the 0xef0200 opt-out marker as an eligible EOA
EIP-8151 · Besu
Account Code Restricted ecRecover
◷0/0old tests v1.1.1bogota-devnet-1
Besu's newest run used tests v1.1.1, but the newest EELS release is v2.0.0. Old tests do not check the current spec, so the old 0/0 is shown but does not count. Next: run v2.0.0.