[Discussion] ERC: ZK Privacy-Preserving Account Recovery
Hello everyone,
We are proposing a new ERC for a standardized, privacy-preserving account recovery mechanism using zero-knowledge proofs. We believe this addresses a critical gap in wallet security and user experience, and we are seeking community feedback on the initial draft.
Abstract
Zero-knowledge Privacy-Preserving Account Recovery (zkPPAR) standardises an interface that enables Ethereum accounts to rotate their signing key by presenting a zero-knowledge proof (ZKP) of knowledge of one or more private recovery factors (password, e-mail account, or both) while leaking no guardian identities or social-graph metadata on-chain. The specification defines a lightweight Guardian registry for factor hashes and a Verifier contract that authorises key rotation for EOAs (EIP-7702) and ERC-4337 smart accounts.
We are also working on a minimal implementation of on-chain contracts and off-chain circuits for 2FA mode on Gmail DKIM signature for EOAs.
Motivation
Key loss is a massive, unsolved problem, resulting in billions of dollars in permanently inaccessible assets. While solutions exist, they present significant trade-offs:
- Off-chain backups (seed phrases) are vulnerable to physical loss, theft, and phishing.
- On-chain social recovery (e.g., via ERC-4337) exposes the user’s social graph (their guardians) publicly on the blockchain, creating a significant privacy leak.
- Custodial solutions re-introduce trusted third parties, undermining the core principle of self-custody.
This proposal aims to create a new standard for on-chain, self-custodial recovery that preserves user privacy by leveraging ZKPs. A user can prove they know a password or have access to an email account without revealing the secret or the identity of any “guardian” service on-chain.
Specification Overview
The proposed standard consists of two main on-chain components and one off-chain component.
Guardian
Contract: A minimal, non-custodial registry where an account can store hashes of its chosen recovery factors (e.g.,H(password)
,H(emailAddress)
). This is done by the user before they lose their key.Verifier
Contract: A contract responsible for authorising key rotation. It works as follows:- It receives a ZKP from the user attempting recovery.
- It verifies this proof against the public inputs, which include the hash of the recovery factor retrieved from the
Guardian
contract. - If the proof is valid, it executes the
rotateKey
function.
- Off-Chain Circuits: ZK circuits where the user generates the proof. The circuit proves statements like
H(myPassword) == onChainPasswordHash
without revealingmyPassword
.
The rotateKey
function is designed to be compatible with both standard EOAs (based on EIP-7702) and Smart Accounts (via their existing ownership update mechanisms, based on EIP-4337).
Rationale & Design Choices
- Minimalism: The standard only defines the necessary interfaces for interoperability (
Guardian
storage layout, function signatures, events). It leaves the choice of ZK proving system (e.g., Groth16, PLONK), hash function, and circuit implementation to the developer. - Privacy: By design, no private information or social graph data ever touches the chain. Only a proof and the new signer’s address are submitted.
- Flexibility: Supports single-factor (password or email) and two-factor (password and email) recovery modes. The
recover
function can accept proof data viacalldata
or, for larger proofs, via an EIP-4844 blob commitment.
Discussion
We are particularly interested in any improvements, points, and questions on this ERC design.
Also, our minimal implementation will be available as soon as it is ready.