Start a project
Product engineering

ChainMail

Encrypted mail with a wallet as the only identity.

An end-to-end encrypted email client where a wallet signature replaces the account entirely: no password, no recovery email, and no server that can read a message even if it wanted to.

Web3 Blockchain Secure Communications Cryptography Zero-knowledge
Sector
Web3 & Secure Communications
Year
2023
Duration
6 months
Team
5 people
Platforms
Web · Browser extension
Status
In production
ChainMail — visual identity for the case study
0 Passwords stored There is no password to store
Client-side Encryption boundary Nothing leaves unencrypted
On-chain Existence proof Content stays off-chain entirely
X25519 Key agreement Derived from the wallet keypair

01 — The problem

Encrypted email has existed for decades and almost nobody uses it, because key management was always the user's problem. The moment a product asks somebody to back up a private key, adoption stops.

Web3 offered a way out. Users already hold a keypair they guard carefully. The question was whether a wallet could carry a mail identity without leaking the contents of a mailbox onto a public ledger.

02 — What we did

We separated identity from transport. The chain holds only what must be public: an address-to-public-key binding and a tamper-evident record that a message existed. Content and metadata never touch it.

Encryption happens in the browser before anything leaves the client. The relay stores ciphertext it cannot open, keyed by a recipient identifier that reveals nothing about the sender. Compromising the server yields an undifferentiated pile of encrypted blobs.

The server holds the envelopes. It has never held a key.
Interface

What it looks like in use

Two of the screens that carry the most weight in daily use, rebuilt here from the production design system.

chainmail.aurezalabs.com/inbox
Inbox · 0x4F2a…9B1cE2E
0x7C88…31Ad · decrypted locally2m
0x1A0e…77Fd · decrypted locally41m
0x93Bb…10Ce · sealed2h
0PASSWORDS
0SERVER KEYS

The list holds ciphertextThreads decrypt in the browser only when opened. The relay never sees a subject line, let alone a body.

chainmail.aurezalabs.com/verify
Message proofVERIFIED
Sender signatureVALID
Commitment on chainBLOCK 21,408,663
Tamper checkINTACT
Content stored on chainNONE
X25519XChaCha20-Poly1305

The chain carries only proofA hash commitment shows a message existed at a time. Content and metadata stay off-chain entirely.

Capabilities

What the system does

Grouped by the job each set of capabilities exists to do, rather than by which team built it.

Identity and access

01 · No account to create

Wallet login

A signature challenge establishes a session. There is no registration step and nothing to reset.

Key derivation

Messaging keys are derived deterministically from a wallet signature, so a mailbox follows the wallet across devices.

Address book

Contacts resolve through on-chain name services, with the underlying address always visible.

Multi-wallet

Several identities in one client with strict separation between their mailboxes.

Messaging

02 · Familiar surface, different substrate

Encrypted inbox

Threads decrypt in the browser on open. The list view holds ciphertext until you ask for it.

Encrypted composition

Recipient public keys are fetched and content sealed before the request is made, per recipient.

Wallet-to-wallet messaging

Direct addressing between wallets with no directory in the middle to enumerate.

Secure attachments

Files encrypted client-side and stored on distributed storage, with only the decryption key travelling in the message.

Verifiability

03 · What the chain is actually for

Existence records

A hash commitment proves a specific message existed at a specific time without revealing anything about it.

Sender attestation

Signatures verify in-client, so a sender cannot be spoofed by a compromised relay.

Tamper evidence

Any alteration in transit breaks verification visibly rather than silently.

Exportable proofs

A verifiable record of correspondence that can be checked independently of the product.

Architecture

How it is put together

Layer by layer, with the reason each one exists — because the reason is usually the interesting part.

01Client crypto

All encryption and decryption in the browser using audited primitives, with keys held only in memory for the session.

  • libsodium
  • X25519
  • XChaCha20-Poly1305
02Identity binding

A smart contract mapping wallet addresses to messaging public keys, with rotation support and history.

  • Solidity
  • EVM
  • Key rotation
03Relay

A zero-knowledge store-and-forward service holding ciphertext blobs indexed by opaque recipient tags.

  • Node.js
  • PostgreSQL
  • Opaque tags
04Storage

Attachments encrypted client-side and pinned to distributed storage, referenced by content hash.

  • IPFS
  • Content addressing
05Application

React client with wallet connectors and a background decryption worker so the inbox stays responsive.

  • React
  • wagmi
  • Web Workers

Technology

Frontend

  • React
  • TypeScript
  • wagmi
  • viem
  • Web Workers

Cryptography

  • libsodium
  • X25519
  • XChaCha20-Poly1305

Chain

  • Solidity
  • Hardhat
  • EVM networks

Platform

  • Node.js
  • PostgreSQL
  • IPFS
  • Docker
Outcome

What changed

Measured against how the operation ran before, not against a benchmark chosen after the fact.

  • Key management stopped being the user's job. Messaging keys derive from the wallet, so there is nothing extra to back up.

  • The relay is uninteresting to attack. It holds ciphertext indexed by opaque tags and no key material.

  • The chain carries only what must be public. Identity binding and existence proofs, never content or metadata.

  • Correspondence is independently verifiable. Proofs can be checked without trusting the product.

How it ran

  1. Weeks 1-3

    Threat modelling

    Defined the adversary set and wrote down exactly what a compromised relay would learn.

  2. Weeks 4-8

    Crypto core

    Key derivation, sealing and the browser worker, reviewed against the threat model.

  3. Weeks 9-14

    Identity contracts

    On-chain key registry with rotation, plus name-service resolution.

  4. Weeks 15-20

    Client

    Inbox, composition, attachments and the background decryption pipeline.

  5. Weeks 21-26

    Audit and hardening

    External review of the cryptographic implementation and the contract surface.

Related work

From the same practice

All fifteen projects

Recycling & E-Waste

Razor ERP

One connected system for a warehouse that ran on paper.

A mobile-first ERP for warehouse and e-waste operations that replaced a decade of spreadsheets, paper travellers and radio calls with a single connected system that works on the floor..

2024 · 7 months
Investment & Asset Management

Kilwa

Market data, sentiment and research in one investment workspace.

An AI investment-intelligence platform that pulls market data, news sentiment and analyst research into a single workspace, so an investment team can go from a question to a defensible answer without leaving the screen..

2025 · 9 months
HR Tech & Recruitment

The Walt

Where candidates move, and where they stall.

A recruitment analytics platform that turns an applicant tracking system's raw event log into a picture of where a hiring funnel actually leaks, with the bottleneck named rather than left to be inferred..

2024 · 5 months
Something similar?

Running into the same problem ChainMail solved?

Tell us what you run. We will reply within two business days with what we would build for your situation — and, just as usefully, what we would leave out.

Start a conversation More work