×

The first step towards bringing your world-changing ideas into action is to use the InterWork Alliance Token Taxonomy Framework to compose your business model of value into a token specification. You begin this process by choosing a token base from a set of classification characteristics that define that token’s basic structure.

The most fundamental differentiator of a token’s classification is the Token Type. Fungible tokens are completely interchangeable with each other. A quantity of fungible tokens and their sum value can be equivalent to another quantity's sum value. For instance, physical currency is fungible, so a one-thousand-dollar stack of ten $100 bills has the same value as a pile of 100,000 cents. Currency tokens would work the same way.

Non-Fungible tokens are not interchangeable with other tokens of the same type, as they typically have different values. A car title is a good example; the title to a 1971 Ford Pinto does not have the same value as one for a 2019 Porsche 911. Baseball cards, comic books, and works of art are similar examples.

Token Unit specifies if there are any quantity or division restrictions for the token. Fractional tokens are divisible - meaning, for example, that a token representing one unit of value could be replaced by five tokens representing .2 units of value each. Currency tokens are typically fractional; other good examples include tokens representing measured solids and liquids that can be subdivided.

Certain items of value make no sense to be represented by subdivided portions, so they would be defined with a Token Unit of Whole to show that they are indivisible and can only be whole numbers. Examples include shopping loyalty points, inventory items, or SKUs which are all treated as wholes because fractions of these items make no sense.

The Singleton Token Unit defines a token where there can be one and only one; it is fully unique. Should anyone ever wish to tokenize the Mona Lisa, that would be a Singleton token because it represents something unique that will never be subdivided or have shared ownership.

The Representation Type defines how things like balances and other value settings are stored. Common tokens share a single set of properties, are not distinct from one another, and have balances recorded in a central place. These tokens are simply represented as a balance or quantity attributed to an owner’s address where all the balances are recorded on the same balance sheet. Common tokens are like money in a bank account. Unique tokens have their own identities, can have unique properties, and be individually traced. Unique tokens are like money in your pocket.

Token classifications will also include Value Type, defining whether the token value is directly reflected in the token itself, like a cryptocurrency, or is a reference of value somewhere else – either digital or physical; Supply denotes how many token instances a token class can have during its lifetime; and Template Type allows for the modeling of more complex business use cases where tokens can have children tokens.

Properties of a token are used to define the information or data a token contains about itself, and how it records its activities. Some properties are set when the token is created, while others are set and updated over a token’s lifetime. How a property is set determines what type of property it is.

Non-behavioral properties can be set independently from a token’s behavior. Good examples of non-behavioral properties are serial numbers and SKUs. Think about it – if you change the SKU of a green t-shirt, its behavior has not changed – it’s still a green t-shirt!

Behavioral properties change as the result of a calculation or logic that is permitted as part of the token’s definition. Consider that all tokens have an owner. Your token may include properties that contain information about the current owner, such as address and phone number. If the token is defined with the transferable behavior - more on this in a moment - and it is transferred from one owner to another, then these behavioral properties will be changed as part of the transfer.

Behaviors are the capabilities of or restrictions against a token or set of tokens. Behaviors are the very business-oriented aspects of a token’s definition, and usually have well-understood implementations in traditional transactional systems. There are many behaviors defined in the Token Taxonomy Framework, and new ones are being added all the time. Many behaviors are available in either-or pairs of opposites. As the pair-wise opposite of transferrable, a token could be defined with non-transferable behavior. Any item of value that cannot change ownership once created – such as an airline ticket – would be defined with this behavior.

To see how these choices all come together to form a composed token, consider how you might then define a set of tokens to represent $100 US bills. These would be fungible, as any $100 bill is equivalent to another; unique properties for these bills, such as serial numbers, are non-behavioral. The bills can be subdivided into smaller bills or coins, they are interchangeable with each other, and they are minted under some form of supply control as defined by the issuing authority. There are more properties and behaviors that can be added to this token definition, but this should give you a good idea how the Framework can be used to compose token definitions for virtually any item of value.