Beijing Coin News Report:
Author:
Mario looks at Web3, Source: X, @Web3Mario
In general, I found that the TON official’s ecological construction idea is different from traditional execution layer projects, also known as public chains. It seems to have chosen traffic-driven rather than asset-driven. This brings a new requirement for developers who want to obtain official endorsement or become a project that the official prefers. The core operational indicators in the cold start stage need to transition from asset-related indicators such as TVL, market value, and holdings to traffic-driven indicators such as DAU, PV, and UV.
Summary: I have been studying the relevant technologies for TON DApp development and thinking about some product design logics. With the increasing popularity of TON, there have been more AMA sessions, roundtable discussions, and other activities, and I have participated in some of them. I have discovered some interesting things and would like to share them with you. In conclusion, I found that the TON official’s ecological construction idea is different from traditional execution layer projects, also known as public chains. It seems to have chosen traffic-driven rather than asset-driven. This brings a new requirement for developers who want to obtain official endorsement or become a project that the official prefers. The core operational indicators in the cold start stage need to transition from asset-related indicators such as TVL, market value, and holdings to traffic-driven indicators 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 the amount of assets accumulated and the composition and distribution of these assets to assess their sustainability and core competitiveness. In simple terms, the evaluation of a chain is based on factors such as the total value locked (TVL) and the proportion of different types of assets, such as blue-chip coins, altcoins, and tokenized assets. Let’s take a few examples to illustrate:
Suppose a chain has a high proportion of blue-chip coins like BTC and ETH, and the top 10% of people own 80% of the total assets. This roughly indicates that the chain is more friendly to traditional cryptocurrency whales and has a strong appeal to them. Usually, there may be endorsements from projects like centralized exchanges (CEX).
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 team’s operational capabilities are good, and there are related community resources and active developer ecosystems. Usually, it is driven by a successful community and has broad community support.
Suppose a chain has a high proportion of tokenized assets. This needs to be treated with caution, as it indicates that it is probably 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 may not be close or the attraction may not be strong, resulting in whales being reluctant to transfer their core assets to the chain. Web3 projects on such chains are easily harvested by whales in a tidal manner.
Of course, different situations may have different interpretations, but you will find that assets are the key to evaluation. This is because the core value of Web3 lies in digital assets, which has been fully discussed in my previous article “The popularity of Runes is a regression of cryptographic technology development, but also the best embodiment of Web3’s core value.” Interested friends can discuss 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 solutions, and economic model design, depending on the type of project, the priority of these two issues may vary.
However, in the process of ecological construction, the TON team seems to have chosen a different approach from this logic and instead chose the conventional approach of traffic-driven projects in Web2 or traditional Internet projects to guide or support products and build ecosystems. The reason for saying this is twofold. First, there have been many articles analyzing the TON ecological DApps, and everyone should have a certain understanding of the current state of the TON ecosystem. The most active category of apps is similar to Notcoin, which is a traffic-based mini-game. If you examine its technical architecture, it can’t even be considered a DApp because Web3 games usually have two notable features: on-chain asset items and core algorithms that utilize the trustless capability of blockchain to reduce trust costs in game operations. However, Notcoin does not have these features; it simply maps a final reward score to a FT token on the TON public chain and airdrops it. You can find many similar examples, and the current situation is naturally inseparable from TON’s support. This indicates that in the eyes of the TON official, 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 forums, TON officials have also chosen to actively guide the community in a certain direction in terms of product design. Last Friday, I participated in a Twitter Space discussion about the TON ecosystem, which included TON foundation officials and Web3 VCs. The impression I got from listening was that there is a big gap in the views of the two parties on the TON ecosystem. TON officials seem to like to compare the TON ecosystem with WeChat mini-programs and encourage traffic-driven products. On the other hand, Web3 VCs focus more on considerations related to digital assets. This also indicates that the official may have a significant difference from traditional Web3 models in the process of building the ecosystem.
So why did the TON official make this choice? This leads to 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: the potential to break barriers rather than the ability to accumulate assets
How do we understand this statement? We know that the core narrative logic of most public chain projects is mainly about the competition for digital assets. They aim to greatly increase network throughput, reduce usage costs, and improve efficiency on the basis of meeting the core values of Web3, such as decentralization. The core value lies in the ability to accumulate digital assets. A public chain that is cheaper and faster to use will attract more digital assets, which serve as the value support for the business models of these public chain projects because higher adoption rates mean more demand for the official tokens used as transaction fees. This will help support the value of the tokens held by the project.
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 users among communication applications globally, reaching 800 million. With such a 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 involves two issues:
TON’s core business logic;
The relationship between TON and Telegram;
First of all, TON’s core business logic is actually similar to that of most public chain projects, which is based on maintaining the value of the TON token. However, TON has an additional choice compared to other projects, which is Telegram’s advertising system. Since the beginning of this year, the TON token has gained an important purpose as the settlement token in Telegram’s advertising commission system. Advertisers use TON tokens to pay for traffic acquisition costs, and this part of the cost 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 the TON token, which is to expand Telegram’s advertising system. This is actually a traffic-driven model commonly used in Web2 projects, but the settlement token has switched from fiat currency to cryptocurrency. To optimize the efficiency of Telegram’s advertising system, it will involve creating more valuable advertising positions and labeling Telegram users. The TON team found that an efficient scenario to achieve these two effects is Mini Apps. As long as a Mini App is frequently used and an advertising commission system is introduced, it can become a high-quality advertising position.
Secondly, we know that Telegram emphasizes privacy protection, and tagging users to enable precise marketing for advertisers is a difficult and sensitive task. Therefore, Telegram cannot provide precise marketing services for advertisers, such as sending targeted ads for a dessert brand to Indian users who like desserts. This affects Telegram’s ability to monetize. However, in Mini Apps, since the user’s participation is not through Telegram itself but through a third-party application, Telegram is just a carrier. This creates conditions for user tagging. In the process of user participation in Mini Apps, user habits and preferences will be tagged, and the entire process is less likely to cause user aversion and is relatively smooth.
These two aspects also explain the phenomenon mentioned earlier. In TON’s choice of project support, it does not value some traditional Web3 values. As long as there is traffic, you can receive official support even if you are not a Web3 project.
Some may question why Telegram should not take the lead in the construction process. 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 introduced the relationship between TON and Telegram in my previous article. In general, from the observed phenomenon, TON’s status is more like a subsidiary supported by Telegram. This subsidiary has implemented certain legal separation to handle certain risky businesses and reduce its own risks. For Telegram, which has such a high adoption rate and emphasizes privacy protection, it naturally receives “special attention” from governments around the world. In order to explore a more stable and less easily disrupted profit model, Telegram chose to use cryptocurrency instead of fiat currency as the settlement target for advertising. However, this will bring new risks in regions that are not friendly to cryptocurrencies. Therefore, the current architecture can effectively reduce this risk. Understanding this relationship, we can conclude that fundamentally, they still have a master-slave relationship. Therefore, when developers design applications, it is recommended to think from the perspective of Telegram rather than the TON public chain in order to more easily obtain official support.
In conclusion, in general, TON has chosen a traffic-driven approach rather than an asset-driven approach in its ecological construction path in the short term. This brings a new requirement for developers who want to obtain official endorsement or become a project that the official prefers. The core operational indicators in the cold start stage need to transition from asset-related indicators such as TVL, market value, and holdings to traffic-driven indicators such as DAU, PV, and UV.
