Since the popularity of ordinarys, the development of the BTC ecosystem has entered a full-scale stage. In a very short period of time, a large number of ecological projects have been born in the market, including hundreds of so-called "BTC L2". Concepts such as oracles, modularization, DA, etc. that are popular in the smart contract market have also quickly extended to the BTC ecosystem.

However, the market performance does not seem to be very good. The ecosystem seems to be in a state of stalling. Many L2s have been sentenced to death before they are even on the mainnet. Merlin, which ranks first in TVL, performs far below expectations. Even the most popular targets like runes seem to be a one-time trend. Let's talk about why this situation occurs in this article.

1. Multi-dimensional reasons for heat shutdown

I personally think there are the following points:

1. The development stage of the BTC ecosystem has moved from Phase 1 to Phase 2, and the popularity of the first-layer asset protocol no longer exists.

I analyze the development of BTC ecosystem into three stages:

  • Phase 1: Layer 1 Asset Issuance

  • Phase 2: L2 Battle

  • Phase 3: DAPP Mass Adoption

The market has quickly shifted from the ordinary narrative of first-layer asset issuance to the second stage. People have found that many first-layer asset protocols do not make much sense, and even feel like they are trying to cash out on their BTC.

The development speed of the second phase is also much faster than I expected, thanks to crypto's accumulation of other public chain technologies, so you can see that there are many EVM-compatible chains that can quickly complete the architecture and initial development.

2. The numerous L2 solutions are of varying quality, which distracts attention.

There are many "BTC L2" solutions on the market. The technical threshold of most solutions is not high. The innovation in the white paper is just "micro-innovation" or just a name to tell the story and attract financing. The quality is uneven. Although I disagree with the definition of "BTC L2" in Bitcoin Magazine, too strict requirements will limit the diversity of solutions, especially in the early stage of the ecosystem. But it does not mean that just packaging it can become "BTC L2" and then attract people to cut leeks.

Although too many projects are beneficial for promoting innovation, they also greatly distract attention and disperse limited on-site funds, so the depressed state is very severe.

3. The overall market environment is not good

Even if the BTC ETF is approved, this round of incremental growth has not shown strong performance. The crypto market belongs to the venture capital market. It is currently highly correlated with the world's risk market. The overall environment is not good, and crypto cannot be immune to it. It may even perform much more dramatically than other risk assets.

There is obviously not enough capital in the market, and the project valuations are pulled very high from the beginning. Funds from various tracks are unwilling to take over from each other, making the sluggish market situation even more intense.

2. Asset security is always the first factor

1. Differences in ecological foundations

In the BTC ecosystem, there is a point that is very different from the ETH ecosystem:

BTC holders have strong demands and desires to “control their own assets”

The difference in their ecological foundations will inevitably lead to different technical solutions and models. In most BTC L2 solutions, whether BTC is used as gas or not, there will be a problem:

How to safely “cross” BTC from L1 to L2?

Due to the limited scripting capabilities of BTC, it cannot easily implement L1/L2 secure cross-chain of BTC assets like smart contracts. Most of the methods adopted are "multi-signature cross-chain bridges".

Simply put, a multi-signature cross-chain bridge is: the user transfers BTC to a multi-signature account on L1, and then the built-in solution will generate a mapping asset for the user on L2. The user submits an application when withdrawing, and then the multi-signature account transfers the assets to the user.

This method is very simple and easy to implement, but its shortcomings are also obvious: security is not effectively guaranteed! Security depends on the security of the multi-signature account, and in most cases it depends on the "moral level of the multi-signer". However, crypto is very "dark forest". I believe that this type of security is not as good as buying BTC ETF (you can understand BTC ETF as a BTC L2, which adopts a custody solution).

Of course, we can see some new innovations, such as innovations based on bitvm, the addition of zk technology, the introduction of decentralized validators and other solutions. What we need to find is a solution that can bring native or quasi-native security.

2. Why emphasize safety?

Without security, who would dare to easily take out BTC to use in these expansion plans or projects? ! If one day it cannot be withdrawn, it will become "Q coin".

It is understood that more than 70%-80% of BTC is in CEX and cold wallets. We can still regard the BTC in CEX as active, while the BTC in cold wallets is completely inactive. If these assets are not activated, the establishment of the ecosystem will undoubtedly be slow or even fail.

3. The primary tasks and methods of the BTC ecosystem

After laying the groundwork for so long, you should be able to see what I want to express, right?

The primary task of the BTC ecosystem is to safely activate BTC assets

Under the premise of safety, if BTC assets can be activated to participate in more scenarios and gain benefits, why not do it! However, it is important to note that "safety is the premise" and it is of utmost importance to ensure that users do not lose control of their assets!

I have observed several types of solutions currently on the market. I will give a brief introduction here, and I will give a detailed introduction to specific projects in the future.

1. Combining time-lock staking

There is a time-lock mechanism in BTC, which can implement some simple locking logic. Some projects are considering combining time-lock to lock the user's BTC, so that the assets are still in the hands of the user, but they need to be unlocked at maturity or some actions are generated due to certain trigger conditions (in fact, BTC scripts do not provide the latter function, but there are some clever ways to deal with it). This is similar to completing the pledge, and the pledge event can be recorded, and then this pledge is used as the security economic layer of the POS chain (we know that the POS chain relies on the pledge of funds).

Although this design has many limitations (for example, the pledged BTC cannot directly participate in DEFI), it can give BTC a safe economic effect, and the generated income or points can also participate in the DEFI ecosystem of the chain in the form of LRT. Being able to maintain security (assets are under your control) and enjoy income is attractive to BTC holders.

This type of project includes babylon, chakra, etc.

2. Improve cross-chain security

Since the general multi-signature cross-chain bridge is not secure enough, we can solve this problem, such as introducing more multi-signers (some side chains use this form, multi-signers add more large institutions to endorse, etc.), adopting decentralized multi-signature verification, and adopting the "withdrawal-reimbursement" + zk technology solution...

Some of these projects can improve security in perception but the security level remains the same in essence, while others can indeed improve security but the progress is relatively slow (such as combining bitvm technology). The latter is the focus of my observation because the market usually rewards time weights.

3. Expand directly on one layer

If we can complete the expansion on L1, then there will be no bridge problem, and naturally there will be no bridge security problem, so expansion based on L1 is also a theoretically feasible idea. There are also many solutions in this area, such as RGB, which realizes off-chain Turing completeness and smart contract expansion through "one-time sealing + client verification", AVM realizes the expansion of smart contracts on the first layer through index programming, RGB++ uses isomorphic binding technology to map the assets on the first layer to the second layer, etc...

This type of project is also a focus of observation. They are more original and may be more difficult to develop, but if they can be successful, the impact they can bring will be greater.

IV. Conclusion

In my judgment of the second stage of "L2 War", I have refined the stages based on recent observations:

  1. L2 Flurry

  2. BTC asset activation plan exploration and progress

  3. Modular solutions are favored and combined

  4. L2 Endgame