In this era of smart contract-compatible chains springing up like mushrooms after rain, users' demand for third-party cross-chain bridges of various native assets is also increasing. Blockchain ecology and projects usually adopt a simple "mint & burn" cross-chain solution, which will result in unlimited control of cross-chain assets belonging to a single cross-chain bridge provider. However, what few people discuss is that once a supplier is bound, it is easy to cause huge risks that are difficult to remedy for asset security and blockchain ecology.

first level title

The development history of the third-party native asset cross-chain bridge

When we need to cross the original assets on one chain to another chain, it is a broad demand to keep the total circulation of the assets in the market unchanged while carrying out the cross-chain. For example, when a project wants to expand to multi-chain development, it usually needs to cross-chain its own contract token and use it for liquidity mining rewards or governance (such as $SUSHI or any other multi-chain DeFi project). For another example, the newly launched EVM-compatible chain usually needs to cross-link some mainstream assets (such as WETH, USDT, and USDC, etc.) to stimulate the activity of the DeFi ecosystem.

This is where the "native asset cross-chain bridge" comes into play. Its "minting and burning" workflow is as follows:

• From source chain to target chain:The user "locks" the original asset on the source chain in a safe smart contract controlled by a subject (decentralized or centralized), and then the subject "casts" the canonical mapping of the original asset to the user on the target chain.

• From the target chain back to the source chain:The user "destroys" the minted normative mapping assets on the bridged target chain, and after confirming the destruction, the subject "releases" the same amount of locked assets on the source chain to the user (minus the corresponding cross-chain handling fee).

To simplify the discussion below, we borrow a term from the network research community and call thisentity controlling the assetreferred to as "bridge structure」。

For blockchains or second-tier sidechains like Avalanche or Polygon, or rollups like Arbitrum and Optimism, an official native asset cross-chain bridge is usually established to connect to Ethereum and used for mainstream asset cross-chains, such as WETH, USDT, USDC, DAI, etc. Usually the "bridge structure" of these official cross-chain bridges has the same security level as the underlying chain consensus (of course there are some exceptions), or in the case of the second layer Rollup, it is securely bound to the first layer of Ethereum. Since the confluence point is Ethereum, a star topology is formed between the chain and its native asset cross-chain bridge.

However, this star topology cannot meet the cross-chain requirements of all native assets:

• If a token was not initially issued on Ethereum, and want to have a direct native asset cross-chain bridge from, for example, Avalanche to BSC, but there is no corresponding official native asset cross-chain bridge that can support this use case.

• If a chain chooses not to operate a decentralized and non-admissioned native asset cross-chain bridge, naturally there is no way to directly meet the cross-chain needs of ecological projects built on this chain. Such examples include Moonriver, Celo, Oasis Emerald, BSC (currently the official BSC bridge has ceased operations) and many more. In this case, not only the contract assets of the project, but also mainstream assets including USDT/USDC/WETH cannot be officially bridged to the chain.

first level title

The most important question when choosing a cross-chain bridge

Now, let’s assume that a DEX on Oasis Emerald wants to list $ROSE/$USDT, which version of cross-chain $USDT should it choose to use? Or if a DeFi project wants to expand to BSC and wants to cross its own contract assets, what cross-chain bridge should be used to create a token mapping?

Every existing native bridge today creates its own unique version of the canonical mapping token, and these tokens are completely incompatible. This is a very ironic reality:Native asset cross-chain bridges are key components to achieve blockchain interoperability, but they are not interoperable with each other.

In this case, the question arises, you can only choose one of them, right?

Should you choose Anyswap, cBridge, Wormhole, or other cross-chain bridges? If you have already started to prepare a comparison table to compare their security models, UI/UX, SDK, aggregator support, future scalability and cost, etc.,that's unnecessary。

Yes, these are all important, but you shouldn't be forced to choose in the first place!

When you, as a DeFi/GameFi/NFT/Metaverse/dApp/blockchain developer, decide to adopt a third-party native asset cross-chain bridge as a solution, the most important things to ask are:

first level title

Vendor-locked cross-chain bridges harm DApp health

Unfortunately, all existing third-party native asset cross-chain bridges suffer from vendor lock-in. So for project developers, when you choose to use any cross-chain solution, no matter whether it is good or bad, the project will always be restricted to this bridge. Technically, this is because the cross-chain bridge you choose is the minter of the only canonical mapping token for that asset on the target chain.

Let's start with the huge asset security risk. Suppose you develop a DEX on the blockchain and currently completely rely on the only version of $USDT mapping minted by a SuperNice Bridge. What would happen if SuperNice Bridge's "bridge structure" had a critical security process flaw that allowed hackers to mint an unlimited amount of $USDT and drain every asset on your DEX? Or you expand your project token to multiple chains, and now 80% of the tokens are locked in the pool controlled by the bridge, the same security breach occurs, and you will experience a devastating market price collapse, and more than any No exchange hack can attack your assets more seriously.

Then there is the question of reliability. What if there is congestion in the cross-chain system? What if the cross-chain service quality drops? What if the cross-chain bridge goes down? Those users who hold your project token are completely in trouble.

Finally, this kind of supplier-locked cross-chain bridge will cause a series of ecological problems that you cannot predict:

• What if it decides to increase the fee?

• What if it decides to rate limit your users?

• What if it stops iterating on UX and makes your users unhappy?

• What if it can't support future usage scenarios for general purpose messaging?

• What if it doesn't work with external bridge aggregators or the API is broken?

• …… 

what can you do

That's right, there's nothing you can do about it. While the above list is just a small part of what could happen, your dApp and your users will be completely subject to unpredictable but realfirst level title。

An open cross-chain bridge standard: easily solve the problem of supplier lock-in

The good news is that this vendor lock-in situation can be easily resolved. We can formulate a unified "single asset specification mapping framework", put blockchain projects and developer communities in a dominant position, and choose the best native asset cross-chain solution among multiple cross-chain bridges.More importantly, as a project developer, you don't have any additional burden.

On a more technical level, the first and most important thing to do is to eradicate the concept of a native token single minter contract. Because in this case, the token can only be minted by a single cross-chain bridge, it will cause the problem of supplier lock-in.

Instead, when a project chooses to expand to other chains, the project's developer community should demand a multi-cross-chain bridge compatible contract.

With this kind of token contract, the project can allow multiple cross-chain bridges to serve as the native asset cross-chain bridge of its contract token at the same time, because each cross-chain bridge will mintThe same version of native specification mapping token. DeFi applications can also request standardized mapping of mainstream assets such as USDT/USDC/WETH that support the open cross-chain bridge standard. Each bridge can also dynamically assign a maximum minting value cap based on the DAO's assessment of security levels, user experience, and other factors.

Obviously, the project party has now become the dominator of the cross-chain bridge. So let's go back to the risk scenario mentioned in the last chapter.

In the event that one of the cross-chain bridges is attacked, resulting in uncapped minting, only the remaining minting quota allocated to the cross-chain bridge (usually even much smaller than the minting cap of the cross-chain bridge) will be reduced without causing the The total supply of contract tokens has dropped sharply, greatly reducing the risk in this situation.

What if one of the cross-chain bridges cannot be used normally? Don't worry, there are other cross-chain bridges that can continue to serve users normally!

What if a certain bridge toll is too high? Consuming too much cross-chain handling fee? UI/UX not intuitive? Limited feature support? No external ecosystem integration? Don't worry, the project's DAO can simply lower the minting cap of the cross-chain bridge and guide users to use other bridges!

first level title

Join us when it matters most! we need you!

We want to make it clear to everyone that we are not publishing this content today to formulate a standard specification, but to hope that it canProvide a strong case for the need for such an open standardsecondary title

For builders of cross-chain and interoperability solutions

secondary title

DAOs for various applications

We hope this article can make everyone realize that it is extremely important to use non-provider-locked native asset cross-chain solutions. If you are considering cross-chain asset integration or expanding to a new chain, no matter which cross-chain bridge solution you are currently considering, we hope you can find a solution that is really beneficial to you, rather than simply looking for one Cross-chain bridge provider.

secondary title

community opinion leader

Please join us in bringing the benefits of an open native asset cross-chain bridge standard to every developer in the world who is looking for advice and informs them of the potential pitfalls of vendor lock-in.

Let's join hands and build an open and interoperable future together!