Confidential Transfers on Solana: What's Native, What's Helius Rings, and What's Actually on Mainnet

On September 7, Helius posted a demo: make a confidential transfer on Solana, right now. The question that followed it around was whether this is the native feature Solana shipped in 2025 — the one that spent a year switched off — or something new.

It is something new. Solana Rings is Helius's own protocol, built by the Light Protocol team it acquired in June, and it runs on devnet only. The native feature — the confidential transfer extension in Token-2022 — is also back, re-enabled on mainnet in June after five audits, and almost nobody has noticed. Two designs now share a name. They hide different things, put their trust in different places, and sit at very different stages.

This post takes both apart: how each one works, what each still reveals, what happened during the year the native one was off, and what the chain says is live today. Every figure was read from a primary source — the Helius documentation and source code, the Solana and Anza documentation, the post-mortem and the audit records, and mainnet itself — on September 9, 2026. The read dates are at the end, because a status that is true in September is a lie by November.

Two Designs That Share a Name

Strip the branding away and the two are unrelated constructions that happen to solve for the same headline.

The native extension encrypts balances in place. A Token-2022 account that opts in keeps its balance as a ciphertext instead of a number. A transfer moves ciphertext from one account to another, and a set of zero-knowledge proofs shows the arithmetic is consistent — the sender had enough, nothing was created, the amount is in range — without revealing the amount. The accounts themselves stay public. Who paid whom is on the ledger; how much is not.

Rings is a shielded pool. Your balance is not a field on an account at all. It is a set of encrypted notes — unspent transaction outputs, the Bitcoin-style kind — sitting in a Merkle tree owned by a Helius-deployed program. A transfer spends some notes, publishes a nullifier for each so they cannot be spent twice, and creates new notes for the recipient, with a proof that the books balance. Because a note has no owner field anyone can read, this design can hide the sender and the recipient as well as the amount — when it is configured to.

The consequences fall out of that one difference. Encrypting balances in place keeps every existing account, wallet address and token standard; it cannot hide the graph. A pool hides the graph; it needs its own state tree, its own key material, a registry to find recipients, and an indexer to read your own balance. Side by side:

How the Native Extension Actually Works

Confidential transfers are one of Token-2022's mint extensions, so the first fact about them is the least advertised: the token issuer opts in, once, at creation. The Solana documentation puts it plainly — "Most extensions can't be added after an account is initialized." A token that already exists cannot grow a confidential mode, and a legacy SPL token cannot have one at all. Every stablecoin that will ever support this either shipped with the extension or will need a new mint.

On a mint that did opt in, a holder configures their own token account for confidential use. That step derives two keys the wallet must keep: an ElGamal keypair for the encrypted balance, and an AES key for a private copy of the same balance that the owner can decrypt quickly. The configuration carries a proof that the public key is well-formed, and from then on the account has two balances the program tracks separately.

• Pending and available. Anything sent to you lands in a pending balance; you fold it into your available balance yourself, with an apply instruction, when you are ready to spend. The split exists so that someone paying you cannot invalidate a transfer you are in the middle of proving. A counter caps how many credits can pile up before you must apply — the documented default is 65,536.
• Amounts are capped at 48 bits. Decrypting ElGamal gets slower as the number grows — the documentation notes that a 32-bit value already takes seconds — so a transfer amount is split into a 16-bit low part and a 32-bit high part, and cannot exceed 2⁴⁸ base units. For a six-decimal token that is about 281 million tokens per transfer; for a nine-decimal token, about 281 thousand.
• Three proofs, three transactions. A transfer needs a ciphertext-validity proof, an equality proof and a range proof. The reference flow in the Solana docs stages them in context-state accounts across three transactions, because "the three proofs are too large for one transaction." Verification runs in a program built into the validator — the ZK ElGamal proof program — which is the piece that was switched off in 2025.

Two more details matter for anyone designing around it. The mint can carry an auditor key — an ElGamal public key that can decrypt every transfer on that mint, read access and never spend access — which is the hook for regulated issuers. And an account holding a confidential balance that is not provably zero cannot be closed. The program will not release the account's rent deposit until the owner empties it with a proof, which is why xroot's rent-reclaim scan lists such an account with the reason it cannot be closed, rather than trying and failing.

The Year It Was Switched Off

Confidential transfers reached mainnet in April 2025 and were off by June. The reason is worth understanding, because it is the same class of mistake any team building on zero-knowledge proofs can make.

The extension's fee logic uses a sigma OR-proof — a way of proving that an encrypted fee is either a fixed percentage of the amount or exactly the cap, without saying which. In an OR-proof the prover supplies part of the challenge itself. The Solana implementation never hashed that prover-supplied value into the Fiat–Shamir transcript, so a malicious prover could choose it after seeing the rest of the transcript and forge a proof that verified. A researcher at zkSecurity reported it on June 10, 2025, with a proof of concept; the fix was one line — append the missing scalar to the transcript. Exploited, it would have let an attacker zero out a fee, burn tokens from a receiver, or mint tokens to the fee authority. Nobody did: the post-mortem records no known exploit, and no meaningful volume was moving through the feature.

The response was fast and layered. Token-2022 was redeployed without the confidential instructions on June 11. Validators were asked to upgrade on June 13. On June 19, at the start of epoch 805, a feature gate disabled the proof program itself. Then the slow part began — five independent reviews of the proof program, the SDK and the extension code:

The maintainers' target was January 2026. The re-enable gate was live on testnet and devnet by April, the rebuilt Token-2022 followed there in May, and on June 29 a contributor wrote "this is live on mainnet" on the tracking issue, which was closed on September 3. The chain agrees. The feature account for reenable_zk_elgamal_proof_program records activation at slot 424,224,000 — the first slot of epoch 982, which works out to early June 2026 — and the Token-2022 program's own upgrade record shows its last deployment at slot 427,147,035, about two weeks later.

Live is not the same as used. On September 9 we read the proof program's recent history from a public RPC node that keeps roughly the last four days. It appeared in four transactions, all within two minutes of each other on September 7; the three we could decode came from a single wallet and touched no token program at all — someone creating and closing proof-related accounts, which looks like a developer testing the plumbing. Whatever demand there is for the native feature, it has not reached mainnet yet.

What Rings Is, Mechanically

Rings comes from a specific lineage. Light Protocol built ZK compression on Solana and wrote the Poseidon-hash and BN254 pairing syscalls that make cheap on-chain proof verification possible. Helius acquired the team on June 10, 2026, announced Rings on August 7, and published the source as zolana under Apache-2.0, tagged alpha. The on-chain layer is called the Solana Privacy Protocol; the SDKs are @heliuslabs/zolana for TypeScript and zolana-client for Rust. The proving stack in the repository is gnark, the Go framework Light used for compression, with proofs verified on-chain through the pairing syscall.

The user-facing object is a Private Wallet, and the design choice that makes it usable is that it keeps your ordinary Solana address as its inbox. A sender types the address they always would. Under the hood the wallet holds a second bundle of keys — a signing key (your Ed25519 key in confidential rings, a separate P-256 key in anonymous ones), a nullifier key that marks notes as spent, and a P-256 viewing key that decrypts what is yours, on their own derivation paths. The public halves are published in an on-chain registry, one record per address. That is how anyone can check whether an address can receive private transfers — and, incidentally, a public list of who has opted in.

• State. Notes live in one state Merkle tree — a single writable account shared by the permissionless Default Ring and every custom ring. Note contents are encrypted to the recipient's viewing key with HPKE, an ECDH key agreement feeding AES-GCM, so only the owner, or someone holding their viewing key, can read an amount. Spent notes go into a separate nullifier tree. A note needs no rent deposit.
• Entry and exit. A deposit hands tokens to an interface account owned by the privacy program, which creates notes in return; a withdrawal reverses it. The asset can be SOL or any SPL or Token-2022 mint — no issuer opt-in, which is the sharpest practical difference from the native extension.
• Throughput. A private transfer costs about 220,000 compute units, and every transfer writes the same tree account, so they share Solana's 12-million-unit per-account limit in each block: roughly 54 private transfers per block, about 130 per second at 400-millisecond blocks, per tree. More trees can be added.
• Rings. The Default Ring is permissionless and confidential: asset and amount are hidden, sender and recipient are not. A Custom Ring is a policy program that runs before the privacy program on every transfer — allowlists, transfer limits, co-signing above a threshold, freeze and thaw, a permanent delegate, an auditor who can read everything in the ring. An anonymous custom ring hides sender and recipient too, by having a relayer submit the transaction and pay its fee.

None of this is a rollup or a sidechain. A private transfer is one Solana transaction, and a Solana program can own notes and use them in an escrow or a swap inside that same transaction. That is the real engineering claim, and the source backs it up. What the source does not settle is governance: the devnet deployment is an ordinary upgradeable program, and nothing we found says who will hold the upgrade authority on mainnet, or whether it will be frozen.

Where the Plaintext Goes Today

The privacy of a zero-knowledge system is only as good as the place the proof is built, because building a proof requires the secrets. The Rings documentation is candid about where that is right now:

Read that as an engineer. Today, when the demo says proving, your wallet sends the recipient, the asset, the amount and your nullifier keys to a Helius server, which returns a proof. The chain sees ciphertext; the RPC vendor sees everything. That is a straightforward beta trade-off — the team says local proving is coming and proving time is still being optimized — but until it lands, the privacy is from the public ledger, not from the operator. The native extension makes the opposite trade: its proofs are built in the client library, at the cost of three transactions and a wallet that has to run the code.

Two more places hold plaintext by design. In delegated decryption the wallet shares its viewing key with the RPC provider, which can then read balances and history but not spend; it is optional in confidential rings and the only mode in anonymous ones, so the ring that hides you from the ledger also requires a provider that can see you. And the Embedded Private Wallet — not live yet — has a wallet provider hold the shielded keypair and run its operations in the provider's infrastructure. Reading a balance at all depends on an indexer that serves encrypted state; Helius runs one, and the docs say anyone can run their own as a fallback.

None of this is hidden; all of it is in the documentation. It is the difference between what the cryptography can do and what the deployment does today, and it is the list to check off before trusting the mainnet release: local proving, a published upgrade authority, and a decryption mode that does not route through the vendor.

What Is Actually on Mainnet Today

Announcements describe intentions. Accounts describe state. On September 9, 2026, at 04:17 UTC, the two states were these:

The devnet number is the beta doing what a beta does — a demo anyone can drive, plus partners integrating — and says nothing about adoption. The mainnet absence is the fact that matters: there is no Rings program to call on mainnet, so anything described as a private transfer on Solana mainnet this week is either the native extension or is not on Solana. The Helius docs open with their own warning — "Helius Privacy is in beta… Names, endpoints, and behavior may change" — and the timeline has already moved once, from August to a two-month window.

What Each One Still Reveals

"Confidential" is a claim about specific fields. Here is what stays public under each design, because that is the list a compliance team or an adversary works from.

• Native extension. The sender's and recipient's token accounts, the mint, and the fact that a confidential transfer happened are all on the ledger; only the amount and the resulting balances are encrypted. Moving money into or out of the confidential balance — the deposit and withdraw steps — carries a plain amount. An auditor key, if the issuer set one, decrypts every transfer. Graph analysis works exactly as it does on a public token.
• Rings, Default Ring. Asset and amount are hidden inside the ring; the source private wallet and the recipient are visible. A deposit from a public wallet reveals source, asset, amount and destination — the docs recommend on-ramping fiat straight into the ring for exactly that reason — and a withdrawal reveals destination, asset and amount. The registry record announces that an address can receive private transfers.
• Rings, anonymous ring. Sender and recipient are hidden from the ledger by the relayer, but the ring's policy program is invoked publicly on every transaction, so the fact that someone transacted in that ring is not. Delegated decryption is mandatory, so the provider sees your balances and history; an auditor, if the ring has one, sees everyone's.
• Both. Timing is public in both: a deposit followed by a withdrawal of a similar size a minute later is linkable by anyone with a block explorer, and Rings' single shared tree means every ring draws on one anonymity set. Neither system hides the transaction fee, the block time, or the program that was called.

If You Are Building on This

• Token issuers. The native extension is a decision at mint time. If your token might ever need encrypted amounts — payroll, treasury, B2B settlement — and its holders will use wallets that can run the proof code, enable the extension when you mint and keep an auditor key you control. Rings needs no decision from you at all, since any mint can be deposited; your holders' privacy then depends on Helius's mainnet release and its proving model.
• Wallet teams. Native support means deriving two keys from the seed, running client-side proving, handling the pending-balance apply step in the UI, and refusing to let a user close an account that still holds a confidential balance. Rings support means a second key bundle on its own derivation paths, a registry lookup on every send, an indexer dependency, and a UI that labels a transfer to an unregistered address as the public withdrawal it becomes.
• Payments and fintech. The custom-ring feature list — allowlists, limits, co-signing, freeze, auditor visibility, managed screening — is aimed squarely at you, and it is more than the native extension offers. Weigh it against the fact that it is one vendor's program, in beta, with server-side proving, and no mainnet date anyone has committed to.
• Holders. Today, on mainnet, the only confidential transfer you can make is on a Token-2022 mint whose issuer opted in, in three transactions, with the amount hidden and your address not. The flow lives in the Rust and TypeScript client libraries; check your wallet before assuming it has a button for it. That is the whole menu until Rings ships.

For what it is worth, xroot does not offer either — and the reason is the theme of section 05. Every operation on the platform is a transaction your wallet signs and nothing else. Building a confidential transfer for you would mean holding the keys that decrypt your balance, or running the prover that sees your plaintext, and that is the line the product exists to stay behind. Where the extension does touch the tools is the rent-reclaim scan, which lists an account holding a confidential balance with the reason it cannot be closed, instead of quietly leaving it out.

The Questions People Actually Ask

Two Privacies, One of Them Real Today

Solana now has a native way to hide how much and a vendor's way to hide who — and only the first exists on mainnet. The native extension is quietly back, quietly capable, and quietly unused, because it asks issuers to decide at mint time and wallets to do real cryptography. Rings is the more ambitious design, with some of the more candid documentation you will read this month, and its own pages tell you what to wait for: local proving, a mainnet program, and an audit trail with names on it. Until then, treat "confidential transfer on Solana, right now" as true on devnet, and as a question on mainnet.

Sources, all read on September 9, 2026: the Helius Privacy documentation — overview, concepts, wallet integration, custom rings and addresses — and the zolana repository; the Solana docs on the confidential transfer extension, the transfer flow and extensions; the encryption and proof design notes; Anza's proof program reference; the April 2025 launch coverage, the June 2025 post-mortem and zkSecurity's write-up; the re-enable tracking issue and the Code4rena contest; the Agave feature-gate list; Solana Compass and Genfinity on the Rings announcement; and epoch 1,000 for the epoch-to-date conversion. Mainnet and devnet state was read through public RPC nodes: the feature-gate accounts, the Token-2022 program-data account, the Rings program addresses, and recent signatures for the proof program.

xroot.dev is not affiliated with, endorsed by, or sponsored by Helius Labs, Anza, or the Solana Foundation. Product names are used only to identify the systems discussed.