This glossary defines Opaque Stellar protocol terms used throughout the documentation and codebase.
A commitment to a private balance in the privacy pool. Created when a user deposits XLM, held as a leaf in the pool state tree. The user proves ownership via a zero-knowledge proof during withdrawal without revealing the deposit. The note is analogous to an anonymous receipt that cannot be linked back to the depositor.
A public identifier published by a recipient to receive stealth payments. Contains spend and view material derived from the recipient's private keys. A sender derives a shared secret from the meta-address and creates a one-time Stellar account to send XLM, keeping the recipient's identity hidden from the public ledger.
A curated collection of deposits approved by the Association Set Provider (ASP). Used to build a Merkle tree root that proves a withdrawal is operating over an approved set of deposits. Prevents the pool from being used with unapproved or poisoned deposits.
A scanning mechanism compiled to WebAssembly that runs in the user's browser. Detects incoming stealth payments by filtering announcements with view tags and reconstructing one-time private keys locally without requiring a hosted scanning service. Keeps receipt discovery private from third parties.
A unique, non-reversible hash derived from a note and secret. Submitted during withdrawal and recorded on-chain to prevent double-spending. Two nullifiers are never identical even if the same note is used twice, preventing note reuse attacks.
A private payment mechanism where the sender creates a one-time Stellar account in the recipient's name using ephemeral cryptography. The recipient's main wallet never appears as the destination, and the payment announcement contains only view tags — not the recipient's identity.
Smart contract that stores recipient meta-addresses. Senders query it to look up a recipient's meta-address before creating a stealth payment.
Smart contract that records payment announcements and view tags. Enables recipients to discover incoming payments without revealing which outputs belong to them.
DKSAP implementation compiled to WASM. Runs locally in the user's browser to scan the public ledger for incoming stealth payments and derive the corresponding private keys.
Smart contract holding user deposits as commitments. Verifies zero-knowledge proofs during withdrawal, records nullifiers to prevent double-spending, and enforces custody invariants to ensure only the note owner can withdraw.
Smart contract that verifies Groth16 proofs generated by the privacy pool withdrawal circuit. Runs on Soroban to validate cryptographic proofs on-chain.
Off-chain service that monitors pool events and publishes:
- Association-set root: Merkle root over approved deposits
- State root: Root of the current pool state tree
Wallets use these roots to generate and verify proofs. The ASP cannot forge or modify proofs, but can gate access by controlling which deposits are approved.
Off-chain service that submits privacy pool withdrawal transactions on behalf of users. Operators register on-chain, receive encrypted payloads from wallets, decrypt them, and submit transactions to earn fees. Cannot modify the withdrawal context (recipient, amount, proof).
Smart contract tracking relayer operators, their X25519 public keys, endpoints, stake, active jobs, bids, and settlement. Enables wallets to verify relayer credentials before submitting encrypted payloads.
Smart contract that verifies zero-knowledge reputation proofs. Checks root validity, nullifier replay protection, and Groth16 verification to allow users to prove reputation without linking it to a public wallet.
User initiating a stealth payment. Derives a shared secret from the recipient's meta-address and creates a one-time Stellar account. Cannot derive the recipient's spend key.
User receiving stealth and private pool payments. Scans announcements locally, sweeps stealth accounts, and generates withdrawal proofs. Can hide their identity from the public ledger but not from their own RPC provider.
Non-custodial Freighter integration that manages user keys locally. Generates proofs, selects relayers, and submits transactions. Rebuilds merkle paths and verifies published roots before proof generation.
Runs the relayer service. Registers on-chain with an X25519 public key and endpoint. Bids on jobs, decrypts payloads, and submits transactions for a fee. Subject to operator-specific threats (key theft, griefing, deanonymization).
Issues attestations under a schema for zero-knowledge reputation. Cannot prove a holder's private reputation statement without the holder's witness.
A browser-based key storage threat model covering compromised extensions, XSS attacks, and clipboard sniffing. See GHOST_THREAT_MODEL.md for details.
A cryptographic hash binding a note to the pool. Users prove possession of the corresponding secret during withdrawal without revealing it.
A sequence of hashes proving membership in a Merkle tree. Wallets rebuild paths locally to prove a note exists in the approved association set and pool state tree.
Commitments bound into a zero-knowledge proof (recipient, amount, fee, relayer address, pool scope). A relayer cannot change the proof context without invalidating the proof.
On-chain funds reserved by a wallet for a relayer job. The relayer can only earn the escrowed fee if they submit the correct transaction. Protects against bids that cannot be backed by registered stake.
Deployment configuration stored in deployments/v1/<network>.json. Contains contract IDs, WASM hashes, RPC URLs, and artifact fingerprints. Frontend and services read from the manifest instead of using hardcoded values.
Verification that circuit artifacts match their pinned hashes in the deployment manifest. Ensures deterministic builds and prevents supply chain attacks on circuit artifacts.