A multi-bridge future for Interchain UST: No Vendor Lock-in, Much Higher Security - Proposed by Celer Network

Summary of Proposal

This proposal is by the Celer Network team. Quick introduction to Celer. Celer is a blockchain interoperability protocol enabling a one-click user experience accessing tokens, DeFi, GameFi, NFTs, governance, privacy solutions and more across multiple chains. cBridge is a decentralized and non-custodial asset bridge that supports more than 40 different tokens across 21 different blockchains and layer-2 rollups. Built with the Celer Inter-chain Message Framework, cBridge has processed more than $4.6 b cross-chain asset transfers volume with $460M TVL on 26 different blockchains for more than 110K unique users and is quickly growing. cBridge like Terra, is built on Cosmos SDK and supports two security models at the same time: Cosmos consensus based security model and an optimistic rollup like security model. We would love to support UST bridging to multiple chains that we support and that would be straightforward with our Terra support coming soon.

However, this proposal is not even about us. In this proposal, we argue that it is dangerous for Terra community to be locked-in to a single bridge for UST bridging needs to any chain and it is possible to have multiple bridges serving Terra UST bridging at the same time without liquidity fragmentation. What’s more important is that this multi-bridge architecture actually provides much higher security for the entire Terra ecosystem compared to just using a single bridge as well! We propose that Terra can do a simple mitigation to leave the door open for a better future of multi-bridge UST without delaying the current planned chain extension.

With this proposed multi-bridge architecture tragedy like the Wormhole $300M+ hack would have never happened in the first place.

In the following, we will first discuss why it is harmful for Terra ecosystem to choose a single bridge and fall into the vendor lock-in trap. Then we will discuss how we can solve the key challenges of liquidity segregation and security issues in a multi-bridge system. Finally, we provide a solution without causing any delay for the current planed UST bridging launch but leave the door open for the future.

Vendor Lock-in is Extremely Dangerous

If you have read this previous post and understand vendor lock-in risks, please feel free to skip this whole section.

When thinking about UST bridging to chains where there is no official canonical token bridge built by Terra, third-party canonical token bridges can serve the purpose. To understand a bit of the history behind canonical token bridges and how they work, please refer to this blog.

There are many different bridging solutions out there. So which one to choose?

Well, that is not actually the right question to ask. Because if Terra chooses only a single bridge for UST bridging to any single chain, it faces the significant vendor lock-in risk.

Vendor lock-in, in terms of these third-party canonical token bridges, occurs when it becomes extremely difficult if not practically impossible to switch from a specific third-party canonical token bridging service to a different one for a blockchain. Effectively “locking” or taking away the choice from the entire Terra community. Unfortunately, many blockchain ecosystems are choosing to use or strongly endorse a single bridge as if it was officially supported.

However, the differences between an official canonical token bridge and a third-party one are not often talked about or considered, adding to the vendor lock-in issue. This is concerning as there are some major differences between the two. Take these three key differences as an example:

  • Entirely different and decoupled security assumptions. Third-party bridges use their own security mechanisms for the bridging process and do not share the security properties of the underlying blockchain.

  • Interests are not fully aligned. Unlike the official bridges, third-party ones are not fully aligned with the interests of the projects using them. Once a project is locked-in with a single bridge, it surrenders a significant, if not monopolistic, portion of their controlling powers to that bridge.

  • Entirely different and decoupled decentralization and reliability model. A blockchain might be fully decentralized and permissionless with incentives for the validators and miners, but a third-party bridge that connects to it may be a more centralized or closed system and the liveness assumptions are also drastically different.

Due to these differences, it creates devastating security and ecosystem risks for projects or blockchain ecosystems that get locked into a single third-party canonical token bridge. The scary part about it is, this is already happening.

First, let’s talk about security. Because some third-party bridges control unlimited mint/burn and lock/burn authority for the bridged asset. This means that the security of that asset being bridged is essentially reduced to the security level of that single bridge. What’s worse is that, in some cases, if the bridged assets are major DeFi assets like WETH/WBTC/USDT/USDC that are widely embedded everywhere in the blockchain, the security of the entire blockchain is effectively reduced to that single bridge’s security level.

Second, interest misalignments create huge ecosystem risks. Just to name a few examples:

  • The bridge can decide to monopolistically increase fees or charge unreasonable fees.

  • The bridge can rate limit your users in favor of some of your competitors that more closely align with their interests.

  • The bridge can stop iterating on and improving user experiences or be slow in innovating on and introducing new functionalities. This, by extension, slows down your blockchain’s innovation.

Finally, on decentralization and reliability. What if the bridging system experiences congestion? What happens if there is service degradation? What if the bridge project goes out of business? It is the users who are left holding the bridged tokens that are the ones left high and dry.

The Fight between Clones

Okay, single bridge and vendor lock-in is scary, blah, blah… Let’s just connect with multiple bridges and let all bridges freely compete in community voting wars and community reward wars like we are having now in Terra ecosystem.

Yeah, we can do that, but let’s play this out a bit. In the beginning, you will end up with a situation where for the same UST, there will be multiple different bridged UST on Ethereum from many different bridges that are ABSOLUTELY incompatible between each other. This is of course not optimal because of the degraded UX and segregated liquidity. Unfortunately, this is already happening on many different blockchains.

Bad as it is, in our opinion, this is still infinitely better than choosing a single bridge and therefore trapping a blockchain ecosystem into a vendor lock-in situation. Given time, after some cut-throat competition between different bridges, probably 1 or 2 bridges will be left to play. What this leaves Terra community is a hectic time of figuring out which token is which and still finally goes back to essentially the same vendor lock-in situation.

Naive Mutual Trust Between Bridges is Harmful

So, can we just ask all bridges to simply mint to the same token address for UST on every destination chain?

Well, it’s not that simple. We need to consider the security implications of this. Let’s examine the following scenario.

Bridge A and Bridge B formed an alliance: for UST on Terra, they will mint into the same token address on Ethereum. Let’s say for UST, the bridged version on Terra is called brUST.

Alice bridged 100 UST to Ethereum via Bridge A. What happened underlying is that 100 UST is locked into a contract on Terra that Bridge A controls and Bridge A mints 100 brUST on Ethereum to Alice.

Bob bridged 50 UST to Etheruem via Bridge B. What happened underlying is that 50 UST is locked into a contract on Terra that Bridge B controls and Bridge B mints 50 brUST on Ethereum to Bob.

Now, Bridge B got hacked like Wormhole, and minted 150 brUST out of thin air on Ethereum to Hacker. Now, because Bridge A also recognizes the same brUST token, Hacker can quickly bridge back the 150 brUST from both Bridge A and Bridge B and get the 150 UST while emptying both Bridge A and B’s reserve.

Now, the sad thing is that even though Alice never used the compromised Bridge B, her asset is also gone. Should Bridge A also be blamed in this case because Bridge A chose to trust and share the security of Bridge B? We believe Bridge A is indeed to blame here and that is precisely why we have never seen any bridge alliance formed in real-life yet. In fact, cBridge came so close to an alliance with another friend bridge and we aborted at the last minute due to this concern and responsibility we both need to undertake for the community.

Don’t Trust, Verify: the Magical Tradeoff of Two-Phase Commit Protocol

So, what do we do now?

Well, history has told us once again that the solutions to many hard computer science problems are just about finding the right tradeoff.

Canonical asset bridges’s core logic is dead-simple : if some tokens go out of the bridge on one chain (by release or minting), the same amount (minus fee and etc) of tokens must have gone into the bridge on another chain (by burning or locking) before that. We can call the above statement the Bridge Invariant . The problem of the above scenario is that Bridge A has no visibility of what is happening in Bridge B. If we have a way for Bridge A to see every action of Bridge B before it actually happens, Bridge A can then stop an action from actually happening if the said action violates the Bridge Invariant (e.g. Bridge B trying to mint 1000 brUST without anything already locked in Terra side).

But how can Bridge A know Bridge B’s minting action before it actually happens?

We call upon the classic computer science design pattern of a Two-Phase Commit protocol with a mandatory delay between prepare and commit step. Whenever a bridge wants to take any action that will release more tokens on any chain (say minting new bridged tokens or releasing locked original tokens), it has to first make an on-chain “prepare” message containing the intended action along with all relevant informations for other bridges in the same alliance to verify the Bridge Invariant. This on-chain “prepare” message can only be “committed” with real-world effect of minting the actual token after a certain period of mandatory delay, say 30 minutes. During that time, all the other bridges that are minting the same token should check for the Invariant and can pause the action should sufficient amount of bridges in the group agree that a Bridge Invariant is violated (e.g. the offending bridge is minting token without actually receiving anything in the original chain).

With this kind of shared sentinel service and a 2PC protocol, multiple bridges can co-exists naturally and more bridges can be added to an ecosystem easily. Because one bridge’s actions is now monitored by all others in the alliance, we in fact achieve an even more secure bridge environment comparing to using any single bridge!

The only tradeoff is the added delay between the “prepare” and “commit” for any bridge action. However, that can be solved by augmenting a liquidity pool based bridge easily like Connext or Celer cBridge’s liquidity pool model.

What can UST do now?

This mutual monitoring solution is not ready. Yes, we understand that. But the good news is that right now, all we need to do is to leave the door open by deploying a bridge contract that allows multiple minters like this one. And yes, Terra community can choose to use one bridge or another to begin with, but Terra community should push for this multi-bridge model with enhanced security and no vendor lock-in risk in the future.

However, if UST uses a single minter contract on the destination chain, then all is lost and UST will be vendor-lock-in forever. Therefore, we strongly urge the community to consider our proposal for the greater good of the Terra community.


good proposal!

1 Like

Is there an action item here you wanted the Terra community to contemplate?


This multi-bridge architecture achieves the three most important goals of Interchain UST:

  1. No liquidity fragmentation.
  2. No vendor lock-in.
  3. Much higher security: unless ALL participating bridges are hacked, Interchain UST will always be safe. Hacking incidents like what happened to Wormhole will be avoided.

To fully realize this architecture, a bridge should

  1. Support a multi-minter token contract on the destination chains of UST.
  2. Support a “two-phase commit” minting model.
  3. Open source a watch tower software for other bridges to act as mutual watch tower service.

Now, we know that none of the bridges today meet all three requirements. But, we respectfully suggest that Terra community can leave the door open for this future evolution direction and Terra community should ask any bridges support UST to at least use a multi-minter-compatible token contract on the destination chain that is minting bridged UST.

Supporting a multi-minter-compatible token contract is not something that is hard to do. In fact, there are widely used contracts such as Frax’s multi-minter contract or Celer’s equivalent version (used by 70+ tokens) of that. Synapse and Celer for example, both already support Frax bridging under multi-minter model. Therefore, it is fully reasonable to ask Synapse or Celer cBridge to add this support for UST.

Note that deploying a multi-minter bridge does not require UST to actually add multiple minters in the beginning.

If a bridge refuses to at least leave the door open, then this bridge is potentially trying to grab monopoly power to vendor lock-in UST into a single bridge and Terra community should avoid using such solution.

Celer cBridge has been a long advocate of an open third-party canonical token bridge and we currently support multi-minter and also the two-phase commit model based on the size of the transfer. We are in the final phase of auditing the coswasm plugin for Terra integration and would love to be considered for bridging needs in Terra community in the future,


This sounds like a smart idea that is forward looking and builds in optionality at no or minimal cost (time to analyze). I’m not technical enough to judge but I would like to see someone from TFL weigh in on the merits of the proposal.


Is this a simple ranting or something ?

Multi has something to chime in on? Let’s have a constructive discussion that is beneficial for users, would like to hear if you have anything to add to this.

Mo is very reasonable and confident with canonical bridge model and security! As facts says all! CBRIDGE is safest and simplest out there for terra


I’m in agreement that no tokens should not be tied or controlled by any single entity beyond Terra itself. UST is an important asset of the ecosystem and something that should be safeguarded.

The proposal is sound in my opinion and limits Terra’s risk exposure over time and maintains minter contract integrity with the community.


Celer Network Rocks deliver what is promised. Fast Secure and Cheap.

1 Like

The ask is that Terra should adopt an open standard for interchain bridging. UST is too important to be subjected to any single vendor lock-in (in multichain/crosschain link). By adopting an open approach to bridging, we can avoid many risks associated to security, and also improve fluidity of assets as more bridges can participate to help move them.

Crypto needs decentralised stablecoin like UST - and therefore having open decentralised bridges (no lock-in) to move UST is a crucial part of that.

As mentioned by @Mo_Dong, sensible multi-minter token contracts are already very well supported and have been proven to work well. e.g., both Frax’s and Celer’s cBridge (and Celer IM)

For others who are reading this, please spend a few minutes going through this article as it sums up pretty well why we should be promoting Open Canonical Token Bridge Standard for the benefits the whole multichain/crosschain movement,