Tokenomics Explained – Tokenomics Depends on the context

The following article may prove extremely helpful and insightful for founders of various projects who wish to implement blockchain technology in their industries. If you plan to design a well-thought-out tokenomics and learn about its challenges and stages, this article is for you. You will learn from this text about things you probably didn’t know, which are crucial for creating successful projects. We will show the key steps of tokenomics construction. We will also present the tools for developing and testing the tokenomics model.

Are you an investor? Do you seek answers on how to assess existing projects’ tokenomics? If so, we encourage you to read on. To invest wisely and avoid unnecessary costs, you must understand the crypto projects basics. This means knowing how to evaluate specific web3 solutions. By knowing the key criteria, you may notice that most released projects are incomplete, as they often lack well-thought-out token’s utility and context.

You will learn about

1. Why does tokenomics depend on context?
2. Why token-based projects are highly complex systems?
3. Tools and processes to address all challenges related to tokenomics

Tokenomics Table – Let’s start with the basics

When founders start designing the tokenomics for their projects, they face filling up the tokenomics table. These include rounds, token allocations, price, cliff, vesting, issuance schedule, and Token Generation Event (TGE).

Round: It’s token allocations where we assign a number of tokens to specific agents or pools. It usually involves fundraising (ex. initial coin offerings) or token sales, as well as outlining future token utilization within the system.

Token allocations: In a token release plan or cryptocurrency project, we set the number of tokens available for each round or sales phase. Token allocation and maximum token supply is crucial as it sets a quantitative limit that will be made available to investors and token holders during a specific period.

Price: For each sales or investment round, a set price is established at which investors can purchase tokens. The price may vary by round. It also may be based on factors, like distribution terms, project evaluation, or stage of development.

Cliff: During this period, participants do not receive tokens and regular token vesting begins afterward. Cliffs determine when token release starts, their length varies based on allocation goals. 

Vesting: Tokens are given out gradually over time. This is often done to encourage long-term participation or engagement in a cryptocurrency project. It addressing positive user behavior to control inflation.

Token Generation Event (TGE): It is an event of the tokens’ issuance process when they are created and given to participants. It usually marks the start of a new cryptocurrency project or the release of tokens for public sale. In tokenomics table projects are describing how many tokens will be released to circulation during this event.

Popular (but wrong) tokenomics design market practices

In the classical approach, several popular practices regarding these dimensions in the market can be observed:

1. The first approach involves copying values from the tokenomics of an already existing project. This idea is based on the assumption that if something worked for someone else, it will also work for us. Sadly, this is usually not true, specially when we ignore differences. These include community adoption, marketing, investor attitudes, monetary policy and market trends.

1. Establishing arbitrary, fixed, or static values. During planning, we may set ourselves arbitrary values that seem to fit our strategy and make general sense, but due to the dynamic and complex nature of projects and the crypto market itself, such an approach is not good enough.

1. Practices based on psychological tricks or superstitions are also evident. For example, using the numbers based on positive associations in some cultures without any real reference to this value in mathematics. Such an approach shows immediate motivation behind the speculative approach, which is not sustainable in the long run.

Most people primarily focus on funding aspect and token’s price when building tokenomics. However, from our experience, these values are often imposed by the negotiation process between founders and different groups of investors. In the project phase, there is often a struggle for dominance and shares, where everyone strives for the greatest profit for themselves. By focusing only on the funding and allowing for a struggle of interests, we may miss other important views on tokenomics in crypto space.

Tokenomics depends on the context

Our approach assumes that, before making mechanisms and values in tokenomics, we must first define the context of our crypto project. We can use an analogy with a shape sorter, a popular toy for children that involves matching a block of the appropriate shape to a corresponding hole in a box. To correctly fit the block (symbolizing our tokenomics), we must first look at the shape we need to fit it into (the project’s context). Sometimes, we may manage to force any block through an inappropriate opening, but such projects usually end up falling apart sooner or later.

In theory, with a clear definition of the project’s context, changing variables seems easy. We know what we want from our token and can adjust the crypto project’s parts to fit that story. But, the situation is far more complicated.

Even if we only talk about the funding context, many key questions will arise:

– From whom will we raise funds?

– Under what conditions?

– How will we design liquidity? 

Note: Liquidity is a key metric, which, along with the token’s total supply and demand characteristics, affects our token’s price.

Contexts

We can identify many different contexts in the world of web3 to which we adapt token utility and a given tokenomics model.

Funding

The funding context mentioned earlier deals with exchanging tokens for investors’ funding. Token sales let creators ensure a steady stream of funding. It pays for the project’s ongoing needs. It’s necessary to define the conditions under which fundraising for token holders will take place, from whom, and in what quantity.

GameFi

This category encompasses blockchain-based games where tokens can be used as in-game assets or additional currency. It’s important to understand that a game is a separate system where we introduce a new token system. For example, when users pay by the token, and it serves as currency, we create an in-game monetary system. So, we must carefully consider its tokenomics. It is needed to keep the gameplay balanced. We must ensure:

• Economic stability, so the game operates and remains playable. If the designed token is economically unstable, it will disrupt the proper functioning of governance tokens in the game.
• Supervision of hyperinflation, pump and dump schemes, and price manipulation to prevent it.
• Adequate circulating supply is key. A bad token supply design may drain the pool, hindering the game’s goals, character development, and add-on purchases and making it stray from its original idea.

DAO (Decentralized Autonomous Organization)

These are decentralized organizations where governance tokens are used to vote. A bad projected system can lead to monopolies, when one person may control the voting take assets, and destroy the system. In DAO governance, tokens are vital. They empower holders to validate transactions, raise funds, and join decision-making. It’s essential to define clearly:

• Who can propose votes.
• The type of voting (e.g., single or multiple choice).
• The method of calculating the strength of a single vote.

DeFi (Decentralized Finance)

This involves decentralized financial products such as loans and on-chain ETFs. Financial tools mimic the traditional market, but they allow for designing financial products on new principles on smart contracts in a web3 environment. This adds unique value for projects and investors. Tokens in the DeFi context often serve as a balancing factor for the system and its mechanics. 

For example, the project we worked on was an on-chain ETF where the token balanced the system. A significant challenge was the flow of illiquid assets – NFTs into more liquid utility tokens and vice versa. Properly managing the token’s supply, as well as high volatility and dynamics, was essential. The protocol also needed protection against liquidity drains and oracle attacks. These issues could disrupt prices when the protocol relies on current market price data from different sources.

Protocols / Infrastructure / DePIN

Protocols are often used to build blockchain infrastructure or networks. They provide tools and a space for making decentralized exchanges and applications. Tokens in these projects are a reward system. Users are motivated by the possibility of earning rewards. They get rewards for participating in the network, providing resources, or keeping it secure. 

For example, we collaborated with a blockchain data analytics company. The company’s revenue came from owning, analyzing, and processing data. They wanted to cut infrastructure costs. They also wanted to diversify geographically. This ensured the system’s response time was as fast as possible, no matter where their clients were. Decentralization was the answer to these needs. The token in this system served a motivational role. It rewarded users who maintained decentralized network infrastructure.

Although it did not have a financial character, proper economic design was still necessary, including token distribution, a reserve in FIAT or stablecoin, and evaluation criteria for when decentralization is optimal.

Web 2.5

This sector combines the current online world with innovative blockchain solutions. This narrative encompasses e-commerce services and loyalty systems. 

Based on our collaboration with a project from the web2.5 sector, we know that the challenge lies in the comprehensive integration of all dimensions:

• Designing a well-functioning real-life loyalty system.
• Implementing real solutions in blockchain technology.
• Ensuring the token functions correctly in all system processes.
• Integrating the token with the entire existing infrastructure of the e-commerce platform.
• Ensuring that despite commissions trading fees and taxes on the token’s path, the token burning entire loyalty campaign makes sense and is profitable.

After reading this section, you know about different contexts tokenomics can have. You know their specific issues and challenges. You also see the importance of considering different audience groups and their interests. Therefore, it becomes evident that tokenomics indeed depends on the context in which it is built and how crucial it is to define it properly, which creators often overlook.

What problems does this create?

Issue I: Founders often don’t truly understand their system.

Founders often start a project without a clear understanding. They lack a vision for the project’s appearance, how to build it, its exact behavior, or its purpose and function. This is not surprising. Such systems are very complex and most of their behaviors cannot be predicted at the start of design. When Tokenomia.pro comes in, we can ask the right questions thanks to our experience. We use them to find and uncover the client’s vision.

Issue II: Multiple contexts within one project.

As we know, it’s essential to consider the appropriate context when designing tokenomics, which often results in a series of challenges. But, we typically deal with many contexts at once. This complicates the process. We can easily imagine or recall projects where tokens fulfill the funding context, being the hard currency in a game (GameFi) and serving as governance tokens in voting processes (DAO) all at the same time. The project results in a complex infrastructure. It considers the needs and challenges of all contexts at once. Designing these projects is harder. It’s hard to predict how the system’s mechanisms will behave. As things get more complex, the chance of weaknesses and threats goes up. These threats are special for each context, so they can destabilize the whole system.

Issue III: System within a system.

System designers often overlook the interaction of outside variables with their crypto projects. The entire system described above, along with its context or even multiple contexts, must be fitted into a larger system, such as a blockchain. So we should consider different variables, including, for example, sentiment towards a particular blockchain, large fluctuations in a particular cryptocurrency, or, in extreme cases, even the collapse of an entire network.

What complex systems are we dealing with?

When we begin to understand tokenomic systems better, we also see their complexity. There are many mechanisms in our system, and if they do not work properly, they can disrupt its proper functioning. It is also important not to ignore the impact of external factors on our tokenomics.

To better illustrate these abstract examples, let’s use a metaphor from real life – a suspension bridge.

Let’s go back in time to the first half of the 19th century. This period saw pioneering solutions in the sector of building suspension bridges. These were times of very experimental bridge building. Most of these bridges were put into use without any safety guarantee. Unfortunately, over a short time, a significant portion of these bridges collapsed. That happened because engineers didn’t understood their operation’s dynamics. Nor were the effects of forces like wind or load. Thus, these massive structures were built through trial and error. Nowadays, such an approach may seem absurd, to expose bridge users to such a huge risk associated with their possible collapse.

Returning to the present, people are always pioneers in some sector. Despite 200 years passing, we still often let users use unverified solutions to make their life more comfortable, at least in theory. In web3, we often see a haphazard attitude. It involves abandoning old, failed projects for new ones with fewer errors. We forgot that, as system designers, we are somewhat responsible for the time and money that users invest. So, as end users, it is worth considering who is behind the system we want to invest in. We should look at the skills and intentions of the designers. Estimated losses only for incorrectly designed systems are estimated at over $600 million. This value does not include errors in the code, and the mere fact of poorly designed mechanisms, pools, or the lack of consideration of the forces of external system interaction on the dynamics of the internal system.

Our high-level process for tokenomics design

Phase One – System Requirements

First, we need to set the initial assumptions the system should meet. We can later check them in simulations. We outline how individual mechanisms are intended to function and determine their economic goals. Both we and the project creators must understand the exact metrics. We want to use them to optimize the system.

We describe processes and relationships between assets, agents, pools, or mechanisms. They are described as mathematical specifications. This is an organized set of mathematical formulas that faithfully reflects the previously described and mapped system. The math specification turns ideas and assumptions about the system into a clear math description. This lets us precisely understand how individual parts work and how they relate.

Based on this, we create system maps and construct flow diagrams. We visually show our resources. We show how they affect the system and their dynamics. We also show the dependencies between them. We can identify sectors where adding new tokens would be helpful by understanding the assets and mechanisms in our system. Visual aids help represent the system. They also show organized knowledge and convey it to the client clearly. Then, we describe all dependencies between system components. These include revenues, expenditures, and relationships, which are given as math.

All of the above points constitute the core of our system and are documented in a single document – the Model Design Document, which we provide to our client. This specification of the entire system serves as a starting point for Phase Two.

Learn how we implemented System Requirements for our client

NFT Customer Engagement Platform with Tokens Cashback

Who will benefit from this case? If you want to know how to combine e-commerce with blockchain, this use case is for you. Below is an example of work for our client that represents a combination of two worl

LEARN MORE

Phase Two – System Model

The purpose of this phase is to transfer the entire system into virtual space. We build a model that mirrors the mechanisms, agents, flows, and dynamics of the entire system. A digital twin of our system will allow us to verify the work done so far, check how our proposed ideas integrate into the whole, and identify errors or potential threats.

The created model can be used throughout the project’s lifecycle, conducting further simulations on it even after the project has been released, updating it, and continuously supplying it with new data to make it increasingly accurate and reliable, thereby better replicating the system’s dynamics and enabling more precise simulation results.

We use advanced simulation tools to build a dynamic model. It’s based on the specifications from the initial phase. This model lets us simulate many scenarios. It is the foundation for key project decisions and continuous adaptation. It ensures that our strategies stay effective and responsive to change.

Tokenomia.pro specializes in low-level modeling. Based on mathematical specifications, descriptions of mechanisms, and agents along with their motivations, goals, and behaviors, documentation with simulation guidelines is built in the form of differential specifications. We graphically present the entire specification to aid client understanding. For each mechanism, we define business logic, states, metrics, and parameters. This later forms the basis upon which we write code in the cadCAD framework within the Python environment. This is a particularly popular framework in the cryptocurrency space, where projects involve numerous variables and unpredictable interactions.

We develop a digital twin model of the entire system and simulation specifications in the form of differential specifications. CadCAD helps simulate hundreds of different scenarios to see potential outcomes and make appropriate changes in system design. It is used by top-tier projects such as Ethereum, Balancer, and Gnosis. It is a multidimensional digital representation of the system and all its components. All metrics, inputs, and parameters replicated in the code can be adjusted and changed as changes occur within the system. 

Note: A thoughtful description of agents, enriched with assumptions from behavioral psychology, allows for finding agents with conflicting interests, as well as considering different numbers of agents depending on the simulation scenario.

Learn how we implemented System Model for our client

GameFi Free-To-Play fusion of Trading Card Game & Board Game

Who will enjoy this case? This use case will interest people who want to incorporate crypto-economics into games or other entertainment platforms (GameFi). Web3 gaming is gaining popularity. There’s a

LEARN MORE

Phase three – System Validation

The final phase of the work is validating initial assumptions. For this purpose, we conduct hundreds, and sometimes even thousands, of simulations. Each scenario has different values for specific parameters, different numbers and behaviors of agents, and more optimistic or pessimistic assumptions about external forces and supply and demand conditions. We also conduct extra scenarios to find the biggest risks, boundary values, and sensitive variables.

Only now can we start talking about Tokenomics. It is the culmination of all the previous phases: we know the context, we know the system, we understand the system within which our system operates, we have a model, and we can validate the assumptions, understanding how the system will behave.

Note: This is an iterative process. We may need to return to a previous step at each stage and change some assumptions. After the validation and recommendation stage, the client may need to check alternative scenarios. They may ask questions like “What if?” Also, as the project develops and we get new data, we can update the system. We can then simulate it more accurately and change specific parameters.

We build simulations based on the designed system. We check the initial project assumptions. We do this with a full analysis of the system. This includes simulations of user numbers, resource changes, supply and demand fluctuations in both cryptocurrencies and traditional business elements. This phase involves rigorous testing in hundreds of scenarios to assess the system’s response to various internal and external forces and to identify necessary modifications, ensuring the project’s adaptability to current and future needs, including secondary market behaviors and token issuance strategies.

Each scenario is a different combination, consisting of different parameter values and variables. We consider a different range of probabilities in A/B testing, Monte Carlo, and parameter sweep. They more accurately replicate dynamics and high variability, and thus probable system behavior. Hundreds of different scenarios generate huge amounts of data and charts. An automatic report is generated for each one. It describes the initial assumptions and specific scenario results.

The collective result is a document in the form of a final report, presenting conclusions and correlations found during the analysis of all scenarios. The report also includes advice on which situations to avoid. It covers what poses the greatest threat and how to defend against it. It also explains the top opportunities and how to maximize them. It has other relevant observations and comments supported by simulation data.

Learn how we implemented System Validation for our client

DeFi Onchain Economics Validation

Who will benefit from this case? This use case may interest people near the final stages of releasing their token for the DeFi Project. They want to do an economic audit of the project to ensure its securit

LEARN MORE

Tokenomics Design – Our approach

We mentioned at the beginning that when specifying values for parameters like rounds, tokens, price, cliffs, vesting, and TGE, people use various strange practices. Our strategy is to set values for these mechanisms and parameters as dynamic functions. The functions depend on parameters important for the entire system. We know the most important system goals thanks to the earlier mapping and validation. In many projects, it is hard to determine specific values in advance. But, web3 solutions have an advantage by making dynamic changes depending on conditions recorded on the protocol. These conditions can be internal or external. For example, the vesting time can vary. It does not have to be a constant value. Instead, it can depend on conditions met by users.

Conclusion  

Based on our extensive experience, the work on the project is divided into three phases, as described above. Thanks to this, we can oversee the efficiency of the design process. It also shows the specific stages. After each, the client can check the previous part and its assumptions. The final result of work on the above phases is a full picture of the tokenomics of a project. Its context, goals, agents, and mechanisms have been defined. The entire system has been visually mapped out in the form of Stock & Flow. All processes and relationships have been described using mathematical formulas. A digital twin of the system has been built in cadCAD in Python. We validated the entire system by running hundreds of scenarios. Based on these scenarios, we made a detailed report on how the system’s changes work and developed a series of recommendations.