Invest1 publisher3 min readPublished
Reviewer says Ethereum's ERC-8424 draft for private RWA tokens can leak a hidden balance within 64 calls
Reviewer zexoverz found that two functions in ERC-8424, a draft giving RWA issuers forced transfers over encrypted balances, can leak a balance within 64 calls. OpenZeppelin's own code already limits that view to holders, so the harder gap is rules whose failed transfers expose amounts.
The Investor · Invest desk
What happened
- OpenZeppelin developer Aryeh Greenberg opened ERC-8424 on September 25, 2026, as an extension of ERC-7984, the Ethereum standard for tokens whose amounts are stored encrypted.
- The draft adds two plaintext eligibility checks, a confidential transfer check, a confidential spendable-balance figure and a forced transfer reserved for authorized parties.
- Forum reviewer zexoverz said the transfer check and spendable-balance function have no caller limit, so anyone able to decrypt the answers could recover a 64-bit balance within 64 calls.
- The draft still needs one more review from an Ethereum editor, either g11tech, jochem-brouwer, samwilsn or xinbenlv.
Compiled by The InvestorSomething wrong?How this is made
Why it matters
- exposure Until the spec restricts callers, any party that can decrypt a query result can reconstruct another holder's balance, the figure the encrypted format exists to hide.
- constraint Holder-only access would close the query paths but not the revert path, so an issuer that switches on amount-based vesting or caps accepts some balance disclosure on every blocked transfer.
- decision The remaining editor reviewer has to decide whether to hold the draft until it adopts the holder-only rule OpenZeppelin already ships in ERC7984Freezable.
The 64 comes from the width of the field. A 64-bit number can take 2 to the 64th power values, about 18.4 quintillion, and a yes-or-no query that halves the remaining range each time gets down to a single value in 64 steps [1]. Against ERC-8424's transfer check, each query asks whether a transfer of a given size would be allowed. The caller decrypts the answer and halves again [8][9]. The spendable-balance function needs no search at all. zexoverz said it would reveal the balance in one call [10].
By zexoverz's own account, the 64-call path works only for a caller who can also decrypt the result [9]. The fix he asked for is already written. OpenZeppelin's current ERC7984Freezable code lets only the account holder see their own figure, and he wants the spec to carry the same rule [11]. The draft's author is an OpenZeppelin developer [2].
The second leak is harder, because limiting who may call a query function does not stop a transfer from failing. Vesting schedules and balance caps depend on the amount held. A failed transfer under them therefore discloses what the draft's own "Disclosure through reverts" section warns about, and nobody has to decrypt anything, zexoverz explained [12]. The spendable figure the draft defines has to account for issuer freezes, lockups, vesting schedules and pledged amounts [5].
The draft exists to give issuers a forced-transfer power over encrypted balances [1], and on control its text is plain. "An issuer may be required to move assets without a holder's consent," the draft says [13]. It sets limits on minting, burning, stopping and freezing without saying how they should be implemented [6]. It also cites ERC-3643 and ERC-7943 as the standards that already handle these tasks for tokens with public balances [7]. So the draft takes a compliance toolkit built for public balances, applies it to encrypted ones, and leaves each implementer to decide how the limits are enforced [6][7]. The reporting does not name an issuer that plans to adopt the standard.
Editors could require holder-only access on the two query functions and let the draft proceed with revert disclosure documented as a known cost. The authors could instead try to redesign how amount-dependent rules fail. Or the draft could stall at the one editor review it still needs [14]. I'd expect the first. The access rule already ships in OpenZeppelin's code [11], and the revert risk is already in the draft's text [12]. Under that outcome issuers get the forced transfer and holders are shielded from strangers' balance queries. A transfer blocked by a vesting schedule or a cap would still tell an observer something about the balance [12]. This view is wrong if a later revision closes the revert path while keeping amount-based vesting and caps.
What to watch
- Whether the next ERC-8424 revision writes the holder-only access rule from OpenZeppelin's ERC7984Freezable into the spec itself.
- Whether the draft's 'Disclosure through reverts' section changes from a warning into a design that stops amount-based vesting and cap rules from revealing balances when a transfer fails.
- Whether the final editor review is made conditional on fixing caller access to the transfer check and spendable-balance function.