ERC-8424: Confidential Real World Asset Token

What it is

A security critique of draft ERC-8424 (Confidential Real World Asset Token, extending ERC-7984) posted on Ethereum Magicians. It targets two functions the draft adds — confidentialCanTransfer and confidentialAvailableBalanceOf — plus the spec's revert clause for amount-dependent transfer rules.

How it works

The draft leaves who can resolve the returned FHE pointer to the implementation. That is safe for plain ERC-7984, but ERC-8424 lets the caller choose the from and amount arguments, and the spec requires the result not be false merely because the operator is unauthorized — so anyone can query anyone. If the caller can also resolve the answer, each confidentialCanTransfer call becomes a comparison against a victim's spendable balance: a euint64 balance falls to binary search in at most 64 calls, and confidentialAvailableBalanceOf(victim) yields it in a single call.

Separately, the revert clause ("MUST return a pointer to false OR revert if any other rule would prevent the transfer") is the leak. Vesting and balance caps depend on the (confidential) amount, so a revert there publishes a disclosure bit with no decryption at all — the same leak the spec's own "Disclosure through reverts" section warns about.

What to do

Two concrete spec fixes the author proposes:

1. Pointer resolution. Adopt the pattern OpenZeppelin's ERC7984Freezable.confidentialAvailable already uses — granting the result only to the account via FHE.allow(amount, account). The suggested normative wording: a returned pointer MUST NOT become resolvable by any party that could not already resolve from's balance (or account's, for the available balance).

1. Reverts. Narrow the revert option to rules whose inputs are all public; amount-dependent rules (vesting, balance caps) must instead return a pointer to false. Reverting on canSend or canReceive remains fine — those are plaintext checks anyway.

Caveats

This is a review comment on a draft ERC, not a deployed-contract vulnerability; the fixes are proposed spec changes, not patches to existing code. The critique assumes an implementation that lets the caller resolve the returned pointer — the exact behavior the author argues the spec should forbid.