In general, I found that TON’s official ecological development strategy is different from traditional execution layer projects, also known as public chains. It seems to have chosen a traffic-driven approach rather than an asset-driven one. This brings a new requirement for developers if they want to obtain official endorsement or become a project that the official prefers. In the cold start stage, the core operational indicators need to transition from asset-related metrics such as TVL, market value, and number of holdings to traffic-driven metrics such as DAU, PV, and UV.
Summary: Recently, I have been studying the relevant technologies for TON DApp development and thinking about some product design logics. As the popularity of TON increases, there have been more AMA sessions, roundtable discussions, and other activities. I have participated in some of them and discovered some interesting things that I would like to share with you all. First, let me state the conclusion. In general, I found that TON’s official ecological development strategy is different from traditional execution layer projects, also known as public chains. It seems to have chosen a traffic-driven approach rather than an asset-driven one. This brings a new requirement for developers if they want to obtain official endorsement or become a project that the official prefers. In the cold start stage, the core operational indicators need to transition from asset-related metrics such as TVL, market value, and number of holdings to traffic-driven metrics such as DAU, PV, and UV.
Asset-driven has always been the core of Web3 project development and operation
Asset-driven has always been the core criterion for judging the success of public chain projects. It is determined by how many assets are accumulated and the composition and distribution of these assets to assess their sustainability and core competitiveness. In simple terms, it refers to how much TVL a chain has, the composition of these TVLs, the proportion of native assets, blue-chip coins, and altcoins, the proportion of voucher assets, the level of Matthew effect, and so on. So, what conclusions can be drawn from these questions? Let me give you a few examples:
Suppose a chain has a high proportion of blue-chip coins such as BTC and ETH, and the top 10% of people own 80% of the assets. This roughly indicates that the chain is more friendly to traditional cryptocurrency whales or has a strong attraction for them. In most cases, there may be endorsement support from projects such as CEX behind it.
Suppose a chain has a high proportion of native assets, a relatively even distribution, and small standard deviations in user assets. This roughly indicates that the chain’s team has good operational capabilities and may have relevant community resources, good community development, and an active developer ecosystem. In most cases, it may be driven by a successful community and have extensive community support.
Suppose a chain has a high proportion of voucher assets, then it needs to be treated with caution. This roughly indicates that it is likely still in the early stage of development and has not effectively attracted core assets. However, the team may have some whale resources, but the cooperation achieved is not close or the attraction is not strong, resulting in whales being unwilling to directly transfer core assets to this chain. Web3 projects on such chains are easily harvested by whales in a tidal manner.
Of course, there will be different interpretations depending on the situation, but everyone will find that assets are the key to judgment. The reason for this situation is that the core value of Web3 lies in digital assets. This topic has been fully discussed in my previous article “The Popularity of Runes Represents a Regressive Development of Encryption Technology, But Also the Best Manifestation of the Core Value of Web3”. 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 in the process of product design, cold start plans, and economic model design, depending on the type of project, the priority of these two issues may vary.
However, it seems that the TON team has not chosen to follow this path in the process of ecological construction but has chosen the conventional approach of traffic-driven Web2 projects or traditional Internet projects to guide or support products and build ecosystems. The reasons for this can be divided into two points. Firstly, there have been many articles analyzing TON’s ecological DApp, and everyone should have a certain understanding of the current state of the TON ecosystem. The most active category of apps currently is mini-games like Notcoin. If we examine its technical architecture, it can’t even be considered a DApp because Web3 games usually have two notable characteristics: on-chain assets and on-chain core algorithms, which utilize the trustless nature of blockchain to reduce trust costs in game operations. However, Notcoin does not have these characteristics; it only maps a final reward point as an FT token on the TON public chain and conducts an airdrop. There are many similar examples, and their current situation is naturally inseparable from TON’s support. This shows that in the eyes of TON officials, some traditional Web3 values are not as important as traffic. As long as there are users, you don’t even have to be a Web3 project to receive official support.
Secondly, in some public occasions, TON officials also choose to actively guide the community to do product design in this direction. Last Friday, I participated in a Twitter space session about the TON ecosystem, which included TON foundation officials and some Web3 VCs. The impression I got was that there is a big gap in their views on the TON ecosystem. The officials seem to like to compare the TON ecosystem to the WeChat mini-program ecosystem and encourage traffic-driven products. However, the Web3 VCs focus more on considerations related to digital assets. This also indicates that the official’s approach to building the ecosystem may differ significantly from the traditional Web3 model.
So why did TON officials make this choice? This involves the core narrative logic of TON’s ecological construction, which is the potential to break barriers rather than the ability to accumulate assets.
The core narrative logic of TON’s ecological construction: potential to break barriers rather than the ability to accumulate assets
How should we understand this statement? We know that the core narrative logic of most public chain projects mainly revolves around the competition for digital assets. It aims to greatly increase network throughput, reduce usage costs, and improve usage efficiency based on certain technologies that meet the core values of Web3, such as decentralization. The core value lies in the ability to accumulate assets. A public chain that is cheaper and faster to use will undoubtedly attract more digital assets, and more digital assets are the value support for the business models of these public chain projects because higher adoption rates mean a greater demand for the official token used as a transaction fee, which will help support the value of the tokens held by the project party.
However, TON’s narrative is different. It lies in its potential to break barriers. You can easily find articles or opinions on the Internet that state that Telegram has the highest number of communication app users globally, reaching 800 million. With the support of this large user base, TON will have unparalleled potential to break barriers. Breaking barriers is the core narrative logic of TON’s ecological construction.
So why is there such a difference? This is related to two issues:
TON’s core business logic;
The relationship between TON and Telegram;
Firstly, TON’s core business logic is actually similar to that of most public chain projects, which is based on maintaining the value of TON tokens. However, for TON, there is an additional option for maintaining value compared to other projects, which is Telegram’s advertising system. Since the beginning of this year, TON tokens have gained an important use case as settlement tokens in Telegram’s advertising commission system. Advertisers pay for traffic acquisition using TON tokens, and this part of the fee is paid to channel owners as commissions, with Telegram deducting a certain percentage of the fee.
This means that in addition to being used as transaction fees on the chain, there is a second choice for supporting the value of TON tokens, which is to expand Telegram’s advertising system. This is actually a traffic-driven model commonly 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 involve two aspects: creating more valuable advertising spaces and tagging Telegram users. The TON team found that a highly efficient scenario for achieving these two effects is the Mini App. As long as the Mini App is used frequently, it can become a high-quality advertising space after introducing the advertising commission system.
Secondly, we know that Telegram, as an application that emphasizes privacy protection, has great difficulty in tagging users to enable precision marketing for advertisers, such as sending advertisements from a dessert brand to Indian users who like desserts. This affects Telegram’s commercialization capabilities. However, in Mini Apps, since users are participating through third-party applications and Telegram is just a carrier, it becomes possible to tag users. During the process of user participation in Mini Apps, their habits and preferences will be tagged, and the entire process is not likely to cause user aversion and is relatively smooth.
These two aspects also explain the phenomenon mentioned earlier. TON, in its choice of project support, does not value some traditional Web3 values. As long as there is traffic, it can receive official support.
Now, some people may wonder if Telegram should be the one leading the construction process at a higher level. As a public chain, in order to build a cohesive community, it should still adhere to some traditional Web3 values. This involves the second issue, the relationship between TON and Telegram. I have already explained the relationship between TON and Telegram in my previous article. In general, TON’s position is more like a subsidiary supported by Telegram. This subsidiary has established certain legal isolation, allowing it to operate certain high-risk businesses through the subsidiary, thereby reducing its own risks. For Telegram, which has such a high adoption rate and emphasizes privacy protection, it naturally attracts significant attention from governments around the world. In order to explore a more stable and less easily disrupted profit model, Telegram has chosen to use cryptocurrency as the settlement target instead of fiat currency in its advertising system. However, this will bring new risks to areas that are not friendly to cryptocurrencies. Therefore, the current architecture can effectively reduce this risk. Based on an understanding of this relationship, it is easy to conclude that the two are fundamentally in a master-slave relationship. Therefore, when developers are designing applications to more easily obtain the official support of TON, it is recommended to think from the perspective of Telegram rather than the TON public chain.
In conclusion, in general, TON has chosen a traffic-driven approach rather than an asset-driven one in the short term on its path of ecological construction. This brings a new requirement for developers if they want to obtain official endorsement or become a project that the official prefers. In the cold start stage, the core operational indicators need to transition from asset-related metrics such as TVL, market value, and number of holdings to traffic-driven metrics such as DAU, PV, and UV.
