Confidential balances (planned)

Solana's Token-2022 standard ships an extension called Confidential Transfer. It encrypts SPL token amounts using Twisted ElGamal over Ristretto255 and verifies homomorphic ciphertext arithmetic via the runtime's ZK ElGamal Proof program.

v1 ships without it. on purpose.

KIRITE v1 is a fixed-denomination ZK shield pool (details). It hides the deposit-to-withdraw link and the recipient address. It does not encrypt amounts because the pool denomination already makes every deposit the same shape.

We considered building on top of Confidential Transfer and chose not to in v1 for four reasons:

• The ZK ElGamal Proof program has been unstable. It was disabled on Solana mainnet in early 2024 for a security review and re-enabled later. Building a privacy product whose core verifier could be paused at the runtime level is a fragility we did not want to ship into.
• WSOL is not a Token-2022 mint. Confidential Transfer requires the mint itself to enable the extension. Native SOL is wrapped via the legacy SPL Token program, so we would have to mint a parallel Token-2022 wrapped SOL just to use it. That adds an extra conversion step at every deposit and withdraw.
• The proof stack is heavy. Confidential Transfer requires range proofs, validity proofs, and equality proofs per send. Combined with the membership proof we already use, browser proof generation would balloon to multiple seconds. The Telegram-mobile form factor cannot absorb that.
• It does not add much in a fixed-denomination pool. Every deposit is the same advertised amount (0.01 / 0.05 / 0.1 / 1 / 10 SOL). An observer can identify the pool from the program account; encrypting a number that is already public adds little.

when we would integrate it

Once two conditions are met, we plan to layer Confidential Transfer onto KIRITE for arbitrary-amount privacy:

1. The ZK ElGamal Proof program reaches stable production status (no further runtime disables, audit-clean) for at least 6 consecutive months.
2. A widely-used Token-2022 wrapped SOL (or USDC, or both) ships in the Solana ecosystem so users do not need a custom conversion step.

preparation status

We are not waiting to start. The integration work is partly done already:

• Staking program already runs on Token-2022. Our $KIRITE staking contract was refactored to anchor_spl::token_interface when $KIRITE itself launched as a Token-2022 mint. The same refactor pattern applies to the privacy pool.
• Client SDKs are token-program agnostic. The Solana web3 helpers we use accept the token program ID as a parameter; they already drive Token-2022 calls in the staking flow today. The same code paths handle the privacy pool when the on-chain side switches.
• Privacy pool refactor is scoped, not blocked. Switching the privacy program from legacy SPL Token to token_interfaceis a roughly one-day job using the staking refactor as the reference. We deliberately did not ship it in v1 because Token-2022 wrapped SOL doesn't exist in production yet, so the upgrade has nothing to wrap today.

The moment a usable Token-2022 wrapped SOL or USDC ships and the ZK ElGamal Proof program proves stable, the on-chain upgrade is short and the client side already speaks the protocol. Until then, the v1 fixed-denomination shield pool is the right product. Mixer-style privacy is the most battle-tested approach in the ecosystem and the one whose security properties we can defend honestly.

v1 documentation

• Shield pool — Groth16 membership proof, Poseidon Merkle tree, nullifier PDA double-spend prevention.
• Stealth address — DKSAP one-time recipient address.
• Threat model — what v1 protects against and where practical privacy still depends on traffic.
• Compliance — sanctions screening, freeze response, reporting channel.