> For the complete documentation index, see [llms.txt](https://docs.useprivatus.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.useprivatus.com/privacy-and-confidential-transfers/confidential-transfers.md). # Confidential Transfers Explained Privatus's privacy model rests on one deliberate, powerful distinction: confidentiality, not anonymity. Addresses stay visible on Solana. Amounts do not. Your financial life becomes verifiable to the network and invisible to everyone else. This page walks through the cryptography that makes that possible. *** ## The building block: Token-2022 confidential balances Privatus is built on Token-2022 confidential balances, the confidential transfer extension native to Solana's token program. Solana is the only major L1 with an encrypted-amount primitive built into the protocol itself, so Privatus does not retrofit privacy at the application layer: it inherits it from the chain and builds on top. Two techniques work in concert: * **Twisted ElGamal encryption** encrypts account balances and transfer amounts homomorphically, meaning the token program can add and subtract encrypted values without ever decrypting them * **Zero-knowledge proofs**, checked by Solana's native ZK proof program, confirm that an encrypted transfer is valid (the sender has sufficient balance, the amount is non-negative and in range) without revealing what the amount actually is The result is remarkable: the chain verifies that a transfer is legitimate and updates both parties' encrypted balances correctly, all without ever learning the amount involved. Privatus programs, written in Rust with Anchor, add handles, agent accounts, spend policies, and disclosure logic on top of this foundation. *** ## What a standard SPL transfer looks like ``` Sender Address [PUBLIC] → Amount [PUBLIC] → Receiver Address [PUBLIC] ``` Anyone with an RPC connection can read the exact amount of every transfer, forever. That is the surveillance default Privatus exists to end. *** ## What a Privatus transfer looks like ``` Sender Address [PUBLIC] → Amount [ENCRYPTED] → Receiver Address [PUBLIC] Proof: a zero-knowledge proof that the encrypted amount is valid, without revealing the amount itself ``` *** ## Step by step 1. You initiate a transfer in the Privatus app. 2. Your device's Privacy Engine encrypts the amount as a twisted ElGamal ciphertext and generates the required ZK proofs locally, using your account's decryption key. The plaintext amount never leaves your device. 3. The encrypted transfer and its proofs are submitted to Solana as a single transaction: a confidential transfer instruction on the token account, with proof verification by Solana's native ZK proof program in the same transaction. 4. The network verifies the proofs and updates both parties' encrypted balances on-chain, typically within a slot or two (\~400ms slots). Addresses remain public. The amount is ciphertext, and stays that way. 5. Only the sender and receiver, using their private decryption keys, can decrypt the amount and see what moved. 6. For compliance, you can generate a selective disclosure proof that reveals a specific transaction's amount to a chosen third party, such as an auditor, without exposing any other transaction. See [Selective Disclosure & Audit Export](/privacy-and-confidential-transfers/selective-disclosure.md). *** ## Beyond confidential amounts: shielded state Confidential balances are the default layer. Accounts on Shadow Pro and above can additionally shield account state itself through Privatus's commitment-tree shielded pool: balances and history are committed as Merkle roots on-chain, with Groth16 proofs verified through Solana's alt\_bn128 syscalls, and stealth meta-addresses unlink recipients from their public identity. See [On-Chain Architecture](/protocol-and-architecture/on-chain-architecture.md) for how the pool works. *** ## Why this matters Public blockchains solved verifiability by making everything visible. That trade-off suits auditors and analysts, but it means anyone on the planet can watch your salary, your rent, or your runway in real time. Privatus keeps everything worth keeping: a transfer's validity is still checked by the network and permanently recorded. What it removes is the surveillance cost. This is what a financial rail built for the open, agent-driven economy should have looked like from the start. *** ## Performance ZK proof generation happens client-side, in the browser or the mobile app, using WASM. On modern devices this adds a small, sub-second delay before a transfer is submitted, privacy at the speed of a tap. Low-power devices fall back to a server-assisted proof generation path where the amount is still never transmitted in plaintext; only proof inputs derived client-side are used. Settlement itself runs at Solana speed: confirmation typically within a slot or two, with fees a fraction of a cent, paid in SOL and handled automatically. *** ## Next * [Selective Disclosure & Audit Export](/privacy-and-confidential-transfers/selective-disclosure.md) * [Key Management & Custody](/privacy-and-confidential-transfers/key-management.md) --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://docs.useprivatus.com/privacy-and-confidential-transfers/confidential-transfers.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.