Token Strength Parameters

How to Judge the Viability, Longevity, and Sustainability of a Token

What Even Are Tokenomics?

As hopefully all of you who read our publication know, Tokenomics go far beyond pie charts and emission schedules, which we see only as the final, finishing touches, built up on a much larger body of work. This is a knowledge gap in the market that we at Tokenomics DAO are here to fill.

Source @mattyTokenomics

How to Think About Tokenomics

Whilst economics are predictive (meaning that, given a rule, we try to estimate an outcome) tokenomics are design oriented (meaning that, given a desired outcome we try and create rules that will encourage said outcome). The reason this is important is that in order to create a sustainable token economic model we need to align incentives between all participants (users), we need to have an understanding of how these users will behave and what they will react/respond to. Thus we touch upon many disciplines such as game theory, behavioral economics & mechanism design to name a few.

We’ve come up with a set of aspects that we feel properly represent how to judge the strength of a token. Thus we bundled these different aspects together and called them Token Strength Parameters (the marketing department always has to have a catchy name you know…) 

So on with it I say!

Tokens Strength Parameters

Simply put, the token strength parameters are: 

• Token utility

• Demand drivers

• Value creation

• Value capture

• Bussines Model

If you’ve been in the tokenomics space for a while none of these will sound new to you. However, there is a lack of standardisation when it comes to what each of these terms means. This is understandable because they are all closely related but tackle slightly different topics and people often get them mixed up. So let's go through them one by one. 

You can see the Token Strength parameters for multiple projects on Tokenomics Hub.

Token Utility

This refers to how the token is being used within the project and by whom. Essentially the token’s use case.

Some examples of token utility include:

• Governance ($UNI)
  Users require tokens to vote

• Gas token ($ETH)
  Users require tokens to access blockspace

• Membership token ($BANK)
  Users require tokens to access a gated community

• Medium of exchange ($BTC)
  Users require tokens to transfer value

• Store of value/HODLing ($BTC)
  Users require token in order to be exposed to asset appreciation. This differs from simple market speculation since HODLers have a much longer time horizon.

Note that in all examples, the token is required by the user to achieve a certain outcome (i.e vote, enter a community, transfer value, etc).

Demand Drivers

A quick TLDR on demand:

Demand for a token comes from 3 sources; 

1. Token Utility
   The user requires the token to use it within the project.

2. Demand Mechanisms
   The user is incentivised to buy the token because it is required to achieve a certain goal within the project, this is closely linked to Token Utility but does not always mirror it.

   A demand mechanism is simply a method/process/requirements that encourages the user to buy a token, thus creating demand.

3. Speculative vehicle
   The user buys the token because they believe it will appreciate in price, there is a myriad of reasons behind this such as brand, hype, reputation, security, etc

Notably, these are ordered with respect to how much control the project has over each type of demand source, from most control to least. The project has the most control over its token utility which is linked to usage. It has control over any demand mechanisms that it puts in place, but less so than direct demand token utility. It has little to no control over speculative demand since this encompasses many aspects that are out of the control of the project

Demand Drivers refer to who is buying/holding the token and why. Essentially, the factors that drive demand for a token. 

As stated above, demand can be thought of as coming from utility, demand mechanisms and speculation. We’ve already covered some cases of token utility (which means that there is a requirement for the token and thus demand).

Some examples of demand mechanisms include:

• Staking (xSushi)
  Users need to stake a token to receive additional tokens via incentives, this can either come from emissions (i.e inflation) or via a buyback of the token which then gets distributed to all stakers (xSushi)

• Stake LP (veBAL)
  Users need to stake LP token (one of which needs to be the project token) to receive yield on their liquidity

• veTokens (veCRV)
  Users need to lockup tokens for a certain period of time to receive voting power and yield (emissions and fee share)

• Options (oTAP)
  Users are incentivised to purchase the token as an option

• Collateralisation (AAVE)
  Users can use the token as collateral on money markets, thus are incentivised to buy and deposit it to earn yield via interest

• Relics
  Users are incentivised to maintain their liquidity position since rewards are based on time in position.

The keen-eyed of you will have noted that this is where game theory walks in and becomes relevant. Game theory is a way of studying how people make decisions when their choices affect others. It helps us predict and understand behaviour in competitive or cooperative situations. The demand mechanisms described above all have to take this into consideration since users’ behaviour responds to incentives. These incentives are shared between whoever interacts with them, creating a competitive and cooperative environment. 

Value Creation

This refers to how the project is creating value and for whom. Value is created when a problem gets solved. It should be noted that if the problem that is being solved is closely linked to the token’s necessity within the project then the value it creates is strongly linked to demand for the token (it can drive demand – i.e it’s a demand driver). 

An easy way to think of the necessity of a token is as follows: if the token is closer to the “completely necessary” end of the spectrum then the problem that the project has set out to solve cannot be solved without the token. If the token is closer to the “Adjacent” end then the problem can be solved without the token.

 A prime example of this is the Bitcoin network, the problem that Bitcoin is solving is that of sound money (amongst other things), this couldn’t be achieved without the $BTC token, thus it is completely necessary meaning that the token itself is the value creation (i.e holding $BTC that is a form of sound money) and therefore directly related to demand.

Value Capture

This refers to how the project is capturing the value it creates. Essentially, if value is being created then it has to flow somewhere (ideally to wherever the project deems most viable).

Two types of value capture exist:

(1) Value accrual to the project
Value that is being directed back to the project itself. This normally takes the form of a percentage of revenue/assets being directed to back the treasury, i.e owned by the project
In some cases, projects opt for decentralisation and allow the value they accrue to be controlled by token holders, we’ll cover what this means in the Demand Drivers section

(2) Value accrual to the token
Value that is being directed back to the token. This is also known as token mapping since value created is being mapped onto the token. There is yet another distinction that we can make here:

Direct token value accrual: revenue created by the project is used to manipulate the supply/demand dynamic of the token.

Manipulating the supply/demand dynamic essentially implies the balancing of the two, since price (also known as equilibrium) is the intersection of supply and demand, thus by constraining supply via locks, burns, buybacks, and more, we can affect the price of a token.  

Indirect token value accrual: revenue gets distributed to token holders.

The reason that this accrues value to the token is because the token acts as a requirement to receive revenue share –and thus is a type of demand driver whose premise is to incentivise users to constrain supply so as to manipulate the supply/demand dynamic. Simply put, users want to earn yield and thus will buy the token to do so. Indirect value accrual does not have the same effect as direct value accrual since it is not affecting the supply/demand dynamic directly.

Value Accrual to the Project Examples

Some examples of value accrual include: 

• Project Owned Liquidity (Tokemak $TOKE)
  The project owns and deploys its own liquidity to DEXs, thus accruing the trading fees and accruing value.

• Bonding (Olympus $OHM)
  Users bond assets in exchange for a vesting token which represents the underlying token. Once the token has vested the users receive the underlying token. The reason this accrues value to the project is that the vesting token normally comes with a discount on the market rate, thus users are incentivised to purchase the token directly from the project rather than on the open market, and therefore the project receives the value directly rather than the sale going to a third party market maker.

• Options (Tapioca DAO $oTAP)
  This is very similar to bonding but the main differences are that users have to option to buy the underlying token once it has vested. The reason this accrues value to the project is however the same as that of bonding: value is going directly to the project rather than the market.

• Token Tax
  A form of tax that can be used on buying and/or selling of a token. This tax goes back to the project.

• Revenue split
  In many cases, revenue is split between token holders and the project itself, meaning that the project accrual value via its cut of revenue.

The crypto space is a vast smorgasbord of use cases and possibilities, thus I simply want to point out that value accrual to the project occurs whenever a part (or all) of the value created gets directed back to the project itself. This may be due to there being a cut on transaction fees, tax on buy/sales, some form of asset bonding, etc

As mentioned, value accrual to the token can take the form of direct and indirect mapping. Some examples include:

Direct 

• Token Buybacks
  Tokens are purchased from the market by the project, thus constraining supply and affecting price. It is irrelevant for this discussion what these tokens are then used to do (i.e burn or make) since the important part is the manipulation of the supply/demand dynamic.

• Staking
  Users are incentivised to stake a token, thus constraining supply and affecting price.

• Locking
  Users are incentivised to lock a token, thus constraining supply and affecting price.

Staking allows users to sell tokens anytime while locking requires waiting for tokens to be unlocked before selling.

Indirect

• Token Burning
  This is one that many people misunderstand. The premise is that tokens get burned by the project upon value creation. If the project has to first buy them back from the market in order to burn them then it is simply a token buyback (as mentioned above, it is indifferent to the supply/demand dynamic of what is done with these tokens after the buyback occurs).
  That leaves the possibility of burning tokens that are not circulating (essentially reducing max supply) upon value being created accrual. Remember that price is the product of circulating supply and demand. So in this case, there is no direct manipulation of the supply/demand dynamic and the only effect that it has is a speculative one.

  

• Yield
  Users want to earn yield on their assets and thus will buy a token if it grants them access to token emissions (via staking) or a share of the revenue produced by the project (via revenue share).

Business Model (BM)

Web3 is the business model for open source, and it seems to be working. Having a sound business model means being able to consistently turn a profit in a sustainable fashion. 

How the BM affects Utility, Demand Drivers, Value Creation, and Value Capture 

Token utility, demand drivers value capture, and value creation all have a monetary aspect to them that glues them together. The business model employed by the project is a crucial piece in determining its sustainability.

• Utility
  The reasons that a user would hold a token is because they need it to perform a certain task or they expect some form of monetary gain. The BM relates more to the latter in this case.

• Demand Drivers
  All demand drivers are related to incentives (i.e what the user gets in return). The reason the BM is relevant here is because of the value of the project.

• Value Created
  Value is probably the parameter that is least linked to BM since a project can create a ton of value without explicitly having a strong business model.

• Value Capture
  The business model also affects value capture (both accrual to project and token) since if the project is not accruing any value to its treasury it is not gaining value and if it does not have any value then there is less of a reason for users to hold the token. Furthermore, if the project uses any form of token value mapping (i.e supply/demand dynamic manipulation) via direct or indirect methods, it will not be very viable since the project is not generating any revenue which will be able to sustain these operations. 

User Behaviour

Users have some effect on all of the above parameters, meaning that we have to have an idea of what the users’ desires and motivations are to understand possible actions.

This is where behavioural economics and mechanism design come into the picture. 

Users respond to some form of incentive, we can design mechanisms to encourage alignment between users and the project.

Our goal (as a network/project) is to have users perform a desired task that brings value to the project. As general network traits, we’re looking to increase engagement, retention, and longevity. In order to achieve this, it is useful to understand the user’s motivation for engaging in the network/product so that we can align behaviour.

We can divide motivation into two types.

Generation Motivation

Underlying motivations for engagement are financial rewards and status.

Specific Motivation

Specific motivations come in multiple forms and can have varying effects on engagement.

Many people assume that only financial rewards are the key motivator for user engagement, this is not true and it is important to determine if there are other user motivations because we cannot incentivise a user to perform a desired task if they’re not interested in the reward in place. Essentially, users will react differently based on their interests and reasons for engaging.

Token Strength Parameters and User Behaviour 

Remember, one of the fundamental principles in economics is that:

People respond to incentives.

Yet, this feels incomplete. As we touched on above, the two types of generic motivation for users are financial and status incentives. People will respond to incentives but only if said incentives are aligned with their desires.

Bob: "Alice, would you help me finish my article for me?"

Alice: "Sure, I can help you out. But what will I get in return?"

Bob: "I can pay you in dollars."

Alice: "Money is not a problem for me. Can you credit me as an author instead?"

Simply put: 

People respond to incentives that align with their desires

Financial Reward

We’re all very familiar with financial incentives since they’re the easiest to understand and encounter on a day-to-day basis, some examples include; receiving cashback for using a credit card, getting a bonus for meeting work-related goals, receiving a commission for making a sale, etc). 

• Utility
  Users are interested in token use case having a close link to asset appreciation and/or yield. This means that the project has to have a good understanding of what value creation looks like and the token has to be woven into this tightly, essentially, more use = more value = asset appreciation. Thus aligning with users' desires and their behaviour should follow suit.

• Demand Drivers
  User is interested in a strong feedback loop to asset appreciation and/or yield via any demand mechanisms put in place by the project.

• Value Creation
  User is interested in monetisable value, thus if there is not a strong link between the value created and the token (via demand drivers) then there is less of an incentive alignment between the users and the project

• Value Capture
  User is interested in a strong value accrual mechanics in place to either (1) map value to token or (2) accrue value to the project. Note that when it comes to the latter, this only aligns incentives between users and the project if token holders have some form of control over said value being accrued (i.e via governance). The extent to which they can control value has an indirect demand driver effect on the token.

• Business Model
  Users are interested in a strong business model that is not extractive but not weak either. It needs to permit growth but also have a strong link to value accrual which as mentioned above can either be directed back to users or to the project itself (granted token holders have governance rights over this value).

Status Motivation

Status incentives are a little harder to see but nevertheless very prevalent in day-to-day life, some examples include: earning a high score or ranking in a game or competition, being acknowledged publicly for contributions to a community or cause, achieving a certain level of followers or subscribers on social media platforms, etc

In the case of web3, status is represented as governance and reputation.

• Utility
  User is interested in utility having a close link to reputation and governance. In either case, actions earn reputation and/or voting power which results in a non-plutocratic system.

• Demand Drivers
  User is less interested in demand for the token since this results in asset appreciation if balanced properly with supply. If the project does not care about token price then this can be ignored, if this is not the case then the project has to find a way to link token demand to status. An example here would be some form of reputation decay whereby only those who provide value maintain their reputation/status level and those who don’t have to purchase it, creating demand. However, this again becomes a plutocratic system since reputation/governance can be purchased.

• Value Creation and Value Capture
  Value creation and value capture are joined at the hip when thinking about the status aspects for the user since they’re interested in the reputation/governance that they have gained increasing in value, by value I am not referring to monetary value but rather influential value. If a user gains reputation/governance in a project and then said project skyrockets in importance their status/voting power has gained in influence.

• Business Model
  User is less interested in the business model outside of its functioning as a means of propagating the project and furthering development.

Summary

Token strength parameters are crucial for sustainable projects that have incentive alignment and aim for longevity, viability, healthy engagement, and retention.

No matter if you’re a user, an investor or a builder, the key takeaway for you is to identify each of these parameters for the project you’re looking into. 

This entails: 

1. Understanding how the token is used within the project (Token Utility)

2. Understanding what effects that may have on demand and any other demand mechanisms put in place by the project (Demand Drivers)

3. Understanding how the project will capture the value it creates (value capture) 

4. Understanding how the business model ties into value capture and where the value is flowing (Business Model) 

5. Understanding the value created by the project (value creation)

6. Understanding how users will respond to the incentives put in place by the project based on their desires 

The easiest way to get into the habit of looking at a token like this to see how it applies to projects you’re familiar with. This tool lists the token strength parameters for a myriad of projects.