How @nyone works

A send is just three things: to, amount, send.

Crypto today asks you for a 42-character string and hopes you didn't paste the wrong one. That's not how money works anywhere else. @nyone replaces that string with something a human can recognise — a social handle, an email, or, if you really want, a wallet address.

Underneath each of these flows is the same architecture: a handle layer that maps human identifiers to on-chain entities, and a shielded pool that keeps the link between sender and recipient unobservable.

From tap to settlement, in six beats.

Here's exactly what happens between the moment you press Send and the moment the money arrives. Most of these steps complete in under a second.

1. 01
   You compose a send

   You pick a recipient — @handle, email, or wallet — and an amount. The app figures out which kind of recipient it is, what tokens you have available, and which balance to draw from (the privacy pool, or an external wallet you've linked).

2. 02
   We turn the recipient into an anonymous reference

   Behind the scenes, the recipient's identifier is hashed into a stable, anonymous reference. Nobody on-chain ever sees "@sarah" — they see a number that only @nyone's directory can resolve back to a real person.

3. 03
   The send becomes a sealed envelope

   Your funds are bundled into what we call a commitment — a cryptographic seal that locks together the amount, the recipient's public key, and a fresh random secret. From the outside it's just a hash. Only the recipient holds the key to open it.

4. 04
   The envelope joins the pool

   That sealed envelope is added to the shielded pool — a tree of every envelope ever deposited. The chain records that something was added, but not what was added or who added it.

5. 05
   The recipient picks it up

   If the recipient already has an account linked to that handle, they can spend the envelope right away. If not, the funds wait safely in escrow until they sign in with the same handle. From that moment they hold the keys to it — not us.

6. 06
   They spend or withdraw

   Spending stays inside the pool — sender and recipient both invisible to outside observers. Withdrawing exits the pool to a regular wallet address, which is the only point where anything becomes externally observable.

An identity layer the chain doesn't have.

Blockchains are very good at agreeing on numbers. They are very bad at agreeing on whether the person who logs in to X today is the same person who tweeted under that name a year ago. That's a problem someone has to solve outside the chain.

What a handle actually is

When you link an identity to your @nyone account — your X handle, your Gmail address, an external wallet — three things get recorded:

• The provider — which authority vouches for this identity (X, Gmail, a wallet signature, and so on).
• The subject — the stable identifier that provider gives you (your X user ID, your Gmail address, your wallet address). For X specifically we store the numeric user ID, not the visible handle, so renaming yourself on X doesn't break your link.
• An attestation on-chain — a small record in our contract that says "this identifier belongs to this account," together with the public keys the privacy layer needs to send funds to it.

Who decides @sarah is really Sarah?

This is the question most crypto identity projects either dodge or answer with "nobody, and that's a feature." We answer it directly. The chain cannot reach out to X and ask "did this user log in?" — so somebody has to translate. Today, that somebody is us.

When you sign in with X or Gmail, you're proving ownership of that identity to its real authority — Twitter, Google. Our service relays that proof onto the chain by publishing the attestation. We do not invent or assign handles. We do not let users claim handles they didn't authenticate against the upstream provider. The provider is still the source of truth; we're a notary that writes that truth into a place the contract can read.

After the attestation, you don't need us

Once a handle is attested, ordinary use is on-chain and trustless. Sending to a handle, claiming funds for a handle you own, transferring inside the pool — none of these require us to be in the loop. Our role ends at the door.

A pool of envelopes nobody can peek into.

Most blockchain transfers are public broadcasts. Sender, recipient, amount, timestamp — anyone with a block explorer can read the whole story. @nyone doesn't do transfers that way. It deposits sealed envelopes into a shared pool and lets recipients prove they own the right one without revealing which one.

The shielded pool, in one picture

Imagine a clear glass jar that anyone can drop a sealed envelope into. From the outside, you see envelopes piling up. You can count them. You cannot read them. Each envelope locks together: this much of this asset belongs to whoever holds this private key. The cryptography that does the sealing — Poseidon hashing inside an incremental tree — is the same family of primitives used by Zcash, Aztec and several identity layers running in production today.

Spending without uncovering

When you spend an envelope, you do not point at it. You stand outside the jar and prove, with a zero-knowledge proof, three things at once:

1. I own one of the envelopes inside this jar.
2. It contains exactly the amount and asset I'm spending.
3. I am leaving behind a one-time marker that prevents anyone — including me — from spending it again.

The chain checks the proof, accepts it, and replaces your envelope with up to two new ones (one for the recipient, one for change). To any observer, two new envelopes appeared in the jar. They cannot tell which old one was spent, who spent it, or who got the new ones.

What's revealed, what isn't

Where each piece of you lives.

@nyone is a stack of three layers, each with a job and a hard limit on what it can see. None of them holds the whole picture — that's the design.

Compromising any one layer doesn't hand the whole system over. The app without the service can't move funds. The service without the chain can't. The chain without the keys can't. And the keys without proofs can't double-spend.

One account, many doors.

Your @nyone account is the thing that owns your funds. Around it, you can attach as many ways to sign in as you like — your X handle, your Gmail, an external wallet, a wallet we manage for you. Any one of them lets you in. None of them is the canonical "you."

Linking

When you link a new sign-in, two things happen at once. The first is administrative — we record that this identity belongs to your account. The second is reconciliation — if anyone has ever sent funds to that handle while it was unclaimed, the escrow is unlocked and converted into envelopes you control, in the same step.

Merging

Sometimes you'll have started two accounts by accident — one with X, one with a wallet — and want to fold them into one. Merging is a real on-chain operation because both accounts may already hold pool balances. The app guides you through it; the contract verifies the maths; from then on, both identities point to the same account.

Losing one of your sign-ins

Because any linked method can sign you in, the practical recovery story is "use another one." We strongly recommend linking at least two. If you ever lose all of them at once — and only then — your funds are unreachable. There is no admin backdoor; the contract itself doesn't know how to reassign your handles to anyone else, and we don't hold a key that could do it.

Three ways to hold your keys.

We don't believe there is one correct custody answer for everyone. We give you three, side by side, and you pick the trade-off you're comfortable with.

You can mix modes: use a managed wallet for everyday convenience and link an external wallet for larger amounts. They both belong to the same account.

What's protected by maths, what's protected by us.

We split this section into two honest halves: the protections that don't require you to trust us at all, and the things you do, today, with a clear-eyed view of what they are and how they shrink over time.

Protected by cryptography

Protected by us — with intent to phase out

Quick answers.

Something missing? Reach out to the team — we'd rather answer questions in the docs than in a thousand individual replies.