RP1 privacy is a cryptographic application boundary, not a promise that the entire chain becomes invisible. The chain verifies proofs and tracks spentness while wallets retain the secret material needed to create and interpret private notes.
Data model
- Note — a private claim that a wallet can spend.
- Commitment — a public binding to a note without revealing the note value.
- Nullifier — a public spend marker that prevents a note from being used twice.
- Merkle root — the commitment-tree state used as a proof input.
- Viewing key — wallet or auditor material for selective disclosure.
Threat model
The design aims to reduce public linkage between shielded inputs, outputs, amounts, and owners. It does not hide:
- the existence of a transaction and its inclusion metadata;
- public fees, public recipients, or public contract calls;
- timing and network-layer observations;
- data an application emits deliberately;
- weaknesses introduced by a small anonymity set or compromised wallet keys.
Wallet responsibilities
The wallet must generate and protect proving/viewing material, avoid logging private note data, select an appropriate anonymity set, validate roots and recipients, and make disclosure consequences clear to the user. A hosted relayer can submit a proof, but it should not automatically receive the user’s viewing key.
Module composition
Privacy can compose with DEX and stablecoin flows. The source tree reserves an EVM privacy-precompile address, but the current application wiring does not register it; use the native privacy messages and queries instead. If a future release activates that adapter, it must still preserve the module’s proof, gas, authorization, and accounting checks. See private finance for user-facing patterns.