Analyzing the Map Protocol: Why is the endpoint the interoperability layer of BTC Layer2?

Written by: Haotian

Recently, BTC layer2 projects have been emerging like mushrooms after rain. An incomplete count shows that there are already hundreds of projects ready to launch, creating a prosperous yet chaotic scene in the entire expansion ecosystem.

Because of this, new chains entering the BTC layer2 track must find a suitable positioning. Next, we will discuss @MapProtocol, which is well-known for being at the heart of the Bitcoin ecosystem, but its ultimate goal may not be layer2, but rather the interoperability layer of BTC. Why?

Because, in my view, there is currently no clear "standard" or "norm" in the BTC layer2 ecosystem: mature EVM Compatible chains can be considered BTC layer2; independent sidechains that can safely transfer BTC assets across chains can also be seen as BTC layer2; performance-oriented new chains with UTXO-like account models can be regarded as BTC layer2, and of course, this includes state channels, Lightning Network, and client-validated RGB as more native BTC layer2.

Theoretically, any chain that can connect to BTC ecosystem-related assets and promote the secondary prosperity of BTC assets through expansion can be classified under the BTC layer2 category. It may sound disrespectful to the definition and boundaries of "layer2," but didn't Vitalik recently suggest abandoning the layer2 concept in the face of the layer2 competition war in Ethereum?

To some extent, the current chaotic and disorderly (entropy) state of BTC layer2 is a form that is not controlled by any individual's subjective will, and it needs to undergo a long period of consensus friction, technical disputes, market competition, and survival of the fittest to gradually become clearer.

Previously, I wrote an analysis of the uniqueness of @BSquaredNetwork in the bitVM challenge mechanism, and also mentioned the abstract design of @ParticleNtwrk in collaboration with @BitmapTech on BTC Connect. MAP Protocol has had a strong voice on Twitter for a long time, and many friends have asked me to analyze it.

To be honest, I didn't understand it at first. Because a chain originally aimed at full-chain interoperability suddenly promotes an all-in Bitcoin layer2 ecosystem, it always feels a bit like compromising for the "narrative." After all, if it can create a narrative for full-chain interoperability, wouldn't positioning it as BTC layer2 be self-limiting?

With this question in mind, let's first analyze the technical logic framework of MAP Protocol:

MAP is positioned as a peer-to-peer full-chain infrastructure based on lightweight clients and ZK, focusing on peer-to-peer interoperability without third-party centralization. How does it achieve this? MAP's solution is to build a MAP relay chain, equivalent to a chain within the BOB chain. This relay chain will pre-compile the signature algorithms of different homogeneous chains in the contract, enabling cross-chain communication and zero-friction asset transfer capabilities.

Taking BTC as an example, MAP first deploys a ZK lightweight client on the BTC chain. The lightweight client does not need to download the full node's historical data and can execute certain operations on the BTC mainnet: for example, verifying block headers and Merkle proofs related to transactions, allowing the mainnet lightweight client to safely complete operations by only verifying specific transaction-related partial data when making withdrawal requests on the layer2 chain.

This actually originates from the Simplified Payment Verification (SPV) technology defined in the Bitcoin white paper.

If we view the BTC mainnet as an asset settlement layer, using lightweight client nodes can significantly enhance the security of asset cross-chain transfers while avoiding the resource consumption and costs of full node verification. The reason for adopting ZK technology is to ensure that the operations on the layer2 sidechain remain consistent with the mainnet verification consensus.

(It should be clarified that lightweight clients can only verify payment types and cannot effectively verify the validity of states on the layer2 chain. That is, the mainnet can verify whether the UTXO unlocking conditions are met for asset transfers based on the partial data submitted from layer2, but cannot verify more complex states on the layer2 chain.)

It can be said that the combination of ZK lightweight clients and relay chains can indeed achieve secure cross-chain asset transfers and frictionless conversions within the same chain. The relay chain will deploy smart contracts that adapt to the full-chain environment (for chains like BTC without smart contracts, lightweight clients will be used for secure asset migration) and follow a set of standards for cross-chain communication, along with a POS-based interaction validity verification mechanism. Achieving these will constitute a full-chain interoperability solution.

Because MAP Protocol has the gene for full-chain interoperability, its development path will differ when positioned as BTC layer2:

1) MAP will focus on the characteristics of the BTC mainnet to enrich its layer2 functions, allowing BTC assets, in addition to the main BTC asset, to safely cross-chain to layer2, such as various inscribed assets.

Due to the strong consensus of BTC as an asset, any layer2 expansion plan finds it difficult to sway the consensus of BTC holders. However, inscribed assets are different. BTC layer2 can manage and circulate these BTC derivative assets at a lower cost and with less loss, achieving the goal of expanding the value of the BTC mainnet through layer2.

To achieve this goal, it is not simply a matter of wrapping BTC assets onto the layer2 chain; it involves managing ledger consistency with indexers, ensuring liquidity compatibility and management of different BTC derivative inscribed assets, and so on. Clearly, developing more expansion capabilities that align with the characteristics of BTC derivative assets is key.

2) MAP will become an interoperability layer (Layer 0) for other BTC layer2s. Imagine if BTC layer2 connects to a batch of mature EVM chains and a batch of Non-EVM performance chains. These chains can connect with the BTC main chain in some way, but isn't the core issue interoperability? Clearly, a chain within a chain that fully accommodates the heterogeneous characteristics of the BTC mainnet and is compatible with other full-chain environments will be crucial.

MAP could choose not to compete for the C position of layer2 chains, observing the competition among other layer2 chains, and then, when they tear the market apart, integrate and manage liquidity based on its full-chain interoperability characteristics.

In my view, this might be a brilliant strategic move.

Of course, in the wild period of BTC layer2 competition, everyone is scrambling for the C position, with some proposals disregarding the objective flaws of the BTC main chain and failing to clarify the core value of layer2 chains actively present in the market. In this context, if a BTC layer2 can stabilize itself and find its ecological positioning, it will be the key to ultimate victory.