Introduction to the Token Taxonomy Framework
When I was a kid, I loved to take things apart, too see how things worked. At first, I was not very good at it. I was rarely able put the thing I took apart back together. From the Stretch Armstrong I promptly ruined on Christmas day using a hammer and nails, a rather disappointing result, to my neighbors Merlin, which got me in a lot of trouble, note to self, don’t take apart things that don’t belong to you.
Eventually, I got pretty good at putting things back together by learning how to take them apart. Careful investigation of a thing’s seams, indentations and the location of the screws. I obtained a specialty set of micro-screwdrivers with all those tiny shaped heads that were magnetized to assist in retrieving a screw that fell into a crevasse. I rigged a flashlight to a headband that required neck positions that I couldn’t hold for long.
Anyway, the most important thing, once you have the right tools was when you removed a screw or a cover, you needed to remember where it went and then group the same screws, washers, pads and connectors together. I found that I needed to catalog these in a notebook. If I didn’t know what something was, I’d give it a name until I found out what it was.
As long I was patient and followed my procedures, I was able to put stuff back together again with confidence. I started doing this when I was 7 years old. By the time I was 10, my Dad had me rigging “Rabbit Ears” to get the best TV signal possible.
Side note for those of you who did not experience a time before there was cable. But Rabbit Ears where antenna used to pick up either VHF or UHF signals that TV stations were broadcast on.
And when I was 12 and got my very first computer, a TI-99/4A. I took it apart and put it back together again. That was the last major thing that I took apart. I lost all interest in taking physical things apart after I wrote my first BASIC program on my rebuilt computer.
If you have made it this far, you’re probably asking yourself, what does this have to do with Tokens?
Well, when I got started in blockchain and eventually tokens, I wanted to know how they worked, so I took one apart.
Much like my experience with Stretch Armstrong, I was initially disappointed when I figured out how a token worked, it was too simple. But as new platforms and tools made it possible to do more with tokens and they became much more interesting.
Switching “take apart” to “decompose”. Not like in rotting flesh, but a more “formal” sounding approach.
Decomposing something makes you really understand something in order to put it back together again. When I was a kid and I took something apart, I mean decomposed, and I couldn’t put it back together again or didn’t want to, I would keep the interesting parts for future use. Useful extra screws, a spare fuse, LEDs, neat looking circuit boards.
This is a side effect of decomposing something, you understand the individual components and usually you find yourself looking at a problem or something that needed to be rigged or hacked and found that one of these extra parts did the trick.
The Token Taxonomy Framework (TTF) is a byproduct of my decomposition tendencies. Meaning the framework is just a collection of spare parts that do interesting things that you can reuse when you have a need for it. In fact, you may have all the basic parts in the TTF to assemble a complete token implementation. But, if you find you are missing a part, you can use the TTF to define exactly what you need in the same way all the other parts in the framework are defined. And when you are done defining your part, you contribute it back to the TTF, so the part is there waiting for someone else to discover it and reuse it.
This makes the TTF a Composition Framework. You can use the framework to decompose existing Tokens to identify its parts and if they don’t exist in the TTF, you add them.
You also use the TTF to define a new token by building as much of the token from the parts that are in the TTF and if you find something missing or could be improved, you add or update it. The more times this process is done makes the TTF better. The more industries and organizations use the TTF it becomes cross industry allowing tokens to be designed to work together. Like Insurance and Finance for documents tokens like a Title or Invoice.
Parts are Artifacts
So, to be a more “formal framework”, we need to use fancy names for these token parts or artifacts. Think of an envelope holding several different documents, each serving a different purpose, that when combined make an artifact.
Artifacts are grouped together, like those tiny screws, so your parts are organized for rapid assembly.
Legos come to mind here.
So, let’s go with that.
An artifact is like a Lego.
We have big Legos for foundations, 2x4 Legos that are common for building most things and then we have all the specialty Legos, like the 1x1, 2x2, 1x1 round, angled tops, etc. Ok, back to tokens.
Templates
A token definition is a template for how to create a specific token. Like the instruction booklets for the Lego set you buy at the store. In the box, you get all the Legos you need to assemble the picture on the box. Just pull out the instruction set and follow the step by step instructions and you will produce a tangible Lego construction. I gotta admit, this process to me is rather unsatisfying, but that is just me.
In this analogy the Token Template is the instruction booklet and the finished tangible result is the Token Class. It is obvious when inspecting the class which template it was created from. You can find other constructed Tokens and know they were created from the same template. Which means, you know how that token works, even if you were not the one who put that specific Lego, I mean token, together.
Token Template = Lego Instruction Booklet
Token Class = Finished Lego Construction from the Template
The part that I dislike about instructions for Lego sets, is following all those step by step instructions and the short-lived sense of accomplishment once it is completed. Most of us, probably discard the instructions afterward and take it apart mixing all the Legos together in a big bucket never to be reconstituted in that prescribed form again. Or maybe that is just me.
With tokens, you can’t do that. Your Token class should always come from a template. That way, when someone else runs into your Token class all they need to know is what template it was created from to be able to know how to use it. This concept allows tokens to be shared on a blockchain and be useful.
When using the Token Taxonomy Framework, you are defining a template that will allow you and others to create classes of from the template that you interact with in a common way.
Big Legos Base Token Artifacts
The largest logical artifacts in the TTF are the base token types, which you typically choose first. Think of this artifact like the big, wide Lego that you use for a construction base.
There are two basic types, fungible and non-fungible that share many common properties but principally differ on their relative value and uniqueness. There are also Hybrid tokens, which allow you to define combinations of parent/child definitions. If this seems obscure, which it is initially, check out the Token Map for background on the basics of Tokens.
Divisible?
Once you have selected your base token type, you need to figure out if you want your token to be able to be divisible. This can be super confusing at first. Money, as usual, comes to the rescue providing us with an analogy. A dollar $ is divisible up to 2 decimal places, so I can have $.50 or $.23 and even add them together to get $.73. A movie ticket token would make no sense too divide. I can’t have .23 of a receipt or movie ticket, unless there is some theater out there that will allow you to watch .23% of the movie. Hmmm.
Behaviors
Most of the TTF consists of behavior artifacts. Some of these behaviors are can apply to any token type like Transferable, Mint-able a.k.a. Issuable and Burnable a.k.a. Retire. These are the most commonly found behaviors and are defined in the base TTF, like a 2x4 Lego.
When you are using the TTF to define your template and there is no defined artifact for a behavior you have in mind, you can just create one. The TTF allows you to describe what the behavior is, provide analogies and define how one would invoke or tell the token to demonstrate the behavior. An artifact is just a collection of files that you create by filling in some standard forms. When satisfied that you have captured the essence of the behavior, you contribute it or add it to the framework. You or others can reuse it in the future in another context.
A behavior reflects some business function of the token like Financeable or Insurable and in the future, you are likely to find a diverse set of them from all industries. These business and industry specific behaviors are like specialized Lego pieces.
Behavior Groups
Sometimes you will find combinations of behaviors that are used repeatedly. The TTF, for example, has one called Supply Control that bundles Mint, Burn and Roles together. When you add this to your template your token will support the minting or issuing of new tokens in the class, allow the burning or retiring of tokens and support assigning a role or group to the mint or issue behavior. The Lego Window piece is a good example.
Composition
Using the base, behavior and behavior groups you can begin building your template. Behind the scenes the TTF requires each individual artifact have a unique symbol.
Weird aspect here, a symbol to represent a token artifact is like a token of a token, kind of.
So, a base token type symbol is either:
Hybrids can be:
for a fungible token class with any number of non-fungible child classes or a non-fungible token class with a fungible class. Hybrids could add multiple classes and one of these could be another hybrid. Which can get complex, if needed.
Behaviors are given lower case letter or letters, usually in italic. The symbols must be unique to the framework. You add a behavior or behavior group to a template definition using braces with a comma between them.
Which brings us to Behavior Groups. Their symbols are UPPER case letters, like Supply Control is SC. So, the template formula above is the same as:
Property Sets
Properties are like data fields for a token. Properties are either behavioral or non-behavioral. A behavioral property means that it is required and controlled by a behavior, like setting its value. A non-behavioral property can stand alone allowing its value to be set directly and is applied to the token base.
For example, the Roles behavior indicates that the token class should support the notion of a role or group that can have members. The role can then be bound to another behavior to indicate that only members of the role can invoke the behavior. I.e. Supply Control defines a Minters role that is bound to the Mint-able behavior. So, the Minters role is behavioral property, meaning that you have to use the Roles Behavior to add or remove a member of the Minters group.
A non-behavioral property might be something like an item SKU or Serial Number. There is no specific behavior tied to these properties but defining them in a property set artifact and adding it to your template means that the token explicitly implements the property so a user of the token will know that it is there.
Both types of properties can be defined in a property set. A behavioral property will have a dependency on a behavior to set its value, usually via logic or calculation that is defined by the behavior. Where a non-behavioral property can have its value set directly by the token owner or another account that has permission.
A property set symbol is prefixed with a:
followed by case insensitive letters that are unique in the framework property set collection. For example:
are the same. To add a property set, you add them to the token formula by surrounding the token and behaviors with brackets [] and +. If more than one is added they can be placed in braces {}. I.e.:
This introduces some properties that can be true or false which you want to clearly indicate the value. So, the above has a behavior ~d where the d is the symbol for sub-dividable the apostrophe means the opposite. So, if applied to a behavior it means that it is not or false.
End
Some key points to wrap up.
- You don’t need to be able to read a token formula, at all. The symbols are links to the artifact’s documentation which contains full words and completely understandable sentences that are used to display the names and descriptions of the artifact or part. The symbols are used mostly by tools and developers to create extensions to the framework.
- This is not a complete overview of the framework but does cover all of the main concepts.
- The Token Taxonomy Initiative will be improving, enhancing and validating the framework over the next couple of months. So, some concepts may expand, or contract and new concepts will be added.
I will post additional articles will be added to the series over the coming weeks to supplement the framework documentation and explain or pose other background topics.
