Capturing crypto value: a guide to tokenization strategies…Part 2/3
Part 1: The (dis)utility token. What’s wrong with the popular payment token? My previous post here.
Part 2: Designing token value. Which token mechanisms can capture value?…but what are some potential problems?
Part 3: Sustainably capturing value. Using these mechanisms, how can value be captured when facing competition?…coming soon.
Part 2: Introduction
A crypto token can be a powerful tool if created and used correctly. Tokenized systems can fund the development of new projects and enable new coordinated systems, powered by self-interested parties. However, for the efficient functioning and security of these systems, it’s crucial that the fuelling token has value.
I outlined in my previous article how a simple payment coin could fail to capture much value, regardless of how popular or frequently used its network becomes. I’m going to look at token designs that I believe will be better at this task.
Defining the problem
The conventional way to think about the crypto landscape is to categorize the tokens. Max from Fabric VC does a good job of this:
However, tokens are not exclusive to a single category and may possess various features spanning this ecosystem. For example, it would be possible to have a ‘work’ token that also pays a dividend generated by the platform- is it still a utility token or is it now a security?
This landscape is not so much a collection of boxes that a token can be placed in, but rather a partial description of the (possibly multiple) value defining features that a token may have.
Instead of focussing on categories, when evaluating a token it helps me to think about the following 3 factors:
1) The token’s design & value source?
How does the crypto system intend to generate value? Does the token’s design capture this? This value source could be the fees earned, passive dividends, or an attempted store of value.
2) Sustainable market share?
What measures can be taken to protect against competing forks and rivals? This is crucial in a world of ‘easily’ forkable and interoperable chains. In theory, it may appear hard to charge users’ fees but I think this could be different in practice. More on this in my next post.
3) Governance?
Governance is control. How has this feature been used to affect the two factors above? Sometimes a lack of governance can aid value creation (bitcoin), other times it can help sustain a profitable market share by increasing the implicit cost to a user switching platforms. More on this in my next post.
Attractive tokens are ones that combine a value accretive design alongside the ability to tackle conventional business challenges, with a suitable control system in place.
I’m going to focus on the first factor in the rest of this post.
Factor 1) The token’s design & value source
Here are some popular token designs that I believe can capture value with varying degrees of success. Most of these have been discussed before, for example here. Hopefully my following interpretation of these is a useful aggregation of the thinking so far:
i) Commodity mechanism
I view this as the easiest mechanism to implement but the hardest to operate successfully. Using this mechanism, the value of the token is whatever the market speculates it will be in the future. Most famously, Bitcoin and its store of value ‘use-case’ is complementary to its token mechanism. However, since store of value is likely to be dominated by only 1–2 tokens, native payment tokens attempting to employ this mechanism have a hard battle ahead.
ii) Coupon mechanism
Can you exchange your crypto token for a certain amount of service in the future? By making an implicit link between token and resource, when the resource appreciates in value the token price will follow. In my previous article I suggested a theme park that sold coupons for the rides. If they improved the rollercoaster, I could experience this increasingly terrifying ride in exchange for my original single coupon. As a result of the theme park improvements, my coupon is now worth more.
A crypto project that was approaching this coupon feature in an interesting way…was EOS. At least, this was until their dramatic (and disappointing) last minute protocol change, separating RAM into its own marketplace, within the Dawn 4.0 update. Putting this update to one side, the original premise from the whitepaper was that by holding 1% of the EOS tokens, you would have guaranteed access to 1% of the block producers’ network resources (CPU, bandwith, RAM) when the network was running at full capacity. The act of rationing scarce network resources, according to token distribution, implicitly linked them and enabled the token to capture this value. This was very different from an ETH or BTC model of charging a variable rate via the GASPRICE or transaction fee, regardless of the amount of tokens held.
Examples? Unfortunately, at present no crypto driven services are priced in a fixed amount of tokens. For example, 1 bitcoin only delivers a changeable amount of USD spending power in the future. Please comment if you know otherwise.
If a token can guarantee an amount of scarce resource in the future, its resultant coupon-like feature will help underpin some value.
iii) Work/medallion mechanism
A useful token design is one that resembles a taxi medallion system. With this system, to operate a taxi you need to buy a medallion. The access to income that it provides, combined with its limited supply, ensures that it retains value.
Extending this idea to cryptoland, a project can require that a participant owns a token in order to be allocated fee-paying work. The more tokens that a participant owns, the higher the chance of being allocated fee-paying work eg. Augur, Ocean, or even a PoS consensus system.
This token mechanism confers the right to participate in the network’s fee generating activity and so delivers value directly to the holder. Estimating the amount of this potential value can be done using conventional DCF methods.
We can refer to both 2) and 3) as features of the ‘true utility tokens’ that I mentioned in my previous post, since they deliver a valued outcome in return for a token holder’s action.
iv) Dividend paying mechanism
With this token feature, a share of the platform fees generated is collected and distributed to passive token holders in the form of a dividend. This can be a useful mechanism to promote adopting this platform vs. non-dividend paying alternatives. The value of this token can be estimated using conventional DCF techniques. Examples include exchange tokens, BNB and HT.
v) Asset-backed mechanism
Perhaps not as interesting (volatile) as those attempting to capture the value of decentralized networks. But nonetheless, a valid token mechanism for capturing value. There are well-documented potential benefits from asset tokenization and reliable ways to value the underlying assets.
vi) Dual token mechanism
A dual token structure can be introduced to improve the ease of payments or governance on a platform, potentially promoting adoption.
If the second token is used for payments, then allowing users to pay in BTC or ETH could enhance user experience in the early days. Once the platform matures, this second token could even be phased out. However, using a second token for payments that is also native to the platform (eg Gnosis) could risk complicating the user’s experience.
A second token for governance can make this process more efficient. For example, Decred’s token holders must pay an additional amount to buy ‘tickets’ if they want to vote.
What about Velocity?
Notice how I’ve suggested some valuable token designs and yet haven’t mentioned the buzzword ‘velocity’? What happens if a project decides to design its token structure in order to ‘reduce velocity’ e.g. adding a dual token? If the token structure results in outcomes that increase the network token’s chance of generating income/value…then velocity will be observed to decrease resultant from an increase in the token price. I don’t find studying velocity by itself is helpful when examining token value.
Problems?
The key problem with these value drivers is that in a world of open-source, forkable and interoperable blockchains, a value-generating platform is an invitation for competition.
For example, if the fee paid to the Augur reporters is too high it will attract competitors. If there are minimal barriers to new reporters entering, then competition for jobs will push the fees down to a point where they equal the cost of providing that reporting service.
In addition to this, if there was a group of Augur reporters who were sufficiently numerous and coordinated, they could fork and start their own network. This would save them the cost of acquiring the medallion tokens of the original platform, allowing them to charge lower fees on a new independent network.
In another example, there would be a similar outcome in a PoS system if the block reward or transaction fee was excessively high relative to the costs. Competing stakers would be willing to accept lower yields on their tokens until this equaled their risk-adjusted cost of capital.
Although the apparent difficulty in charging fees may be cheered by a user, this outcome is the fairly bleak conclusion that crypto investors studying dApps have often arrived at. This has been most clearly outlined by Pfeffer.
Solutions?
One obvious solution is to focus on token design i), a fee-free commodity store of value. However, whilst the prize is significant in size, it will most likely be dominated by Bitcoin.
More interesting solutions may be uncovered by thinking about how these systems will be used in practice.
I agree that the above concerns are reasonable for a crypto system at its theoretical long-term equilibrium. However, in reality the system’s fee potential could depend upon the strength of its relationship with the end-user.
I believe that because of this, contrary to popular belief, value could accrue to the user facing dApp layer tokens more often than the base level protocol. I will look further into how this could occur in my next post.
Conclusion
The design of a token can be crucial in determining whether it will capture the value generated on a crypto network. For a store of value application, the token design is fairly simple. However, competing against Bitcoin will be tough.
For other use cases, driven by dApps, there are various token designs that should allow the token’s value to increase alongside the fee-paying activity on the network. However, even with this in place, competition from rivals could hinder any attempts at charging fees.
Nonetheless, I don’t believe the dApp token story ends here. Rather, due to the proximity of dApps to the end user, and the pricing power this may entail, I believe that dApps could be more likely to capture token value than the underlying base protocols powering them. Stay tuned for more on this in my next post, Part 3.
// Follow me @CryptoBonsai