# Draft EIP-8425 clarifies account recovery and retained delegations

Canonical: https://forkbrief.com/news/91701c74-c363-490c-ac5c-c61406e092aa
Published: 2026-10-24T18:51:38.770Z
Publisher: Fork Brief

The October 24 specification update makes delegated-code callability and recovery boundaries explicit while the proposal remains Draft.

An October 24 [revision](https://github.com/ethereum/EIPs/commit/e858e912ff55370eb8125873455af531e322d9b2) to Draft EIP-8425 explicitly says existing EIP-7702 delegations would be retained under its proposed ECDSA freeze. The update also makes account recovery exclusions and the role of an original seed after authorization changes more explicit.

Under the underlying proposal, legacy ECDSA-signed sender transactions would become invalid from a freeze time that is still undefined. ECDSA authorization tuples could no longer install, replace or clear delegations. Existing delegation indicators, however, would remain, and delegated code would stay callable under applicable execution rules.

## The account's code sets the boundary

[EIP-7702](https://eips.ethereum.org/EIPS/eip-7702) stores a short delegation indicator in an account rather than the full delegated program. Code-executing operations follow its pointer and run the target program in the authorizing account's context.

The revised recovery section explicitly excludes accounts with regular deployed code, including those migrated through EIP-8298. Eligible accounts must instead have empty code or an EIP-7702 delegation indicator. The [parent version](https://github.com/ethereum/EIPs/blob/fb527daa1830467d6be1336cbf36ed11ef23e6a2/EIPS/eip-8425.md) already named those two eligible code forms; this is a clarification of that boundary.

Within that scope, the updated text says a valid original-seed proof could authorize recovery even after key rotation or other authorization changes. It retains two existing recovery paths: an eligible prior commitment, or an original-seed proof that does not require one.

Commitment-based recovery would use the effective, unrevoked commitment from the canonical state immediately before `SAFE_RECOVERY_TIME`. That cutoff must be no later than the freeze time. Leaving it unset would disable commitment-based recovery.

## Parameters and implementation remain open

The [specification](https://eips.ethereum.org/EIPS/eip-8425) remains Draft. Freeze timestamps, verification algorithms, proof systems, test cases and a reference implementation are marked TBD. The October 24 merge updates proposal text; it does not activate Ethereum rules or supply a deployed recovery procedure.

## Sources

- [EIP-8425: parent specification before October24clarification](https://raw.githubusercontent.com/ethereum/EIPs/fb527daa1830467d6be1336cbf36ed11ef23e6a2/EIPS/eip-8425.md) — Ethereum EIPs
- [EIP-8425: Quantum Freeze and Account Recovery, October24revision](https://raw.githubusercontent.com/ethereum/EIPs/e858e912ff55370eb8125873455af531e322d9b2/EIPS/eip-8425.md) — Ethereum EIPs
- [EIP-7702: Set Code for EOAs, reference specification](https://raw.githubusercontent.com/ethereum/EIPs/master/EIPS/eip-7702.md) — Ethereum EIPs
- [Update EIP-8425: clarify recovery scope and account access rules](https://github.com/ethereum/EIPs/commit/e858e912ff55370eb8125873455af531e322d9b2) — Ethereum EIPs

- [Editorial policy](https://forkbrief.com/editorial-policy)
- [Request a correction](https://forkbrief.com/corrections)