Private Payments
Pay a private receiving address and return any remaining value as change.
How a payment works#
A private payment spends existing notes and creates new ones. Each note has a commitment to its asset, amount and owner, along with the fields that define its spending rules. The proof shows that the sender knows the openings of notes in an accepted note-tree root and that the outputs preserve their value.
The Pool records a nullifier for each spent input. It can reject a second spend without revealing which commitment was consumed. The sender encrypts each new note for its recipient, who can find it later in public delivery data.
What the proof authorizes#
The proof covers the payment the user reviewed, including its destination, outputs, fee and public execution context. Someone else can submit that proof, but cannot use it to change the recipient or redirect the fee.
Save the prepared request and controller signatures for retries. The existing proof remains bound to its original chain and deployment. If you switch deployments, prepare a new payment and collect its approval before submission.
Inputs and change#
A spend supports at most two input notes and two output notes. It uses one asset, and its inputs must share a controller. A payment can use two notes when one is too small. If the balance is split across more notes, consolidate them or build an ordered router sequence first.
Display the token amount alongside any USD estimate. Prices can change what the interface shows and what the relay charges. The spend still accounts for the actual token units.
| Data | Where to keep it |
|---|---|
| Note openings and spend secrets | The holder's device or encrypted backup |
| Proof and public inputs | Relay submission and onchain verification |
| Encrypted output delivery | Public history that the client authenticates |
| Plaintext private balance | The holder's recovered account state |
What is public#
Note openings stay private under the protocol's cryptographic assumptions. Observers can still see proof submissions, commitments, nullifiers, timing and any nonzero public fields. A payment submitted directly from the payer's wallet also reveals that wallet as its sender.
Deposits and withdrawals publish additional information. Controller calls and network traffic can add links too. Describe those facts in the payment flow so users know what the private transfer hides.