N-11: ConfidentialFungibleToken Allowance Semantics Diverge From ERC-20 And Are Undocumented

N-03 ConfidentialFungibleToken Allowance Semantics Diverge From ERC-20 And Are Undocumented

Severity: Note

Source: Midnight Foundation #02 — OpenZeppelin Compact Contracts Audit, Release 0.3.0-alpha.1 (2026-08-18)

The approve circuit debits the owner's spendable balance by value and funds the escrow with it, so an allowance is reserved rather than merely permitted and the sum of outstanding approvals is bounded by the owner's balance. This diverges from the ERC-20 semantics an integrator will assume, where allowances are unfunded and may exceed the balance across several spenders, and the module header's disclosure and design notes do not record the difference. A frontend ported from an ERC-20 token would therefore present approve as free and idempotent while the user's spendable balance silently drops. The deduction in balance during approvals is in fact necessary due to the added confidentiality layer. At spend time, a spender would have to prove the owner's balance covers the allowance, which needs the owner's plaintext and therefore the owner's encryption secret, which the spender does not have.

Consider stating in the module header that allowances are funded at approve time, and that total outstanding approvals are therefore bounded by the owner's balance.

Start in contracts/src/token/ConfidentialFungibleToken.compact, especially the module header and design notes around lines 81-88. Read the approve circuit around lines 878-933 to verify how approvals affect spendable balances. Done means the header clearly states that allowances are funded at approval time and that outstanding approvals are bounded by the owner's balance.