Velocity in the context of token valuation
The network effect is a widely used methodology to value (utility) tokens. In a nutshell, an increasing number of users implies a higher valuation of the token ecosystem. A widely cited criticism within this framework is the high token velocity problem.
The concept of velocity is taken from another economic theory, the quantity theory of money.
MV = PQ
The components of above equation, loosely applied to a tokenised ecosystem, can be described as follows:
M: Market cap of the circulating tokens (the aggregated token value)
V: Token velocity (the number of times a token changes hands)
P: Cost price of the “utility” provided (dApp consumer cost)
Q: Number of transactions
Intuitively: P x Q is the gross domestic product of the ecosystem calculated as the consumer cost of one transaction multiplied with the total number of transactions, i.e. the total spent. M x V is the money supply within the ecosystem calculated as the market cap multiplied with token turnaround. In our quest for a valuation method, we can derive market cap by re-shuffling the formula.
M = PQ / V
Example: decentralised Uber connecting drivers and passengers directly.
P: $10 per ride
Q: 1,000 rides per year
V: on average, a token changes hands 10x per year
Market cap = ($10 x 1,000) / 10 = $1,000. As the circulating number of tokens is given at any point in time, token price is a simple division of market cap by number of tokens.
Problem? In the above set-up, it should be clear that a high velocity will shrink the market cap needed to make the equation balance, intuitively you require less market cap value to match the ecosystem’s total spent in case of a high token turnaround. In the above example:
- if velocity is 1,000x, market cap is $10
- if velocity is 1x, market cap is $10,000
The total spent in both cases remains $10,000, but a differing token velocity has resulted in two significantly distinct valuations.
At this stage, with the velocity problem hopefully defined, we can reflect on the implications for token design. Many tokens are flawed, constructed merely as a Medium of Exchange, however if we incentivise users to HODL the token it can become Money.
Medium of Exchange tokens have no mechanism to slow down the token velocity. In the dUber example, imagine the token serves solely as a value transfer mechanism. dUber passengers will interact with the blockchain via APIs and pay for the service with Fiat (or BTC), the non-userfriendly tokenisation will be hidden from the end-user. In a fraction of time: passenger pays with Fiat > API converts to dUber token > token sent to dUber driver > driver converts back to Fiat. With nobody incentivised to HODL the token, the supply is endless, velocity is infinite and resulting token price equilibrium near zero.
Consideration — The actual token price in above example is irrelevant in the transaction flow; the $10 ride equivalent can be transferred via 1 x $10 token or 1,000 x $0.01 tokens without further impact.
A Medium of Exchange token can become Money if people are incentivised to HODL the token (and as such slow the velocity). Masternodes, staking and profit sharing are a few examples. In the dUber example, one can implement driver staking for network participation, passenger staking for discounts, etc.
Consideration — Even Fiat’s main purpose is Medium of Exchange, but as people have come to believe it holds future value, they are happy to HODL on a bank account as Money. Bootstrapping that same MoE into Money belief is the difficult hurdle tokens need to overcome.
Well-designed (utility) tokens can function and hold value as Money within a confined niche digital ecosystem.
Consideration — Many existing tokens are flawed, but I believe projects can retro-actively tweak the model to reintroduce value. Of course, entirely up to the team’s discretion, one can only hope the right team incentives are in place.
In a follow-up post I want to discuss the merit of tokens as Money. Why invest in token Money? Is volatile token Money practical? Is the complexity of token Money needed? I believe a dual-token structure (staking + stable token) can simplify the discussion.
Acknowledgements — My summarised observations are inspired by a multitude of other (more extensive) posts by, i.a., Chris Burniske, Tushar Jain, Brendan Bernstein, Alex Evans, Ashley Lannquist, John Pfeffer