ZK-Email Wallet Documentation

The ZK-Email Wallet is a unique type of non-custodial cryptocurrency wallet that is managed via email. This document provides an overview of its features and future development plans. You can try our demo at https://sendeth.org.

Features

The ZK-Email Wallet currently supports the following functions:

  • ETH Transfers: Users can transfer ETH from standard ETH addresses to email wallets, from email wallets to standard ETH addresses, and between email wallets.
  • ERC20 Transfers: The wallet also supports transfers of ERC20 tokens.

Currently, the wallet uniquely provides the following features:

  • Send money to people without accounts: Because transfers are authorized by an email address, you can mass send money or assets to people who have never used email wallet before but do have an email address. If the email address does not claim the money in 1 year (or another preset time), it can be returned to the sender. This avoids problems with dead email addresses or transactions the recipient does not want to recieve.
  • No user interaction with Ethereum: By delegating control of their account to an account abstraction wallet under their email provider (which they already trust with their bank account recovery and social media password reset control), users can avoid ever having to think about private keys or the complexity of the crypto ecosystem.

How It Works (User Perspective)

For each transaction, you send an email. This email can be formatted for you on https://sendeth.org, or you can simply email "relayer@sendeth.org" with a subject like "Send 2 DAI to friend@gmail.com". The relayer will automatically deploy a new wallet for you (if you don't have one) that can only be authorized via emails from you. If you want to test without any Goerli assets, you can start trying to send TEST token like "Send 2 TEST to friend@gmail.com", which will automatically spend from a free 10 token starting balance.

This money is sent to a smart contract wallet authorized to your friend's email address (in this case, friend@gmail.com), meaning only emails from them can spend the money. This transaction occurs in wallets on-chain, and neither the relayer nor us can steal your funds (since we can't generate a fake email from you with the correct cryptographic signatures, only your email provider can). Currently, transfers happen on Goerli -- dm us if you need free Goerli ETH/DAI/USDC to test it out!

If you want to mass-send to a lot of email addresses at once, right now you have to send one email per transaction.

How It Works (Technical Summary)

All sent emails are typically signed using a private key that is managed by your email domain server via the DKIM protocol. This signature is included in the headers of the email.

The DKIM signature serves to authenticate that the email was indeed sent by you, thereby providing a secure means to manage your wallet. Rather than verifying the signature directly on-chain, a zero-knowledge (zk) proof of the signature is generated by a permissionless entity, known as the relayer, and subsequently verified on-chain. The relayer also masks out all of the email addresses to ensure that they are not published publicly on-chain. This authorizes a transaction only if the email is formatted exactly correctly, or else the entire transaction will revert.

Below is an illustration of a standard interaction with the wallet:

  1. An email is sent to the Relayer's email address with a subject such as "Send 1 ETH to recipient@gmail.com".
  2. The Relayer authenticates the DKIM signature and generates a zk proof of the email.
  3. The ZK circuit validates the subject's regular expression, the recipient's email address, and the amount to be transferred.
  4. Sensitive data, such as the sender's email and the recipient's email in the subject line, is not disclosed on-chain.
  5. The Relayer generates an Ethereum transaction that mirrors the intended action specified in the subject.
  6. The smart contract verifies the ZK Proof and ensures that the subject line corresponds with the transaction.
  7. The smart contract executes the transaction, transferring 1 ETH to the recipient's Email Wallet address.
  8. The Relayer awaits confirmation of the transaction, and subsequently sends an email to both you and the recipient detailing the transaction.

Note that email addresses are salted via the message ID of your email, so you can always retrieve your own on-chain address without the relayer's help.

For a more detailed technical breakdown of the cryptographic technology used in emails, read the technical blog post behind zk-email! For a more in-depth technical breakdown of our code, read through our Github repository! For a detailed breakdown of the protocol, read through our presentation slides.

Future Development

In the next month or two, we intend to prioritize:

  • KYC-Free Onboarding and Offboarding: We intend to build a native integration with ZK P2P, which uses the same base email proving technology to atomically swap off onto Venmo or Revolut.
  • Native Swaps: We also intend to natively build out a swapping integration, where i.e. Uniswap is integrated into the wallet for seamless token swaps between currencies.
  • Bulk Sending: We intend to include bulk-sending a list of amounts to a list of email addresses, in one email or transaction.

The initial version of the ZK-Email Wallet does not support privacy features. However, we intend to build a full UTXO model by the end of 2023. The core components of the wallet will be redesigned and reimplemented to support these features, but the user flow will remain the same.

Overview

The ZK-Email Wallet is a non-custodial cryptocurrency wallet managed via email.

The core component of this wallet is a smart-contract. The V1 contract supports:

  • Transfers of ETH
  • Transfers of ERC20 tokens
  • Extensions for using external contracts, such as Uniswap, and other functionalities

ZK-Email

The wallet is managed by users through email, leveraging zk-email or proof of email technology for trustless operations.

ZK-Email is a mechanism that validates the existence of an email message and verifies statements about any data contained within it. This technology can be used to build a trustless bridge from Web2 to Web3, without the need for third-party intermediaries like oracles such as Chainlink. In this context, email serves as a source of oracle data.

Core Technical Components

The core components of ZK-Email include:

  • ZK-RSA - RSA signature verification in Zero-Knowledge (ZK)
  • ZK-Regex - Regex pattern matching in ZK

Most modern mail servers sign email messages with a DKIM signature (essentially RSA) to mitigate various attack vectors. By verifying the DKIM signature of an email, we can confirm that it was processed by a specific mail server. This alone makes it possible to build a Web2 <-> Web3 bridge. However, in most cases, we need to conceal certain information contained in the message. Removing this information from the message would invalidate the signature, so we use ZK proving systems to check the signature in ZK and keep all data private, except for what needs to be public. This approach enhances privacy and significantly reduces the size of the calldata.

One challenge is that email messages often don't adhere to a specific format. To effectively retrieve necessary information, we use ZK-Regex.

For more information on ZK-Email, refer to this blog post by Aayush.

ZK-Email can be used to build various applications, including:

  • Proof of Twitter - Proving ownership of a Twitter account/username on-chain
  • ZK-P2P - A trustless bridge from fiat to crypto

The ZK-Email Wallet is one such application built using ZK-Email.

Specification

Circuits

Smart-contract

Relayer

The relayer sets up the email receiver (IMTP client) and email sender (SMTP client). It then continuosly checks for new emails using the IMTP client. When new emails arrive, the are processed. From, body and subject is extracted, and stored as a row in the DB, and also pushed into a queue as Unvalidated emails.

Next all emails in the queue which have an unvalidated status, are handled. Handling involves writing the email to a sepcific directory.

The relayer is also running the coordinator.py which is watching that directory. If new files are found in that directory, it uploads them to s3 using boto3. Then, either generates the proof locally (on the relayer server) or sends the email to another server.

The dockerfile is used to set up the proof gen server while the circom_proofgen.sh is invoked for proof generation. Proof generation involves generating inputs, witness, proof and then forwarding the proof to the chain.

State is updated to pending for emails for which tx has been sent. Now, we watch for the transaction to mine on chain and once it does, we validate that it's the right nullifer, and then update the status to Ready. The relayer then responds to the sender with a reply email using the email sender client.

The relayer server can be a very small, cheap server with a lot of storage for the database. The proof generation server is spun up on demand as a 64-ish core box and takes only a few seconds to start.

UTXO & Privacy version