Solana's ledger can now conceal how much money moved between two parties — but not who those parties are. That is the central trade-off of Privacy Rings, the confidential-transfer system that Solana infrastructure provider Helius announced on November 10 in its launch post.

The permissionless default Ring operates as a shielded pool: encrypted balances live on Solana's own ledger, transfers settle in ordinary Solana transactions, and zero-knowledge proofs verify each move. Three products have already adopted it — Decrypt, which uses confidential transfers in its money account; the Ore mining and staking app; and Aurora Intents, which delivers assets from other chains straight into a confidential balance.

For wallets that never opt in, nothing changes. An existing Solana address keeps its public history, and privacy begins only when funds are moved into a private balance — and even then, only for the fields the Ring is designed to encrypt. Which fields those are, and who can still read them, determines how much protection the system actually provides.

Payments to unprepared recipients take the public route

The detail most likely to catch a payroll or treasury team off guard appears in Helius's product FAQ: when the recipient of a payment has no Private Wallet, the Privacy API turns the payment into a withdrawal to the recipient's public address. The money arrives, but on the public route, where the asset and amount are visible to anyone.

Helius's transfer guide explains why the fallback exists. A private transfer is addressed to a shielded address — a bundle of signing, nullifier and viewing keys that the recipient publishes in a registry record — and the encrypted output is locked to that recipient's viewing key. Someone who has never registered one has no private balance for the funds to land in. Helius's landing page is accurate when it says recipients do not need a special wallet to receive funds; it is the privacy of that receipt, not the receipt itself, that depends on the setup.

For an application, this makes the recipient's status part of the payment screen. A sender who sees a familiar Solana address and assumes the amount will be encrypted could be approving a public transfer. The sensible design is to show which route will execute before the signature is requested, and to make the public route an explicit choice rather than a silent default. Helius is building an embedded private wallet that holds both balance types for exactly this reason, and says Backpack, Squads, Jupiter, DFlow and Titan are among the teams working on integrations. Until a recipient's wallet supports private receipt, the fallback is the route their payments take — which makes the rollout of those integrations the practical gate on how much of a payment flow can stay on the encrypted route.

What the chain still shows on the private route

Even when both sides are fully set up, the default Ring is confidential rather than anonymous. Helius's guides lay out the visibility of each step, and the pattern is the one a chain analyst would expect: the ends of the journey are public, the middle is encrypted.

• Deposit — public: depositing address, asset, amount; encrypted: the private balance that results.
• Private transfer — public: sender and recipient addresses, fee payer; encrypted: asset, amount, optional memo.
• Withdrawal — public: withdrawing address, destination, asset, amount; encrypted: whatever private balance remains.

The breakdown draws on Helius's deposit, transfer and withdrawal guides for the default Ring, and covers direct onchain visibility only; inference from other records is a separate question.

Consider a company that funds payroll from a treasury wallet already linked to its name. Moving 30,000 USDC into a private balance publishes that figure on the deposit. The salary transfers that follow hide each amount, so no one can read an individual pay packet off the ledger. What they can read is the shape: a known corporate address paying the same dozen addresses on the same day each month. If any of those recipients has ever been tied to a person, the encrypted amount is the only thing standing between that pattern and a salary estimate — and the estimate narrows the moment an employee withdraws to a public balance, because the withdrawn amount is visible. A recurring recipient could just as easily be a supplier, so the chain never proves employment, but narrowing possibilities is precisely what analytics firms sell. Coindoo traced the same identity trail in its coverage of COTI's approach to private payments.

Two smaller details sharpen the picture. The fee payer on a private transfer is a public Solana address, and Helius allows a gas sponsor to cover it — which means a company sponsoring fees for staff is signing its name to every transaction even when it is not the sender. The memo field, if used, is encrypted along with the amount, so an invoice reference travels privately while the two addresses exchanging it do not.

Who can read the amount besides the chain

Encrypting a field onchain settles what the public sees. It says nothing about who the user has let in. Helius's encryption documentation separates the question into layers, and the layer a business actually negotiates is the middle one: delegated access.

• Counterparty — sees the transaction they were part of; receiving a payment opens nothing else in the sender's wallet.
• Delegated viewing key — a provider the user authorizes can read balances and history, but cannot move funds.
• Transaction viewing key — discloses one transaction only, such as an invoice to an auditor without the rest of the ledger.
• Ramp provider — a fiat on- or off-ramp keeps the onchain leg encrypted but handles the bank side and knows its details.

By default the viewing key stays on the user's device and decryption happens locally; Helius generates proofs and relays transactions but never holds keys. Delegation is the point at which a company's accountant, treasury software or reconciliation service gets a copy of that key. The practical consequence is a cleaner split than most finance teams get from a bank: a bookkeeper can be given full read access to a private ledger with no ability to approve a payment, and a counterparty can be shown a single line of it. The flip side is that every delegation is a standing disclosure, so a business that hands viewing keys to several vendors has quietly rebuilt the audience it was trying to shrink.

How this differs from Solana's existing confidential transfers

Solana already offers amount-hiding through the confidential transfer extension in Token Extensions, so the question of what Rings adds is fair. The extension works per token: an issuer enables it on a mint, and holders of that mint can shield balances and transfer amounts, while the token itself and the counterparties remain visible. Rings operate as a pool that accepts SOL, SPL and Token-2022 assets without the issuer's involvement, encrypt the asset as well as the amount, and expose private balances to other programs through cross-program invocations — the mechanism Helius proposes for private escrows, swaps and collateral. Both approaches leave the two addresses in the open; Rings widen what sits between them.

Custom Rings and the audits

Address-level anonymity is on the roadmap, not on mainnet. Helius's Custom Rings documentation describes institution-run Rings that can be configured as confidential, like the default, or anonymous, with sender and recipient encrypted and transfers submitted through a relayer. Each adds an auditor key with read access under a policy the institution sets, plus onchain allowlists, blocklists, freezes and extra signature requirements. Transfers across Rings follow the source Ring's rules and can combine a default-Ring balance with one Custom Ring in a single transaction. Helius puts the targeted mainnet release in Q4 2026, with audits still in progress.

The live default Ring has been through three independent audits by Certora, ZK Security and OtterSec, and the trusted setup for its circuits was run by engineers from the Solana Foundation, Blueshift, Zcash, Certora, OtterSec and ZK Security. Multi-party setups of that kind are a standard safeguard in zero-knowledge systems — the parameters are generated jointly, so no single participant holds what it would take to forge proofs alone — and Zcash's presence on the list is worth noting, since that project pioneered shielded pools on a public blockchain. Formal verification of the programs and circuits is underway, with Helius expecting completion by the end of 2026. Together with the Q4 2026 Custom Rings target, that makes 2026 the year to watch for the roadmap's two remaining milestones: address-level anonymity and formal verification.

Three questions before signing

A Privacy Rings payment is private along exactly three dimensions, and the sender controls only one of them. Which route the payment takes is decided by the recipient's wallet. Which addresses appear is decided by the chain. Who else can decrypt the amount is the sender's call, through the keys they choose to delegate.

Any application built on Rings should answer those three questions on the confirmation screen: private route or public withdrawal, which fields stay visible, and who already holds a viewing key. Hiding an amount is useful. Knowing precisely what remains visible is what makes the hiding worth relying on.