Skip to content
CLOAKS

Knowledge center

How on-chain privacy
actually works.

Each explainer answers four questions: what it protects, what can remain visible, who must be trusted, and where to learn more. Sources are official documentation — research references, not CLOAKS partners.

13 entries

Explainer

Public addresses are not anonymity

An address is a pseudonym. Every payment, balance and interaction tied to it is public and permanent, so one link to your identity can unlock its whole history.

What does this protect?
On its own, nothing beyond not printing your name on-chain.
What can remain visible?
Balances, counterparties, amounts, timing, app interactions and any links made by exchanges, ENS-style names or reuse.
Who must be trusted?
Anyone who can link the address to you — exchanges, merchants, apps, analytics firms.

Explainer

Zero-knowledge proofs

A zero-knowledge proof convinces a verifier a statement is true without revealing the data behind it. It is a building block, not a privacy mode: an app using ZK can still publish plenty.

What does this protect?
Only the specific private inputs of the statement being proved.
What can remain visible?
Everything the app chooses to publish, plus who submitted the proof, when, and any public inputs.
Who must be trusted?
Circuit correctness, the proof system's setup (some need a trusted setup), and the app's design.

Explainer

Shielded balances and transfers

Shielded pools hold funds as encrypted notes. Transfers inside the pool are validated with proofs, so balances and counterparties inside the pool are hidden from the public.

What does this protect?
Balances and transfers that stay inside the pool.
What can remain visible?
Deposits (shielding) and withdrawals (unshielding) — their addresses, amounts and timing — plus metadata from relayers or RPCs.
Who must be trusted?
The pool's contracts and circuits, any trusted setup, and services such as broadcasters that submit transactions.

Explainer

Stealth addresses

ERC-5564 is an Ethereum/EVM standard: a sender derives a fresh one-time address for the recipient from their stealth meta-address and publishes an announcement the recipient can scan. It is not a native Solana feature.

What does this protect?
The public link between the recipient's known identity and the address that received funds.
What can remain visible?
The sender, the amount, the announcement, and how the recipient later funds gas or combines those addresses.
Who must be trusted?
The cryptography and the recipient's scanning tools; careless spending can relink addresses.
Where can I learn more?

Explainer

Confidential token amounts

Solana's Confidential Balances (a Token-2022 extension) encrypts token balances and transfer amounts. Proofs are checked by the ZK ElGamal Proof Program.

What does this protect?
Token balances and confidential transfer amounts.
What can remain visible?
The mint, token accounts, account owners and transaction participation remain public.
Who must be trusted?
The token programs; and, if the mint configures one, an auditor key that can decrypt transfer amounts (not full balances, and it cannot move tokens).

Explainer

Fully homomorphic encryption

FHE lets programs compute on encrypted data. Zama's protocol runs FHE off the host chain via coprocessors and uses threshold decryption, with contracts defining who may decrypt what.

What does this protect?
Encrypted inputs and contract state, as defined by each contract's access rules.
What can remain visible?
That a contract was called, by which address, and when; anything the contract allows to be decrypted.
Who must be trusted?
The parties holding shares of the decryption key, the coprocessors, and the application's access-control logic.

Explainer

Selective disclosure and viewing keys

Sharing selected records reveals only what you choose. A viewing key is broader: in RAILGUN it lets the holder read interactions for an address (optionally within a block range) — but never spend. Viewing and spending are different permissions.

What does this protect?
Spending authority stays with you when you share view access.
What can remain visible?
Anything you share — and once copied, it cannot be revoked. A viewing key can expose an entire scoped history.
Who must be trusted?
Whoever receives the records or key.

Explainer

App, browser and RPC metadata

Even with strong on-chain privacy, the services you use observe you: RPC providers see IP addresses and queried accounts, apps log sessions, browsers leak fingerprints.

What does this protect?
On-chain privacy tools do not protect this layer by default.
What can remain visible?
IP address, device, timing, accounts you query and apps you connect to.
Who must be trusted?
RPC providers, wallet and app operators, analytics vendors, and your network.

Explainer

Deposits, withdrawals and bridges

The edges of any privacy system are public. Depositing and withdrawing similar amounts close in time links them. Bridges and intent solvers see both legs of a cross-chain move.

What does this protect?
Only activity between entry and exit.
What can remain visible?
Entry and exit transactions, amounts, timing, and bridge records on both chains.
Who must be trusted?
Bridge operators, relayers and solvers, and the size of the crowd you blend into.

Field note

Field note: the CLOAKS concept

CLOAKS explores privacy in layers: value, identity, activity and disclosure. An open network should not mean every balance and relationship is readable by anyone.

Field note

Field note: what isn't included

There is no live privacy protocol, token, wallet connection, encrypted balance, relayer, or security audit. Simulations never move funds or broadcast transactions.

Field note

Field note: what production privacy requires

A defined threat model, reviewed cryptography, independent security testing, and clear disclosure of metadata risks such as timing, deposits and withdrawals.

Field note

Field note: your safety

CLOAKS never asks for private keys, seed phrases, personal information or real wallet addresses. Anything claiming to be CLOAKS that does is not us.

Glossary

Shielding
Moving funds from a public address into a privacy system. Usually a public transaction.
Unshielding
Moving funds out of a privacy system to a public address. Usually a public transaction.
Note
An encrypted record of value inside a shielded pool.
Nullifier
A unique tag that marks a note or vote as used without revealing which one.
Viewing key
A key that can read activity but cannot spend.
Spending key
The key that authorises moving funds. Never share it.
Stealth meta-address
Public information a sender uses to derive a fresh address for a recipient.
Auditor key
An optional key (e.g. on a Solana confidential mint) that can decrypt transfer amounts.
Anonymity set
The crowd of possible senders or recipients you blend into.
RPC provider
The service your wallet queries to read and submit transactions.