How it works
Shield, hold, earn, spend, pay, prove: the lifecycle of money inside a XEROPAY account, and the two keys that control it.
Status: design. XEROPAY is being built. These pages describe intended behaviour. Nothing here is claimed as live mainnet. Details can change. See What's live.
XEROPAY is an account, not a mixer. The account is the product; the shielded pool underneath is plumbing. This page walks through what is supposed to happen to a unit of value from the moment it enters.
1. Shield
Money enters through a licensed fiat ramp or a bridge. At the boundary of the pool it is screened: sanctioned sources are refused before anything is shielded. What passes lands as one or more encrypted notes bound to your spending key. From that moment the chain can see a deposit into a pool; it is not supposed to see whose balance grew. See Shield and unshield.
2. Hold
A balance is the sum of the notes your spending key can open. Notes can hold stablecoins or tokenized stocks. Your app decrypts them locally; the XEROPAY server is not the source of positions. You can split notes across vaults for saving, spending, and investing. See The shielded account.
3. Earn
Shielded deposits are designed to pool and route into real yield venues. Returns are meant to credit per note, so you earn without a visible deposit, claim, or running balance. Auto-sweep can move idle balance into that pool on its own. Rates publish with venues, not before. See Private yield.
4. Spend and pay
Everyday spend is specified to settle from shielded funds, with limits, freeze, and a kill switch — networks named only when issuance is real. Payments go to stealth addresses: a fresh receiving address per payment, so a shared handle cannot be scraped for a balance. Recurring rent and subscriptions are meant to run without a repeating on-chain cadence. A business can pay a roster from one treasury. See Spend rails and Payments.
5. Prove
When someone legitimately needs to see inside, you issue a viewing key: read-only, scoped to a date range, revocable, optionally self-expiring. When they only need a yes-or-no answer, you issue an attestation instead — balance above X, held N months. See Viewing keys and Attestations.
6. Unshield
Leaving the pool is screened again. Exits can be split and staggered so an unshield is harder to match to a shield by clock. Destinations are named. This is not a hop through a mixer.
The two keys
| Key | Can | Cannot | Held by |
|---|---|---|---|
| Spending key | Open notes, sign spends, issue viewing keys | — | You. On-device; recoverable via guardians |
| Viewing key | Read notes inside its scope and dates | Spend, issue further keys, read outside scope | Whoever you give it to, until expiry or revoke |
There is no third key. XEROPAY is specified to hold no master viewing key and cannot move funds.
What the chain sees
| Event | Public | Hidden |
|---|---|---|
| Shield | A deposit into the pool, screened | Whose balance it became |
| Transfer inside the pool | That a proof was verified | Sender, recipient, amount, asset |
| Yield credit | Pool-level routing when venues are live | Per-note accrual |
| Spend / pay | Pool-level settlement where a rail exists | Which account paid |
| Unshield | A withdrawal from the pool, screened | Which notes, when they were shielded |