Architecture

​

Private Wallet and User

Users hold their encrypted balance in a Private Wallet and sign private transactions with their existing Solana Ed25519 key. A private wallet integration adds a shielded keypair to your key management. You can integrate it yourself or use the Embedded Private Wallet.

​

Private Transactions

Private transfers are normal Solana transactions. The Solana runtime verifies the signatures and invokes the Solana Privacy Program, which verifies the ZK proof without revealing the encrypted state. A typical confidential transfer consumes around 927 bytes, well within v1’s 4,096-byte limit.

Example Confidential Transfer

Component	Bytes
Groth16 proof	192
Other privacy instruction data: ciphertexts, commitments, nullifiers, keys and metadata	418
Six account addresses × 32 bytes	192
One Ed25519 signature	64
Recent blockhash	32
Version, message header, config mask and counts	10
Compute-unit and loaded-account-data limits	8
Instruction header	4
Seven instruction account indices	7
Total	927

For the spec’s 2-input, 3-output confidential transfer example. View source code: Spec · xtask/src/main.rsSee the Solana v1 transaction layout.

​

RPC

A single Helius RPC URL makes the Solana RPC, indexer, and a remote prover available.

• Solana RPC – Returns the public balance and submits transactions to the Solana network.
• Indexer – The indexer serves the encrypted state a wallet needs to read balances and build private transactions; anyone can also run their own indexer permissionlessly as a fallback.
• Prover – Zero-knowledge proofs can be generated locally or by a prover server in milliseconds, depending on the transaction and hardware. Helius uses GPU proving.

For custom Rings, optional features include an optional Ring RPC to serve decrypted balances and history using a shared viewing key or a configured Ring auditor key. Additionally, anonymous transactions use a relayer so the user does not appear as the transaction fee payer.

​

Privacy and Solana Programs

The Solana Privacy Program (SPP) is the main program that verifies and executes all private state transitions. Custom Ring programs and ZK Solana programs add compliance or application logic, then invoke SPP to update private state. Other Solana programs can interact with these programs through CPI in the same transaction, within Solana’s transaction limits, such as the CPI depth limit of 5.

ZK Program Transaction Flow

• Permissionless Ring
• Custom Rings

• ZK Program alone
• ZK Program and additional Solana Program

• ZK Program alone
• ZK Program and additional Solana Program

​

Solana Privacy Program (SPP)

The Solana Privacy Program verifies zero-knowledge proofs and updates private state. Use it to deposit tokens, transfer private balances, and withdraw tokens to public accounts. Other programs invoke SPP through CPI to execute private state transitions.

​

Custom Ring Program

A Custom Ring program defines transfer permissions and any additional authorities, similar to Token-2022. Use it to configure auditors, require a co-signer, or allow an authority to freeze balances. It verifies a ZK proof to enforce its custom compliance logic, then invokes SPP to update private state.

​

ZK Solana Program

Zero-knowledge (ZK) Solana programs enable private escrows in Solana programs to enforce application logic over private balances. You can build private swaps, staking, lending, and more with ZK Solana programs. For example, a confidential swap can enforce the agreed amounts and price without making them public. The program verifies a ZK proof of its application logic, then invokes SPP, directly or through a Custom Ring program, to update private state.

​

State Merkle Tree and Forester

The Default Ring and all Custom Rings store private state in a state Merkle tree account, which is maintained by a Forester node. Tree accounts commit to private state without storing it in separate Solana accounts. Therefore, you read balances and transaction history with dedicated indexer RPC methods, such as getShieldedTransactionsByTags, instead of Solana account methods like getAccountInfo. See Read a Private Balance and Read Private Transaction History.

​

Throughput

The tree is stored in one writable Solana account. Private transfers that write to this account share Solana’s 12 million CU per-account write-lock limit per block. Different UTXOs can be spent independently, but transactions writing to the same tree still share Solana account locks and compute limits. A confidential transfer consumes approximately 140,000 CU in the instruction benchmark. One tree therefore supports approximately 86 private transfers per block, or approximately 215 transactions per second at current Solana block times of about 400 milliseconds. The protocol can add more trees to increase throughput. Each tree is a separate writable account with its own per-account compute budget, so transactions on different trees do not compete for the same write-lock budget.

​

SPL Interface

The SPL interface enables interoperability between publicly and privately held tokens. It is an escrow per mint, which can be created permissionlessly but must be created once per mint.

• At deposit to a private balance of SOL and SPL assets, an interface PDA owned by the Solana Privacy Program escrows tokens and creates UTXOs with the user as owner.
• At withdrawal to a public balance, existing UTXOs are marked as spent, and tokens are released to the Solana token accounts.

For mints that do not have an interface PDA yet, the first deposit can include an instruction to create the interface PDA in the same transaction.

​

Learn More

​

Didn’t find what you were looking for?