Blockchain Standards are Eating the World

Published in

Coinmonks

6 min readMay 11, 2018

Unless you’ve been living under a cave, you’ve heard the term Initial Coin Offering (ICO). I’m not going to debate whether issuing a large quantity of cryptoassets is legal, ethical or just stupid 😲. I’d like to discuss what enabled the explosion of tokens that started early 2017 and continues to this day.

Standards

A Walk Down ERC-20 Memory Lane

Mostly happening on the Ethereum blockchain, almost every token launched was an ERC-20 token. This stands for Ethereum Request for Comment. It comes from a loosely based standards process for the Ethereum blockchain. This process aims to define abstract interfaces for commonly used smart contract designs and data structures. Wait… What?

Say you want to create a token on Ethereum. You want this token to have certain properties: fungibility, divisibility and a limited supply. The interface and data for a standard ERC-20 token can provide all of that functionality in it’s design. You simply have to fill in the parameters you want and deploy your token. Here is that interface and some of the data (without the actual code):

// somewhat borrowed from
// https://github.com/OpenZeppelin/openzeppelin-solidity/tree/master/contracts/token/ERC20contract ERC20Basic {
  string public name; // ex: "Matt Token"
  string public symbol; // ex "MT"
  uint8 public decimals; // ex 18 (decimal places)  // the total supply of this token
  function totalSupply() public view returns (uint256);  // find the balance of tokens at a specific address
  function balanceOf(address who) public view returns (uint256);  // transfer tokens to another address
  function transfer(
    address to, uint256 value
  ) public returns (bool);  // record an event on the blockchain
  event Transfer(
    address indexed from, address indexed to, uint256 value
  );
}

It only takes a few basic functions and data properties to “be” an ERC-20 compliant token. What’s important is that everyone has agreed on these terms.

Standard Requirements

For a standard, the community must agree on the following:

Variable Naming
Function Signatures
Expected Behaviors
A Somewhat Standard Implementation

Variable naming is more than convention. This must be strictly adhered to. For instance, a wallet could allow community submitted ERC-20 tokens, but what happens when someone submits a token that has a variable tokenName instead of name. The wallet software cannot read the name property of the token, and we’ll likely end up with “undefined” as a user. That’s no way to do user experience (UX).

Function signatures are a big one. Imagine an exchange implementing a different set of functions for each token they wish to add? One uses transfer(address,uint256) another transferFrom(address,address,unit256) another safeTransferFrom(address,address,uint256,bytes) and so on… The uint256 is simply the amount of value being transferred and the bytes in the last example would be a piece of data for optional callback behavior. However, different interfaces that are non-standard or go unsupported by tokens, can easily lead to security issues, slow the adoption of new tokens and worst of all create a terrible UX for new users.

Expected behavior means that we expect a function to do what it was designed to do. There is no one stopping you from adding a bunch of funky logic to your ERC-20 transfer(address,uint256) function. However, at the end of all that funky logic, you should probably transfer the amount of tokens specified by the user who called the function and provided the arguments to the parameters address to and uint256 value. If you didn’t transfer that value, perhaps you took a fee, then your protocol wouldn’t be very good 😂. Behaviors become especially important when callback functions are expected. An example would be a function that is called after a token is transferred successfully. If you expect this to happen, and it doesn’t. It’s going to be very hard for other developers, dapps, wallets, exchanges to interact with your token.

Are Blockchain Standards Eating the World? 🤔

So what? A handful of cool projects launched tokens last year and the rest were garbage. This attitude of the retail investor or surface crypto user misses the crucial point. There are thousands of ERC-20 tokens, and they’re all supported in every wallet that supports the ERC-20 standard. This level of inter-operability and support is unprecedented even in modern software. Think about how hard it is to get two databases to exchange information, or learn a new application programming interface (API).

The true beauty of a useful standard is enabling developers to launch their smart contracts adhering to common interface and instantly have them be a part of an entire ecosystem.

Wallets, Exchanges and Applications

These days, any fungible token launched on Ethereum would be foolish not to implement the standard ERC-20 interface. They would have to run around to each wallet coder, exchange and any decentralized application they want adoption on, and beg for them to implement some twist on what is already standard. No good 😣.

The Future of Standards 🤗

Since ERC-20, we’ve seen a lot of cool standards proposals. Most interesting is the Non-Fungible Token standard, ERC-721. You might have seen this in the form of CryptoKitties that launched at the end of 2017. Non-Fungible Tokens (NFTs) like their counterpart, FTs, are enjoying the same explosion of post standardization. There are hundreds of ERC-721 contracts now. What’s even more interesting, since NFTs represent distinct assets, are all the other layers you can place on them. Projects like Userfeeds.io are building social networking layers on top of CryptoKitties and other NFTs. If there was no standard interface for all NFTs, the brilliant developers at Userfeeds would spend most of their time writing abstraction layers and data marshaling code, instead of expanding on the tools, APIs and universe they are creating.

I see a bright future for Ethereum standards. I have proposed one of my own that I feel will become an essential building block in the fungible and non-fungible ecosystem of wallets, exchanges and applications. ERC-998 Composable Non-Fungible Token (CNFT) standard is an extension of the NFT standard ERC-721 that will allow a CNFT to own another CNFT, NFT or FT. Wait… What?

Imagine a character you own 👸 (really own, cryptographically) from a blockchain based game. You find a sword 🗡️ and shield 🛡️, equip this on your character, play for days and level up. What about fungible tokens? Well your player could have cash 💵, mana 🥃, resources 🌲, etc… Now it’s time to try a different game. The character and all the items transfer seamlessly to the new game with a single function call. Now you’re bored and want to sell your character on a decentralized exchange for NFTs like rarebits.io. Rarebits can enumerate all the possessions of your CNFT and show other users, trustlessly, what items your character has equipped and what they will receive if they purchase.

How about a real world example. You like useless tokens right? What if you could place all your useless tokens into a single CNFT and shoot that over to your Trezor or Ledger in a single transfer. What if you could reach inside your CNFT and transfer out specific amounts of specific ERC-20 tokens… 🤯. Can anyone say “Index Fund”?

Wrapping Up

Blockchain standards are not only eating the world, they’re eating other protocols and early projects in the ecosystem. Not because the projects are bad, but because they didn’t create a defensible smart contract ecosystem. Standards are abstractions for the basic use cases of digital scarcity. Here I’ve presented why standards are important for the adoption of fungible, non-fungible and composable tokens. Using these building blocks and a few extra functions, we can create a ton of complex assets.

Personal Note

Standards matter to me because I don’t want to live in a siloed world any longer. I want to own my data, my assets, my records, and I want to be able to ship them from system to system. Without standards, we don’t see adoption among wallets, exchanges and applications. This means we don’t see adoption from users. If it becomes too complicated or confusing to create, use and exchange cryptoassets that are truly decentralized, we run the risk as a community of decentralization becoming a niche movement. Our efforts cannot be for nought. We must work together to standardize the basic building blocks of cryptoassets and focus on adding value where it counts. Solving real world problems and designing kick ass user experiences.

medium.com/@mattdlockyer
twitter.com/mattdlockyer
linkedin.com/in/mattlockyer