Status / EIP-8151
Clients open a cell for the why, the three checks and the evidence
EELS to do update tests to EIP version af5ea766 EIP 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-05
af5ea766Update EIP-7851: sync relevant EIP-8298 clarifications before archival (commit for EIP-7851, EIP-8298; it also edits this EIP) untestedtests: not updated to this text. EELS v2.0.0 still tests the text from 2026-10-18 (e2fad38c). - 2026-10-18
e2fad38cUpdate EIP-8151: empty failure output and EIP-8038 access gas EELS v2.0.0 implements this texttests: 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 - tests: no EELS release tests this text.
- tests: no EELS release tests this text.
- 2026-05-14
43953c6dUpdate EIP-7851: use code-controlled delegation (commit for EIP-7851; it also edits this EIP) oldertests: no EELS release tests this text. - 2026-05-13
3010b58bUpdate EIP-7851: Few tweaks to 7851 and 8151 (commit for EIP-7851; it also edits this EIP) oldertests: no EELS release tests this text. - tests: no EELS release tests this text.
- tests: no EELS release tests this text.
Open EIP PRs 1 not merged, not counted
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-08; a hint from names, it never changes a test verdict
| Nethermind EL | spec changed since 29 files on master name the EIP, 3 merged PRs #15252 merged #15196 merged #13959 merged |
|---|---|
| Geth EL | no named code or PR no file on master and no PR title names the EIP |
| Reth EL | no named code or PR no file on main and no PR title names the EIP |
| ethrex EL | no named code or PR no file on main and no PR title names the EIP |
| Besu EL | no named code or PR no 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.
Next nothing to do
Three checks
Spec changeuntested
Test proofuntested
change
af5ea766 2026-11-05 Update EIP-7851: sync relevant EIP-8298 clarifications before archival untested+ 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`.
64/64 pass here likely test
test_account_code.py::test_permitted_code shares words ecRecover, permitClient runok
Open EIP PRs 1 not merged, not counted
- 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.
Next nothing to do
Three checks
Spec changeuntested
Test proofuntested
change
af5ea766 2026-11-05 Update EIP-7851: sync relevant EIP-8298 clarifications before archival untested+ 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`.
64/64 pass here likely test
test_account_code.py::test_permitted_code shares words ecRecover, permitClient runok
Open EIP PRs 1 not merged, not counted
- 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.
Next nothing to do
Three checks
Spec changeuntested
Test proofuntested
change
af5ea766 2026-11-05 Update EIP-7851: sync relevant EIP-8298 clarifications before archival untested+ 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`.
64/64 pass here likely test
test_account_code.py::test_permitted_code shares words ecRecover, permitClient runok
Open EIP PRs 1 not merged, not counted
- 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.
Next nothing to do
Three checks
Spec changeuntested
Test proofuntested
change
af5ea766 2026-11-05 Update EIP-7851: sync relevant EIP-8298 clarifications before archival untested+ 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`.
64/64 pass here likely test
test_account_code.py::test_permitted_code shares words ecRecover, permitClient runok
result374/374 cases in
eip8151_account_code_restricted_ecrecovertests
tests-bogota-devnet@v2.0.0image
ethpandaops/ethrex:bogota-devnet-2-linux-amd64version
ethrex/v29.0.1-bogota-devnet-2-c9d292a4997faec4578598805f13ad04c1566c5d/x86_64-unknown-linux-gnu/rustc-v1.93.1Open EIP PRs 1 not merged, not counted
- 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.
Next run v2.0.0 · owner Besu
Three checks
Spec changeuntested
Test proofn/a
n/a: this run used old tests, so proofs for the current tests do not apply.
Client runold tests
Open EIP PRs 1 not merged, not counted
- EIPs#12605 Update EIP-8151: treat the 0xef0200 opt-out marker as an eligible EOA
EIP-8151 · EELS
Account Code Restricted ecRecover
1 untested1 spec change untested1 since the EELS pin
EELS v2.0.0 tests EIP commit e2fad38c; the EIP changed 1 time since, newest af5ea766 on 2026-11-05.
Next write test · owner EELS
spec changes proven0 of 1 since the EELS pin