Authenticating ERC721 Tokens

Question

The standard metadata schema for ERC721 Tokens requires three properties to be populated for each Token:

1. name
   
2. description
   
3. image

So if we created a collectible-game called say "CryptoHippos", we could populate these properties as follows:
-name - "CryptoHippo Token#123" (where the # would of course change for each Token)
-description - "Another unique creature from the super-addictive CryptoHippo Blockchain Game!"
-image - "http://www.cryptoHippos.com/images/CryptoHippo123.png"

Or something like that.

Now let's say our game is a huge hit and someone decides to steal some of our thunder by creating their own "hippo" contract that generates Token-metadata that is 99.9% identical to ours, as follows (see if you can spot the difference):
-name - "CryptoHippo Token#123" (here they make an exact copy of our name property)
-description - "Another unique creature from the super-addictive CryptoHippo Blockchain Game!" (same thing: an exact copy of our Metadata)
-image - "http://www.cryptoHippoos.com/images/CryptoHippo123.png" (here they have to use a slightly different URL - it's just one letter off - because they obviously can't access our domain)

So, if they put these tokens out there, my questions are:

1. How would the average consumer know that these are not authentic "CryptoHippo" tokens? The name and description properties certainly says they are, so how would they know they're not?
   
2. What if we decided to store the images of our tokens on IPFS and not host them on our cryptoHippos.com server - meaning that instead of our very true and authentic cryptoHippos.com domain appearing in the Token's metadata, the generic ipfs domain would appear, making it even easier to fake Tokens to seem authentic - so what then?
   

Seems like the metadata is very hackable.
Is there some other technique, trick, or different approach to take to ensure Tokens aren't fake-able?

Answer 1

The specification you are referring to is the "ERC721 Metadata JSON Schema" standardized in ERC-721.

A side note, this specification does NOT require those three properties. It is merely specified that if you include any of those properties then they will have a certain well-known meaning as per the schema. To understand this distinction, please study the referenced JSON Schema standard.

The problem you cite--what happens if another contract purports to by the real CryptoHippos--is a fundamental reputation problem for on-chain applications. Here, "fundamental" means it cannot be solved using the blockchain itself, you need another mechanism.

And the answer is that you trademark the term and posture so as to threaten to sue anybody else that may infringe on your trademark. In other words, you make a website with a real legal entity's name on it, mention "CryptoHippos" as a trademark, and you link to your smart contract.

If anybody else mentions CryptoHippos and tries to associate with another imposter smart contract, you would need to sue them. There is no magic Web3/"decentralized"/magic/fairies solution here.

As another illustration of how this issue is fundamental, consider the Ethereum project as a whole. What prevents you from forking the project and having everybody else do a hard fork upgrade with you? (Or similarly, what stops you from refusing to do a hard fork upgrade that Ethereum Foundation demands?) The answer is nothing stops you. But you would not be able to call that thing "Ethereum". The threat exists that Ethereum Foundation would sue you for trademark infringement and they could easily prove damages of some part of a trillion dollars.