Analysis: The key choice for TON's official ecosystem construction is flow-driven rather than asset-driven.

This article is machine translated
Show original

Author | @Web3Mario

Abstract: I have been learning the relevant technologies of 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. I have also participated in some of them and found some interesting things. I hope to share them 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 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.

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

The core criterion for judging whether a public chain project is successful has always been how many assets have been 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 percentage of native assets are there, what percentage of blue-chip coins and Altcoin are there, what percentage of voucher assets are there, the degree of the Matthew effect, etc. So what conclusions do these questions correspond to? Let's give a few examples to illustrate:

Assuming that BTC, ETH and other blue-chip coins account for a high proportion of the total value in a chain, and the top 10% of people own 80% of the assets, it generally means that the chain is more friendly to traditional cryptocurrency whale, or it has a strong appeal to traditional cryptocurrency whale. 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.

If a chain has a high proportion of voucher assets, it needs to be treated with caution. This roughly means that it is probably still in the early stages of construction and has not effectively attracted core assets. However, the team may have some whale resources, but the cooperation is not close or the attraction is not strong, which makes the whale reluctant to transfer their core assets directly to it. Web3 projects on this chain are easily harvested by whale in a tidal manner.

Of course, there will be different interpretations depending on the situation, but you 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 did not seem to follow this idea in the process of ecological construction, but chose Web2 projects, or the conventional method in traditional Internet projects - traffic-driven, to guide or support products and build an ecosystem. There are two reasons for this. First, there are already many articles analyzing TON ecological DApps. I believe everyone should have a certain understanding of the current status of TON ecology. The most active APP category at present is the traffic mini-game similar to Notcoin. Looking closely at its technical architecture, it cannot even be considered a DApp, because usually, Web3 games have two significant features, asset props on the chain, and core algorithm on the chain, both of which use the trust-free ability of blockchain to reduce the trust cost in the game operation process. Notcoin does not have such a feature, but only maps a final reward point to a FT token on the TON public chain and issues an airdrop. You can find many similar examples, and their current status is naturally inseparable from the support of TON. 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 and you will get 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 the TON ecosystem, 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 the TON ecosystem. Officials seemed to like to compare the TON ecosystem with the WeChat applet ecosystem, 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 ecosystem.

So why did TON officials make such a choice? This involves 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: 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 here, 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 similar to that of most public chain projects, which are based on the maintenance of 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 pay for traffic purchases through TON tokens, 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 brings conditions for user labeling. In the process of user participation in Mini App, user's habit preferences and other information 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 the selection 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.

Source
Disclaimer: The content above is only the author's opinion which does not represent any position of Followin, and is not intended as, and shall not be understood or construed as, investment advice from Followin.
Like
1
Add to Favorites
1
Comments