Every inbox already
has an account.
Mailey derives a deterministic ERC-20 account on Robinhood Chain from an email address. Send to someone who has never held a wallet — they take the private key by proving the inbox is theirs, then walk away with it.
Capital flow
Where the money actually sits
An address is derived the first time anyone asks for it. Funds settle to that account immediately — the difference between a claimed and an unclaimed inbox is who holds the key, not where the balance lives.
Derivation
HKDF-SHA512 over the canonical inbox, reduced into the secp256k1 field. Pure function, no database.
Escrow
Unclaimed accounts are signable by the hosted vault under a published policy and a full audit log.
Release
Verification hands over the raw key and a v3 keystore, then optionally cuts hosted signing for good.
Lifecycle
Three states, one direction
Someone sends to your address
The sender types an email. Mailey resolves it through MDS-1 into a secp256k1 account and settles the transfer there. The recipient gets a notification, not a seed phrase.
You prove the inbox is yours
A six-digit code lands in that inbox. Five attempts, ten minutes, one live challenge at a time. Proving control claims the account and opens a session.
You take the key
Set an export passphrase and Mailey hands back the raw key plus an encrypted v3 keystore. Sever hosted signing and Mailey can no longer move anything — the account is only yours.
Product
Built like infrastructure, not a demo
Every surface that touches key material is specified, rate limited and logged.
Resolve before you send
Type an address, get a checksummed account and a public commitment. No onboarding, no invite, no app install on the other side.
Escrow with an exit
Until the inbox is proven, the key sits in a hosted vault with a published policy. The moment it is proven, the key is yours and hosted signing can be severed permanently.
Provider-aware normalization
Dots, plus-tags and provider aliases fold into one canonical inbox, so j.doe+shop@gmail.com and jdoe@gmail.com never split a balance.
Keystore-grade export
Web3 Secret Storage v3 with scrypt N=2^17. The passphrase is used once, in memory, and is never stored or transmitted back.
Audit trail by default
Every code issued, session opened, and key released is written to an append-only account log you can read and export.
MDS-1
The derivation is the product
One deterministic function turns a canonical inbox into an account. It is published, testable, and identical on every machine that holds the root secret.
- Pure derivation. No key material is written to the database — ever. The account row is a cache of a function output.
- Counter-hardened. Candidates outside [1, n−1] are rejected and re-derived with an incrementing counter.
- Commitment published. keccak(eid ‖ account) lets anyone verify a resolver answer without learning the inbox.
canonical = normalize("J.Doe+shop@Gmail.com")
// → "jdoe@gmail.com"
eid = sha256(canonical)
sk = HKDF-SHA512(
ikm: ROOT, // KMS boundary
salt: "mailey/mds-1",
info: `acct:${canonical}:${i}`,
) // 32 bytes
assert 0 < sk < secp256k1.n // else i++
account = keccak(pubkey(sk))[12:]
commitment = keccak(eid ‖ account)API
One call to turn an inbox into an account
Resolve addresses from your own product. Payroll, refunds, affiliate payouts, invoices — anywhere you already have an email and no wallet.
curl https://mailey.app/api/v1/resolve \
-H "Authorization: Bearer mk_live_…" \
-G --data-urlencode "email=cfo@acme.com"
{
"ok": true,
"data": {
"address": "0x7c3f…9a12",
"canonical": "cfo@acme.com",
"derivation": "mds-1",
"claimed": false,
"self_custody": false
}
}0
Accounts derived
0
Inboxes claimed
0
Transfers settled
$0.00
Volume routed
Questions
The parts people push on
Still unresolved? Read the docs or write to security@mailey.app.
Your address is already an account.
Claim it in under a minute. Keep the key forever.
2 domains · 2 accounts · robinhood chain · mds-1