As more smart contract compatible chains go live everyday, we are seeing that third-party canonical token bridges are starting to quickly gain traction. We’ve seen projects and blockchain ecosystems often resort to one of the simple “mint & burn” solutions that give unrestricted control of the bridged assets to only a single bridge. However, what is not being discussed is the massive security and ecosystem risk that a project is taking on once it has been locked into a specific vendor of bridge.
In this blog post, we will discuss the various high security and ecosystem risks taken on by only using a single canonical token bridging solution that causes vendor lock-in. Additionally, we’ll talk about the benefits of using an Open Canonical Token Bridge standard that truly puts the interests of the users, project developers, and blockchain ecosystems before any of the short-sighted interests of a single bridge solution. Finally, we are calling for a collaborative community initiative by all bridge builders, blockchain ecosystems, application developers, influencers, and users to adopt this Open Canonical Token Bridge Standard to work towards achieving a better interoperability future for everyone.
A Brief History of Third-party Canonical Token Bridges
There is often the need to be able to bridge a token from its original chain to a different chain while still maintaining the unchanged total circulating supply of that token. This can happen when a project wants to expand to multiple chains and wants to bridge its own protocol token for use as liquidity mining rewards or governance (e.g $SUSHI or any other multi-chain DeFi projects). This can also come from a newly launched EVM compatible chain with a strong need to bridge various mainstream assets like WETH, USDT and USDC in order to bootstrap up to a vivid DeFi ecosystem.
This is where a “canonical token bridge” comes into play. Canonical token bridges work in the following “mint&burn” flow.
- From original chain to the destination chain: Users lock up the original assets on the original chain in a vault smart contract that an entity (decentralized or centralized) controls and then the same entity mints a canonical mapping of the original tokens on the destination chain to the user who locked up the original assets on the original chain.
- From the bridged chain to the original chain: Users burn the minted canonical mapping tokens on the bridged destination chain. Then, upon observing the token burn, the controlling entity releases the same amount (minus a fee) of the locked up tokens to the user on the original chain.
To simplify the following discussion, we’ll borrow a term from the networking research community and call this controlling entity the “Bridge Fabric”.
For a blockchain or L2 sidechain like Avalanche or Polygon, or a rollup like Arbitrum and Optimism, an official canonical token bridge is often built to connect to Ethereum and is used to bridge critical assets like WETH, USDT, USDC, and DAI. The Bridge Fabrics for these official bridges often have the same security level as the underlying chain’s consensus (with some exceptions) or in the case of L2 rollups, are bound to Ethereum’s L1 security. With the rendezvous point being Ethereum, a star topology is formed among chains and their official canonical token bridges.
However, this star topology does not fulfill all bridging needs:
- If a token is not originally issued on Ethereum, and wishes to have a direct canonical token bridge from say Avalanche to Binance Smart Chain. No official canonical token bridge is able to support this.
- If a chain opts to not operate a decentralized and permissionless canonical token bridge, there is no official bridge to fulfill the bridging needs for projects building on top of the chain. Examples of such chains include Moonriver, Celo, Oasis Emerald, BSC(with the recent BSC bridge decommission) and more. In these cases, the project’s protocol tokens as well as key assets like USDT/USDC/WETH do not have an official bridge into the chain.
Third-party canonical token bridge solutions have been developed to solve these needs. However, instead of using a Bridge Fabric that shares the security level of the underlying chains, these third-party solutions use their own Bridge Fabric for the mint&burn process. This means that they carry their own security assumptions and model. For many existing solutions, such as Anyswap, the Bridging Fabric is essentially a threshold multisig maintained by a set of signer servers. For Celer cBridge, the Bridging Fabric is the State Guardian Network, a tendermint-based PoS blockchain itself.
The Most Important Question to Ask When Choosing a Bridge
Now, let’s say a DEX on Oasis Emerald wants to list a ($ROSE, $USDT) pair, which version of the bridged $USDT should it choose to use? Or, let’s say a DeFi project is expanding to BSC and wants to bridge its own protocol token over. Which bridge should it work with to create the token’s canonical mapping?
Today, each existing canonical bridge creates its own unique canonical mapping tokens that are not compatible with any other canonical token bridge. Ironically, as a key component to enable blockchain interoperability, the canonical token bridges themselves are not interoperable.
So you have to choose one of them, right?
Should you choose Anyswap, cBridge or Wormhole? Or something else? If you have started to draw up a comparison table to compare the security models, UI/UX, SDKs, aggregator supports, future extensibility, and costs, PLEASE STOP.
Yes, these are important, but you should not be forced to make a choice in the first place!
THE SINGLE MOST IMPORTANT THING to ask when you, the DeFi/GameFi/NFT/Metaverse/dApp/blockchain developers, are deciding on a third-party canonical token bridge solution is:
DOES THIS BRIDGE CAUSE VENDOR LOCK-IN?
Vendor Lock-in Bridges are Bad for Your dApp’s Health
Unfortunately, all existing third-party canonical token bridges have the vendor lock-in problem. The moment you choose to use any bridge solution, good or bad, the project is bound to that bridge forever. Technically, that is only due to the fact that the bridge you chose is the one and only minter of the canonical mapping token on the destination chain.
This opens the project adopting this kind of bridge to huge security risks. Say you are a DEX on a blockchain that is relying on a single copy of $USDT from say SuperNice Bridge. What happens if SuperNice Bridge’s Bridge Fabric has a critical security issue that allows a hacker to mint an infinite amount of $USDT and drain every single asset on your DEX? Another example is if you have expanded your project’s token to multiple chains and now have 80% of the tokens locked in bridge controlled pools. If the same security flaw were to happen, you would experience a market price crash for your asset larger than any centralized exchange hack.
In fact, if a blockchain ecosystem relies on only a single third-party canonical token bridge, the economic security level of that blockchain will be effectively reduced to the security level of that particular bridge and has nothing to do with whatever consensus mechanism this chain is built on.
Then there are reliability issues. What if the bridging system experiences congestion? What happens if there is service degradation? What if the bridge project goes out of business? Your users who are holding the bridged tokens are the ones left hanging out to dry.
Finally, vendor lock-in creates several ecosystem issues that you never expected: what can you do:
- if the bridge decides to increase fees?
- If the bridge decides to rate limit your users?
- if the bridge stops iterating on user experience and your users complain?
- if the bridge cannot support future use cases of generic message passing?
- if the bridge does not work with external bridging aggregators or has broken APIs?
That’s right, there is nothing you can do. And the list goes on. Your dApp and your users are completely at the mercy of this totally unexpected but truly monopolistic power.
An Open Canonical Token Bridge Standard: A Simple Fix
Not everything is all doom and gloom though. This vendor lock-in situation can be fixed quite easily. The project and dev communities should be put in the driver’s seat with multiple bridges competing to offer the best canonical token bridging solution under a unified single token mapping framework. Better yet, there is no extra effort needed on your end!
On a more technical note, the first and most important thing to do is to eradicate the concept of the single-minter canonical token contract. Where tokens can be only minted by a single bridge and therefore cause vendor lock-in.
Instead, when a project expands to another chain, the dev community should ask for a multi-bridge compatible contract like this.
With this token contract, the project would be able to allow multiple bridges to concurrently serve as canonical token bridges for its protocol token. This is because every bridge will be minting the same type of canonical mapping tokens, instead of different ones. DeFi apps can also ask that key assets like USDT/USDC/WETH to be the canonical mappings that support this Open Canonical Token standard. Each bridge can also be dynamically allocated with a maximal mintable cap based on the DAO’s assessment of the security level, user experience, and other factors.
Now that the projects own the bridges, let’s revisit the risk scenarios mentioned above.
In the scenario where one of the bridges was hacked and allowed infinite minting, the risk exposure is drastically reduced from the total supply of the token to only the remaining minting quota allocated to that bridge (often much smaller than the quota cap).
What happens if one of the bridges goes down? No worries, you have other bridges that can take up the slack so as to not interfere with the smooth user experience!
Fees too high? Gas costs too high? UI/UX not intuitive? Limited feature support? No external ecosystem integration? No worries, the project DAO can simply reduce the quota allocation cap for the bridge that isn’t particularly attractive to you and guide users to use other, better bridges!
It should be clear by now that an Open Canonical Token Bridge standard is the single best option that allows multiple bridges to co-exists for a single canonical bridged asset by putting the benefits of users, dApp developers and the blockchain ecosystem front and center.
Join the Movement: We Need You!
We want to be very clear that what we have outlined in this blog is not intended to be a standard specification. Instead, we hope it can make a strong case for the need of such an open standard. We look forward to working with everyone in the ecosystem to promote and define such a standard for the greater good and future.
To Bridge and Interoperability Solution Builders
History has proven repeatedly that open standard wins and closed garden loses. We are fully open and looking forward to working with any bridge and interoperability infrastructure project to build this open standard together.
To Application DAOs
We hope that this blog post has convinced you of the importance of using a canonical token bridging solution without vendor lock-in. If you are considering integrating bridged assets or expanding into new chains, no matter which bridging solution you talk to, ask for a solution that benefits YOU, instead of the bridge.
If you have already integrated with some vendor lock-in tokens, we are more than happy to work with you to migrate them to a much more open version with additional incentives for user migration. Please do not hesitate to reach out to us and ask!
Please, work with us to spread the word about the benefits of an Open Canonical Token standard and make the hidden risk of vendor lock-in clearly visible to any new developers seeking information or advice about bridging solutions.
Let’s build an open interoperability future together!
Via this site
