Skip to content

Private finance

Preview

Use commitments, nullifiers, Groth16 proofs, viewing keys, and private application boundaries on RP1.

Updated View as Markdown

RP1’s privacy surface is designed for selective confidentiality in financial workflows. A shielded pool can hide transaction amounts and ownership relationships from ordinary chain observers while preserving cryptographic validity and controlled disclosure.

Core model

  1. A shield operation moves transparent assets into a shielded pool and creates commitments.
  2. A private transfer proves that the spender owns valid notes and that the input nullifiers have not been spent.
  3. The verifier checks the Groth16 proof against the Merkle root and public inputs.
  4. The chain records new commitments and nullifiers without learning the private note values.
  5. An unshield operation proves a valid spend and sends transparent assets to an explicit recipient.

Viewing keys let a wallet or authorized reviewer recover the information they need without making every observer a participant in the private transaction graph.

What remains public

Privacy does not hide everything. Depending on the flow, observers can still see transaction inclusion, fees, module events, public recipients, pool-level statistics, and any data an application intentionally places in a public message. A privacy claim should always say which fields are private and which metadata remains observable.

Composable private workflows

  • Shielded DEX liquidity and swaps can apply privacy to market operations.
  • Shielded stablecoin flows can keep a financial position private while preserving the module’s proof and accounting rules.
  • Private contract execution is a preview/planned adapter boundary rather than a general public workflow in the current application wiring. If enabled by a future release, encrypted state and viewing-key-controlled reads still would not turn arbitrary code into an unbounded private runtime.
  • The TypeScript SDK exposes privacy helpers, but proof generation, key custody, and note recovery remain wallet responsibilities.

Integration checklist

  • Use a current Merkle root and reject stale or mismatched roots.
  • Keep proving and viewing material out of hosted servers unless the user has explicitly delegated that trust.
  • Never log note plaintext, viewing keys, or unblinded amounts.
  • Test proof failure, spent-nullifier, invalid-recipient, and unshield-recovery paths.
  • Explain the privacy set and metadata leakage to end users before they sign.

Read the privacy architecture, the module reference, and SDK privacy guidance.

Navigation

Type to search…

↑↓ navigate↵ selectEsc close