## Why we need a model for token valuations

Tokenomics is an indispensable part of an ICO. Token valuations are hard. With many ICOs failing, there is lots of uncertainty as to whether a token is a good investment. Unfortunately, there is no standard model to perform valuations. In this article I will unravel a theory of token valuations I have been working on, which can be used to answer some of the tokenomics questions that I have been asked again and again.

The model makes the following assumptions:

- We are interested in creating forecasts of the value of a token.
- The total number of tokens issued is a known parameter.
- There are forecasts around the total transacted value over the period of interest.

Therefore, given accurate forecasts of the total transacted value we are trying to create a pricing model for any token.

## The equation of exchange for token valuations

Most of the suggested valuation models right now involve around the equation of exchange. This is a simple tautology coming from monetary economics. Quoting Wikipedia:

where, for a given period,

is the total nominal amount of money supply in circulation on average in an economy.

is the velocity of money, that is the average frequency with which a unit of money is spent.

is the price level.

is an index of real expenditures (on newly produced goods and services).

The left hand side is simply the total amount of money, multiplied by how many times it changed hands. The right-hand side is the total level of nominal expenditures, that is, average price of a good or a service, times the quantity of goods or services.

Vitalik Buterin flipped velocity and the price giving us the following equation:

MC = TH

Where C is the price or the cost of a token, defined as C=1/P, and H is the average holding time, defined as H=1/V. This makes calculations conceptually easier for an ICO.

Regarding M, this is now the total number of coins, and T is the total economic value of transactions.

## Estimating velocity and holding time

Estimating velocity can be tricky. When we have M, T and C calculating H (or V) is trivial. However, what we know in advance is is only M and T. Fortunately, there is an improved version of the equation of exchange: the Cambridge equation.

The **Cambridge equation** treats money as a store of value. This is more suitable for our purpose of evaluating ICOs and tokens. The Cambridge equation assumes that money demand is going to be a proportion of an individual’s nominal income.

Assuming that the system is in equilibrium and money demand equals money supply then this turns into:

So, the velocity is equal to 1/k. That is, the velocity is the inverse of the proportion of money that is held in cash. Given Buterin’s version of the equation we derive that the price of a token is:

C = kQ/M = HQ/M

This equation provides two insights:

- It confirms Buterin’s initial intuition that increasing holding time can increase the valuation of a token.
- It provides a new way to estimate holding time/velocity, as the proportion of tokens that are being held as a store of value.

Note that this equation is not perfect as it ignores the causal relation between the different variables. So, whereas higher holding times will cause an increase in value, in the extreme case where everyone is holding the token, then the total value of transactions would reach zero. However, it is a good start and a very convenient model to use. We can just set the parameter *k* as the proportion of tokens that are not being actively exchanged within a given time window, and hence we can directly estimate velocity (and the holding time).

## Modelling expectations

To recap, in our model we assume that we know the following:

- Knowledge of the total amount of tokens in circulation.
- Forecasts of the total transacted value.
- We can use the total transacted value

Note that while point 2 is the most difficult one, we can always run different scenarios, in order to figure out how the price will react.

What this model is not taking into account is:

- User expectations around price.
- Uncertainty around the price.

User expectations are not easy to model. A proposed way is to assume that users will not accept a worse price than the price they bought in for a period T. This means, that the token value will not drop below the ICO price for some period, but will eventually converge to the true valuation. We can model this using an S-adoption curve and the following equation:

Where S(t) is the expectations curve, which can simply modelled as a modified version of a logistic function.

S(t) = 1/(1+exp(-t - r))

Where r is the *expectations factor. *That is the point in time where the weight between the original ICO price and the real valuation will be completely balanced. Hence, if, let’s say, we are using a monthly time window, and we set r=12, then the logistic curve will look like that over time.

Hence, for the first few months the price will be equal to the ICO price, as the equation above be roughly equal to:

C_t = C_{ICO}

Regarding the modelling of uncertainty, there are two ways to improve the model. One way is to include a probabilistic or statistical model of the S-curve above. A second way is to find a way to calculate confidence intervals around the price of the tokens. This is still work-in-progress and it is covered in another post.

## The framework for valuating icos

Given that, we can calculate the price of token as follows. First we take those 5 steps.

- Decide on a time window (e.g. monthly).
- Set the total number of tokens
*M*. - Set the expectations factor. We can easily assume that at t_0 the price of the token is equal to the sale price during the ICO.
- Set the total demand for the good/service provided by the company for the full-time period.
- Set an average price P in $ for the service provided by the company. For simplicity, we can assume this is stable over the full time window.

An issue we are facing is the interdependency between holding time and token price at a given moment in time. In order to by pass this we just need to use variable values from the previous timestep. An easy (albeit simplified) way to do this is to simply assume that the holding time does not change drastically between timesteps, and we can simply use the holding time from the previous timestep.

We can then calculate the real value of the token as:

H_t = M_{t-1} - T_{t-1}/C_{t-1}

C_t = H_t T_t/M_t

A proper solution would require us to calculate the derivative of H_t or simply break down the calculations in many small timesteps (e.g. model each individual transaction). However, this is something to be researched and for now we can go with this simplification.

Once we have real value of the token, we can use the *token valuation formula* in order to run different scenarios (depending on expectations) as to how the price of the token will move. We can see an example of running such the formula below.

In the figure above we have a hypothetical ICO that is selling at $0.25. The forecasts predict that the total monetary value of transactions is going to be low for the first 1-2 years, but it is going to pick up after that. We can see that according to an expectation factor of 12 months, there is a critical period around months 10 to 18 where declining expectations can cause a drop in price.

## Valuating token economies: Conclusions and further work

The model presented here provides a way to run valuations of ICOs and token economies. This is still a work in progress, with some issues remaining to be addressed. Some of these are:

- The expectations curve can be based on real data. Perhaps a regression or spline model might be more appropriate than a logistic curve.
- The model is not fully supporting confidence intervals yet. A way to achieve that is covered in another post.
- The model is not taking into account speculators or other exogenous shocks to the economy. This could be modelled as an additional noise component based on historical data.

Nevertheless, tokenomics is a new field and any step in the right direction can only help the community. Feel free to get in touch with any thoughts, comments or if you need any code.

## 0 Comments