Email Registry
Obsidion has developed an onchain email registry to improve the user experience of being able to send assets directly to an email address.
Adding Email During Account Creation
You can add your email to the registry during the account creation process. All you have to do is sign in with google while creating your account.
Adding Email Later
You can also add your email to the email registry later if you would like. To do this navigate to the "Settings" tab in the bottom left of the screen and in the general settings tab you will see the option to add an email.
To add your email.
- Click on the "Add Email" button.
- Sign in with Google
- That's it!
Changing/Removing Email
If you have added your email to the registry, you will see the option to remove or change you email.

You can easily change the email that is associated with your aztec account by using the " Change Email " button. Once again you will be prompted to sign in with your google account and this will change the association in the email registry.
Likewise if you want to remove unlink the email from the aztec address you can use the "Remove Email" button and this remove the email and the address from the registry.
Technical Details
The Email Registry is a smart contract deployed on the Aztec network that establishes a secure mapping between email addresses and Aztec addresses. This enables users to identify and interact with other users via their email addresses rather than aztec addresses.
Adding Email
When you sign in with google, it returns a JWT (JSON Web Token) client-side. This email is hashed with the users sub (googles unique identifier of that user) so that obsidion never stores the email addresses directly.
JWT Token Processing
The JWT is split into its three components - header, payload and signature. These are encoded in Base64URL format. The header and payload are processed on chain.
Google rotates its keys that are used to sign the JWT. A unique identifier is calculated for Google's public key by hashing all its components. This "jwk_id" will be checked against an allowlist in the contract which is constantly updated by obsidion.
When processing a JWT, the system identifies which od Google's keys was used to sign it and retrieves the corresponding processed key data. Inside the smart contract this public key signature (RSA). Is verified as the signature that was used to sign the jwt data. If the signature does not match, the transaction will be reverted.
Claim Extraction
Critical claims are extracted from the payload:
- iat (Issued At Time): Timestamp when Google issued the token
- sub (Subject): Google's unique identifier for the user
- email: The user's verified email address
- nonce: A unique value to prevent replay attacks
- issuer: In this case google
- aud: The contract ensures the JWT was intended specifically for use on Obsidion wallet.
To prevent replay attacks with old jwt tokens, the contract enforces time constraints. The contract obtains the current blockchain timestamps. It checks that the JWT's issuance time (iat) is before the current time (preventing future-dated tokens), and within an acceptable delay window from the current time (preventing old tokens). If none of these assertions hold, the transaction reverts.
The email address is hashed, this ensures real emails are never stored. The sub (subject id) is also hashed, this data is extracted from the JWT. In order to retreive the address from the registry, both of these hashes are needed be known. Obsidion stores the sub hash so we can implement rate limiting to prevent people from brute forcing the contract to extract the link between their emails and accounts.
A nonce is included into the jwt token to prevent replay attacks. The nonce claim is extracted from the JWT payload and committed to, this is compared against the expected nonce value provided in the transaction. If they do not match the transaction reverts. This ensures that each JWT can only be used for its intended purpose and prevents attackers from reusing JWTs.
The contract verifies that JWTs come from the expected authentication provider. The iss claim is extracts from the payload and committed to. This is compared against the expected issuer (google). If they dont match, the transaction reverts.
The contract ensures that the JWT was intended specifically for Obsidion wallet. The aud claim is extracted from the JWT, hashed and committed to. The contract verifies this aud hash is in its allowlist of approved Obsidion application IDs. Just as before, if this assertion fails, the transaction reverts, meaning you cannot use JWTs created on other applications.
All of these checks happen privately client side and a zero-knowledge proof is created, so no user data is leaked . This process verifies that Google issued the JWT through their signature, and that the token has bot been tampered with.
Email Uniqueness Enforcement
The contract prevents multiple users from registering the same email:
- Existing Registration Check: Before registering a new email, the contract checks if the email has already been registered.
Address Retrieval
When a user wants to sedn funds to another user via email, the email is hashed. To query the registry the sub hash for the user is still needed to obtain the hash needed to query the registry. This is obtained from a call to Obsidions backend, this query is rate limited to prevent abuse.
The Wallet then queries the smart contract for this unique hash which will return an Aztec Address if a user has registered their email.
Summary
- A zero-knowledge proof of the valid JWT obtain from google is processed.
- No email address is ever stored on-chain or exposed in transactions, all emails are double hashed and lookups are based on these hashes. To get this information, the user has to obtain the sub hash from Obsidion which is rate-limited.
- This is an opt in service and email addresses are linked to wallets. If someone queries your email, they can only see your public funds, your private assets are never visible.
- To receive funds from a user, you need to be aware of them by registering them as a contact in obsidion.