Privacy

Arbitrum Sepolia test build.

In short: your keys and proofs stay in your browser; the public chain shows deposits and withdrawals but not what connects them; and the reserve's auditor can read every payment a member makes. The details are below.

What stays in your browser

Your passkey derives your keys in the browser each time you unlock. The keys, each payment link's blinding, and your recovery phrase (when your passkey has no PRF support) are kept in this browser's storage and are never sent to a server. The one key that is sent is your key exchange, when you register (see below). Proofs are generated here too.

What registering stores

Spending needs a registration, which starts with a demo KYC: you give a name, a country and pick a file. The file never leaves your browser; only its name and size are sent. The server stores the name, country, file name and size, and your key exchange, in a database, encrypted under a server secret. The auditor can read them and uses the key exchange to open the spends you file. Treat the demo KYC as a simulation: do not enter real identity details or upload real documents.

What the link store keeps

When you create a payment link, the server stores its id (an owner commitment, which is already in the link URL), the amount, your note and the creation time, so the payer's page can show them and your other devices can find the link again. It keeps no key material and no address of yours. It lives in a Neon Postgres database.

What the relayer sees

A withdrawal is relayed: the server submits the proof your browser made and pays the gas. It sees the proof's public inputs, which are the same values the chain publishes: two nullifiers, two new note hashes, the amount and the destination address. The proof fixes all of them, so the relayer cannot change where funds go. The relayer also registers your account with the reserve, which puts your member leaf and key exchange on-chain.

What the chain shows

A payment is a public USDG transfer from the payer into the MIST reserve, with the link id as calldata. A withdrawal shows the relayer, the destination and the amount. Nothing on-chain connects the two, but amounts can: a unique amount paid and later withdrawn in full is easy to pair. Whoever holds the reserve's auditor key can decrypt the outputs of spends made by its members; that is the compliance path, by design. Whoever can read the server's database and its secret can read every member's history too.

What this build does not do

No analytics, no cookies, no accounts on our side. There is no default way to recover funds if you lose both your passkey and your recovery phrase.