3 inboxes resolved2 claimed3 domains1 coins paying an inbox1% pool fee on Varo · 90% to the inboxno wallet required to receivekey released on one verification3 inboxes resolved2 claimed3 domains1 coins paying an inbox1% pool fee on Varo · 90% to the inboxno wallet required to receivekey released on one verification
MDS-1 resolver live on Robinhood Chain

Every inbox already
has a wallet.

X Money does this for a Twitter handle. XVaro does it for the address everyone already has: a deterministic ERC-20 account on Robinhood Chain, derived from any email. Pay someone who has never held a wallet, or launch a coin whose fees are theirs — they take the private key by proving the inbox, then walk away with it.

Try
No wallet required to receive Key release in one verification Exportable to any wallet

Launched here

Coins, and the inboxes earning from them

See the whole board →

Recent launches

1live from the chain

Why email

X Money gave an account to a handle. We gave one to everybody.

Tying money to a social handle only works inside that social network: one company, one app, one account you do not own. Email is the opposite — it predates every platform, works across every provider, and already belongs to the person using it.

A handle

  • Lives on one platform, under its rules
  • The company can rename, suspend or delete it
  • Only reaches people who joined that network
  • No handle, no money

An inbox

  • An open standard nobody owns or gatekeeps
  • Your employer, your bank and your grandmother all have one
  • Works across every provider, in every country
  • You already know the address of the person you want to pay

Same idea, wider surface. Every address that can receive a message can now receive money, hold a token, and earn the fees of a coin — without its owner joining anything at all.

◇ gmail.com◇ icloud.com◇ outlook.com◇ proton.me◇ hey.com◇ fastmail.com◇ stripe.com◇ vercel.com◇ linear.app◇ ramp.com◇ mercury.com◇ anthropic.com◇ gmail.com◇ icloud.com◇ outlook.com◇ proton.me◇ hey.com◇ fastmail.com◇ stripe.com◇ vercel.com◇ linear.app◇ ramp.com◇ mercury.com◇ anthropic.com

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.

Any inbox

nina@studio.com

Typed by anyone, at any time. No signup on the other side.

MDS-1

································································

hashing the canonical inbox…

On-chain account

0x········································

Receives immediately. The key is released when the inbox is proven.

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

01

Someone sends to your address

The sender types an email. XVaro resolves it through MDS-1 into a secp256k1 account and settles the transfer there. The recipient gets a notification, not a seed phrase.

02

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.

03

You take the key

Set an export passphrase and XVaro hands back the raw key plus an encrypted v3 keystore. Sever hosted signing and XVaro can no longer move anything — the account is only yours.

Launch on Varo

Point a coin's fees at a person, not a wallet

Launch through XVaro and the pool fee goes to an email address. The recipient needs no wallet, signs nothing, and installs nothing — the money starts accruing to them from the first trade.

01

You launch the coin

Name, ticker, picture — a normal Varo launch, signed by your own wallet. The one extra field is an email address.

fee_recipients: [{ wallet: mds1("nina@studio.com") }]
02

Varo pays that address

Every trade pays a 1% pool fee, and Varo credits it in the coin’s locker to the account derived from that inbox. XVaro puts no contract in between.

locker.claim(index) → 4.21 WETH
03

They claim the inbox

A six-digit code proves the mailbox. Then they pull the fees — and can export the private key and never need us again.

claim(index) → funds land in their account

Pay a designer, a streamer, a whole newsletter list — anyone with an inbox can be the beneficiary of a token before they have ever heard of one.

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.
Read the security model
typescript
canonical = normalize("J.Doe+shop@Gmail.com")
// → "jdoe@gmail.com"

eid = sha256(canonical)
sk  = HKDF-SHA512(
        ikm:  ROOT,                 // KMS boundary
        salt: "xvaro/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.

bash
curl https://xvaro.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@xvaro.app.

Until you export, yes — and we say so plainly. The key is derived from a root secret inside our KMS boundary, which means XVaro can sign for an unclaimed inbox. The lifecycle is designed to end that: claim, export, sever. After severing, hosted signing is disabled and the only holder of the key is you.

Your address is already an account.

Claim it in under a minute. Keep the key forever.

3 domains · 3 accounts · robinhood chain · mds-1