The One Thing Missing from the ERC 721 Standard for Digital Collectibles on the Blockchain

The ERC-721 standard rose to prominence with the rise of Crypto Kitties, one of the first blockchain games to really achieve scale. Crypto Kitties became so popular that it slowed down the Ethereum network, and the digital collectibles (the “kitties”) that were being collected sold for up to $100,000 (yes, in real, fiat money!)

Digital Collectible games have a long history and have been adopted to each new technology trend. Starting in the non-digital world (trading cards and Magic: the Gathering cards),the collection mechanic is a tried and true, reliable game mechanic in the world of video games. Some of the most lucrative mobile games, for example, have the idea of collecting digital characters (fish in Tap Fish, Pokemon in Pokemon Go).

Crypto Kitties has shown that blockchain is no exception. In fact, the idea that ownership can be tracked in a de-centralized blockchain makes it particularly suitable for collectibles — there is no doubt about the rarity of a particular collectible; there is (theoretically) no centralized control over who owns what; there is no doubt about the recent worth of a particular item.

In wake of this, the ERC 721 standard has been defined to make digital collectibles games easy. Here is a list of implementations on Etherscan, along with transaction volume.

Being a video game designer, I took a look at this standard when it was first defined to see how it might be used in a world of digital collectibles that were decentralized. It is based loosely on the ERC-20 standard, which has been used by many tokens / ICOs.

A quick overview of ERC20 — fungible tokens

The ERC-20 standard made it easy to implement in a smartcontract a certain number of fungible tokens. For example, Binance coin (BNB) or OmiseGo (OMG). The idea is that the smartcontract which is the official home of the token has to implement a number of methods which allow for the storage of tokens, to allow anyone to see how many tokens are owned by a specific address, and to allow for the transfer of the tokens from one address to another.

ERC20 tokens are like money — one dollar is pretty much like another when they are stored electronically in bank accounts — which is why they are called fungible tokens.

This specification has created a very large market, since the tokens are paid for in Ether. The market cap of the top 10 ERC20 tokens is in the hundreds of millions, perhaps even billions as I write this.

Introducing the ERC 721 standard

I don’t know if it was such a great idea to base the ERC721 standard on the ERC20 standard but this is the path that was taken, and so they are very similar.

The basic difference is the idea that each ERC721 token is non-fungible, so each token is unique and it has an owner, who can sell it to other owners. The tokenid is used to identify a particular token, which is whey they are called digital assets.

However, by framing ERC721 objects as non-fungible tokens, rather than as digital collectible objects, the standard is very much about tracking and transferring ownership. The following methods are part of the ERC 721 standard (this particular list was taken from coincentral ):

· balanceOf() to count all Non-Fungible Tokens (NFT’s) assigned to an owner

· ownerOf() to find the owner of an NFT

· safeTransferFrom() to transfer the ownership of an NFT from one address to another address and throws exceptions if the parameters have problems

· transferFrom() to transfer ownership of an NFT

· approve() to set or reaffirm the approved address for an NFT

· setApprovalForAll() to enable or disable approval of a third party (“operator”) to manage all of msg.sender’s assets

· getApproved() returns the approved address for this NFT or the zero address if there is none

· isApprovedForAll() returns true if the operator is an approved operator for the owner, otherwise returns false

· supportsInterface() returns true if the contract implements a valid interfaceID, otherwise returns false

What’s Missing for Digital Collectibles

While the interface supports each digital “asset” as having an identity which can be owned by only one person, there are plenty of thigns missing in this standard to make it really work well for digital collectibles like Crypto Kitties or other video game assets.

The idea of collectibles, particularly digital collectibles, within games is very much tied to a visual representation of the item being collected! This idea was completely left out of the standard. In fact, you can’t imagine a video game type collectible without an image representing the object! In the world of games and collectibles, the two are inseparable.

In the ERC721 standard as it’s defined, there is no standard way to associate an image with an id, which means that as far as the blockchain is concerened, each digital asset (or non-fungible token) is just a number!

Of course, storage of information on the blockchain is expensive, which is why images are not usually stored on-chain, but are stored off chain on centralized servers. Over time, protocols like IPFS (Filecoin) and others will make this more possible.

The images for Crypto Kitties are not stored on the blockchain, but on a centralized server

Crypto kitties solves that problem by having another id associated with an id, called its genes. This code is then used to call a central server which then returns the image for the particular kitty.

While this is a pretty standard solution, we are now back to the idea of each games collectibles being in a walled garden, which kind of defeats the purpose of having a de-centralized standard for collectibles. (A good overview is here: Your CryptoKitty Isn’t Forever — Why Dapps Aren’t as Decentralized As You Think)

Theoretically, you could build a de-centralized exchange to allow for trading of collectibles items — each owner would list their collectible, and the ERC721 standard allows this (in the same way that EtherDelta allows for trading of ERC20 tokens). There would be one thing missing though — and that is the most important thing from the perspective of digital collectibles — what the collectible looks like!

There are many implementations and tutorials on how to build your own ERC721 token. (A good tutorial is here — Build your own Crypto Kitties clone in 20 minutes).

Open Zeppelin has rolled out a full implementation that adds a few methods which aren’t part of the original interface.

• tokensOf( _owner ) — Returns list of token ID’s of specific _owner
• approvedFor( _tokenId ) — Returns the approved address to take ownership of a given token ID

These types of extensions are useful, even if they aren’t part of the official standard yet and it gave me a simple idea which could transform NFTs into real digital collectibles.

Digital Asset Extension to Make NFTs into Digital Collectibles

I would propose a simple extension that would make all ERC721 contracts inter-operable with the world of digital collections.

While storing image on the blockchain would be a more complicated endeavor, this “interim” approach would allow trading platforms and other sites to reference and interact in a standard way with all of the ERC721 digital collectibles out there:

· imageOf (__tokenId)– Returns a URL which returns an image for a specific token; returns blank if there is no “official” image for this tokenId

The idea is that this new method, imageOf, would simply return a URL which is the “official” keeper of the digital images of each of the collectibles, so only the owner of the contract could set or change this URL. This URL could be a server like the cryptokitties server or it could be a reference to an on-chain, decentralized storage.

The format could be modified or extended, but it provides an “official” image for each non-fungible token. The URL could return any kind of image supported by web browsers — jpeg, png, etc.,

There would need to be more discussion to define the various types of URLs and content-types that are returned — but the addition of this simple, optional method, would move the world of de-centralized digital collectibles significantly forward, rather than each ERC721 contract doing it in its own way!

You could eventually see a healthy trading economy that wasn’t controlled by the creator of the digital tokens, but was controlled by smartcontracts on the Ethereum blockchain. That is the whole point of the blockchain, after all!

UPDATE: ERC721 Metadata Optional Standard to Accomplish This

Well it turns out since I first looked at it, there is an optional set of metadata that ERC 721 smartcontracts can implement which can accomplish this, through a level of indirection.

Not all contracts implement this (for example, Crypto Kitties, doesn’t, but some others do), and the three metadata functions below are meant to help provide interoperability for digital assets:

/// @title ERC-721 Non-Fungible Token Standard, optional metadata extension/// @dev See https://github.com/ethereum/EIPs/blob/master/EIPS/eip-721.md/// Note: the ERC-165 identifier for this interface is 0x5b5e139f.interface ERC721Metadata /* is ERC721 */ {/// @notice A descriptive name for a collection of NFTs in this contractfunction name() external view returns (string _name);

/// @notice An abbreviated name for NFTs in this contractfunction symbol() external view returns (string _symbol);

/// @notice A distinct Uniform Resource Identifier (URI) for a given asset./// @dev Throws if `_tokenId` is not a valid NFT. URIs are defined in RFC/// 3986. The URI may point to a JSON file that conforms to the "ERC721/// Metadata JSON Schema".function tokenURI(uint256 _tokenId) external view returns (string);}

The tokenURI metadata method, if implemented is meant to be able to accomplish this. However, the response might actually be in JSON file rather than the image itself, which would require an additional levelof parsing, but the “image” element in the JSON is meant to provide this:

{"title": "Asset Metadata","type": "object","properties": {"name": {"type": "string","description": "Identifies the asset to which this NFT represents",},"description": {"type": "string","description": "Describes the asset to which this NFT represents",},"image": {"type": "string","description": "A URI pointing to a resource with mime type image/* representing the asset to which this NFT represents. Consider making any images at a width between 320 and 1080 pixels and aspect ratio between 1.91:1 and 4:5 inclusive.",}}}

In looking at the top 5 (by transaction volume) in the Etherscan link provided above, only two of them seem to implement this method:

• Crypto kitties — not implemented
• Lucid Sight — tokenURL is implemented but pretty much returns blank if you choose a token id from a recent transaction, so not really implemented.
• CryptoRome-Land — Contract ABI not provided, so doesn’t look like they implemented this.
• Gods-Unchained — the method is implemented and it returns a URL like this: https://api.godsunchained.com/card/61000 where 61000 is the tokenid. This seems promising, but going to this URL pretty much returns an error for every recent tokenId!
• HodlEarthToken — Contract ABI not provided, so doesn’t look like they want people calling that method to see if the URI is there or not!

So, the top 5 smartcontracts (as of September, 2018) which implement ERC721 don’t seem to have the images easily accessible (with the exception of Gods-Unchained, but this produces an error when you try to access it). Having a separate server provide JSON is a level of indirection which is probably complicating this more than it needs to be.

As more ERC 721 contracts implement more metadata, the question of where the images live becomes important to the nature of decentralized apps and marketplaces. As the market for non-fungible digital collectibles evolve, we’ll start to see how many use IPFS or other distributed systems vs. centralized servers, and this may determine how “portable” digital collectibles really are!