Solana Can Now Hide Amounts But Not Who Paid Whom

Key Takeaways

• Payments to unprepared recipients become public withdrawals.
• Viewing keys can be shared without spending rights.
• Sender and recipient addresses stay visible onchain.
• Institutional Custom Rings are targeted for Q4 2026.

Helius’s November 10 announcement describes the permissionless default Ring as a shielded pool whose encrypted balances live on Solana’s own ledger and whose transfers settle in ordinary Solana transactions, verified by zero-knowledge proofs. Three products are already using it: Decrypt for 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.

Nothing changes for a wallet that doesn’t opt in. An existing Solana address keeps its public history; 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, is what the rest of this piece sets out.

A private transfer needs a recipient who can receive one

The detail most likely to catch a payroll or treasury team off guard is 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.

The 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 don’t 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 with both balance types for exactly this reason, and says Backpack, Squads, Jupiter, DFlow and Titan are among the teams working on integrations, but until a recipient’s wallet supports private receipt, the fallback is the route their payments take.

What the chain still shows on the private route

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

Step 1 · Deposit

Public: depositing address, asset, amount

Encrypted: the private balance that results

Step 2 · Private transfer

Public: sender and recipient addresses, fee payer

Encrypted: asset, amount, optional memo

Step 3 · Withdrawal

Public: withdrawing address, destination, asset, amount

Encrypted: whatever private balance remains

Source: Helius deposit, transfer and withdrawal guides for the default Ring. Direct onchain visibility only; inference from other records is a separate question.

Take 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 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 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 isn’t the sender. And the memo field, if used, is encrypted 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. It cannot move funds.

Transaction viewing key

Discloses one transaction only, 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, which is how Helius proposes private escrows, swaps and collateral. Both approaches leave the two addresses in the open; Rings widen what sits between them.

DeFi Liquidity Providers Can Sell Future Fees Upfront

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, 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. Formal verification of the programs and circuits is underway, with Helius expecting completion by the end of 2026.

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.