Security
What protects your mail, how each protection is enforced, and the limits we do not paper over.
Security here is not a feature bolted on top. It is the shape of the system: what the client is allowed to know, what the chain is allowed to carry, and what the contracts are structurally unable to do. This page explains why that shape holds.
The short version
Sealed before it leaves
Messages are encrypted in your browser against the recipient's published key. Plaintext never exists anywhere else.
Nobody holds your key
Your mailbox key is derived from one signature and lives in the tab. It is never stored, never transmitted, and we could not produce it if compelled.
No operator to compromise
There is no server, no database, and no admin able to read, seize or delete. The contracts have no such function to call.
Your key never leaves the browser
A wallet's signing key secures funds and cannot encrypt. bMail derives a separate X25519 keypair from a single EIP-712 signature, run through HKDF-SHA256.
Three properties matter:
- It is typed data, not an opaque hash. Your wallet renders exactly what you are signing, including a warning that this signature is the mailbox key.
- It is never broadcast. The signature does not become a transaction. It costs nothing and moves nothing.
- It is deterministic. The same wallet reproduces the same mailbox on any device, so there is nothing to back up and nothing to intercept in transit.
The derived secret exists only in the memory of the tab that derived it. We never see it. A demand made to us produces nothing, because there is nothing to produce.
The chain carries ciphertext, and only ciphertext
Each message is sealed with NaCl crypto_box: X25519 for key
agreement, XSalsa20-Poly1305 for authenticated encryption. Conservative, widely
reviewed primitives used in the standard way. Nothing here is novel
cryptography, which is deliberate.
Every message uses a fresh ephemeral keypair, discarded immediately after sealing, and the plaintext is padded to 256-byte blocks so its length leaks less about its content.
Each envelope carries the message sealed twice: once to the recipient and once to you, so your own sent mail stays readable. Both come from the same ephemeral secret, so this costs size, not secrecy.
A copied envelope is useless
Everything on a public chain can be copied. So each envelope commits, inside the encrypted payload, to the route it was written for: sender, recipient, chain, and the exact contract instance.
Lift an envelope out of the log and re-emit it as your own, or replay it on another deployment, and the client compares what it decrypted against the event it actually observed, sees the mismatch, and refuses it. Without that binding, a copied envelope would decrypt cleanly and look authentic.
Hostile keys are screened, in both directions
Some Curve25519 points force the shared secret to a value anyone can compute. A key like that would make every message sealed to it readable by the whole world while still looking encrypted.
bMail rejects them on both sides of the exchange: the recipient's published key and the ephemeral key attached to an incoming message. Screening only the outbound side leaves the same hole open from the other direction.
The registry enforces this on chain as well as in the client, so the property holds for every client that ever speaks to it, not only this one.
The contracts cannot hold anything hostage
Where money is involved, the failure modes are designed out rather than documented around.
| Risk | Why it cannot happen |
|---|---|
| A counterparty blocks your refund by refusing payment | Payouts run on a fixed gas budget and fall back to a credit you withdraw yourself. A hostile recipient cannot stall anyone else's transaction. |
| Escrow gets stranded | After the window, anyone at all can push it to whoever it belongs to. It does not depend on either party staying active. |
| Someone takes your money and blocks you | Refused on chain. Blocking a sender returns their stamp; you cannot keep both. |
| A recipient baits you into an expensive reply | Answering a message somebody paid to send you is always free, enforced by the contract rather than by the interface. |
| Delivery fails because a payment failed | The message event is emitted before any settlement. Delivery is never contingent on money moving. |
| Your name is taken from you | No function exists to reassign a registered name. Transfers need both parties and expire; releasing one holds a grace window for you. |
What the operator can and cannot do
| Can | Cannot |
|---|---|
| Reserve names against impersonation | Read any message |
| Set the premium name fee | Take or reassign a registered name |
| Withdraw collected name fees | Touch stamp escrow or user balances |
| Hand ownership on, in two steps | Change anyone's encryption key |
Reserving a name never evicts someone who already holds it. The registry refuses to dispossess a holder, so the protection is a gate rather than a seizure.
What we do not claim
These are real limits. Knowing them is part of using the system safely.
Metadata is public
Anyone can see that one address messaged another, when, and roughly how large. Encryption protects contents, not the fact of contact.
No independent audit
The review rounds were self-directed. They found real and severe issues, which is an argument for outside eyes rather than against them.
Lose the wallet, lose the mailbox
There is no recovery path, because a recovery path is by construction somebody else who can read your mail.
Authorship is chain-bound
A valid tag proves the ciphertext was not altered, not who wrote it. Provable authorship needs a per-account signing key. It is planned.
Nothing can be unsent
Writes to a public chain are permanent. There is no delete, and claiming otherwise would be dishonest.
The interface is a trust point
A compromised page could capture your signature at derivation time. Run your own copy if that matters to you; the client is static files.
Reporting a vulnerability
If you find something, tell us before telling anyone else and allow a reasonable window for a fix. A dedicated disclosure contact is being published alongside the security policy; until then, reach us through the channels on the main site.