Token-0x
First Flight #54
Beginner FriendlyDeFi
100 EXP
View all submissions
Previous Next
Submission Details
Impact: low
Likelihood: low

ERC20 Compliance Issue: balanceOf(0) Reverts

Author Revealed upon completion

Root + Impact

The balanceOf() function reverts when queried with address(0), which violates ERC-20 expectations and breaks compatibility with exchanges, explorers, multicall aggregators, and DeFi integrations that rely on balanceOf(address(0)) returning a normal numeric value (typically 0). This results in downstream failures and makes the token non-standard.

Description

Normal behavior:
Under the ERC-20 standard, balanceOf(address) must always return a uint256 balance for any address, including address(0). The specification does not define any revert condition. All major ERC-20 implementations (OpenZeppelin, USDT, USDC, DAI, AAVE, UNI) return a numeric value for zero-address queries to maintain compatibility with wallets, exchanges, indexers, batch calls, and explorers.

Issue:
This ERC-20 implementation reverts when balanceOf(address(0)) is queried. Many integrations perform batch balance queries or probe zero-address for analytics. The revert breaks multicall aggregations, portfolio trackers, exchanges, burn tracking systems, and off-chain indexers.

function _balanceOf(address owner) internal view returns (uint256) {
assembly {
@> if iszero(owner) { // ❌ Non-standard: causes revert for address(0)
@> revert(0, 0)
}
​
// ... storage lookups omitted ...
}
}

Risk

Likelihood:

  • Address scanners, explorers, multicall routers, and indexers routinely query balanceOf(address(0)) during normal operation.

  • DeFi integrations often fetch balances in batches, and a single revert (from zero-address) causes the entire batch to fail.

Impact:

  • Exchanges, wallets, scanners, and DEX aggregators may fail to integrate the token because balanceOf(0) reverts instead of returning 0.

  • Burn tracking and supply analytics become impossible because querying zero-address balance reverts instead of returning the number of burned tokens.

Proof of Concept

The following Foundry test demonstrates that querying balanceOf(address(0)) reverts unexpectedly, breaking ERC-20 compatibility expectations:

function testBalanceOfZeroReverts() public {
vm.expectRevert(); // ❌ Should NOT revert under ERC20 standard behavior
token.balanceOf(address(0));
}

Observed behavior:
The call reverts, confirming the token is non-standard and will break integrations.

Recommended Mitigation

Remove the revert condition and allow balanceOf(address(0)) to behave like any other address lookup:

function _balanceOf(address owner) internal view returns (uint256) {
assembly {
- if iszero(owner) {
- revert(0, 0)
- }
​
// ... existing storage lookup logic ...
}
}

This restores ERC-20 compliance, prevents unexpected reverts, and ensures full compatibility with wallets, explorers, exchanges, DEXs, and off-chain indexers.

Support

FAQs

Can't find an answer? Chat with us on Discord, Twitter or Linkedin.

Give us feedback!