Author: @Web3Mario (https://x.com/web3_mario)
Abstract: I have been learning the relevant technologies for TON DApp development recently, and trying to think about some product design logic. As TON becomes more popular, some AMA, roundtable discussions and other activities have become more and more frequent. I have also participated in some of them and found some interesting things that I hope to share with you. Let me first talk about the conclusion. In general, I found that the official ecological construction ideas of TON are different from traditional execution layer projects, that is, the so-called public chains. It seems to choose traffic-driven rather than asset-driven. This brings a new requirement to developers. If you want to get official endorsement, or more bluntly become a project that the official likes more, the core operating indicators in the cold start phase need to transition from asset-related, such as TVL, market value, number of coins held, etc. to traffic-driven, such as DAU, PV, UV, etc.
Asset-driven development has always been the core of Web3 project development and operation
For a long time, the core criterion for judging whether a public chain project is successful is how much assets are accumulated, and judging whether it is sustainable and its core competitiveness based on the composition and distribution of assets. In layman's terms, it is how much TVL a chain has, how these TVLs are composed, what is the proportion of native assets, what is the ratio of blue chip coins to altcoins, what is the proportion of voucher assets, the degree of Matthew effect, etc. So what conclusions do these questions correspond to? Let's give a few examples to illustrate:
Assuming that blue-chip coins such as BTC and ETH account for a high proportion of the total value in a chain, and the top ten percent of people own eighty percent of the assets, it roughly means that the chain is more friendly to traditional cryptocurrency whales, or it has a strong appeal to traditional cryptocurrency whales. Usually, there may be endorsements and support from projects such as CEX behind it.
Assuming that the proportion of native assets in a chain is high, the distribution is relatively even, and the standard deviation of user assets is small, it generally means that the chain team has good operational capabilities, or has relevant community resources, good community construction, and a relatively active developer ecosystem. Usually, it is likely to be driven by a community with a successful background and has relatively broad community support.
Assuming that the proportion of voucher assets in a chain is high, it needs to be treated with caution. This roughly means that it is most likely still in the early stages of construction and has not effectively attracted core assets. However, the team will have some whale resources, but the cooperation reached is not close or the attraction is not strong, which makes the whales reluctant to transfer their core assets directly to it. Web3 projects on this chain can easily be 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 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 is a setback in the development of encryption technology, but it is also the best embodiment 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 solutions, and economic model design. Depending on the type of project, the priority of these two issues will be different.
However, the TON team does not seem to choose to follow this idea during the ecological construction process. Instead, it chooses the Web2 project, or the conventional method in traditional Internet projects-traffic drive, to guide or support products and build an ecosystem. There are two reasons for saying this. First, there have been many articles analyzing the DApps in the TON ecosystem. I believe everyone should have a certain understanding of the current status of the TON ecosystem. The most active APP category at present is traffic games similar to Notcoin. Taking a closer look at its technical architecture, it cannot even be counted as a DApp, because usually, Web3 games have two distinctive features: assets and props are put on the chain, and core algorithms are put on the chain, both of which use the trustless ability of the blockchain. To reduce the trust cost in the game operation process. Notcoin does not have such characteristics. It just maps a final reward point to an FT token on the TON public chain and issues an airdrop. You can find many similar examples, and the current situation is naturally inseparable from the support of TON. This shows that in the eyes of TON officials, some traditional Web3 values are not important compared to traffic. As long as there are users, you can even Even if it is not a Web3 project, it will also receive official support.
Secondly, in some public occasions, TON officials also choose to actively guide the community to design products in this direction. Last Friday, I participated in a Twitter space about TON ecology, which included TON foundation officials and some Web3 VCs. My feeling after listening to them was that there was a big gap between their views on TON ecology. Officials seemed to like to compare TON ecology with WeChat mini-program ecology, and tried their best to guide users to associate the two, and encouraged traffic-driven products, while Web3 VCs talked more about digital asset considerations. This also shows that the official is likely to have a relatively large difference from the traditional Web3 model in the process of building the ecology.
So why did TON officials make such a choice? This involves the core narrative logic of TON's ecological construction, which is the potential to break the circle rather than the ability to accumulate assets.
The core narrative logic of TON ecosystem construction: Breakthrough potential rather than asset accumulation ability
How to understand this sentence? We know that the core narrative logic of most public chain projects is still the competition for digital assets, that is, through certain technologies, on the basis of ensuring that the core values of Web3 are met, such as decentralization, the network throughput is greatly improved, the cost of use is reduced, and the efficiency of use is improved. Its core value lies in the ability to precipitate digital assets. A cheaper and faster public chain will obviously attract more digital assets, and more digital assets are the value support of the business model of these public chain projects, because a higher adoption rate means more demand for official tokens as handling fees, which will help support the value of a large number of tokens in the hands of the project parties.
However, the narrative that TON hopes to create is not this, but its potential to break through the circle. You can easily find such soft articles or such opinions on the Internet: Telegram has the highest number of communication application users in the world, up to 800 million people, and TON will have unparalleled advantages in breaking through the circle with the support of this large user base. Breaking through the circle is the core narrative logic of TON in its ecological construction.
So why is there such a difference? The core involves two issues:
TON’s core business logic;
The relationship between TON and Telegram;
First of all, the core business logic of the TON team is actually similar to that of most public chain projects, all of which are based on maintaining the value of TON tokens. However, compared with other projects, TON has an additional option for maintenance, which is Telegram's advertising system. We know that since the beginning of this year, TON tokens have an important use as a settlement token in Telegram's advertising commission system. Advertisers use TON tokens to pay for traffic purchases, and this part of the fee will be paid to the channel owner of the corresponding channel as a commission, and Telegram officials will extract a certain percentage of the fee.
This means that in addition to the handling fee for using the chain, there is a second option for how to support the value of TON tokens, which is to expand the cake of Telegram's advertising system. This is actually a common traffic-driven model for Web2 projects, except that the settlement token has switched from legal currency to cryptocurrency. In order for Telegram to optimize the efficiency of the advertising system, it will specifically involve two aspects: creating more valuable advertising space and labeling Telegram users. The TON team found that an efficient scenario for achieving these two effects is Mini App. First of all, as long as Mini App is used frequently, it can become a high-quality advertising space after introducing the advertising commission system.
Secondly, we know that Telegram is an application that emphasizes privacy protection. It is extremely difficult and sensitive to label users and give advertisers the ability to conduct precision marketing. Therefore, Telegram cannot provide advertisers with precision marketing services, such as distributing a dessert brand advertisement to Indian users who like desserts. This affects Telegram's commercialization capabilities. However, in Mini App, since the user's participation is not Telegram, but this third-party application, Telegram is just a carrier, which creates conditions for user labeling. In the process of user participation in Mini App, user's habits and preferences will be labeled, and the whole process is not easy to cause user disgust and is relatively smooth.
The above two aspects also explain the phenomenon mentioned above. TON does not pay much attention to some traditional Web3 values in its choice of project support. As long as there is traffic, it can get official support.
Some people may wonder, shouldn’t this construction process be led by Telegram? As a public chain, TON should still follow some traditional Web3 values in order to build a cohesive community. This involves the second question, the relationship between TON and Telegram. I have introduced the relationship between TON and Telegram in my previous article. In general, from a phenomenal point of view, TON's status is actually more like a subsidiary supported by Telegram. The subsidiary has made certain legal isolation, so that it can operate through the subsidiary when dealing with certain risky businesses, thereby reducing its own risks. For Telegram, an APP with such a high adoption rate and emphasis on privacy protection, it is naturally "focused on" by government departments of various countries. In order to explore a more stable and less easily disturbed profit model, Telegram chose to use cryptocurrency instead of legal currency as the subject of advertising settlement. However, this will bring new risks to some areas that are unfriendly to crypto assets. Therefore, the current architecture can effectively reduce this risk. Based on this understanding of the relationship, we can easily draw a conclusion that the two are essentially a master-slave relationship. Therefore, when developers are designing applications, in order to more easily obtain official support from TON, it is recommended that they should think from the perspective of Telegram rather than the TON public chain.
Finally, to sum up, in general, TON's ecological construction path has chosen traffic-driven rather than asset-driven in the short term. This brings a new requirement to developers. If they want to obtain official endorsement, or more directly become a project that the official prefers, the core operating indicators in the cold start phase need to transition from asset-related, such as TVL, market value, number of coins held, etc., to traffic-driven, such as DAU, PV, UV, etc. Of course, regarding this conclusion, or some TON application development issues, and some TON product ideas, everyone is welcome to communicate with me on my Twitter.