archived snapshot 2026-11-05T16:29:22Z, shown with the current code and proofs · latest data · all snapshots
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
Client PRs matched by title, not a verdict
open and merged PRs whose title names EIP-8151; merged ones since 2026-09-06
| Nethermind | #15252 merged feat(txpool): track EIP-8151 ecrecover signers as frame-tx code dependencies #15196 merged fix(evm): align EIP-8151 ecRecover with the updated spec #13959 merged EIP-8151: account-code restricted ecRecover |
|---|---|
| Geth | none found by title |
| Reth | none found by title |
| ethrex | none found by title |
| Besu | none found by title |
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