Author: Eric SJ (@sjbtc 9)
"We embrace Bitcoin because it has saved the world economy from inflation, yet in Web3 we are practicing what we oppose: inflation through time-based unlocking."
The theme of this article will be an exploration of the issues surrounding token issuance, from the phenomenon of "low circulation, high FDV" to the improvement of the "fair launch" Launch paradigm.
Before that:
I have previously reviewed the evolution of token distribution methods over the years, from free airdrops to the recently emerged Tap to Earn, and interested friends can revisit this article.
I. The Essence of the "Low Circulation, High FDV" Problem
Even though I have previously published a related Chinese report, looking back now, I have not really explored the essence of the problem. The correct question to ask is:
Why is there a gap between market capitalization and FDV? And why are they problematic?
Looking back at the traditional financial market, this seems to be a feature unique to Web3, as the traditional financial market, while having a difference between total shares and market capitalization, this difference is not very large and is not a widespread phenomenon. However, in the VC-backed tokens we are familiar with this year, this phenomenon is ubiquitous.
(Most initial circulations are controlled within 20%)
Even if there are subsequent new share issuances in securities, they are usually through financing or stock splits, both of which are immediately reflected in the market price.
The fundamental difference between the two markets lies in the culture, which is a problem inherent in the design of Bitcoin: pre-fixed supply, making the market supply and demand curve coincide with the issuance curve. If we apply this phenomenon to the traditional financial market, FDV = all possible future dilutions of the stock.
Therefore, in my view, the FDV metric has no practical meaning, which is why I @sjbtc 9 only use market capitalization as the current reference indicator, rather than FDV.
However, before the official TGE of a project, this indicator is very important for the fundraising stage. How to properly distribute the cake while also raising funds reasonably in the process of distributing interests to various parties is crucial for a project. Therefore, back to the first question:
Essentially, the difference between market capitalization and FDV is a result of the transition between the primary and secondary markets.
But this is not the root cause that the market has criticized. After all, the primary market provides a very high trial-and-error space for the industry's development. What really causes this phenomenon to become problematic is the corresponding: time-based unlocking issue.
The model itself is not the problem, but how it is adopted. After all, Bitcoin also started with low circulation, but while most projects have imitated Bitcoin's limited total supply and low initial circulation, they have not adopted its core principle: demand-driven issuance rather than time-based issuance.
The relationship between Bitcoin's issuance and price is often misunderstood as purely based on time (thanks to the well-known "four-year halving cycle"), but in fact, it is also driven by demand factors. Even all mined coins are based on this logic: if miners cannot ultimately benefit in the market in the long run, they will leave the node group.
This demand-driven issuance and market logic is in line with basic economic principles: Only when supply and demand are formed can prices be formed, and for an L1 protocol, only when this supply and demand is formed can security be maintained.
In stark contrast, most crypto projects (especially VC-backed projects) only follow time-based issuance, without the market supply and demand link, and this is the real root of the "low circulation, high FDV" problem.
In addition, there is a more hidden problem: misalignment of interests.
Most projects have different issuance arrangements for the team, VCs, community, and treasury.
Although at the time of issuance, it seems that some "vulnerable groups" (such as the community) are prioritized and their tokens are unlocked first, this leads to conflicts of interest, reflecting an extremely poor design.
The typical manifestations of this situation are:
(1) Before unlocking, the community/market expects token dumping, so they often act on this expectation to avoid further losses, which is a major starting point for the "sell high, buy low" crowd;
(2) While the project team, after the unlocking period, artificially inflates the token price through news and market making to attract retail investors, and then dumps the tokens on them.
This misalignment pits the team and VCs against the community, undermining trust and leading to poor post-TGE performance of many VC-backed tokens.
Therefore, demand-driven token issuance may be a more reliable solution.
II. Demand-Driven Unlocking
For projects with pre-fixed total supply and low initial circulation, the economically reasonable solution is issuance based on demand rather than time (this is particularly applicable to VC-backed projects with vesting mechanisms).
This will bring two market effects:
(1) Supply-demand balance: Tokens will only be released when there is additional demand (e.g. token consumption), thereby preventing planned inflation;
(2) Alignment of interests: Tokens will only be unlocked when the community/market generates additional demand for the tokens (e.g. protocol usage), aligning the interests of the team and VCs with the community.
However, this also brings new risks: the vesting of the team and VCs is uncertain. If the community stops participating, demand will wane, and no new tokens will be unlocked.
But shouldn't this risk be borne by the team and VCs? Without it, Web3 will still be a zero-sum game between insiders and the community - or worse, a financial scam.
III. Three Models Based on Demand-Driven Unlocking
Based on the above observations and conclusions, this article proposes three token launch models centered around the supply-demand model, with the core being fair launch, but with variations in the revenue model:
-I assume a common scenario of initial low circulation (10%) and large community allocation
(1) No Revenue Model: If the token has no revenue model, but each time the circulating tokens are consumed and burned, an equal amount of new tokens will be released (proportionally allocated to the team/VCs/community/treasury, etc.) to maintain a constant circulating supply until the final release.
The essence of this design is to drive new token unlocking through burning or consumption, but this design will inherently dilute the community's share in the circulating supply with each round of release, until the community's share becomes less than the other parts.
Even so, this version is more reasonable than a purely time-based unlocking.
(2) Revenue Model: This model requires the project itself to have revenue outside of the token, such as some cross-chain bridges, DEXs, Pumps, and other DeFi protocols. This model is based on the "No Revenue Model", where the protocol's own revenue is used to buy and burn newly issued shares, thereby ensuring the stability of the circulating supply.
With the offsetting effects, the impact on market price and circulation will be minimized, making the overall pool more stable, and in this model design, the community's majority share can be maximized while not harming the interests of the other parties.
(3) Income Model Plus Version:This is based on the second version, dividing the revenue of the protocol itself into two parts, one still used to hedge the impact of unlocking, and the other used to inject liquidity into the token's liquidity pool.
In an ideal state, this will form a positive flywheel effect on the basic model design of the token, until all the unlocking is completed, while also ensuring a certain price stability of the token.
Compared to the previous model, this requires more precise mathematical calculations: to set the optimal unlocking ratio between burning and issuance, and to determine the ideal revenue allocation - ensuring that one part is used to pay for the inflation buyback, while the remaining part is effectively injected into the pool.
The core root of these three model designs is to bind the unlocking of the token and the interests of all parties together, transforming the original misaligned opposition into a demand-driven need like a single rope.
Currently, we can see many projects that have incorporated revenue, burning, and buyback into the token economy, but there is no design for high FDV that binds market demand with token unlocking.
IV. Theoretical Examples
In fact, most of the views in this article come from a tweet cited by @gabby_world_, the Founder.
I have translated the problems and models mentioned therein, and made quite a few modifications, hoping to help you understand the underlying economic design thinking and what it is based on.
And this design has also been applied to the token design of their own project.
From my perspective, I think basing the unlocking of future tokens on supply and demand is a very bold and difficult attempt, because as a project party, the first thing to convince is that their investors accept this.
Personally, as a VC, to be honest, it is very difficult for us to accept this.
Although many attribute the poor performance of the crypto market to lack of liquidity, stagnation of innovation or narrative fatigue, few realize that the real problem lies in the unfair redistribution of wealth, which further exacerbates the divide between institutions and the community, and is also the reason why the MEME craze has been ongoing.
I'm not sure how the GabbyWorld team coordinates this, but in the midst of what I see as somewhat idealistic designs, they have also made preliminary implementations, which is quite difficult.
For the fair launch of the token market, I have previously stated that community-driven collective wisdom is not desirable, as the decision-making cost will be very high in business expansion.
Gabby's way of using the token's own supply and demand to drive unlocking is difficult for other projects to replicate, and if this can be made to work, it deserves a separate category in the issuance history classification I initially provided.
