Hi @bogdan, thanks for the feedback. The thing is that “minting” is not formally defined in ERC-721’s spec. The only formal mention of it is the following:
/// @dev This emits when ownership of any NFT changes by any mechanism.
/// This event emits when NFTs are created (`from` == 0) and destroyed
/// (`to` == 0). Exception: during contract creation, any number of NFTs
/// may be created and assigned without emitting Transfer. At the time of
/// any transfer, the approved address for that NFT (if any) is reset to none.
event Transfer(address indexed _from, address indexed _to, uint256 indexed _tokenId);
Theoretically, the benefit of this standard is to show better information in wallet UIs by interpreting revert reasons. In practice, this didn’t happen as expected, which is understandable since many popular tokens didn’t follow this standard and aren’t upgradeable.
For those cases, I think identifying an “already minted” error can be done by checking for the ERC721InvalidSender(...) error with address(0) as the argument. The rationale is that when attempting to mint an already-existing token, the operation typically tries to transfer from address(0) (which represents minting), but since the token already has a valid owner, address(0) becomes an invalid sender.
As an example, OpenZeppelin Contracts does this.
btw we should finalize this standard soon