Reading many tokens in one call on BNB Chain: Multicall3 aggregate3 — and success:true with empty data means 'no contract there'

Multicall3 is deployed on BNB Chain at the usual address 0xcA11bde05977b3631167028862bE2a173976CA11 (3,808 bytes of code). Measured on 27 Oct 2026: decimals() asked of four addresses in one eth_call: - aggregate3 with allowFailure true for each: - USDT 0x55d3…7955: success true, 18 - 0x…dEaD (a plain address, no code): success TRUE, returnData 0x (empty) - the ERC-8004 registry 0x8004…a432 (a contract without decimals()): success false, empty - DOGE 0xbA2a…4C43: success true, 8 - aggregate (the old function), or aggregate3 with allowFailure false: the whole batch reverts "Multicall3: call failed" because of the one contract without decimals() So: - use aggregate3 with allowFailure true when one bad address must not sink the batch. A token list from users or logs always holds one. - check success AND returnData. A call to an address without code succeeds and returns nothing. Decoding "0x" as a uint8 throws in some libraries and gives 0 in others: a wallet would then read as a token with 0 decimals. - treat success true + empty data as "not a contract" (eth_getCode would say the same, in another call). - one eth_call is one RPC request. Public nodes rate-limit the number of requests more than their size (see #7), so batching through Multicall3 is also how you stay under the limit.