ERC-721 Tokens – Why ERC721 Contracts Need to Conform to Both ERC721 and ERC165 Standards

erc-721tokens

Reading through the EIP for ERC 721 I notice that it is required to implement 2 different interfaces. Why is this?

I noticed this portion in the documentation, but I think some clarification is necessary.

ERC-165 Interface

We chose Standard Interface Detection (ERC-165) to expose the
interfaces that a ERC-721 smart contract supports.

A future EIP may create a global registry of interfaces for contracts.
We strongly support such an EIP and it would allow your ERC-721
implementation to implement ERC721Enumerable, ERC721Metadata, or other
interfaces by delegating to a separate contract.

Best Answer

The ERC-165 standard provides a standard for generating an identifier for an interface.

This way, if the identifier of a given version of a given interface matches with your contract, it's a way of ensuring that your contract is compliant with that interface.

As per line 4 of the specification,

///  Note: the ERC-165 identifier for this interface is 0x80ac58cd

Edit:

In plain English, basically it's a way of taking a finger print of the interface, and checking that against a finger print of the functions you've implemented, and makes sure they're the same.

Related Solutions

ERC-721 – Why Does ERC721 Have transferFrom and safeTransferFrom?

There is an explanation in the original Github ERC721 thread about keeping the "unsafe" transfer function (comment from Dieter Shirley, alias "dete", one of the authors of EIP-721) :

Upon further reflection and discussion with @flockonus, we are proposing to keep a straightforward (and therefore "unsafe") transfer() method. (i.e. It would work like ERC-20, and not EIP-223.)

Our reasoning is as follows:

Simpler is always better for standards. The fewer requirements, the harder it is to screw it up. (And NFTs are already complicated enough!)

It is not the job of a smart contract to protect against every possible user error (it must protect against invalid actions, not unintended actions). In particular, the case we are trying to avoid (sending NFTs to contracts that don't know how to handle them) is better served by checks and warnings in the wallet software. A wallet (or other smart contract interface) will always be able to have more robust and dynamic checks than a smart contract, and is also able to engage in some "back-and-forth" dialog with the user. Smart contracts don't have the equivalent of a "This seems unsafe, are you sure?" dialog box!

This functionality has therefore been retained for greater flexibility and to keep the standard as simple as possible.

Tokens – How to Understand CryptoPunks as NFTs without ERC20, ERC721, or ERC1155

Etherscan hardcoded the CryptoPunks contact to show up that way.

Basically Etherscan is programmed this way:

If contract is CryptoPunks
  handleCryptoPunksSpecially()
Else If contract is CryptoKities
  handleCryptoKittiesSpecially()
Else If contract follows ERC721()
  handleGenericERC721()
Else
  itIsNotAnERC721()

And this is precisely why we need standards, so everybody does not need to to one-off programming like that.

Best Answer

Related Solutions

ERC-721 – Why Does ERC721 Have transferFrom and safeTransferFrom?

Tokens – How to Understand CryptoPunks as NFTs without ERC20, ERC721, or ERC1155

Related Topic