Introduction

Email OAuth (EO) allows users to provides an ephemeral private key with an authority to issue transactions on behalf of their email-based account on-chain, simply by sending one email for each key.

This is useful for 1) onboarding new users and 2) issuing many transactions frequently without requiring the user’s consent every time.

The simplest approach to achieve EO is as follows:

1. A new user deploys a new email-based account, which verifies a ZK proof of emails sent from the user’s specific email address and executes processes described in the email subjects.
2. When signing in to an application using EO, the user (specifically the frontend script) locally generates a new ephemeral private key and its corresponding EOA, and sends an email with a subject such as “Approve an ephemeral key with code 6 at small brain games”.
3. Once the email-based account verifies the proof of the email, it stores the EOA address in the subject. After that, it will accept any transactions signed by the ephemeral private key.

Notably, the above flow is not secure very well because a frontend script of a malicious application can use the ephemeral private key to sign a transaction to exploit all assets from the user’s wallet.

To mitigate such a risk, we additionally introduces an approval mechanism such that the email-based account rejects a transaction from the ephemeral EOA to transfer ERC20 tokens if its transferred token amount exceeds an approved one.

The user describes the approved amount for each ephemeral EOA in the subject.

Although this design of EO works in a secure manner, this is not user-friendly for two reasons.

1. The user needs to directly writes an Ethereum address in the subject, which is not intuitive for new Ethereum users.
2. To send tokens using EO, the user first needs to deposit them from their current wallets.

We solve the first issue by specifying the ephemeral EOA by a combination of a static user name and a dynamic timestamp.

A subject to activate the ephemeral EOA can be intuitive, e.g., “vitalik.eth sign in at timestamp 12345678”.

The second issue is solved in a similar approach to Permit2.

Once the user links their existing wallet to the email-based account, a transaction executed through EO can access to a necessary amount of funds in the linked wallet, without depositing all funds to the email-based account beforehand.

These advantages suggest that EO can improve Ethereum UX for both new and experienced users, allowing them to sign into Dapps using their email addresses and make transactions frequently without pushing “confirm” button every time and managing funds distributed across multiple wallets.

We construct EO based on ether-email-auth.