Do you sometimes feel confused about blockchain programming, specifically with words like ERC20 and ERC721? Have trouble understanding what it all means? This post takes some concepts that get presented in somewhat obscure terminology and breaks them down into everyday common-sense language.


ERC means “Ethereum Request for Comments”. It’s like “RFC” but for the Ethereum blockchain. Here’s its history. Basically it means, let’s talk about this thing and come up with some standards.


By this point in 2018, if you’re reading this post, I’m going to assume you’ve heard of “tokens” on the blockchain. (And there’s a reason I put that word in quotes, stand by…) Some tokens you may have heard of are, in no particular order, ZRX, TRON, SNT, etc. Hell, you can even get rich buying the right ones at the right time—or at least, you’ve heard that!

To get a sense of scale and scope, you can see lots of these tokens listed on and on the ERC20 Tokens list.

SO. Why did I put quotes around the word tokens?

Well, the word tokens conjures up something nice, big, and fat. A pile of quarters. A stack of skee-ball tickets. While within each pile one quarter is the same as another quarter, my mind’s eye still shows me a pile of physical objects that I can line up in rows on my dresser and count:

Quarters Skee Ball

Which is how quarters and skee-ball tickets work!!!

This could very well leave me with the mental model that the same holds for these “digital tokens”, which means that at some level, I could arrange them on my dresser and count them (ZRX 1, ZRX 2, ZRX 3, etc).

In other words, that they are THINGS.


The way the information about these tokens is represented on the blockchain does not correspond to a pile of anything. With a digital token like ZRX (where each ZRX at any moment has the same value as another ZRX) I can’t say, give me the fourth ZRX in your pile…because there is no fourth ZRX.

And there is no pile.


The way the information about these tokens is represented on the blockchain is much simpler than that. When someone decides to make a new token, they say something like this:

I’m going to make a new token! I’m going to get rich! I’m going to get my father out of jail! And get me one of those cars!!!

After a minute or two of thought, they might further decide:

Each of my tokens is gonna have the same value as every other. I’m gonna make 100 of them. Because they’ll be worth more that way!! And I’m going to name them ‘MEW’ tokens, because I like the sound that cats make (and in my mind they all make THE EXACT SAME SOUND). That’s because I’m a dog-person.

At this point our hero writes a line of code that looks like (more or less) like this:

tokenName: 'MEW'
totalSupply: 100

In other words, they don’t make a list of 100 MEW tokens, they just choose the number 100. And bingo, there you go, you have 100 MEW “tokens”.

And, importantly, they deploy that contract to the blockchain, and that contract gets a unique address. Let’s say MEW lives at address 999* (*addresses are way more confusing-looking than good ‘ol 999, but for the point of this post I’m using kindergarten numbers).

Now, let’s say MEW gets on an exchange and I buy a single MEW token for $1. What happens? Again, at a high level, the person who wrote the MEW contract wrote a data structure that keeps track of who owns how many MEW. That data structure is called: balances.

SO if my public address is 123, the balances data structure looks like this:

balances[123] = 1;

And if YOU by TWO MEWs for $1 each and YOUR public address is 234, the VERY SAME balances mapping now looks like this:

balances[123] = 1;
balances[234] = 2;

In other words, what you’re interacting with at a basic level is a number. Not “100 tokens”. But, the number 100.

And when people own them, again, a number. If I own 2 MEWs, the number after my address is “2”.

That’s it.


And this, creating a token in which each token is the same as any other given token, is what’s referred to as following the ERC20 standard. And in fact, there is agreed-upon boilerplate code that you can use to build this type of token in a very very short amount of time. And it means that if everyone who creates an ERC20 token uses the same boilerplate, it’s a no-brainer for different tokens to play nicely with each other, on, say, a crypto-currency exchange.

Starting to think about code duplication

NOW, to play this out for a sec, let’s say we don’t only invent the MEW token, we also invent the RUFF token and the CHIRP token and the SQUEAK token. Well, we would simply make 3 more contracts, with pretty much exactly the same code, but probably some different numbers (maybe we make 1000 SQUEAK and 25 RUFF and 1000000 CHIRP). Apart from their addresses & names, the contracts ARE THE SAME. Because it doesn’t take any more code to represent 1000000 CHIRP than it does 1000 SQUEAK.

One could argue: that’s a lot of the same code deployed on the blockchain to do exactly the same thing. We’ll come back to this.

Unique Tokens

NOW, there is ANOTHER, shiny new type of “token” that’s different from the interchangable type I described above. This type of token is one where you can own one, and I can own one, but somehow yours is way more valuable than mine. They’re different. They’re not peas in a pod, they’re, let’s say, kittens in a litter. And the place you may have heard of this is….CryptoKitties.

A CryptoKitty (yup!) is a kind of token that got super famous because people spent a lot of money for unique pictures of cats. Which means that if I’m the owner of the CryptoKitties contract, and I want to make 100 CryptoKitties, it’s not the same as writing the number 100 in my code. Because each one is different!

And you want to know WHICH ONE you own, not simply THAT YOU OWN ONE.

So the way this data is stored is a little different. In this case, you can imagine that if there are 100 unique “tokens”, these correspond to 100 unique placeholders (let’s call those placeholders 1,2,3,4…100). And if I buy CryptoKitty #1, we’d store that information differently, in a data structure called tokenOwner, which keeps track for every single token who its owner is.

So if my public address is (still) 123, the tokenOwner data structure looks like this:

tokenOwner[1] = 123

And then if I buy ANOTHER CryptoKitty, let’s say CryptoKitty 14, the data would look like this:

tokenOwner[1] = 123
tokenOwner[14] = 123

And if YOU buy a CryptoKitty, let’s say CryptoKitty #23, and YOUR public address is (still) 234, the data would look like this:

tokenOwner[1] = 123
tokenOwner[14] = 123
tokenOwner[23] = 234

And there are a few other easy ways to figure out who owns what, but, at a high level, this is how it differs to keep track of ownership of UNIQUE things versus ownership of SAME things.


This standard is called ERC721, which is also referred to an an NFT, and like an ERC20, there is secure, user-tested, boilerplate code that you can reuse for your own application.

Which brings us to…


SAME things == "fungible" == ERC20 == a quarter
UNIQUE things == "non-fungible" == ERC721 == a unique and special cat

Fungible, Non-fungible. You’ll see those words around a lot in blockchain land. Now you know what they mean.

Back to Code Duplication

So then you could start to say: well, isn’t creating a contract for every single FUNGIBLE token that behaves the same way, redundant?

And you could also say: hey, isn’t it ALSO redundant to create a contract for every single NON-FUNGIBLE token that behaves the same way, ALSO redundant?

Now if you’re just a person, making one token, it’s no big deal.

But if you’re creating a whole universe of tokens—a zoo, say!—you might decide that could create ONE CONTRACT that keeps track of all the different animals in the zoo. And you might make some rules like “every can of Fancy Feast Savory Salmon is the same as every other can of Fancy Feast Savory Salmon”.

BUT, every pig is unique amongst all the pigs!

You get the idea.

Well, it wouldn’t be so hard to imagine taking the basic ideas we already learned and putting them in one overarching contract that lets you keep track of all animals and foods in the zoo: which were the same (fungible), which were unique (non-fungible), and who owned what. I’m not going to go into what that code might look like here, but this is what folks are talking about with things like the 1155 Standard.

A Very Serious Grain of Salt

And this is where I want to stop and say, development for the Ethereum blockchain is moving at a mind-boggling pace. There are so many people working on new ideas, protocols, standards, businesses every single day that it is easy to get caught up in the formality of the language (“ERC1155”) and forget that what it represents is people having discussions about the best ways to handle new use-cases for application development on the blockchain.

There are a bunch of proposed standards, and each one is invented to handle new use-cases. Some of them will become standards in the way that ERC20 and ERC721 are: a literal interface that allows you to implement specific functionality and be interoperable with other contracts. Some, that seem like set-in-stone standards like ERC20, will evolve into new standards that extend their functionality or become deprecated, as people learn more about best practices. Some proposed standards will merge with others, as they realize they are trying to do similar things. Some of them will become effectively “discussion headers”.

As a spectator or a developer, I recommend knowing the standards exist, what the basic ones are, and what problems they are solving; and also knowing that a lot of them are stand-ins for conversation about how to code things up in a functional and efficient way in a new programming paradigm. You want to be aware of the best-practice ways to do things so thay you’re not reinventing the wheel and risking security holes—while at the same time keeping clear-eyed about the logic and needs of your particular application.

When I’m feeling a bit of ERC-Overload, I have a scenario I use to amuse myself: imagine that every time you inherited from a class in OO you said: I’m implementing OORC32473483. That numeric designation might make you think there’s magic under the hood, and stop you from thinking about the really important questions—like why you’re using inheritance instead of composition anyway, and whether a Cow is actually a subclass of Animal or of Vehicle.

In other words, use your words, not just your numbers.

Blockchain development is a really neat space and it’s a mind-bender: it’s not your CRUD app, it’s not your Box Business, and it’s probably The Future. Perhaps “just code” that you’re writing today becomes a standard in the future. Or perhaps the existing standards allow you to not think at all, and build a beautiful application on top of them.

Either way, if you’ve got the appetite for bending your mind, there’s a lot here to do it with. I hope this article gave you some perspective on navigating the field.

Happy Coding!