Hidden Token Balances: What Can a Failed Transfer Leak?
A token hides your balance, then a transfer fails in public or a public check answers yes or no. What did you just give away?
IN 30 SECONDS
A revert is a failure that undoes a call’s changes; if nothing catches it, the whole transaction fails, in public. When the failure comes from a secret comparison, it can reveal that comparison’s result. This stage shows what a failed transfer, a repeated yes-or-no check and a holder count can each leak.
KEY TAKEAWAYS · 3
- A public failure caused by a secret comparison can reveal the comparison’s result. The ERC-7984 draft still allows a revert: it’s a privacy point, not a ban.
- A public yes or no about a secret can leak it. Rebuilding a balance by repeated questions needs specific conditions, such as repeated access and a balance that stays put.
- You can count holders without decrypting each balance. Who learns that count is a separate policy decision.
On this page
Why a failed transfer can leak a secret
IN SHORT If a transfer fails in public because of a secret comparison, the failure can reveal the comparison’s result.
WORDS TO KNOW
- Revert
- A failure that undoes a call’s changes. If nothing catches it, the whole transaction fails in public (the fee is still paid).
- Pre-check
- A call that asks whether a transfer would pass, before anyone sends it.
- Oracle
- Here, any interface that answers questions about a secret.
- Zero-knowledge proof
- A proof that a fact is true without showing the data behind it.
Picture a contract that Revert A failure that undoes a call’s changes. If nothing catches it, the whole transaction fails in public (the fee is still paid). See the glossary when the hidden balance is too small: the transaction is cancelled, in public. Anyone who can tie the failure to that check can learn one fact: the unfrozen balance was below that amount.
A revert that leaks a comparison is a privacy point. Reverts are not banned.
The ERC-7984 draft says plainly that a transfer may revert when the balance is too low.
Coming up next: And if nobody sends anything, but anyone can ask whether a transfer would pass?
When a pre-check becomes an oracle
IN SHORT A public yes or no about a secret balance, asked again and again, can narrow that balance down.
A Pre-check A call that asks whether a transfer would pass, before anyone sends it. See the glossary asks “would this transfer pass?” before anyone sends it. ERC-3643, a Final standard, has one for compliance. Here, an Oracle Here, any interface that answers questions about a secret. See the glossary means any interface that answers questions about a secret.
HYPOTHETICAL ORACLE
Step 1. Ask. The caller asks whether the balance is at least the middle of the possible range.
- Ask The caller asks whether the balance is at least the middle of the possible range.
- Answer The interface (API) answers yes or no in plain text. Half the range is now ruled out.
- Repeat The caller asks again about the half that’s left. Each round can halve the range again, as far as queries and precision allow.
In the scenario shown, the reasoning only works if all four of these hold:
- the range is known and finite;
- the caller picks the amounts and can ask again and again, whether access is public or only authorized;
- the answer flips only once as the amount grows;
- the balance stays put long enough.
ERC-3643’s compliance pre-check doesn’t, on its own, require letting anyone test a secret sender balance. Its checks on who may hold the token can stick to public rules.
Other designs may use permissions, hidden results, or proofs that give only an allowed yes or no. Each one moves the line of what gets shown, and each needs its own review.
ITEM GET
Audit every public yes or no
Coming up next: So can a rule that needs balances, like a cap on holders, still work?
Counting holders without revealing every balance
IN SHORT You can count holders with a nonzero balance without decrypting each one. Who gets to see the count is a separate choice.
IN PLAIN WORDS
Some token rules cap how many holders there can be. That needs a count of nonzero balances, not the balances themselves.
A design can keep an encrypted flag per holder and an encrypted counter. Or it can use Zero-knowledge proof A proof that a fact is true without showing the data behind it. See the glossary, which prove a fact without showing the data behind it.
The hard part moves to getting it right. Count each holder going from zero to positive and back, never twice. Cover minting, burning (destroying tokens), recovery and forced transfer too.
WATCH OUT
A published total can still leak information when combined with other observations.
Sources: ERC-7984 (Draft), ERC-3643, OpenZeppelin ERC7984Freezable v0.5.0.
FAQ
No: the ERC-7984 draft allows a revert when the balance is too low. OpenZeppelin ERC7984Freezable v0.5.0 instead moves an encrypted zero when the unfrozen balance is too low, and other errors can still revert. Check your version and the actual transfer result.
STAGE CLEAR
What you now know
- Why a public failure on a secret comparison can reveal that comparison’s result.
- Which assumptions a repeated yes-or-no question needs to narrow a hidden balance down.
Check yourself
Tap or click a question to see the answer.
A team says: “Our pre-check only answers yes or no, so it can’t leak a balance.” Is that safe?
Not necessarily. Within a known range, if anyone can ask again and again about amounts they choose, while the balance stays put, those answers can narrow it down. So look at who may ask, and how often.
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.