Confidential Tokens: Who Sees Amounts, What to Check
An auditor key, a permission on one value, a public reveal: three ways to show a hidden amount. Do you know which one your token uses?
IN 30 SECONDS
A disclosure mechanism is the way a hidden amount gets shown to someone: a permission on one value, an auditor key or a public reveal. Each reaches different data. This stage maps them, lists the token rules that raise privacy questions, and gives the checks I’d want before integrating.
KEY TAKEAWAYS · 3
- Per-value permissions, auditor keys and public disclosure are different mechanisms. Design and test each one against the privacy line you intend.
- List every operation the token needs before you pick a privacy mechanism. Encrypting the balance alone isn’t a full privacy policy.
- Before integrating, check that wallets and back offices read the actual amount moved, not just the transaction status.
On this page
Define who can learn which information
IN SHORT A permission on one encrypted value, an auditor key and a public disclosure are three mechanisms with three different reaches.
WORDS TO KNOW
- Ciphertext handle
- The reference a contract keeps to one encrypted value, instead of the value itself.
- Auditor key
- A key that lets one named auditor decrypt some confidential data, such as transfer amounts.
- Back office
- The internal systems that process and record transfers behind a wallet or a platform.
- Privacy threat model
- A written map of who could learn what, and how.
So write down who can ask to see a value, which past records they can see, how access changes, and how keys get recovered.
Coming up next: So which of your token’s rules need one of these?
Start with the operations, then decide what to hide
IN SHORT List every operation the token needs before you pick a privacy mechanism, because each rule raises its own privacy question.
IN PLAIN WORDS
Plan for every operation: plain transfers, partial and full freezes, forced transfers, recovery, holder limits and reports. The issuer’s special powers follow other rules than a holder’s own transfers. Test both.
If the list of who may hold the token is meant to be public, today’s address checks may still work. Hide who people are, or who is on the list, and that changes. Encrypting the balance alone isn’t a full privacy policy.
WATCH OUT
ERC-3643’s published interfaces take amounts in plain text, in the style of ERC-20. A confidential token doesn’t become ERC-3643-compatible just because it has similar controls. Write down which interface and behavior you really built.
Coming up next: So what would I want to see before plugging one in?
What I’d require before integrating
IN SHORT Before integrating a confidential token, I’d want proof that wallets and back offices read the actual result, not just the transaction status.
STEP BY STEP
Step 1. Submitted. The holder asked for an amount, before execution.
- Submitted The holder asked for an amount, before execution.
- Executed The transaction succeeded. On OpenZeppelin ERC7984Freezable v0.5.0, a request above the unfrozen balance still lands here, with an encrypted zero moved; other errors may revert instead.
- Verified An authorized party checked the actual amount, by decrypting it or through a proof.
My list for wallets and Back office The internal systems that process and record transfers behind a wallet or a platform. See the glossary, before I’d plug it in:
- a Privacy threat model A written map of who could learn what, and how. See the glossary;
- the exact library versions;
- tests on what each transfer really moved;
- a rule for who may see what;
- a drill to test recovery.
Then get the crypto of the chosen scheme reviewed. To pick the framework itself, see choosing a permissioned-token framework.
A standard interface doesn’t prove that the code is safe.
ITEM GET
Design each reveal on purpose
Sources: ERC-7984 (Draft), ERC-3643, OpenZeppelin ERC7984Freezable v0.5.0, Zama ACL, Zama protocol, Solana confidential transfers.
FAQ
No. ERC-7984 is a Draft interface for confidential tokens. ERC-3643 is a Final standard for permissioned tokens, with other interfaces and rules. Mixing them takes deliberate code and a conformance review: adding a freeze doesn’t let you swap one for the other.
Not if the code can return an actual amount, still encrypted, that differs from the request. The app has to read that result and let allowed users check it. The status of the transaction alone isn’t enough.
No. I’m a named author of ERC-3643, but I haven’t deployed, run or benchmarked a confidential-token system. This post reads public specs and one pinned library version: no numbers from production, no security assurance.
STAGE CLEAR
What you now know
- What a permission on one value, an auditor key and a public disclosure each reveal.
- Why a wallet should keep submitted, executed and verified apart.
Check yourself
Tap or click a question to see the answer.
A Solana token sets an auditor key. Can the auditor now read every holder’s full balance?
No. The auditor key covers transfer amounts, encrypted for that auditor while the key is set. It gives no view of full balances.
Former CTO of Integra. Named author (1 of 5) of ERC-3643, first author of ERC-6960, co-author of ERC-7410, and co-author of ERC-8203, which is still a draft. Building production AI and regulated Web3 systems.
Have a project to ship or a role to fill?
Discuss your project or roleFollow the engineering notes
Get new articles on production AI and smart contracts by email.