All posts
2026-05-28

Encrypted amounts are not private: hiding the number isn't hiding the link

There are two different things people mean by "private," and most tools only do the easy one. You can hide how much you sent, or you can hide who you sent it to. These are not the same problem, and solving the first does almost nothing for the second. A growing class of confidential-transfer schemes encrypts the amount on a transfer — the number is hidden, the balances are encrypted — and presents this as privacy. It is a real and useful feature. It is also the half of the problem that leaks the least information.

This post is about the other half: the link between sender and recipient, which amount-encryption leaves completely intact.

What an encrypted amount actually hides

Picture a normal Solana transfer with the amount blanked out. An observer still sees: wallet A sent something to wallet B, at this timestamp, in this token. The graph edge is there. The two addresses are there. The timing is there. The only thing missing is the figure in the amount field.

For a lot of real-world deanonymization, the figure is the least valuable piece. If an investigator, a counterparty, or a curious stranger can already see that your wallet pays a specific recipient every two weeks, they have your relationship, your cadence, and — by cross-referencing other public transfers — usually a good estimate of the amount anyway. Encrypting the number raises the effort slightly. It does not break the connection.

And on a transparent ledger, the connection is the sensitive part. Your counterparties, your payroll, your trading relationships, the fact that wallet A and wallet B are the same person — those are graph properties, not amount properties. They survive amount-encryption untouched.

The thing that actually has to disappear: the edge

Privacy on a public chain is fundamentally about the graph, not the labels on the edges. To get real unlinkability you have to remove the edge itself — make it so that no observer can draw a line from where funds went in to where they came out.

That requires a shielded pool. Many people deposit behind cryptographic commitments; each later withdraws using a zero-knowledge proof that asserts "I own one of the unspent deposits in this pool" without revealing which one (/learn/how-zk-proofs-work). The deposit and the withdraw are two separate transactions with no edge between them. The observer sees a deposit from wallet A and an unrelated withdraw to wallet B and genuinely cannot tell whether they're the same person — because the math that would let them tell was never published.

Note what changed. It isn't that the amount is encrypted. It's that the connection is gone. That's a structurally harder thing to build — it needs a Merkle tree of commitments, a nullifier scheme to prevent double-spends, and a real proving system (/glossary/shielded-pool, /glossary/nullifier) — which is exactly why amount-encryption is the more common offering. It's the easier engineering problem.

"But everyone uses the same amounts" — why the pool still needs care

Breaking the edge is necessary but not automatically sufficient, and this is where amounts come back into the story — from a completely different direction. Inside a shielded pool, the danger isn't that your amount is visible; it's that your amount is distinctive. If every deposit in the pool is roughly 0.5 SOL and you deposit 47, then when 47 comes back out the math points at you regardless of how good the proof was. The proof hides which note you spent; an outlier amount narrows the suspect list to one anyway.

So in a shielded pool the goal is the opposite of encryption: you want your amount to look like everyone else's. Deposit and withdraw in amounts that match the crowd, in round figures, and you blend into the largest possible set. /blog/anonymity-sets-on-solana works through exactly how amount bands shape who you hide among. This is a more honest treatment of amounts than encryption gives you: the number isn't the secret, the similarity to others is the protection.

A quick way to tell which kind of "private" a tool offers

Ask one question: after I use it, can an observer still see that my wallet is connected to the recipient?

  • If the answer is "yes, but they can't see how much" — it's amount privacy. Useful for hiding balances and payment sizes; useless for hiding relationships.
  • If the answer is "no, the connection itself is gone" — it's link privacy, which is what a shielded pool provides.

Most things sold as confidential transfers are the first kind. For the threat models people actually care about — not wanting a counterparty to map your treasury, not wanting a recipient to see your whole net worth, not wanting your payroll graph to be public — you need the second.

Where to go next

If you want to see link privacy in practice, /blog/sending-sol-without-revealing-your-main-wallet is the step-by-step. If you want the honest boundaries — what even link privacy doesn't fix — /learn/what-solmask-cannot-protect-you-from is the unvarnished list. And /compare lays out how different designs in this space actually differ.

FAQ

Q. Isn't encrypting the amount still better than nothing? A. Yes, for the narrow goal of hiding balances and payment sizes. Just don't mistake it for unlinkability — it leaves the sender, recipient, and timing fully public, which is usually the information people actually wanted to protect.

Q. If a shielded pool breaks the link, why does it care about amounts at all? A. Because an unusual amount re-identifies you by elimination even when the proof is perfect. Inside a pool you want your amount to resemble the crowd, not to be hidden. It's the inverse of amount-encryption.

Q. Does SolMask encrypt amounts too? A. SolMask hides the link, which is the harder and more valuable property. Deposit and withdraw amounts are part of how you blend in, so the guidance is to match the crowd rather than to stand out. See /blog/anonymity-sets-on-solana.

Q. Can I get both — hidden amounts and a broken link? A. Link privacy is the property that defeats graph analysis, and it's what to prioritize. Combine it with good amount hygiene (round figures, match peers) and a fresh recipient address and you've covered what amount-encryption alone can't touch.

Encrypted amounts are not private: hiding the number isn't hiding the link · SolMask