Fixing Broken “Single” Utility Tokenomics: Part 2 — HODLing Powers
This blog post is the second in a multi-part series on fixing utility tokenomics. Part one is here. For a more in depth exposition see the Difuon tokenomics white paper here.
Separation of Concerns
In Part 1, I explained how a single utility token could NOT be both a good medium-of-exchange and a good store-of-value (at least an appreciating one). The seemingly obvious solution is to separate these concerns into two different tokens; the first, a medium-of-exchange (MoE) token, and the second, a store-of-value (SoV) token. This means that a participant no longer must purchase SoV tokens in order to access the associated network or platform. In a sense the SoV token is now optional. The business of the platform may be conducted with merely the MoE token.
The usual response when I propose this “obvious” solution is, “If the SoV token is not required to use the platform why would anyone want to buy it, especially an investor?”
A visceral example of this is the QuantStamp token. Like many utility-token based business models, QuantStamp (QS) raised over $30 million through a sale of its utility token (QSP) in an ICO. Its primary business is providing smart contract audits as a service. After the initial pump-n-dump phase, its token price started to rise again as the network actually started providing real utility via significant smart contract audit sales. Because the QSP was required to purchase audits and the price of audits was denominated in QSP, this demand for audits resulted in increased demand for the token. Its price started rising again. The unfortunate result, however, was that other providers of audit services were now more competitively priced. QS had a problem, either give up their market or give up on their token. They chose the latter. Much to the ire of the holders of QSP, QuantStamp began accepting payment for audit services in fiat (USD). Essentially they now had two tokens (QSP and USD), both optional. But with the QSP now optional, it had no other driver of value so its price dropped. This is shown in the following chart. The vertical green line is when it became known that QS was accepting fiat for audits.
This puts a finer point on the former question, “If the SoV token is not required to use the platform why would anyone want to buy it, especially an investor?” The short answer is that optional utility is still utility. Indeed optional utility can be very valuable. It does require, however, appropriate mechanism design which QS did not have. I will explain later how to use mechanism design to imbue an SoV token with optional but still valuable utility. First, let’s look at the advantages of a dedicated MoE token that has clearly separated its concerns from SoV.
Stable, Low Friction, High Velocity Medium-of-Exchange
As I described in Part 1, a good MoE token has low friction, high velocity, relative stability, wide availability, high throughput, low latency, and low average settlement costs. The most important properties are stability, low friction, and high velocity. Large fiat reserve currencies such as the USD have all of these properties. The world runs on fiat so anything else has much higher friction. So why not use fiat, plain old money (POM), for the MoE token in the first place? Indeed, for a given platform, fiat might be the best choice for the MoE token. Founders should seriously consider a fiat payment channel as their first choice. Why bother at all then with a crypto token for MoE? The answer; most platform business models — especially two-sided networks — rely almost exclusively on online transactions. The settlement costs of most electronic payment channels (credit cards, ACH, etc) are relatively high. Many have a minimum transaction amount. Consequently, if the platform needs to support micro- or nano-transactions and also wants to minimize settlement costs then using a crypto-token or some form of distributed ledger technology for the MoE may be advantageous. The crypto-token in this case may be ephemeral in that its purpose is to facilitate batched settlement to/from fiat but not as a stand-alone MoE token. The customer facing payment channel is still fiat.
Friction Kills
The current friction that users must overcome in order to use crypto-tokens as the MoE for a platform is absurdly high. This is further complicated in the US because the IRS considers each loss or gain in a cypto token transaction to be taxable event (capital gains) that must be reported on a tax return. When a business depends on adoption and growth, adding a very high friction on-ramp is usually a very bad idea. In my opinion, this is a “the emperor has no clothes” moment for the ICO world. In other words, if a platform wants broad adoption, then using anything for the MoE other than fiat or a fiat integrated crypto-token always was and still is a bad idea. Why was it ever thought to be a good idea? Because, using fiat as the MoE does not provide a way to raise money and hence the confusion of concerns discussed in Part 1. (See here for a humorous take on the absurdly high friction of conducting business with non-fiat MoE tokens.)
There are many ways to build integrated fiat-crypto token payment channels. The key property is that the platform provides transparent fiat on- and off-ramps. Consumers can pay in fiat (on-ramp) and producers can get paid in fiat (off-ramp). One approach is to peg the MoE to fiat that is backed by a fiat liquidity pool. This can be provided by the platform itself or by a banking institution. This is sometimes called a fiat anchor. Transaction records track MoE credits against account(s) held at the anchor. The Stellar network with Stronghold is such an example. There are others that are building on- and off-ramps for Bitcoin and Ethereum crypto-currencies.
When the platform provides both on- and off-ramps then the crypto MoE may be denominated in fiat and may be ephemeral (i.e. minted and burned on demand). In this case, the distributed ledger is just providing a diffuse trust mechanism for tracking account balances. It’s essentially fiat, but with augmented decentralized balance tracking that supports micro-transactions and provides lower settlement costs by batching transactions. In general, in order to minimize friction and thereby maximize adoption, the platform should allow participants to see only fiat if they so choose.
Appreciating Store-of-Value to Drive Virtuous Behavior
Given that a low-friction-high-velocity-stable MoE token (which may be fiat) is used to consummate transactions on the platform then, with clean separation of concerns, an optional companion SoV taken can be used to reward and promote virtuous participation on the platform. Such an SoV token may be used as a marketing tool to incentivize adoption, shape behavior, and reward participant-sourced improvements to the network. These are all good drivers of the positive two-sided network effects that accelerate growth of the network. Indeed, the main purpose of the SoV token is to monetize positive feedback loops that drive network dynamics.
We can model the platform as a dynamical tokenomic system with various forces that influence its behavior. The important insight is that different forces may be dominant at different phases of the platform growth. By carefully balancing these forces and phases we may create automatic positive feedback loops that reinforce beneficial participation and growth of the platform and may also reinforce desirable pricing behavior of the SoV token. We want to employ algorithmic mechanisms that automatically drive appreciation of the SoV token as the network grows.
My background as an autonomous vehicle control system designer and machine learning researcher has been a major source of inspiration behind this approach. I was also inspired by the idea from modern monetary circuit theory that monetary flows are best modeled by differential equation dynamics not static equilibriums. Indeed, a big attraction to me of distributed consensus technology is the potential to use it to build decentralized automated reasoning systems that involve humans but are less corruptible and more fair than human-only systems. Some of my early work on decentralized identity and reputation laid the foundation for such systems. This blog series and the associated white paper describe some of the work we are doing now to build on that foundation.
HODLing Powers of the Redemptive Benefit Token
In homage to the internet meme resulting from the drunken misspelling of hold as hodl, which serendipitously is also an acronym for Hold On for Dear Life (HODL), we have titled the driving forces of the SoV token HODLing powers. More specifically we call it a redemptive benefit token.
The HODLing powers are actually nothing new, they are all well established mechanisms long used in business to drive adoption and good behavior. What is new is the combination of these acting together in a phased participation–price positive feedback loop. The powers are as follows:
Redemption — like a transferable gift-card program the SoV tokens can be redeemed for products and services on the platform. Example: Restaurant gift card.
Promotion — like the points in loyalty program SoV tokens can be redeemed for products and services at promotional prices provided only to members of the program. The promotions may vary from time-to-time to incentivize adoption of different products or services and to reward loyal participation. Example: Airline frequent flyer program.
Rewards — like a spending rewards program, holders of SoV tokens earn cash-back like rewards as a function of their spending on the platform and their holdings in SoV. Example: Costco Executive Members earn cash-back in-store vouchers.
Membership — like membership or license fee, staked SoV tokens entitle holders privileged access to the platform. Staking means that the member risks losing the staked SoV tokens should the member misbehave. Example: Delta Diamond-level members and their traveling companions gain free access to airport SkyClubs and priority on free upgrades. Another example: for a fee, real-estate agents may list properties they have for sale on the MLS.
Please note that there does not appear to be much new here. We wanted to reduce friction by using familiar mechanisms couched in familiar terms. We could just as easily use the word points, coupons, tickets, or stamps instead of tokens. This is business as usual, nothing new here except some terminology.
Because the associated platform is decentralized, the programs are best run using a distributed consensus algorithm. This facilitates credible transfer of the SoV tokens which makes the the associated HODLing powers portable amongst participants. The major innovation here is that by running these programs on a distributed ledger, the account balances denominated in SoV tokens are credibly transferable and, in that sense, liquid. An Ethereum based ERC-20 smart contract or another distributed ledger with similar capabilities can host the SoV token. But because the SoV token is optional, the instability and high friction associated with many of these kinds of ledgers do not interfere with the core functionality of the platform. Unlike the MoE token, the redemptive benefit (SoV) token does not need to be low friction to be useful.
Two-sided Menu
The redemption and promotion HODLing powers rely on a two-sided menu. An example is shown in the following diagram. In the menu, the center column provides the names of products sold on the platform, one per row. For each product, the price in units of SoV tokens with symbol # is in the left column; the price in units of MoV tokens with symbol $ is in the right column. In addition to the two-sided menu is a reserve pool of redeemed SoV tokens and a liquidity pool of fiat (in this case USD) to back the MoE account balances. In this case 1 SoV = 1 MoE, i.e. #1 = $1.
Let’s consider an example fiat transaction using the MoE side of the menu. In step one of the transaction, a customer, Alice, chooses to buy product P2 from the menu using fiat (USD). She deposits $4 fiat into the liquidity pool and gets a $4 credit in MoE into her MoE account. The liquidity pool now has $4 and Alice has a $4 credit in her account. In step two the $4 MoE credit is spent to purchase P2. Alice’s $4 MoE is deducted from her account. Suppose that P2 is a high margin software service that the platform itself, named Bob, is providing. So Bob gives the product to Alice. But Bob must pay $1 to another supplier, Sam, who helps support the product. This leaves $3 in gross profit margin for Bob, the platform provider. In step two, $1 in MoE credit is deposited to Sam’s account and $3 is deposited to Bob’s account. Finally in step three, Sam chooses to cash out and withdraws $1 in MoE from his account and converts it to $1 in USD through the liquidity pool. This leaves $3 in the liquidity pool. These color coded steps are shown in the following diagram. The diagram shows the balance in each participant’s MoE account at the end of each step.
Suppose, furthermore, that Alice next decides to buy P2 with fiat three more times. But Sam does not withdraw his payments. At the end of the fourth purchase, Bob, the platform will have $12 in MoE. Sam will have $3 in MoE and the fiat liquidity pool will have $15.
Redemption
Now let’s consider an example redemption transaction that uses the SoV side of the menu. Suppose Carol, a customer, has SoV tokens that she purchased sometime earlier. In step one of the transaction, Carol chooses to redeem #4 worth of these tokens for product P2 using the SoV side of the menu. The #4 SoV tokens are accepted by the platform (Bob), and then the tokens go into the reserve pool (they are taken out of circulation). Bob gives product P2 to Carol. Bob does not get paid any MoE by this transaction. In step 2 Bob pays Sam $1 for supporting the product. This is deducted from the $12 in earned gross profits in Bob’s account. When Bob originally sold the SoV tokens, (think gift card), Bob incurred a liability to provide products and services from the SoV side of the menu in return for the SoV in the gift card. Bob, when honoring the gift card for P2, must pay for his actual costs of providing the product. Because, as mentioned above, P2 is a high margin software service, Bob’s out of pocket costs to Sam are only $1. This cost is deducted from the accumulated gross profit on all of Bob’s sales in Bob’s MoE account and paid to Sam’s MoE account. At the end of step two, the reserve pool has #4, Sam has $4 in his MoE account, Bob has $11 in his MoE account, and the liquidity pool still has $15. This transaction is shown in the diagram below.
Suppose that Carol next chooses to redeem SoV for P2 three more times. At the end of the fourth transaction the reserve pool will have #12 in SoV, Bob will have $8 in MoE, Sam will have $7 in MoE, and the liquidity pool will still have $15.
Effectively Bob, as the platform, is backing the SoV out of his gross margins. As long as Bob is making money selling products to fiat customers he can pay off the liability he incurred when he originally sold the SoV tokens. Every time Bob redeems an SoV token he takes it out of circulation thereby reducing his liability and reducing the supply of SoV tokens. The price of the SoV token is a function of the price of the products and services in the menu for which it can be redeemed. Given that the MoE side of the menu is competitively priced customers will be drawn to the platform in order to buy its products and services. Because the MoE token is either fiat or is pegged to fiat, the price of products on the MoE side of the menu is stable. Purchases via the MoE side of the menu for a product validate its MoE pricing and thereby also validate its equivalent price in redeemable SoV. This limits the downward volatility of the price of the SoV token. As long as the platform is in business the SoV token will have significant support for its non-speculative redemptive value.
Suppose that Bob originally sold to Igor #20 SoV tokens for $10 (a discount of 50%) as an investment prior to platform launch. The risk to Igor is that Bob never successfully launches the platform. But this is no different from any startup investment. The return to Igor is that he may get nearly double his investment merely by redeeming the SoV. The liability to Bob is that he has to provide $20 worth of products or services to whomever redeems the SoV tokens. But Bob estimates that on average his out of pocket costs will only be 25% of the value of the services (a 75% gross margin). So he has a hard liability of only $5 and will forego $15 in future profits when he honors the SoV tokens. Bob has $10 with which to build the platform. Suppose that a few weeks later Igor gets impatient and sells his #20 of SoV tokens to Carol for $15. Igor makes a 50% return of $5 on his $10 investment. Carol who is patient waits for Bob to finish building his platform then is pleased to purchase products at a 25% discount using the SoV tokens and the SoV side of the menu. Indeed should Carol not be able to use all of her tokens she should be able to find willing buyers who need the product and are willing to pay more than $0.75 per #1 SoV but something less than the face value of $1 per #1 SoV . Once the platform launches and is providing products, Carol should be able to find willing buyers who will pay almost the face value of $1 per #1 SoV.
Price Floor
The effect of redemption through the two-sided menu is that it establishes a price floor for the SoV token. Once the platform launches, redemptive utility of the platform will drive the price of any discounted tokens up to the floor. This is a virtuous tokenomics driver because it protects both investors and secondary buyers from speculative downward volatility once the platform has real utility. The major constraint is that the total value of the initial supply of SoV tokens is less than the total expected gross profits of the platform over some reasonable redemptive time horizon. This provides a solid basis for valuation of the SoV prior to and during the immediate post-launch period of the platform.
Promotion
One chief purpose of loyalty programs is to retain customers. Typically the cost of acquiring a new customer may be many times the cost of retaining an existing customer. Loyalty promotions reward existing customers for their continued use of the platform. The friction of obtaining and using SoV is a type of customer acquisition cost. SoV buyers may be early adopters who are more passionate about the platform’s products and services and find future value in participating in promotions only available through the SoV token. The buzz and referrals that such passionate early adopters create is a positive network effect than can drive more rapid adoption of the associated platform. This is marketing 101.
Consider, for example, an SoV promotional transaction using the two-sided menu. In this case Bob adds a new entry in the menu named P3* with a promotional version of product P3. Promotional P3* may include special time or quantity provisions. But the major change is that instead of #2 SoV for a $2 product, promotional P3* has a price of #1 on the SoV side. During the promotion the value of an SoV token redeemed for P3 is now effectively doubled. Let’s suppose, like product P2 above, the out of pocket cost to Bob to provide P3 is also $1 and is paid to Sam. In step one of the transaction, Carol chooses to redeem #1 of her SoV for P3*. The #1 SoV token is accepted by the platform, Bob, and goes into the reserve pool. It is taken out of circulation. Bob gives product P3 to Carol. In step 2 Bob pays Sam $1 for supporting the product. This is deducted from the $8 in earned gross profits in Bob’s account. Bob does not get paid any MoE by this transaction. Someone choosing to buy P3 with fiat must still pay $2. At the end of step two, the reserve pool has #13, Sam has $8 in his MoE account. Bob has $7 in his MoE account and the liquidity pool still has $15. This transaction is shown in the diagram below.
A good analogy for how the the promotion power affects SoV price is the valuation of airline points in a frequent flyer loyalty program. Normally 20,000 points buys a domestic ticket but during the promotion only 10,000 points are needed to buy a domestic ticket. If the average price of a domestic ticket is $400 then on average 20,000 points are worth $400. During the promotion 20,000 points are worth $800 because that many points can now buy two domestic tickets. When multiple products in the menu have different effective conversion rates to fiat, there is no longer a single price floor. Each product establishes its own price floor. All the products together create a composite price floor.
Consumptive Weighted Average Valuation
This poses the question: how is the price of the SoV token affected by promotions in the menu. Let’s suppose that P3* is very popular and 50% of all SoV redemptions use P3*. The effective conversion rate for P3* is #1 SoV = $2 MoE. The other 50% of SoV redemptions have an effective conversion rate of #1 SoV = $1 MoE. The consumptive weighted average of all SoV redemption transactions in MoE is #1 SoV = (0.5 * $2) + (0.5 * $1) = $1.5 MoE. Thus the promotion has driven the price of SoV above the initial price floor of #1 = $1 to #1 = $1.5. A 50% valuation rise. A consumptive weighted average is a fairly straight forward way to calculate a valuation for the SoV when the two-sided menu has variable promotional pricing. It is one way to estimate the composite price floor. This can be made into a time moving average to better account for limited-time promotions. The constraint on promotional pricing for a product is that there be strong market demand for its fiat price. The only way to take advantage of the promotion is to either already hold SoV tokens or to buy them with fiat from an existing holder on a third party exchange. Each promotional redemption removes SoV tokens from circulation. This acts to drive the SoV price up to the consumptive weighted average. Returning to the airline example, given that 20,000 points buys a domestic ticket, the equivalent value of the points depends on what specific domestic ticket is purchased. A ticket from LA to NY will be worth more than a ticket from LA to Phoenix. The product in this case is a class of service, i.e. a domestic ticket’s true value is based on the actual ticket purchased via redemption. A consumptive weighted average is one way to estimate the composite value of that class of service.
Let’s return to Igor who purchased SoV tokens at $0.50 each. If Igor had been more patient and held onto his SoV until the promotion kicked in he would have been able to sell Carol his tokens at somewhere between $1.50 and $2.00 each for a more than 300% return on his original investment.
Gift card and loyalty programs are very common. What is different here is that by hosting these programs on a decentralized trustworthy distributed consensus infrastructure the value of the programs to a participant can be made portable in a credible way. Portability (i.e. potential transferability), can be very valuable to the participants in a loyalty program thereby providing a positive feedback loop to loyalty. This is like an unused gift card that can be re-gifted or extra frequent flyer points that can be used to buy a ticket for a friend. The promotion HODLing power both drives adoption and drives up the price of the SoV.
Rewards
A common spending rewards program is a cash back program where participants get a refund or credit as a function of how much they spend on the platform. Often these programs require some membership fee in order to participate at higher reward levels (for example: Discover, Amazon Prime, Costco Executive). We do something similar with the SoV token where participants earn MoE tokens as a function of both their holdings in SoV and their spending in MoE. These earned MoE tokens may then be used to purchase additional products or services via the MoE side of the menu. This incentivizes participants to hold tokens not for their redemptive value but instead for their reward earning rate value.
If we make the earning rate of MoE per expenditure of MoE an inverse nonlinear function of the number of SoV held then the demand for SoV to hold may go up exponentially as a function of the total spending on the platform. Demand for SoV to hold can be even further increased by making the earning rate of MoE per expenditure a function of the length of time a given quantity of SoV are held.
Consider, for example, that the earning rate for holding #10 SoV is 2% of MoE spent. If Alice spends $1,000 in MoE while she also holds #10 SoV then she would earn $20 = 0.02 * 1000 in MoV as “cash back.” If she instead spends $2,000 in MoE, she would earn $40 in MoE for the same #10 SoV held. At this point she has amortized her SoV holding four times over. Suppose that to earn 3% Alice must hold #50 in SoV. For the same $2000 spend she would earn $60. If every year she continued to spend $2000 she would be strongly incentivized to continue holding on to her SoV.
The value of the SoV tokens that Alice is holding is no longer merely its redemption value but is instead a function of the value accrued by earning spending rewards. If Alice only holds #10 SoV and gets a reward of $40 every year for $2,000 in spending, then it would still make sense for her to spend at least $40 to buy those #10 in tokens. The demand for held SoV due to spending rewards can be estimated by generating a histogram of the spending levels of all of the participants and then mapping each spending level to the earning level that is positively amortized for a given amount of held SoV. The demand for holding SoV may therefore rise as spending on the platform increases and may drive the price of SoV to be many times its redemption price.
Membership
Like an exclusive club where members must pay to join and may lose their membership should they violate club rules, staked SoV tokens incentivize good behavior for activities on the platform less the staker lose their staked SoV. On a decentralized platform, participants might serve in different support roles and earn MoE for their service. In order to be selected for a support role the participant must put some SoV at stake. This is like a refundable deposit or license fee that enables one to get paid for acting in a support role as long as they behave. For example, support roles may include, a validator node host, a voter on the use of community SoV tokens for bounties, or a host of other platform infrastructure.
Consider for example, that Sam wishes to host a validator node and the minimum stake to host a validator node is #100 SoV. Suppose that the validator node earns $1,000 in MoE each year. The value to Sam of his #100 SoV stake is at least $1,000, that is, ten times his stake for just the first year. If we make the selection strength for hosting validator nodes an inverse nonlinear function of the amount staked then the demand for SoV tokens may increase exponentially with the number of validator nodes. This may drive the holding of large numbers of SoV tokens as a function of the size of the platform infrastructure. This demand can be estimated by estimating the number of infrastructure components and the associated membership stakes.
Phased Growth in SoV Value
The result of the four HODLing powers acting together is that one HODLing power may become the dominant driver of SoV demand at each phase of platform growth. A notional view of how these behaviors may drive together the SoV price as a function of platform growth is shown in the diagram below.
During the pre-launch phase, SoV tokens may be sold at discount and do not yet have consumptive value. However, the eventual redemption value provides an expected price floor to which the price may rise. Once the platform launches the SoV tokens may be redeemed for products and services on the menu. Market demand for these products and services may then more strongly drive the price up to the floor as discounted SoV are redeemed for those products and services. During the promotional phase, promotional pricing is used to drive adoption of new products and services. This creates a composite price floor that may be higher than the initial redemptive price. Continued redemption decreases the supply of SoV tokens. During the rewards phase, demand for SoV becomes a function of the spending on the platform. For larger spenders, the value of holding an SoV token may be many time higher than its redemptive price. During the membership phase, demand for SoV becomes a function of the size of platform infrastructure and the need to stake SoV to serve in infrastructure support. The value of a staked token for service in a support role may be many times its redemptive price.
The motivation for using mechanism design for the SoV token was to replace speculative price drivers with drivers based on true utility in the platform. My key insight was recognizing that the different HODLing powers could be aligned with the different growth phases of the platform thereby enabling all the HODLing powers to be combined into one SoV token.
Read the full whitepaper to see more detail. Go to our website here to see what we at Difuon are planning to do with our innovative dual utility tokenomics model. Stay tuned for the next blog in this series where we look at how to balance influence and interest with different rewards and staking functions.
