Key choice for TON's official ecosystem development: traffic-driven rather than asset-driven

Author:++@Web3Mario++（https://x.com/web3_mario）

Abstract: Recently, I have been continuously learning about the technologies related to TON DApp development and trying to think about some product design logic. With the rising popularity of TON, activities such as AMAs and roundtable discussions have also increased, and I have participated in some of them, discovering some interesting things that I hope to share with everyone. To conclude, I found that the TON official's approach to ecosystem construction is quite different from traditional execution layer projects, or what is known as public chains. It seems to choose traffic-driven rather than asset-driven. This brings a whole new requirement for developers: if they hope to gain official endorsement, or more straightforwardly, become projects favored by the official, the core operational metrics during the cold start phase need to transition from asset-related metrics, such as TVL, market cap, and number of holders, to traffic-driven metrics, such as DAU, PV, and UV.

Asset-driven has always been the core of Web3 project development and operation

Historically, the core judgment standard for the success of public chain projects has been how much asset has been accumulated, and sustainability and core competitiveness are judged based on the composition and distribution of these assets. Simply put, it is about how much TVL a chain has, how these TVLs are composed, what proportion of native assets there are, the ratio of blue-chip coins to altcoins, the proportion of certificate-type assets, the degree of the Matthew effect, etc. So what conclusions correspond to these questions? Let’s illustrate with a few examples:

• Suppose a chain has a high proportion of blue-chip coins like BTC and ETH in its total value, and the top ten percent of people own eighty percent of the assets. This roughly indicates that the chain is relatively friendly to traditional cryptocurrency whales, or that it has a strong attraction for traditional cryptocurrency whales. Typically, there may be backing support from projects like CEX behind it.
• Suppose a chain has a high proportion of native assets, a relatively even distribution, and a small standard deviation of user assets. This roughly indicates that the chain team has good operational capabilities, or has relevant community resources, good community building, and an active developer ecosystem. Typically, it may be driven by a community with a successful background and has broad community support.
• Suppose a chain has a high proportion of certificate-type assets, then caution is warranted. This roughly indicates that it is likely still in the early construction stage and has not formed effective attraction to core assets. However, the team may have some whale resources, but the collaborations achieved are not close or attractive enough, leading to whales being reluctant to directly transfer core assets onto it. Web3 projects on such chains can easily be harvested by whale tides.

Of course, different interpretations may arise based on different situations, but one will find that assets are the key to judgment. The reason for this is that the core value of Web3 lies in digital assets. This topic has been thoroughly discussed in my previous article++ "The Popularity of Runes is a Regression in the Development of Cryptographic Technology, but it is the Best Reflection of Web3's Core Value"++, and interested friends can discuss it with me. Therefore, for a long time, Web3 developers have focused on how to create and maintain asset value, or how to effectively attract assets during product design, cold start plans, and economic model design. Depending on the type of project, the priority of these two issues may vary.

However, the TON team seems to have chosen not to follow this line of thinking in the process of ecosystem construction, but rather to adopt the conventional method found in Web2 projects, or traditional internet projects—traffic-driven—to guide or support products and build the ecosystem. The reasons for this are twofold. First, there have already been many articles analyzing TON ecosystem DApps, and I believe everyone should have some understanding of the current state of the TON ecosystem. The most active category of apps currently is traffic games like Notcoin. Upon closer examination of its technical architecture, it cannot even be considered a DApp, because typically, Web3 games have two significant characteristics: asset props on-chain and core algorithms on-chain, both utilizing the trustless capabilities of blockchain to reduce trust costs during game operations. Notcoin does not possess such characteristics; it merely maps a final reward point to a type of FT token on the TON public chain and has issued an airdrop once. You can find many similar examples, and its current state is naturally inseparable from TON's support, indicating that in the eyes of the TON officials, some traditional Web3 values are not as important as traffic; as long as there are users, you may not even be a Web3 project and still receive official support.

Secondly, in some public occasions, TON officials have also chosen to actively guide the community towards this direction in product design. Last Friday, I participated in a Twitter Space about the TON ecosystem, which included officials from the TON foundation and some Web3 VCs. My impression from listening was that there is a significant gap between the two parties regarding their views on the TON ecosystem. The officials seem to prefer to benchmark the TON ecosystem against the WeChat Mini Program ecosystem, vigorously guiding users to associate the two and encouraging traffic-driven products, while the Web3 VCs talk more about considerations related to digital assets. This also indicates that the official may have a considerable divergence from traditional Web3 models in the process of building the ecosystem.

So why would the TON officials make such a choice? This brings us to the core narrative logic of TON ecosystem construction, which is the potential to break the circle, rather than the ability to accumulate assets.

The core narrative logic of TON ecosystem construction: breaking the circle potential rather than asset accumulation ability

How should we understand this statement? We know that the core narrative logic of most public chain projects still revolves around the competition for digital assets, that is, through certain technologies, while ensuring that the core values of Web3 are met, such as decentralization, greatly improving network throughput, reducing usage costs, and enhancing efficiency. Its core value lies in the ability to accumulate digital assets. A cheaper and faster public chain will obviously attract more digital assets, and more digital assets are the value support for the business model of these public chain projects. Higher adoption rates mean greater demand for the official tokens used as transaction fees, which will help support the value of the large number of tokens held by the project parties.

However, the narrative that TON hopes to create is not here, but rather in its potential to break the circle. You can easily find such soft articles or viewpoints online: Telegram has the highest number of communication app users globally, reaching 800 million, and TON, backed by this large user base, will have unparalleled advantages in breaking the circle. Breaking the circle is the core narrative logic of TON's ecosystem construction.

So why is there such a difference? This fundamentally involves two issues:

• The core business logic of TON;
• The relationship between TON and Telegram;

First, the core business logic of the TON team is actually similar to that of most public chain projects, built on maintaining the value of the TON token. However, for TON, the path of maintenance has an additional option compared to other projects, which is Telegram's advertising system. We know that since the beginning of this year, the TON token has gained an important use case as the settlement token in Telegram's advertising commission system. Advertisers pay for traffic purchases using TON tokens, and this portion of the fee is paid to the respective channel owners as commissions, with Telegram taking a certain percentage of the fees.

This means that in addition to being used as transaction fees for the chain, there is a second option for supporting the value of the TON token, which is to expand the advertising system of Telegram. This is actually a common traffic-driven model seen in Web2 projects, except that the settlement token has switched from fiat currency to cryptocurrency. To optimize the efficiency of Telegram's advertising system, it will specifically involve two aspects: creating more valuable advertising slots and tagging Telegram users. The TON team has found that an efficient scenario to achieve these two effects is Mini Apps. As long as Mini Apps are used frequently, after introducing the advertising commission system, they can become high-quality advertising slots.

Secondly, we know that Telegram, as an application that emphasizes privacy protection, faces significant challenges and sensitivities in tagging users to provide advertisers with precise marketing capabilities. Therefore, Telegram cannot offer precise marketing services to advertisers, such as targeting ads for a dessert brand to Indian users who like sweets, which affects Telegram's commercialization capabilities. However, in Mini Apps, since the user participation主体 is not Telegram but the third-party application, Telegram merely serves as a carrier, which creates conditions for tagging users. During the user's participation in Mini Apps, information such as user habits and preferences will be tagged, and the entire process is less likely to cause user aversion, making it smoother.

The above two aspects also explain the phenomenon mentioned earlier: in terms of project support, TON does not prioritize some traditional Web3 values; as long as there is traffic, official support can be obtained.

Some may wonder if the construction process should be better led by Telegram. As a public chain, TON should still adhere to some traditional Web3 values to build a cohesive community. This brings us to the second issue, the relationship between TON and Telegram.++ I have introduced the relationship between TON and Telegram in my previous article++. Overall, from a phenomenological perspective, TON's position is more like a subsidiary supported by Telegram, which has made some legal separations to handle certain risky businesses through the subsidiary, thereby reducing its own risks. For Telegram, which has such high adoption and emphasizes privacy protection, it is naturally under "close scrutiny" by various government departments. In the pursuit of a more stable and less interfered profit model, Telegram has chosen to use cryptocurrency instead of fiat currency as the settlement object for advertising. However, this brings new risks in regions that are not friendly to crypto assets. Therefore, the current structure effectively reduces such risks. Understanding this relationship leads us to a conclusion: the two are essentially in a master-servant relationship. Therefore, when developers design applications, it is advisable to think from the perspective of Telegram rather than the TON public chain to more easily gain official support.

In conclusion, TON's ecosystem construction path has chosen traffic-driven rather than asset-driven in the short term. This brings a whole new requirement for developers: if they hope to gain official endorsement, or more straightforwardly, become projects favored by the official, the core operational metrics during the cold start phase need to transition from asset-related metrics, such as TVL, market cap, and number of holders, to traffic-driven metrics, such as DAU, PV, and UV.