ERC-XXXX: ZK Privacy-Preserving Account Recovery

ERCs
, , ,
1

[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.

  1. 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.
  2. 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.
  3. Off-Chain Circuits: ZK circuits where the user generates the proof. The circuit proves statements like H(myPassword) == onChainPasswordHash without revealing myPassword.

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 via calldata 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.

2

Hmm for a privacy preserving mechanism, I’m not sure if the Guardian contract hinders this impact, especially if it is reliant on what I assume to be centralised operators like email providers (i.e. Gmail) for recovery methods…

1 Like
3

Thank you for raising this important point, @CypherVae.

We appreciate your concern regarding the potential centralization risks introduced by relying on email providers (e.g., Gmail) as part of the recovery process. Let me clarify the design rationale and trade-offs we considered when incorporating this mechanism:

1. On-Chain Privacy via Hash Commitment

The Guardian contract does not store any plaintext personal identifiers such as passwords or email addresses. Instead, it stores cryptographic hashes of user-selected recovery factors. These hashes act as commitments, ensuring that no identifiable information or metadata is publicly visible or linkable on-chain.

2. Centralization vs. Usability Trade-Off

Your concern about relying on centralized services like Gmail is entirely valid. However, this decision was made after evaluating several design alternatives, each with its own trade-offs between security, usability, and decentralization:

2.1 ZKP-Only Recovery (Pre-generated Proofs)

Our initial idea involved users pre-generating zero-knowledge proofs and storing them in a guardian contract. However, this created a significant usability burden, as users would need to safeguard both their private key and the precomputed proof. If either was lost, recovery would become impossible—defeating the purpose of the mechanism.

2.2 Password-Only Recovery

Next, we explored a design using a single-factor password hash as the recovery anchor. However, this approach is highly vulnerable to offline dictionary attacks, particularly if users choose weak or short passwords. We concluded that requiring long, complex passwords would impair user experience and adoption.

2.3 Email-Based Recovery (via DKIM Signatures or JWT tokens)

We ultimately opted for an email-based factor, leveraging Gmail’s DKIM-signed emails or JWT token to construct a verifiable proof of email account access. This method aligns with users’ existing mental models—many are already accustomed to using their email accounts for authentication flows across web applications, including web3 wallets via OAuth or AA sessions.

While this method does introduce a degree of reliance on centralized infrastructure, it offers a pragmatic and user-friendly recovery path. The recovery mechanism remains non-custodial, as the mail provider does not interact with the blockchain directly, nor does it hold or rotate keys—users prove access to their own accounts via off-chain ZKPs.

In summary, our design prioritizes privacy on-chain, while balancing user experience and implementation feasibility. We are also exploring pluggable factor types to reduce reliance on centralized services in future iterations.

We welcome further feedback and alternative ideas that may preserve both privacy and decentralization without sacrificing UX.

4

Hey @aryaethn thanks for this proposal. You’re in the way to create something great together with @Arvolear’s EIP-7947: Account Abstraction Recovery Interface (AARI) - #11 by Arvolear

2 Likes
5

Hi @ivanmmurcia,

Yeah. Great proposal by @Arvolear. We wanted to make sure that our proposal is feasible, so at first we started implementing the circuits. After a week or two I saw EIP-7947 (AARI) submitted by him.

I hope both of these EIP/ERCs help the whole community in Private Key Recovery.

1 Like