What is a token, really?

One thing I hope to do with this newsletter is to help demystify some Web3 concepts for people I consider to be my capital markets peers, e.g. my LinkedIn network here. If you are already familiar with blockchain and know the ERC-20 specification by heart, this article is not for you ??

It took me an embarrassingly long time to understand what a token really is. It wasn't until I created one myself that I finally and fully understood. Now that I understand it, I am kind of kicking myself for not getting it earlier. It is completely trivial and I was overly complicating things in my mind. If you're like me and haven't yet implemented your own token, hopefully this article helps you understand what a(n ERC-20) token really is.

It is probably safe to assume anyone reading this understands the basic nature of financial transactions so without saying much, you could probably guess a lot of properties of tokens and you'd be right. Conceptually, a token is a lot like a normal fiat currency. As such, you expect certain things of tokens. For example, you expect to:

• Know how many tokens you own, i.e. token balance.
• Be able to receive tokens from someone.
• Be able to send tokens to someone.

When you receive a token from someone, you expect your balance of that token to increase and you expect the sender's balance to decrease by the same amount. You might also expect that you cannot send more tokens than you own.

What is the above describing? This simple concept has been around for at least 700 years and hopefully makes you think of a ledger and double-entry accounting. A token simply consists of a list of accounts with respective balances and a token transfer simply debits one account and credits another. This can be implemented with a few lines of computer code.

The Double Spend Red Herring

When I was first learning about blockchain, a lot of resources focused on the "double spend" problem, i.e. if a token is just a string of bits, how can you ensure that you don't spend the same token twice? This focus on double spend made me think there was something special about the token itself. The digital token must have some special property that keeps it from being spent twice. This is a huge red herring as far as understanding what tokens really are is concerned.

There is really nothing special about a token. It is literally a few lines of simple code. One of the common ERC-20 token standard implementations by OpenZeppelin consists of roughly 66 lines of code (counting semicolons). Your token balance is just a number recorded in a super simple data structure that maps addresses to (unsigned) integers. The thing that is special about tokens is how and where this code is run and not about the token itself.

Clients and Servers

I think by now even the least technical of professionals these days has at least a rudimentary understanding of the concept of "client" and "server". If you have kids (especially if they play Minecraft or Roblox), you probably hear them routinely complain, "They shut down my server!" Most applications today have a client, which represents the user interface, connecting to some remote service. That remote service is running on a machine called a "server". When it comes to web applications, the client consists of code running in your web browser on your computer. For example, I am writing this article using an editor as part of the LinkedIn client application. When I publish it, this article will be stored permanently on LinkedIn's servers.

The magic of digital tokens is that the simple code describing them is running on a completely transparent, immutable, permissionless and trustless "world server". When you receive a token from someone, this means the code simply increases the integer number describing your balance and decreases the integer number describing the sender's balance. That's it. There is no magic property of a token that keeps it from being spent twice. The magic is that there is only one copy of that code on the "world server" and that code gets run just once per transaction and everyone agrees that it has run.

When you own a token, all that means is that some simple code running on some "world server" contains a map that associates your address (think "account #") to an integer number representing your balance. That's really it.

The Token API

The data structure representing the account mapping itself is secure and protected from direct manipulation. The only way to interact with this mapping is through a limited number of functions. These functions include the obvious things like:

• balanceOf: Retrieve the token balance of any address (not only your own).
• transfer: Transfer some of your tokens to another address.

However, unlike fiat currencies, you can know exactly how many tokens there are in circulation at any given time via

• totalSupply: Total number of the tokens in circulation.

In addition to these basic token functions, for the purpose of writing decentralized financial applications such as automated market makers, we need the ability to give another piece of code, i.e. smart contract, permission to transfer tokens out of your account. These include:

• allowance: Retrieve the amount of tokens approved for transfer by an external contract for any address (not only your own).
• approve: Give permission to an external contract to transfer tokens out of your account.
• transferFrom: Transfer an approved amount of tokens from someone else's account.

That's it!

So to summarize, a token is really just a very small bit of very simple code (66 lines!) that keeps track of a mapping from addresses to integers with a standard set of functions. The "double spend problem" is kind of a red herring. Tokens are special because the code used to control them is running on a "world server" i.e. a blockchain.