Author @sleepy0x13
Doodles TGE completely meets my expectations, very typical. I really can't think of anyone who would buy its token, so this trend is not surprising, but rather reasonable.
I want to talk about my views on issuing tokens for application layer projects through this incident.
Many Web3 application projects have an illusion: "If I issue a token and design enough utility, the whole thing will take off."
Perhaps they really think this way, or maybe they have been educated by exchanges and VCs. But I believe this kind of thinking is fundamentally wrong.
1 | No one will buy your token because of utility.
The first step for many projects in designing a token is: I want it to be usable. So they start designing reward mechanisms, ticketing mechanisms, platform fee discounts, unlocking content, community governance, upgrading props... It looks very rich.
But the problem is: being usable does not equal wanting to use it, and it certainly does not mean people will buy it.
I believe that the logic of an application layer token relying on functionality to drive demand has been untenable from day one. Why?
① Users have no motivation to use it.
You have set a path for users: to use a function → first buy the token → then consume. But users will not take the initiative to do this "first buy the token" action.
- Discounts, unlocking, permissions, these functions are seen by users as "something that should be available by default," which is not sufficient to drive token purchase behavior.
- Functions are not exclusive and do not form pain points, so why should they use yours? Not to mention the cumbersome process and the need to bear asset fluctuations.
- Users have a short-term usage mindset, while tokens are long-term tradable assets, creating a mismatch.
② Functions cannot form sovereignty.
Web2's points, memberships, and coupon systems are fine, but no one has made them into tokens.
- Tokens are circulating sovereign assets; you give them "holding rights," not "one-time functionality."
- Functional scenarios (like tipping, voting) are weak relationships, temporary, and replaceable, making them inherently unsuitable for assetization.
If you turn your coffee loyalty card into a token, users will be puzzled: I finish my coffee, and that's it. Why should I bear price fluctuations?
③ Consumption-type tokens are destined to face value spillover.
This is actually a structural issue at the core.
After users tip, the tokens flow to creators; when creators monetize, it means selling pressure.
Without a value return mechanism, tokens become one-way circulation from users → creators → market.
There is no closed loop, only an open loop.
So it's not about whether one is willing to hold functional assets, but the fact that functional tokens do not have any "value retention mechanism" after use, which inherently creates continuous selling pressure.
In summary:
Tokens are not tools, but sovereignty. Functionality can only create one-time motivation, while assets require long-term belief, and the two are inherently in conflict.
2 | Products have a lifecycle, while assets must be oriented towards the long term.
This is the most fatal yet easily overlooked issue with application layer tokens: lifecycle mismatch.
The lifecycle of consumer-grade products is inherently short, especially Web3 application products:
- User dividends are consumed quickly, and retention costs are high.
- The migration threshold for creators and users is extremely low.
- Popularity is a scarce resource that dilutes continuously.
But tokens are something else:
- They are financial assets.
- They can be priced, traded, valued, and allocated.
- Their existence time is unlimited.
You are using a product with a 6-8 month lifecycle to endorse an asset that can theoretically be traded for 6-8 years. This is not a narrative issue; it's a structural mismatch.
And once you launch a token, the market will immediately ask you from an asset perspective:
- Where does your income come from? Can it be sustained?
- Can the profits be distributed? How?
- Can business growth drive token appreciation?
As a result, you present community activity + product roadmap to explain token value... This is not a valuation model; this is a fantasy.
Therefore, tokens should not be tied to a specific "product," but to an "organization" that can continuously create income and possesses assetization logic.
In other words:
You are not issuing tokens for a specific product but should be a financial representation of a company, a complete content system, or even a cultural IP.
If you do not have such scale capabilities, it means you are using the expectation of a short-lived product to package an everlasting asset imagination. This is not building an ecosystem; it's prematurely exhausting the future.
3 | Most utilities are a reluctant substitute for dividend logic.
I have talked with many project parties; many of them actually know that the most reasonable value anchor for tokens is asset-based incentive logic: dividends, buybacks, revenue sharing.
But why don't they do it?
It's not that they don't understand; regulation is an unavoidable hurdle.
- Clearly defined dividends trigger securities attributes.
- Adding protocol fee sharing requires compliance disclosure of income and distribution logic.
- Designing staking profit-sharing mechanisms can easily be classified as passive income schemes.
Once you go down this path, it means you have to face a series of issues regarding compliance, auditing, KYC, financial transparency, and cross-border legal structures.
So most projects choose to "avoid" and design seemingly useful but actually unvalued "pseudo-utility" mechanisms. These mechanisms appear "legally safe" but lack a structure that can truly support token valuation.
They are all avoiding the pricing logic of asset attributes. However, even if you do not treat tokens as assets, the market will not truly treat them as points.
Investors, communities, secondary market traders, they see: this token, if I hold it, can it bring cash flow, network dividends, or resource permissions in the future?
If you don't give an answer, they will give you a more direct response—selling.
So the more you avoid, package, and cover up the dividend logic with complex mechanisms, the faster the market will see through that you have no intention of distributing profits, and then vote with their feet.
Is there a way to design a reasonable token model without crossing the red line? Perhaps there is, but it must be very difficult. If you are issuing a long-term token that bears asset attributes, then you must face this reality.
You can choose not to distribute dividends, but you must clearly explain why the token is valuable.
Ultimately, utility is not the goal; it is a temporary measure. The market is always realistic and will not be deceived by narratives and mechanism diagrams for too long.
You can design it in a convoluted manner, but you must ultimately answer that question:
"What exactly makes this token worth holding?"
4 | Web3 does not need so many tokens; it needs real commercial closed loops.
Looking back at the development trajectory of Web3 over the past few years, we will find an increasingly obvious trend:
Tokens are becoming less like assets and more like hooks for narratives.
Many projects issue tokens not because tokens are indispensable in the model, but because they are "so useful":
- Building communities, doing airdrops.
- Working with VCs to inflate valuations.
- Creating narratives, cold starts.
Tokens are treated as a kind of market expectation management tool rather than as assets.
But when you use tokens to carry popularity and narratives without underlying value capture logic, they will always just be a narrative container, not a profit-sharing mechanism.
Such tokens are treated as options by the market from the moment they are launched:
- When not making money, discarded like a worn-out shoe.
- When they rise a bit, cash out for arbitrage.
- Without long-term holding motivation, lacking valuation anchors.
This is not a failure of the token; it is that you never intended for it to succeed from the very beginning—you just let it fulfill its tool attributes and then abandoned it.
A truly vital token must meet the following:
① It represents a real, sustainable value creation system.
② It has a clear, verifiable value return mechanism.
③ Its issuance is not the goal but a financial expression naturally evolved from your business closed loop. In other words, issuing tokens is not a growth hack, but a manifestation of your business model's maturity to tokenize future profits.
Projects without value creation merely issue tokens to cash out the bubble in advance;
Projects without value return merely create a secondary relay race;
Teams without a long-term perspective merely design paths for disguised exits.
Web3 lacks technology, players, and money. What it lacks is projects that can design tokens as a structural financial responsibility.
5 | Tokens are a type of value contract, not an operational tool.
Issuing tokens is fundamentally not a technical task, nor just a matter of trust, but rather financial structure design.
When you issue a token, it is essentially equivalent to signing a cross-time value commitment to the market:
① This system can create value.
② Holders have the right to receive part of the returns.
③ The issuer will use some mechanism to fulfill this right.
This is a quasi-contractual relationship that does not need to be written in black and white but will be remembered by the market in every transaction and every K-line.
So when you issue a token, the market assumes you have completed three things:
- You understand that you are issuing a financial instrument, not platform points.
- You accept that you must distribute returns in a rational, transparent, and sustainable manner.
- You acknowledge a fact: Tokens are a kind of trust asset that transcends time, cannot rely on popularity for support, and can only rely on value fulfillment.
But the reality is that most projects have no intention of creating asset structures:
- Using tokens to attract people, boost growth, and inflate expectations.
- Not establishing value return, not bearing asset responsibilities.
This is not building Web3; this is using Web3 narratives for Web1 harvesting.
Application layer tokens seem to have never been designed from an asset perspective. From the very beginning, there was no closed loop of value capture + distribution, nor was there any assumption of financial responsibility.
Web3 does not lack protocols, creativity, or narratives.
What it lacks is a way of thinking that truly treats tokens as long-term assets,
a respect for the capital market, a sense of responsibility towards holders, and a professional understanding of financial models.