The Non-Fungibles Revolution of 2018
A proposal for a new standard, with critical improvements.
We started building the LAND contract in September of 2017. After some early developments, we saw other projects adopting a model based on distinguishable digital assets, or “Non-Fungible Tokens”. Some examples of these are crypto collectibles like Cryptopunks, Rare Pepe Cards, and everyone’s favorite CryptoKitties.
At its peak, ERC721 contracts accounted for 20% of all Ethereum traffic, noticeably slowing down the network. Tens of millions in USD equivalent have been spent on crypto collectibles at an accelerating rate , with most of these transactions occurring in just the past few months, resulting in significant media coverage.
Given this rapid adoption, it is critical to invest in improving a secure standard for distinguishable assets. Here are some insights and ideas compiled from our experience with building a smart contract and dApps around the concept of non-fungible tokens.
How ERC20 influenced ERC721
In late October, we began collaborating on the ERC721 standard for non-fungible assets. This standard is based heavily on the ERC20 token, and was written to include as much common language and existing implementations as possible.
However, fungible and non-fungible tokens are vastly different in how they are presented on interfaces, how users interact with them, and how they are traded. We think that the similarity between ERC721 and ERC20 is very much a Bad Thing™.
In fact, the ERC721 standard inherited some of the problems from ERC20s that still haven’t been fixed.
Here are just a few of the issues that we found after implementing and testing different interfaces that interact with ERC721 tokens:
- approve: this function was initially intended to enable a smart contract to gain control over tokens based on certain conditions (most notably, the 0x protocol and EtherDelta). Calling approve for every single asset that you own is incredibly inefficient.
- The takeOwnership and transferFrom functions seem superfluous. Given that the purpose of approve is to grant a smart contract control of your asset, but is almost always used to simply transfer that asset to another address, takeOwnership and transferFrom are just syntax flavor, a dangerous thing in smart contracts. A simple transfer to the contract address is enough.
- transferFrom(from, to, assetId) has a useless parameter. from can always be inferred since
from == ownerOf[assetId] - Lack of standardization: critical components should be standardized, like an image for listing the tokens under a category.
- Poor extensibility: we imagine that most cryptoassets will need to define a list of characteristics unique to their domain (such as the breeding frequency for CryptoKitties or the land contents of Decentraland). A new NFT standard should permit such modifications (and improvements) for different use cases.
There are numerous proposals and requests for a better standard for fungible tokens (see ERC223, ERC677, and ERC777). However, many plain ERC20 contracts simply don’t have a way to recover tokens. This has led to the loss of more than 3,000,000 USD worth of tokens, with just 1,000,000 USD in the EOS smart contract. Our own contract, Decentraland’s MANA, has more than 100,000 USD in different tokens.
Suffice it to say, we need to be very careful when drafting a new token standard.
Proposal for a New Standard for Non-Fungible Tokens
In an effort to advance the NFT community’s standards, we propose a different approach to this new category of digital assets: the ERC821. This new standard would include the following functions and features:
- transferAndCall: a function defined in a similar manner to the latest ERC777. This is a critical piece, since almost every intended use of approve is to allow a smart contract to react to receiving a token.
- Additional security by reducing the attack surface: ERC821 should drop all unnecessary functionality, like calling approve on a single token. You should create a contract if you need this level of granularity for your assets. There’s no need to pollute the standard interface by adding additional points of vulnerability.
- Signal for ERC820 compatibility: growing together with the rest of the ecosystem will be a clear advantage of the next decade’s standards for this virtual economy. ERC820 allows your contract to signal its implementation of a new standard, creating a great method for future improvements and upgrades.
We welcome the entire NFT community to help us expand and improve this proposal. We know that it’s not ready yet, but since we already have a reference implementation, we hope that you will begin playing with it. Together we can iterate and improve upon this standard so that everyone can use it. Thanks!
Join the discussion in the Github issue or check out the implementation!
