Please refer to ens::verifiable-records for more context on linking emails to ens names.

Introduction

This document describes how ENS name owners can verifiably link their email addresses to their ENS names. We outline the proof generation and verification flow for email address linking.

Assumptions

• The user already owns an email address and ens name
• The user intends to generate a proof compatible with the design detailed here.

Context

This use case leverages the EmailAuth circuit, which allows users to authorize commands via email. A relayer back-end will assist in crafting emails, generating proofs, and submitting them on-chain.

Proving Flow Specification

Entities & Roles

• User:
  • Owns an ENS name and an email address
  • Initiates linking and confirms via email reply
• Frontend (FE):
  • Connects to user’s wallet
  • Displays owned ENS names
  • Collects email input and sends TX to update ENS text records
  • Calls backend API to send confirmation email
  • Can be used to check validity of email keys on any ens name
• Backend (BE):
  • Sends the confirmation email to the user
  • Listens for confirmation replies
  • Generates the zk-SNARK proof using a prover service
  • Performs a view call to the verifier contract to ABI-encode public inputs
  • Submits the proof TX on-chain
• Verifier Contract:
  • Exposes verifyTextRecord(node, key, value) → bool view
  • Exposes entrypoint(bytes proof) - updates the mapping of email → ens
  • Exposes encode(bytes zkproof, uint256[] publicSignals) returns (bytes proof))
  • On success, allows the mapping of (email → ENS name) to be permanently recorded
• ENS Resolver:
  • Stores two text records under the user’s node:
    • email: the user’s address string
    • email__proof: ABI-encoded (verifierAddress, proofData)

Proof Generation & Verification Flow

1. User Launches FE

   FE initializes and prompts the user to connect their wallet.

2. ENS Name Selection

   FE fetches and displays the user’s ENS names. User selects one.

3. Email Input & TX

   • User enters their email address.
   • FE submits two parallel actions:
     1. API call to BE to send a “confirm” email.
     2. Wallet pop-up to sign and send a transaction that updates the ENS resolver with:
        • email = "<user-email>"
        • email__proof = abi.encode(verifierAddress)