Conversation
|
I think that won't happen cuz there is NFT ownership check here. if (_ownerOf[id] != address(0)) {
revert AlreadyExists();
} |
This revert indicates that minting duplicate IDs is prohibited. The minting process only cares whether the ID to be minted is already taken, without considering the possibility of over-issuance due to errors in the preceding logic. unchecked {
balanceOf[to] += _getUnit();
} |
|
I don't think it's a logic error. It's the way it works. NFT balances of whitelisted addresses can be incorrect, but Uniswap protocol will work because their ERC20 balance is correct. And there is no need for Uniswap contracts to hold NFTs. |
|
This issue implies that the owner could surreptitiously mint additional ERC-721 tokens. Suppose the owner sets their own EOA wallet as a whitelist and exploits this to infinitely mint ERC-721 tokens, potentially flooding the NFT market. If you don't consider this a logical error, then perhaps calling it a backdoor would be more appropriate. |
|
Yes, that can be possible. Now I understand what you mean. |
In certain circumstances, exploiting two different states of
transferFromcan lead to a bug that allows minting ERC-721 tokens out of thin air through a whitelist. Specifically, when a regular EOA (Externally Owned Account) transfers an ERC-721 token to a Whitelist EOA, and then the Whitelist transfers one ERC-20 token back to the regular EOA, due to the_transfermethod skipping the burn for whitelisted addresses, two ERC-721 tokens are created. To prevent this method from minting tokens,transferFromstrictly prohibits transferring thetokenIdto a whitelisted address. Moreover, to prevent circumventing this restriction by toggling the whitelist status, setting a whitelist address to true will forcibly clear any ERC-721 tokens on the whitelist address.