B/f we talk abt this mistake many web3 platforms are making, I’m assuming the goal of the platform is to:
1) expedite growth & distribution— to get to critical mass / network effect faster & distribute values to users & contributors
2) achieve longevity— to be a sustainable going concern, not a one trick pony
Quick walkthrough of why tokenization helps accomplish these goals—
Let’s say you’re starting a decentralized ride sharing platform called *Uber*.
You issue a utility token—UberCoin. It’ll be a platform-wide payment medium for txn fees charged on each ride.
You airdrop UberCoins to early riders & drivers. This’ll help you grow faster than your competitors that don’t have a token.
Why?
B/c aside from benefit of ride share itself, users have potential gain from expected future price increase of UberCoin, which nudges more people into using Uber. And having a critical mass of users is life-or-death for the platform/market place biz model.
’The price appreciation gain is important at early stage b/c at beginning it’s likely that gain from product utility alone is small— e.g. it takes a long time to get a ride b/c you don’t have that many drivers yet & your app is buggy.
Expected price gain from UberCoin makes your early users more forgiving & buys time to get your sh*t together:
Contrary to popular belief, expected price increase of UberCoin doesn’t have to come from financial bubble or hype—
Uber users need UberCoin to pay for txns on platform—> when Uber user base grows, UberCoin demand increases—> price appreciation, other things equal. (’Tis the same underling mechanism of my web3 platform valuation model.)
Expected token price increase from platform growth attracts more users to platform which reinforces token price increase. Adoption flywheel spins faster w/ this self-fulfilling cycle.
So far so good. But here comes the mistake.
In attempt to make token more appealing to crypto-native speculators & make flywheel spin even faster, many web3 platforms chose to put a hard cap on token supply.
Capped token supply would make price increase faster, hence faster platform growth, right? What’s the problem?
There’re several.
1. It can attract more “fake adoption”
Let’s consider 2 types of users.
User A: Alice, who lives in SF, goes out often & doesn’t own a car. Uber could be a great product for her though singing up for new app is a hassle & Alice doesn’t like to try unproven products.
UberCoin is the extra incentive for Alice— who’ll actually benefit from using the platform, while the token provides an additional 🥕:
User B: Bob, who lives on a farm in Montana, never used a taxi & never will, but is happy to buy any computer coin that moves.
Bob is the kind of user that needs to be handled w/ care. On one hand Uber needs Bob b/c he provides short term liquidity to UberCoin & makes a 2ndary mkt possible.
On other hand though, if Uber has too many Bobs in its token owner base, it’ll increase price volatility.
Since Bob gains no real utility from Uber & all his reason for owning UberCoin comes from expected price increase. His decision to hold UberCoin is *more sensitive* to token price change compared to Alice.
Capping token supply will likely attract you more Bobs, as it’s perceived by many crypto speculators as leading to higher price increase (it’s not true btw). But make no mistake, if mkt trend starts to revert, Bobs will dump UberCoin faster than Kim K. drops boyfriends.
’Tis a stylized example. In reality any token can attract a spectrum of holders in btw Alice & Bob. But principle remains same.
The more a web3 platform’s user base is dominated by price appreciation motive, the more its token price will be held hostage by boom/bust cycle in crypto mkt, which in turn makes adoption growth more volatile.
It’s counter-productive for the platform— the point of having UberCoin is to attract the *right users* faster, not to attract people who wouldn’t otherwise use Uber in a million yrs.
It also gives false signal for product development— all you see is user base grows very fast but you don’t know how much of it is b/c you have a good product & how much is just a mirage. And you won’t know until bear mkt hit & the wrong people all go away.
Over past cycle prices of tokens w/ supply cap rose more in bull mkt & dropped more in bear mkt compared to tokens w/o cap. Though it doesn’t directly prove that supply cap attracts more speculative holder base, it’s consistent with that.
24/ Ironically, tokens w/ hard supply cap have on average dropped more in bear mkt compared to those without. Difference is statistically significant. pic.twitter.com/vKPr79wjYF
— Tascha (@TaschaLabs) December 16, 2022
But this is actually only a minor drawback of having token supply capped, compared to the next one:
2. It limits possibility of seigniorage revenue
Seigniorage— difference btw mkt value of a currency & its production cost— used to be a monopoly profit available only to governments. W/ tokenization it’s a profit source for web3 platforms as well.
B/f you shout “But money printing is bad!”, let’s make something clear.
There’s nothing intrinsically good or bad abt issuing money. Problem is traditionally, there’s no effective mechanism to limit governments on how much money they can issue. So that power tends to get abused.
But it doesn’t mean seigniorage profit in itself is bad. At end of day inflation— like income or sales tax— is just a form of taxation, a revenue source to fund necessary operation of underlining entity.
Revenue model of most web2 platforms is txn fees— akin to tax revenue in public sector. Web3 platforms can have fiscal revenues (from txn fees) AND monetary revenues (from token issuance).
All taxes— fiscal or monetary— are distortionary. Having a mix of revenue options are better than less since you can mix/combine them to get to same revenue goal w/ less distortion to user behaviors.
And here’s the kicker. Seigniorage revenue can be *better* than txn fee revenue for Uber.
Why?
(BTW, like this so far? Subscribe to my newsletter to get smarter about web3 & macro.
B/c txn fee is a tax on actual platform activities— you’re taxing Alice, or people who take & give rides. And keep in mind whatever activity you charge a fee on, you discourage. In contrast seigniorage is an inflation tax on*everyone* who holds UberCoin— both Alice and Bob.
This is the part I find myself explaining to projects I work with again & again:
Bob doesn’t really use Uber, remember? If you can tax Bob some, so that you don’t have to tax Alice (your real user) as much— i.e. lower txn fee somewhat & use seigniorage to make up for it— you can have same revenue but achieve higher platform activity.
Bottomline is a combination of txn fee & token issuance revenue is likely more optimal than sole reliance on either.
If you worry abt impact of this inflation tax on user incentive to hold UberCoin, you can share seigniorage proceeds w/ existing users as rewards in the form of, say, staking rewards or activity-based rewards.
But w/ hard token supply cap you literally remove the possibility of having seigniorage revenue down the road. For what? To make Bob happy?
Here’s a 3rd drawback of fixed token supply:
3. It discourages transaction activity w/ the token as medium of exchange
Gresham’s law, aka “bad money drives out good”, is the phenomenon that when a currency appreciates against others strongly & persistently, it tends to disappear from circulation.
I.e. people hoard it, instead of transacting w/ it. The reason should be obvious.
If Uber’s goal is to have more & more people use UberCoin for activities on Uber, instead of becoming a bitcoin competitor, this is something it may not want to ignore.
Obv the opposite can also be true— if a currency depreciates in value strongly & persistently, it tends to disappear from circulation, b/c people lose faith.
Not having a fixed cap does NOT mean issuing as many tokens as you want.
How do you manage issuance schedule, so as to avoid pitfalls above but also make UberCoin attractive to users you want to have?
Some potential options:
Option 1: Make issuance schedule dynamically respond to platform growth
When there’s higher user growth, i.e. token demand increase, issue more, otherwise issue less. It helps moderate price volatility while getting seigniorage revenue when feasible. Challenge is you’d need a good response formula & explain the unpredictable schedule to users.
Option 2: Have a fixed issuance schedule programmed well in advance
Tell users from get go how much new tokens will be issued in yr 2, yr3, yr 4…to infinity. Benefit is simple to execute, clear communication & users know exactly what to expect. Challenge is it’s not flexible to growth condition & crypto mkt condition.
Option 3: Fix the issuance schedule for a while and then re-evaluate
Have a fixed issuance schedule for, say, 3 yrs. Once platform is more stable, switch to something more sophisticated, such as option 1.
The goal should be to have token value grow steadily (which will happen if the platform grows) w/ moderate volatility.
Communicating issuance path clearly & having it programmed rather than discretionary should help solve user trust & time inconsistency problems that plague traditional fiat currency issuers, w/o having to adopt a capped token supply.