[Demo/Proposal] Getting 1B users on NEAR - using email based signing (DKIM)

There are 1.5 Billion Gmail accounts - wouldn’t it be cool to “just use email” to interact with blockchain and not think about private keys ?

Now you can ! (via the demo / proof-of-concept).


You start by sending email with subject “init” to input.near@gmail.com - this will create a new NEAR account for you (you’ll be able to see it on https://explorer.testnet.near.org/accounts/email-demo.testnet)

(if your account is foobar@gmail.com - you’ll get foobar_gmail_com.email-demo.testnet account)

Afterwards you can use one of the other supported commands (you have to create email with a given command in a subject):

  • add_key ed25519:XXXXX
  • transfer baz.testnet 2.3

This currently works for emails from gmail.com domain only.

Example (from example.near@gmail.com account):

The ‘init’ email has triggered this transaction:


And the account that was created:


And then the second email transferred 0.4 NEAR to mm-near.testnet


How does it work?

It works based on DKIM (DomainKeys Identified Mail) where the server (in this case Google) is signing the email with their private key - and the signature is attached in email header.

When you send email to input.near@gmail.com - there is a small IMAP client, that fetches it - and puts it on chain.

Then the contract (running on email-demo.testnet) is picking it up, doing the DKIM verification and creating a new account if needed or forwarding the request.

This means that signature verification is actually done within the smart contract (so you cannot ‘forge’ a fake email).

The newly created accounts are also running a small contract - so that they follow the requests that they receive from the email-demo.testnet contract.

You can see all the code here: GitHub - mm-near/near-email-auth

What it could be used for ?

There are a lot of interesting use cases - mostly focusing around account recovery and account migrations.

Also creating new gmail accounts is relatively difficult for bots - so this could be an interesting defense against sybil attacks.

What could happen next ?

While this is only a demo - we could actually make it a “proper” protocol feature (basically having such DKIM-based email as another key type) - if there is enough support for the idea.


The potential for this is great.