Opus finding
DopplerDN404.tokenByIndex uses totalSupply/_unit() which counts both NFT and fractional tokens
mediumbugmedium
- src/dn404/DopplerDN404.sol:212-232
`idLimit = $.totalSupply / _unit()` represents the maximum number of NFT IDs that could theoretically have been minted, but DN404 only mints NFTs corresponding to whole units owned by non-skipped addresses; the actual scanning bound should be the highest minted token ID (`$.nextTokenId - 1` or similar internal counter). If burning has occurred and totalSupply has decreased, but the `nextTokenId` has continued to increase, then `idLimit` will be smaller than the actual token ID space, and some existing token IDs may be missed, causing `tokenByIndex` to wrongly revert with `GlobalIndexOutOfBounds`. Conversely, since DN404's `oo` map is indexed by token ID (1-indexed when `_useOneIndexed()`), scanning a fixed range starting at `start` for `idLimit` slots is fragile. The check `if (index >= total) revert` enforces validity, but the loop may exit without finding any token if minted IDs are sparse beyond `idLimit`. This needs DN404 internals to verify whether token IDs are always contiguous.
Recommendation
Use a more robust upper bound, e.g., `$.nextTokenId` (or whichever DN404 field tracks the high water mark of minted IDs), or iterate until `found == index` and verify against `totalNFTSupply` for early termination.