Mailey

Trust

Security model, stated plainly

Escrow is a real custody state, not a euphemism. This page describes exactly what Mailey can do with your account at each point in its life, and how to end that capability.

updated September 2026

The short version

Mailey derives one secp256k1 account per inbox from a root secret. Until you export, Mailey can sign for that account. That is the honest description of escrow, and the entire product is built to move you out of it.

  • Anyone can derive and fund an address. Only the inbox owner can claim it.
  • Claiming requires a code delivered to the inbox. There is no other path.
  • Exporting hands you the raw key. Severing disables hosted signing permanently.

Custody lifecycle

StateWho can signHow you leave it
unclaimedMailey's hosted vaultVerify a code sent to the inbox
claimedMailey, on your instructionExport the key
self-custodyYou, plus Mailey unless severedSever hosted signing
severedYou onlyTerminal state

Severing is a one-way switch on the account record: the signing service refuses every request for that account afterwards. You can re-enable it from settings if you decide you want hosted convenience back — that decision is logged.

Key derivation

MDS-1 is a pure function. Given the same canonical inbox and the same root secret it produces the same account on any machine, and nothing about it is stored:

  • HKDF-SHA512 with salt mailey/mds-1 and info acct:<canonical>:<counter>.
  • Candidates outside the secp256k1 field order are discarded and the counter advances.
  • The account row in the database is a cache: address, lifecycle state, timestamps. No key material, no passphrase, no seed.

Root secret

The root lives in the KMS boundary and is supplied to the service through MAILEY_MASTER_SEED. Compromise of the root is compromise of every unexported account — which is the reason export and severing exist, and the reason we publish the lifecycle instead of calling ourselves non-custodial.

Inbox proof

  • Six-digit codes, generated with a CSPRNG, hashed before storage.
  • Ten-minute expiry, five attempts, one live challenge per inbox and purpose.
  • Issuance is rate limited per IP and per inbox; verification is rate limited per IP.
  • Codes for export always go to the account's own inbox, never to a supplied address.

Mailey sends mail and never reads it. There is no IMAP connection, no OAuth scope and no mailbox token anywhere in the system.

Key export

Export requires an active session plus a fresh code. The passphrase you supply is used once, in memory, to build a Web3 Secret Storage v3 keystore:

  • scrypt with N=2^17, r=8, p=1, dklen=32.
  • aes-128-ctr over the key, MAC = keccak(dk[16:32] ‖ ciphertext).
  • The raw key and the keystore are returned once and never written to disk or logs.

Every export writes an immutable record — timestamp, IP, user agent, whether hosted signing was severed — visible in your account log.

What we do not defend against

  • A compromised mailbox. Whoever reads the inbox can claim the account before you do. If your mail is compromised, export is not enough — move the funds.
  • Address reuse by a previous owner. Recycled corporate addresses resolve to the same account. Treat inbox ownership changes as key rotation events.
  • Irreversible transfers. Settled transfers cannot be recalled by anyone, including us.
  • Your own device. The export screen shows key material in a browser. If the machine is compromised, so is the key.

Disclosure

Report vulnerabilities to security@mailey.app. We acknowledge within 24 hours and aim to ship a fix or a mitigation within seven days. No legal action is taken against researchers acting in good faith who avoid privacy violations, service degradation, and data destruction.