Introduction
Crypto systems have the potential to create significant amounts of value through the provision of new services and the enhancement of existing. However, it is not clear how much of this value the tokens themselves will actually be able to capture. This series of posts will study tokenisation strategies, how effective they are at capturing value and how well they perform their intended role.
Having established the traits of a less-valuable token, we are then able to identify and suggest traits of more valuable tokens. I will refer to those displaying higher value traits as ‘true utility tokens’ and ‘equity-style security tokens’ and I will discuss both in detail in my next post. But for now, let’s start by looking at where things seem to have gone wrong…the ‘utility’ token.
Part 1: The (dis)utility token
Whilst cryptoland seems very keen to classify coins as ‘utility tokens’ in order to prevent extra regulation and disclosure, it’s worth taking a step back to study the underlying financial value of this so called ‘utility’ with the help of some ‘tokenomics’.
In what follows, we will take a look at a generic crypto ‘utility’ token and see how it may confer very little utility and, as a result, may capture very little value. We will also look at common approaches to improve the tokenomics of this utility coin, and find that many of these approaches could prove fruitless.
But do not despair crypto hodlers! This does not mean that all utility tokens are worthless, it just means that the current plethora of tokens resembling this example are in fact probably not ‘utility tokens’ at all.
If The Far Side did ‘utility’ tokens?
Tokenisation strategy
An entrepreneur, Alice, wants to open a shop and has two options to finance this. Traditionally, she could sell future cashflows (equity or debt) in the project to raise the funds needed to set up the shop and buy inventory. Once operating, Alice may redistribute the profit she made at the end of the year to equity holders in the form of dividends.
If the project is successful, both Alice and the equity investors stand to benefit. If these shares were in crypto format instead, with accompanying tweaks to the assumptions and holder’s rights, we could call this an ‘equity-style security token’. More on this to follow in my next post, stay tuned.
Advancing from this traditional method of funding, one of the reasons that people got excited about crypto was that it offered Alice a different way to finance the shop- through the sale of so called ‘utility’ tokens, let’s call them ShopCoin (SCN). Since the shop will only accept payment in SCN (to promote customer loyalty, says Alice) a customer will need to buy these tokens in advance if they want to visit the shop.
These tokens may seem attractive to customers living nearby who will want to visit the shop if the tokens are sold at a discount to ‘fair value’ for early supporters, and even more so if it is known that Alice plans to later open more shops across the country that will only accept the same (finite) SCN for payment.
In addition, there may be people living far away who will never visit the shop but want to buy these tokens to speculate on their future demand. In effect Alice has ‘forward sold’ her future revenue for a discount, receiving cash upfront today. The customer/speculator has received a scarce asset for less than they think its worth. Apparently, both Alice and the early customer stand to benefit.
Sounds familiar huh? Add on some technical bells and whistles and you have the sales’ pitch for the ‘utility’ token of a generic crypto project today. We’re now going to see various potential problems with this proposed token function, and why in fact it could offer very little utility (and value).
Problems
- Non-fiat pricing
The items in the shops are not actually priced in SCN. Even though the sales tag is quoted in SCN, since the items in the shop have been produced/sourced and paid for in USD, the price that Alice charges the customer will depend upon the SCN-USD exchange rate at that time. If SCN-USD suddenly halves, Alice will require twice the amount of SCN for the same item if they are to cover their USD costs. The SCN doesn’t command a predetermined value, it just depends what the SCN-USD rate is. The token is not providing utility here.
2. Exchange rate volatility
The exchange rate of SCN-USD is volatile. Alice doesn’t actually want SCN since her costs are all in USD. The customer doesn’t want to have to use SCN tokens and would rather just use the USD currently in his/her pocket. Because SCN-USD exchange rate is volatile, neither Alice nor the customer will voluntarily keep extra SCN tokens after the transaction (assuming they were just shopping and had no interest in speculating or investing in SCN).
The token is not providing utility here, simply adding an extra step in the transaction process.
These may seem like trivial inconveniences but they have serious implications for the token’s value. Both 1. and 2. combine to reveal a problematic issue known as token velocity.
3. Token velocity
The original intended use of this theory was to study an economy’s money supply (i.e. credit growth) in relation to its nominal GDP in an attempt to predict how monetary policy would impact inflation. Nonetheless, the concept works well in cryptoland to help us think about a token when it’s used for payments i.e. it’s being used as a ‘medium of exchange’.
If a single token flows from a customer to Alice during a purchase, when Alice sells the token to receive USD (to pay her costs) it flows back to the next waiting customer. We can see how this single token can be continually re-used throughout the day. This concept of how ‘fast’ or how many times a token is able to be recycled through the system is what crypto-land has adopted as its interpretation of the concept of the ‘velocity of money’.
In this example of Alice’s shop, if the SCN tokens could be bought/sold quickly and without transaction cost, then the shopper would not bother pre-buying any SCN. Instead they would wait till they found an item they wanted to buy then quickly swap USD into SCN and buy the item. Alice would receive this SCN and quickly swap it back into USD. Taken to its extreme, where transactions are near instant and frictionless, all the purchases by the customers over the day could be conducted in SCN without anyone actually holding a single token for more than a fraction of a moment. The result? No one holds the SCN token and so it’s nearly worthless. Not entirely worthless as then it couldn’t perform the function of transferring value, but near enough.
To be clear, it’s not the fast transaction speed or the low cost of swapping USD into SCN and back that cause this problem. The fast speeds and low costs make this behaviour possible but it’s the lack of desire from a user (different from speculator) to actually hold a SCN token (due to items being priced in USD and SCN’s volatility) that is the root of the problem.
There have been attempts to estimate and model a crypto token’s monetary velocity. Here, the authors use realistic assumptions regarding transaction times and the size of addressable markets, enhancing with some microeconomic estimates of optimal wallet sizes and frequency of transactions. However the outcome is obvious and predictable- in any scenario where transaction speeds and costs of trading are at levels consistent with a technology suitable for mass adoption, if the token is not intrinsically valuable then by definition it’s worthless, regardless of the quantity or value of the transactions that it is facilitating. In this scenario, the technology is still functioning and the payments are still occurring.
In these scenarios, the token is not providing any utility. At best it is speculation on future value/purchasing power of a token. Perhaps this helps us answer the utility/security debate. Or perhaps the answer even simpler: could these tokens just be currency? Either way, this is clearly an obstacle to user adoption, even without touching on the obvious inconveniences of having to use and manage multiple tokens across multiple Dapps.
So what solutions can we suggest to address the above problems?
Solutions to the disutility token?
Velocity solutions, anyone?
- Tokens directly redeemable for a service?
If 1 token conferred 1 unit of service or good at a time in the future, then this token would be directly delivering a utility. If a fairground sold 1 token for 1 ride, this token would be valuable and would trade at the price that people believed this ride to be worth. If the fairground later improved the excitement from the ride, the token would increase in value as it could still be redeemed for 1 ride. In other words, even though the ride is now suddenly twice as good, I can still access it with the same single token I previously bought. Whilst seemingly straightforward, pricing goods/services in a fixed token quantity is difficult until the whole economy (or an entire supply chain) is using a single token. However, there are certain ways around this problem (EOS.io) and they will be explored in my next post, stay tuned.
2. Avoid token volatility?
Stablecoins make an attempt at this. Whilst an interesting angle and beneficial to the crypto ecosystem, they are not a rewarding investment due to their aspired stability. Basis.io is an exception to this, offering the ability to invest in ‘baseshares’ albeit dependent on the success of their algorithmic approach to monetary policy.
3. Reduce ‘token velocity’?
3.a. Payment period
In the example of Alice’s shop, we assumed that SCN tokens could be purchased frequently and easily. If SCN tokens could only be purchased at the beginning of the day, then all the customers for that day would need to pre-buy enough tokens to cover their planned purchases. The more customers and planned purchases that there are, the more tokens would be demanded at the start of the day. If this time window for acquiring the token is extended, e.g. you can only buy tokens at the start of every week, then even more tokens would be pre-bought (hodlers get excited!). This artificial constraint on the token purchase window is ultimately what various attempts at creating ‘velocity sinks’ within a token protocol aim to achieve, by only allowing tokens to be bought/traded at certain times or by requiring the buyer/seller to lock-up their funds for the duration of the service, rather than a more familiar ‘payment upon delivery’ approach. However this has two implications, both of which worsen the user experience.
Firstly, long payment periods means increased exposure to the volatility of the crypto token’s USD price. It’s a poor UX if the vendor receives half the USD that they intended when they initiated the transaction.
Secondly, if the payment period is naturally quick, the Dapp will be vulnerable to forking or losing out to competitors by imposing an artificially long time constraint. Several ‘work’ based crypto projects (gems, ethearnal) require a token to be staked inside a smart contract during the service provision. The convention in a real world provision of service would be to pay some portion of the fee upfront (maybe zero upfront) and the rest upon completion. If the transaction could have taken place in 5 seconds rather than the imposed period of 5 days, or if the transaction could have occurred without an accompanying token stake, it won’t be long until a competing crypto project offers a solution without such features and so a better UX. Perhaps the lengthy payment period and full upfront payment is required, due to a natural long lead-time for the service or good to be provided combined with a lack of trust regarding the buyer and seller. Here, a crypto solution could be helpful. But regardless, this feature will only increase the value of a token if the time period is of significant length.
These issues both suggest that altering the payment period will not benefit the token’s value in a sustainable way.
3.b. Staking
Trends to ‘stake’ tokens that are not being used (sometimes rewarded by a passive income) are another attempt at reducing a token’s velocity. To see why this is unhelpful, consider the weighted average velocity of a platform’s token.
Let’s imagine a system where there are 100 tokens and each is currently worth $1, so the total money supply value is $100. There’s a certain amount of economic activity occurring on this platform- $100 of transaction fees being generated each day. This means that we can think of each token as being used once per day (i.e. velocity of 1) in order for 100 tokens to deliver $100 of value transfer from buyer to seller of the service. In reality, it may be just one user generating all the tx fees, where the buyer’s token is moving 100 times between that buyer and the service seller each day (assume fast transactions possible etc) whilst the rest of the 99 tokens are hodled. The resulting ‘velocity’ of that 1 active token is then 100, and the rest have velocity of 0. The weighted average velocity of the tokens in the system is (1*100 + 99*0)/100 = 1 again, despite 99% of the tokens having the lowest possibly velocity. And using MV=PQ, we are back at the same token money value of $100 again (M = PQ/V = $100), despite the staking system.
Staking systems: good luck!
With a token staking system, you are encouraged to commit to locking up your token for a period of time (velocity of these = zero) whilst the rest of the users/tokens continue to do the same amount of activity (velocity of these now higher). There is no net result on the overall system’s token value. By introducing staking, the only impact you are having is to reduce the liquidity (amount of tokens available to buy or sell at a point in time) of the tokens in circulation. Low liquidity is a double-edged sword- when a buyer arrives they push up the price a lot more than if the token market was liquid. But similarly, when a token seller arrives they will push the price down a lot. The result is an increase to the (already high) token price volatility with the negative implications on UX as per above.
It should now be clear that if a token is only used for payment, regardless of how we try to ‘control its velocity’, the token fails to capture much of the economic value, irrespective of the benefit (financial or otherwise) that the crypto system may be enabling.
Where does that leave us?
This is not to say that all payment tokens will go to zero. There is a circularity of logic that sustains them: if they are believed to be worth something, then they are worth something. If 1 token is believed to be able to deliver $1 worth (or more!) of purchasing power in a year’s time, then there’s nothing stopping it from doing so. This is how a ‘store of value’ asset begins life and, by similar logic, how real-world fiat systems maintain value. If enough people with enough credibility and deep enough pockets believe the same vision then this can be self-propagated and sustained. That is, until the thesis changes (i.e. regulation), the value is no longer being stored (i.e. price declines), or some newer shinier asset comes along (*insert latest ICO*) and the initial trickle of people exiting from this failed store of value turns into a stampede. Then the feared demise becomes the self-fulfilling prophecy.
This is the point that Pfeffer makes in his very clear argument- that store of value is the main ‘use case’ for crypto. Whilst I don’t disagree with this view entirely, I believe that tokens can capture additional forms of economic value if designed correctly.
Conclusion
In this article we’ve seen how badly designed utility tokens provide minimal utility and may fail to capture much value. There are ways in which people have tried to address some of the supposed problems. However, since the core problem is a lack of real value being attached to the very token itself (outside of speculation or classification as a store of value), these proposed methods do not offer sustainable solutions.
In my next post I will move on to discuss two important token designs and the value that they can command. These tokens are ‘true utility tokens’ and ‘equity-style security tokens’.
…Please find Part 2/3 here
// Follow me @CryptoBonsai for more crypto insights