Hedera Tokens

Before I Begin, a Quick Word

When you approach new technology as a tech writer, you take it for granted that you’re going to get some things wrong at the beginning. There will be great gaps in your understanding that you hope to fill along the way. Depending on your ultimate purpose -- a user guide, a cookbook article, a tutorial, or whatever -- some areas of the technology will always be uncertain to you. That’s not a problem, as you often don’t need perfect and complete knowledge to achieve your purpose.

Add to this the fact that technology evolves. As a tech writer of new technology, I know that today’s truths may be tomorrow’s falsehoods. Ask any tech writer about the frustration of having to unravel several months’ worth of work to bring draft docs back into usefulness due to a new discovery or last minute development by the engineering teams.

So as I begin this series of posts where I dig deeper into Hedera, I accept the fact that I may be making errant assumptions early on. Over time, as I persist in my discovery, I’ll self-correct. Please bear with me. It's the tech writer way.

The Hedera Token Service Takes a Back Seat - Temporarily

I begin this series with a brief examination of the Hedera Token. Originally I'd planned on starting with the Hedera Token Service (HTS). But I quickly decided that it would be better to examine just what these tokens things are before I look at HTS, the service that creates and manages them.

As I noted in my documentation overview, my main source of truth on HTS is the Hedera Tokenization Whitepaper. That whitepaper is also the major source for my investigation here on tokens.

Tokens

The token is the fundamental mechanism for distributed ledger operations. There are two types of tokens: fungible and non-fungible.

Fungible is a just synonym for identical. For example, two one dollar bills are fungible in that they persist in equal value -- their relative values are immutable. If you and I swap a dollar between us, neither of us is at a disadvantage.

Non-fungible tokens (NFTs) though, are not identical. Their relative values are not immutable. If I use my dollar to buy a candy bar, there’s no guarantee that tomorrow I can buy another of the same candy bar for a dollar. Tomorrow my dollar may buy two or (more likely) only half of one. In this case, the dollar as a method of exchange with a candy bar is non-fungible.

Basic Token Use Cases

Along with token types, the whitepaper provides two fundamental use case classes that all tokens fall into, whether fungible or non-fungible. These are utility tokens and security tokens. Since the whitepaper was released, a couple of other classes seem to have surfaced. For want of guidance, I’m calling them representative tokens and ownership tokens.

Utility tokens provide the bearer with proof of access. An example of a fungible utility token would be a general admission ticket to this year’s opening Boston Pops concert. It doesn’t matter which ticket you have, any one of them will do to get you into the venue's general admission section.

An example of a non-fungible utility token would be the boarding pass for your flight to Boston so you can use your ticket to the concert. No one else who possesses your boarding pass can have your seat (as long as the airline is doing its job). 

Security Tokens (security as in financial instrument) represent value. Security tokens could represent shares in a company (fungible), or ownership of a property (non-fungible).  

Representative tokens verify the existence of an auditable state. For example, emissions and carbon offset tokens can document the lifecycle of carbon credits in a auditable way. These could be fungible or non-fungible depending on the application. If such a token enables me to offset the same amount of carbon in China, the U.S. and India, and for any industry, I'd call it fungible.

Tokens used to establish a product’s supply chain state also exist in this class.

Ownership tokens verify the bearer’s property rights. For example, the check ticket for your checked coat at the theater establishes you as the owner of the coat. If you give that check ticket to someone else, as far as the coat room is concerned the coat belongs to that person. It’s not yours anymore.

Note that the thing represented by the token may or may not have value. Also, the token could itself be the thing which is the valuable owned property.

Token Object Details

I need to describe a bit about tokens as programmatic objects. When Hedera tokens are defined, they carry within their definition information on their identity and operational attributes. The whitepaper lists 12 attributes available to any Hedera token; the most current specification lists 21.

Currently, only a few of these fields are required (name, symbol, and treasury account ID) and the rest are either optional or conditional. I’ll be digging into what that means in a future posting. 

This richness of use for tokens makes me wonder if creating and managing the different types requires different types of code. A question I'm sure I'll find out later.

That's a Good Stopping Point 

Okay, that’s the end of my peek into Hedera Tokens. I think I have a good enough idea about what they are to start thinking about what you can do with them using the HTS. I didn't answer all of my questions about tokens, so I'll jot down some concepts to consider going forward on a technical watchlist. I may not answer any of them for a while (truth is, I may never answer a watchlist item), but I like to scan the list as it grows during my research. They are open questions that I may need to explore when I can.

1. Are there any Fungible types of representative or ownership tokens? From the standpoint of developer documentation, does it matter if there are or are not?

2. What is the distinction between required, optional, and conditional token properties

3. As a developer, do I have to approach the care and feeding of tokens differently based on the fungibility or class of token?  

 

Thanks for reading, and stay tuned.