SOLSTACKBlog
← All guides

Token Creation & Minting

Confidential Transfers on Solana: How They Actually Work

Token-2022's confidential transfer extension hides transfer amounts using zero-knowledge proofs while keeping sender and receiver public — here's the actual mechanism and its real limitations.

2026-09-23·6 min read·Verified against mainnet-beta

Solana is a fully public ledger by design — every balance, every transfer amount, every account is visible to anyone. Token-2022's confidential transfer extension is the one mechanism that pushes back against that, hiding amounts while deliberately keeping everything else public. It's one of the more advanced and least-understood extensions in the Token-2022 spec.

What actually stays private, and what doesn't

Confidential transfers hide the amount moved in a transfer. They do not hide:

  • Who sent and who received — both addresses remain fully public, exactly like any other Solana transaction.
  • That a transfer happened at all — the transaction itself is visible on-chain, timestamped, linked to both accounts.
  • The existence or ownership of the token account — only the balance and transfer amounts inside it are encrypted.

This is a narrower privacy guarantee than something like a fully shielded pool. Think of it as "confidential amounts on an otherwise public ledger," not anonymity.

The mechanism: encrypted balances and zero-knowledge proofs

Under the hood, balances and transfer amounts are stored using ElGamal encryption, a form of additive homomorphic encryption — meaning encrypted amounts can be added and subtracted without ever being decrypted, which is exactly what a transfer needs (subtract from sender, add to receiver) without revealing either number to the validators processing it.

To prove a transfer is valid without revealing the amount — that the sender isn't spending more than their encrypted balance holds, and that the amounts add up correctly — the extension uses zero-knowledge range proofs. These are cryptographic proofs that a hidden number satisfies certain properties (like "this decrypts to a non-negative value within a valid range") without revealing the number itself. Generating and verifying these proofs is computationally heavier than a normal transfer, which is part of why confidential transfers aren't the default.

Why this extension is rarely seen in the wild

A few real constraints keep confidential transfers uncommon compared to the other Token-2022 extensions:

  • Client complexity. A wallet needs to manage encryption keys separately from the account's normal signing key, and needs specific support for generating and verifying the zero-knowledge proofs — this isn't automatic in most wallets yet.
  • Compute cost. The proof generation and verification add real transaction size and compute budget overhead compared to a plain transfer.
  • Auditability tradeoffs. Regulated use cases (exchanges, custodians) generally need to be able to see transaction amounts for compliance — confidential transfers are often a poor fit for exactly the institutions that might otherwise want token infrastructure.

Where it's actually useful

The clearest fit is payroll or business-to-business transfers, where the parties involved don't want transfer amounts visible to every competitor and observer, but don't need to hide who's transacting with whom. It's a narrower and more deliberate tool than general "privacy coin" framing suggests.

Tooling support today

This is one of the least commonly exposed Token-2022 extensions in consumer-facing creator tools, Solstack included — building a confidential-transfer mint requires wallet-side support for the encryption and proof flow that most wallets, including the major Solana wallets as of today, don't yet fully implement end-to-end. If you're evaluating this extension for a real use case, the current state is closer to "usable with custom tooling and a specific wallet setup" than "click a checkbox in a token creator."

For the Token-2022 extensions Solstack's creator does build today — transfer fee and interest-bearing — see the Token-2022 concepts doc or the Token-2022 Creator.