Skip to main content
Privacy Pools are Arcane’s on-chain privacy layer for Stellar/Soroban. They let you transfer assets between parties without revealing sender identity, recipient identity, or transaction amounts on the public ledger — while simultaneously producing an encrypted audit payload that your compliance team can review through the Auditing Portal. Every private transaction is cryptographically verified on-chain before any state change occurs, so privacy and integrity are enforced by the protocol itself, not by trust in a third party.

​
Transaction types

A Privacy Pool supports four logical transaction shapes. All of them flow through a single contract entrypoint (transact), and the shape is determined by the inputs you provide rather than by separate methods.
TypeWhat it does
DepositMoves tokens from a public Stellar account into the privacy pool, creating a new private coin (commitment)
WithdrawRemoves tokens from the privacy pool to a public Stellar account, consuming an existing private coin
TransferMoves value between private coins entirely within the pool — no tokens leave the contract
MixedCombines deposit, transfer, and withdraw operations in a single atomic transaction
Because all four shapes share a single transact entrypoint, an outside observer cannot determine which type of operation occurred just from the contract call.

​
Zero-knowledge proofs

Every transaction includes a Groth16 zero-knowledge proof generated by the client SDK before the transaction is submitted. When the contract receives the transaction, it verifies the proof against the published verification key on-chain. If the proof is invalid, the transaction is rejected — no state changes occur. This means the contract can confirm that:
  • You own the coins you are spending.
  • The transaction is correctly balanced (inputs equal outputs plus any fees).
  • No coin has been spent twice.
All of this is verified without the contract — or any observer — ever seeing the private inputs: the coin values, the sender’s private key, or the recipient’s address.
Arcane uses Groth16 proofs generated from Circom circuits. The circuits encode the exact constraints for each transaction shape. You do not need to understand the cryptography to integrate Privacy Pools — the client SDK handles proof generation automatically.

​
The commitment model

Every private coin in the pool is represented as a commitment — a Poseidon hash that encodes the coin’s value and ownership information without revealing either. Commitments are stored in an on-chain Merkle tree. The commitment is computed as a layered Poseidon hash over the coin’s private fields: 
precommitment    = Poseidon(secret, sharedSecret[0], sharedSecret[1])
balanceCommitment = Poseidon(value, asset[0], asset[1])
commitment       = Poseidon(nullifier, balanceCommitment, precommitment)
When you spend a coin, you prove membership in the Merkle tree and reveal only a nullifier hash — Poseidon(nullifier) — that uniquely identifies the coin as spent. The contract records the nullifier hash to prevent double-spending. Because the nullifier hash is a one-way Poseidon hash, it cannot be linked back to the original commitment by anyone who does not hold the private key. The result is a spend model where:
  • Ownership is proven without being revealed.
  • Spending is proven without identifying which coin was spent.
  • Double-spending is prevented without linking transactions together.

​
Stealth addresses

Recipients in Arcane Privacy Pools use stealth addresses — one-time private addresses with the Bech32 prefix stpl1. A stealth address is derived from the recipient’s wallet signature using BabyJubJub ECDH: the recipient signs a message with their Stellar wallet, the SDK hashes the signature and derives a BabyJubJub scalar, and the resulting public point is encoded as the stpl1 address. Only the recipient holds the corresponding private scalar, so only they can claim coins sent to their stealth address. The client SDK (PrivacyPoolSDK) handles stealth address generation and derivation for you. The BabyJubJub scalar and ECDH shared-secret computation happen entirely on the client — nothing sensitive is ever sent to a server.
Stealth addresses are single-use by design. Each new transaction to the same recipient should use a freshly derived stealth address to prevent linkability.

​
Built-in compliance

Privacy does not mean unauditable. Every transaction automatically emits an AuditEncodedDigest event on-chain. This event contains the full transaction details encrypted with keys that only authorized parties can decrypt. Neither the contract nor public observers can read the payload — but the Arcane Scanner indexes it, and the Auditing Portal can decrypt it using keys managed under your organization’s access controls. This means:
  • Audit data is always available for any transaction, regardless of when a disclosure request is created.
  • Compliance workflows happen entirely off-chain without affecting transaction execution.
  • Access to decrypted audit data is always scoped to approved disclosure cases.
See Auditing Portal for how the portal indexes and surfaces this data to your compliance team.

Client SDK

Learn how to integrate the Privacy Pool SDK into your application, initialize a pool, and submit private transactions.

Cryptography

Deep dive into commitments, nullifiers, stealth address derivation, and the Groth16 proof system.