Stablecoin Bridging: Architectures and Risks
Contents
Introduction
The emergence of multiple blockchains
The creation and success of several chains outside of Ethereum brought about the need for stable value on those chains. Most attempts at making native stablecoins outside of Ethereum failed in the long term, with very few exceptions. This lack of native stablecoins resulted in ecosystems being made up mostly of bridged stablecoins (multiDAI, albridgeFRAX, wormholeUDSC, etc.). These tokens were mere representations of their original forms on Ethereum, carrying the risk of the protocols that bridged them to new chains.
Since the emergence of these new chains, most of the original multichain bridges have been exploited, costing users billions of dollars.
From these bridge failures, several stablecoin projects have begun to take a more proactive approach to managing the bridging of their stablecoins between chains. Below is a breakdown of the challenges, current solutions, and risk mitigations strategies surrounding decentralized stablecoin bridging. The perspective of this analysis is that of token management rather than internal bridge algorithms.
Challenges
Fungibility across multiple chains
The first versions of bridges had a simple “mint & burn” model. Under this model, users would lock tokens on a source chain and bridges would mint a corresponding token on the desired destination chain. The issue with this model is that it resulted in several versions of the same token. In certain chains, there were so many versions of USDC, that there was a serious issue of fragmented liquidity. Several liquidity pools had to be made to connect the various forms of USDC. Not only was this costly, it added an extra burden for bridges to have their versions of tokens adopted by DEXs over alternative versions.
Chain risk exposure
This risk relates to events at a project’s deployment on one chain affecting that same project’s deployment on a different chain. For multichain projects that are not connected to each other, like Aave V2, this risk isn't as pronounced. In that case, there is no connection between deployments.
When it comes to stablecoin projects deployed on multiple chains, the risk exposure changes. This is because the collateralization of a stablecoin is global to the extent that stablecoins are fungible across several chain deployments - fungibility co-mingles stablecoins minted from different chains. In the event of bad debt at one chain, all connected stablecoins are affected.
If the total debt on a chain is equal to the circulating supply, then any bad debt is contained to that chain. This is because no stablecoins have co-mingled, and are therefore distinguishable from each other. If the total debt exceeds circulating supply, the the bad debt generated from those loans affects the chain where those stablecoins have been bridged to. Below is an illustration of this principle.
Counterparty exposure
Tokens received from bridges on destination chains are not the same as the tokens locked on source chains. Instead, they are IOUs that correspond to locked tokens. If the underlying tokens on the source chains are stolen, then the IOUs lose all of their value. This reality requires users to look at bridges as collateral-backed debt holders with counterparty risk.
Bridges that can transfer tokens outside of the L1<>L2 relationship exist outside of the consensus of the chains they are interacting with. Bridging between an L1 and its L2s typically carries no additional trust assumptions from those that govern the L2s. Whereas bridging that occurs between chains that do not share consensus do add extra trust assumptions. As such, exposing a stablecoin to a non-L2 messaging layer adds risk to protocol designs.
Over the last 2 years, more than $2.5 billion has been stolen from non-L2 bridges. These exploits have significantly impacted entire DeFi ecosystems and projects. Below is a list of the major bridge hacks occurring over the last 2 years:
Ronin: $624M
Poly Network: $611M
BNB Bridge: $586M
Wormhole: $326M
Nomad: $190M
Multichain: $126M
Harmony: $100M
Source: https://rekt.news/leaderboard/
At some point, many of these bridges were considered the pinnacle of bridge engineering. But as time showed, all had critical flaws in their design and/or implementation. Given the reliance of offchain infrastructure, it is difficult to know for certain all of the details of how bridges work. There is a large component of trust in using these bridges.
Operational burden and centralization
Web2 dependencies
Several bridges rely on web2 infrastructure. This can include bots, nodes, and access to nodes. This infrastructure has two main issues. The first is that it cannot run forever. If teams stop paying for services, for example, bridging could stop or become unsafe. The second issue is transparency. Since this tooling exists outside of blockchains, it is much harder to verify how it is being run.
Liquidity management
Liquidity-based canonical bridging relies on liquidity being deposited by teams to manage risk exposure. If teams disappear, then there is no one to deposit liquidity. This creates a significant reliance on protocol teams.
Multisigs
Aside from the centralization component of multisigs, this type of tooling requires human action. If economic and reputational incentives change dramatically, multisig signers might not be motivated to continue participating. Changing incentives could also make multisig signers malicious.
Stablecoin bridging implementations
FRAX
FRAX is native to Ethereum, but has been bridged to multiple chains. FRAX is one of the few decentralized stablecoin teams, along with MAI, that has built out an extensive crosschain presence. The team has previously used third party bridges to expand to other chains in the early days of the multichain world. Given the various hacks suffered by most major bridges in the last 2 years, the team decided to shift to an internal solution.
Frax Ferry focuses on routes from Ethereum to other chains, with L2<>L2 bridging handled by third parties. Frax Ferry functions via liquidity-based canonical bridging (discussed below), where canonicalFRAX is unlocked from pools seeded by the team. A 24-hour waiting period allots the system ample time to identify any suspicious transactions.
In terms of security, Frax Ferry has a network of bots to track bridging transactions. If any irregularities are caught, then transactions can be paused. A multisig on destination chains can also stop transactions if found to be defective/malicious.
Benefit:
There are no external dependencies for the protocol (i.e. third party messaging layers / contracts)
Liquidity-based canonical bridging limits downside exposure of bridge malfunctions or exploits
Internal product ensures the fungibility of the stablecoin
Risks:
Given its dependency of bot and multisig infrastructure, Frax Ferry adds notable operation burdens
Centralized components require some level of trust on the team. It must be noted that the Frax team has been a reliable builder group for a long time
Aave Portals
Aave has historically been a multichain protocol, meaning that its deployments exist separate from each other. Its introduction of Aave Portals is not a complete shift to a crosschain model, but it is an important step in the integration of its separate systems.
Aave Portals will allow users to bridge deposits between Aave deployments. The Collateral/Loan relationship will still occur solely on one chain, so there is no chain-to-chain bad debt risk arising from loans on different chains.
Bridging will be open to any protocol that is whitelisted by Aave governance. These bridges will have the task of relaying aToken balances between deployments as well as transferring the underlying tokens.
Bridging Flow
1. User sends aToken to whitelisted bridge on the source chain
2. Bridge mints unbacked aToken on the destination chain, which is immediately included in the interest generation of that pool
3. Bridge withdraws underlying tokens from source chain, and bridges the underlying tokens
4. Underlying tokens are deposited on behalf of user on the destination chain
Benefits:
Portals are able to diversify across multiple bridges, with new bridges whitelisted by governance. This diversifies counterparty risk and allows Aave to upgrade bridging architecture as technology improves
Since bridging providers are able to mint unbacked aTokens to front deposits, users are able to bridge relatively quickly
Risks:
Much trust is placed on bridging providers as they are able to mint unbacked aTokens that are provided before underlying assets are transferred. This represents a risk to destination chain deployments. If a bridge were to mint unlimited amounts of aTokens that could affect the solvency of the affected deployment
Non-bridging users are exposed to risks taken by bridging users. Users that only deposit on one chain will be exposed to incoming deposits from other chains, which carry the infrastructure risk related to whitelisted bridges
sUSD
sUSD is only available on two chains, Optimism and Ethereum. However, they’ve been innovating in the crosschain space via CCIP from Chainlink. The team created a mint and burn bridge called Teleporters on top of CCIP. sUSD from Synthetix’s V3 platform (“snxUSD”) can be transferred to Optimism from Ethereum, and vice versa. Tokens are burned on the source chain and minted on the destination chain. Since the only bridge is run by the Synthetix team, sUSD’s fungibility can be ensured.
Additional security measures have been put in place to reduce downside cases. These include rate limiting on bridge transactions, which is native to CCIP’s token transfer service. The Active Risk Management (ARM) Network has also been implemented by Chainlink, which serves as an added monitoring layer for transactions. This is a new feature that Chainlink has added to its system that did not previous exist with its DON.
Benefits:
Straightforward system, which relies solely on CCIP to relay bridge transactions. Since Synthetix already uses Chainlink for pricing data, there are no new trust assumptions.
Fungibility is ensured given that only this bridge can transfer sUSD
Risks:
Centralization risk is present given the reliance on a single crosschain messaging layer
MAI
Early Canonical bridging
MAI was the first decentralized stablecoin protocol to go crosschain. At the onset of the crosschain world we experience today, MAI began to deploy native issuance on several chains, including Polygon, Avalanche, and other low-cost chains. This unearthed several barriers given the absence of robust bridging infrastructure at the time. Knowing that bridging would improve, the protocol instituted what is now referred to as canonical bridging in June 2021. Using a “Crosschain Hub” contract, MAI was able to accept certain bridgedMAI versions from whitelisted bridges, and exchange them for canonicalMAI. The system allowed several bridges to transfer value using MAI, while allowing the protocol to maintain token sovereignty.
If a bridge were to become compromised, or if better technology arose, then the protocol could offboard bridges and add new ones. This system worked and allowed QiDao’s core lending mechanism to become the most used CDP in all blockchains.
QiDao has deprecated this form of bridging given the decreased use of mint and burn bridges.
Current model
MAI is currently bridged by two protocols, Stargate (via Layer Zero) and Squid (via Axelar). Stargate uses a bridge pool approach, where stablecoin protocols can deposit tokens in bridge pools to be swapped between chains. These sToken pools allow QiDao to limit its exposure to Stargate, since only the tokens in the pools can be used to bridge.
Squid also uses a liquidity-based model, but via DEX LPs. Squid mints their own version of MAI, axlMAI on each chain. QiDao then creates axlMAI-MAI LPs on KyberSwap which can be used to swap for canonicalMAI. The whole process of bridging and swapping has been automated by Squid. The main benefit of using DEX LPs is the introduction of slippage. If bridging is concentrated too much on a certain chain, the exchange rate for axlMAI:MAI becomes progressively less favorable. At some point, it becomes profitable for arbitrageurs to make the bridging transactions in the opposite direction of the trend. Such a system addresses the central problem with liquidity-based models, which is the need to manage deposits in pools. Having a native arbitrage model, this system can largely manage itself.
Given that MAI has maintained token sovereignty over bridges, it has been able to continually upgrade its approach as better technologies become available. The defining theme in this approach has been optimizing for adaptability. This is exemplified by Stargate and Squid replacing older bridging technology in MAI’s crosschain design.
Benefits
Adaptability: bridges can be added and removed from the system as better technology becomes available.
Diversification: counterparty risk is diversified among a diverse set of reputable bridges.
Exposure management: downside cases are limited by liquidity deposits.
Decentralization: third party bridges decentralize control of the overall protocol design.
Risks
Operational burden: bridge liquidity management requires upkeep.
Stablecoin Bridging Standards
Mint and Burn Standard
This is the oldest and simplest form of bridging. Tokens are locked by users on the source chain into a bridge contract. The bridge then relays a message to the destination chain indicating the amount of tokens locked and the recipient address. A new token is finally issued by the bridge to represent the tokens locked on the destination chain. In theory, the only way to unlock tokens at the source chain is to return the bridged tokens on the destination chain.
Liquidity Pool Standard
What differentiates this type of bridging is that external protocols do not at any point mint the canonical form of the stablecoin. This was the response to mint & burn bridges that arose to maintain token sovereignty of tokens. For this method to function, stablecoin projects need to provide stablecoins for bridging operations. This can be done by either allocating part of the treasury for these pools, or by minting unbacked stablecoins to seed into the pools. The later involves using the token contract of the stablecoin to mint tokens without using collateral to back it. This does not present an issue with collateralization of the stablecoin since these tokens are not in circulation. It is only when a user deposits backed stablecoins on another chain that the unbacked stablecoins can inherit the collateralization of the now-locked stablecoin on the source chain.
The main issue with liquidity-based models is their operational burden. Unlike token standard models, liquidity models require the provision of tokens to contracts for bridging to occur. This is difficult to automate fully, and usually requires some level of human interaction.
Protocol-owned pools
This option is most suited for projects that interact with mint and burn bridges. These bridges mint their own versions of stablecoins on the destination chain. As such, these various versions need to be aggregated to prevent fungibility and liquidity fragmentation issues. Contracts can be set up to accept whitelisted stablecoin versions from specific bridges and return canonical stablecoins.
From a risk management perspective, this model has the best emergency scenario tooling for protocols. Given that the protocol controls the Hub contract, teams can pause bridging at any time. Special logic can be included in these Hub contracts for a automated risk mitigation strategies. This can include rate limiting, among other measures.
Operational upkeep for this model is managing the whitelisting of new tokens as well as the continued provision of additional liquidity for bridging.
bridgedToken-canonicalToken LPs
Like the system above, these LPs serve to aggregate bridged versions of stablecoins with canonical versions. This option allows teams to handle aggregation without needing to deploy their own contracts. Instead, projects can use existing liquidity pool contracts via DEXs. Additionally, this option can introduce the idea of slippage. LPs can have price curves, which naturally incentivize or disincentivize bridging in a particular chain. For example, if too many stablecoins are bridged into a particular chain, then the exchange rate of bridgedStablecoin to canonicalStablecoin will deviate from 1:1. At a certain point, the deviation will be great enough to either (1) disincentivize users from bridging into that chain, or (2) incentivize users on that chain to bridge out of that chain to capture the arbitrage.
A major benefit of these models is the ability to limit bridging into and out of chains. By modifying buy-side and sell-side liquidity for bridged tokens, protocols can set different limits for outflows and inflows. Limits orders can be used for this purpose.
Another benefit worth highlighting for this model is the impact it can have on DEX relationships. Having these LPs on a DEX will bring TVL, volume, fees to chosen DEXs, the holy trinity of what DEXs want. As a result, stablecoin projects can leverage these benefits to receive incentives for their stablecoin on other LPs. This can have material impacts on the cost of capital for stablecoin projects attracting LP liquidity.
In emergency scenarios, removing exposure from specific bridges is relatively simple. By removing tokens from LP contracts, teams can immediately pause bridging. Non-protocol actors can also provide LP liquidity for bridging to occur, but these deposits would be made up of user-minted stablecoins. As such, their presence does not constitute bad debt risk.
Operationally, these models are quite tasking. Protocols need to provide LP liquidity, which comes with higher complexities than depositing stablecoins into single-token pools. This burden is amplified by the need to manage the amount of exposure protocols want to have to bridges on each chain.
Bridge-owned pools
Some bridges have been built on top of messaging protocols to allow for liquidity-based canonical bridging without the need for external contracts. Stargate is a good example of this, which is built on top of Layer Zero. It allows projects to deposit their stablecoins in sToken pools. These pools then represent the limits of what can be bridged into a particular chain. When users brigde out of a chain, those tokens are also added to the bridge-owned pools. For non-project stablecoins, bridges usually have to provide some incentives and/or source market makers to attract liquidity.
Responding to emergency scenarios is a bit trickier under these systems. This is due to who has claims to what deposits. As well as who can withdraw from pools. In an emergency scenario, the stablecoin protocol will want to remove 100% of its exposure to the bridge. This is particularly important in the case of using unbacked stablecoin deposits. If any stablecoins are unduly removed from the bridge, bad debt becomes a threat.
However, it is not simple to remove all exposure from these systems. The balance of tokens on each chain will change depending on the inflows and outflows on that chain. The protocol will only be able to withdraw the sum of tokens it has deposited on a chain’s pool minus the net balance of tokens that has been bridged into the chain. See formula below on how to calculate the amount of tokens protocols can withdraw from bridge pools.
Tokens available for withdrawal (A) = sum of tokens deposited by protocol (B) + sum of tokens bridged out of chain - sum of tokens bridged into chain
If A > B, there is a surplus and the protocol can withdraw all tokens it has deposited. If B < A, there is a deficit and not all tokens can be withdrawn.
This calculation assumes that only the project running the stablecoin would provide stablecoin liquidity in bridge pools. Such an assumption can be made due to precedent as well as the disincentive of providing liquidity to non-incentivized pools.
Given this reality, the only way to completely remove exposure from these types of bridges is to bridge from chains with net inflows to chains with net outflows. This is because chain pools with a net inflows will have a deficit of receipt tokens to deposits, while a chain with net outflows will have a surplus. If a bridge seizes to function before protocols can remove exposure, the bad debt exposure could become unrepairable.
This type of bridging demands high operational upkeep. Protocols are incentivized to manage the exposure they have on bridge pools. If the market cap of the stablecoin, or the volume of bridging increases, then more stablecoins need to be provided. Under opposite conditions, stablecoins need to be removed. Automating such a system would require web2 infrastructure. Many teams that manage these pools do so via human processes.
Token standards and proxies
A newer standard has emerged to address the complexity of liquidity-based systems. Token standards allow whitelisted parties to mint stablecoins. With the understanding that messaging protocols ensure tokens are locked in source chains, stablecoin protocols allow external parties to generate new stablecoins via adapted token contracts or token wrappers (for already-deployed stablecoins). There are several optimization that safeguard protocols from downside cases. Since these token standards can have any logic embedded into the contracts, almost anything can be done to mitigate risks, such as an infinite mint attack.
The main protocols that have put forth token standards are Layer Zero (OFT), Axelar (ITS), and Connext (XERC). Fortunately, using one standard still allows projects to leverage various messaging protocols. For example, an OFT can interact with Axelar and Connext. As such, these standards allow for a much cleaner experience for projects that want to diversify their counterparty risk. Projects can create their own internal implementations of these standards, though this could increase smart contract risk.
Mitigating Risks
Global limits on inflows and outflows
Given that the risk associated with between chain deployments comes from the mixing of stablecoins minted from different chains, a state where no stablecoins have been bridged between chains can be said to have no exposure to crosschain bad debt risk. From this point, protocols can decide to what extent they want to expose chains to each other. This is exemplified by QiDao’s Chain Risk strategy, where the debt to circulating supply ratio on each chain is kept at a minimum of 80%. This means that only 20% of the bad debt risk from each chain can be introduced to other chains. The chain risk framework, however, was established after the protocol had allowed bridging for over 2 years. So adherence to this new system requires the gradual movement of MAI away from chains with high debt-to-circulating supply ratios.
Implementing this threshold is very challenging for projects. In order to manage this threshold, the following metrics must be tracked in a trustless manner:
Total debt from all loans within a chain
The addition of new vaults/troves that contain debt
The circulating supply of the stablecoin on a chain, which is sometimes different from total supply
If these metrics can be tracked trustlessly, then the protocol must then implement a system by which these metrics can alter the available inflow and outflow limits of the stablecoin. In a liquidity-based system, this would involve adding or removing stablecoins from bridge pools. In a token standard approach, this would entail adjusting global outflow and inflow parameters.
Permanent isolation
An infallible method to prevent bad debt risk between chain deployments is to fully isolate each chain or groups of chains. This would result in separate stablecoins with the same parallel mechanism on each chain. The impact on a stablecoin would be the following:
Increased cost of capital of maintaining peg. Expected return from liquidity providers tends to be higher for stablecoins with larger market caps
Increased volatility on the stablecoin. Stablecoins with smaller market cap tend to have higher volatility that stablecoins with larger market cap
Less integrations with bluechip projects. Having a smaller market cap reduces the addressable market size for integration partners, which disincentivizes integrations.
However, this approach would still grant projects the benefits of network effects. If a user trusts a system on one chain, they will likely also trust a separate system with the same code and operational procedures.
Temporary isolation
Bridging between chains could be paused temporarily instead of permanently. For example, new chain deployments could have a warm up period to allow for additional testing to occur. This protects older chains from unknown risks related to new chains. Another reason for temporary isolations could be exploits. If a force majeure event occurs on a chain, the protocol could act quickly to prevent bad debt leakages to other chains.
Other optimizations on bridge contracts
Rate limiting
Delayed bridging execution
Emergency shutdown/pause procedures for bridging
Final thoughts
The desire of many legacy stablecoins to expand to new chains as well as the overwhelming amount of bridge hacks has led many stablecoin projects to include bridging design into their protocol architectures. The set of solutions implemented by leading stablecoins is diverse, but with a common focus on fungibility.
Standards such as OFT/IST/XERC are an incredible step in making canonical bridging less human-dependent while allowing for the diversification of counterparty risk. This has resulted in their recent popularity and adoption. In parallel, older versions of bridging such as bridge-controlled mint and burn models and bridge-owned token pools seem to be fading away within stablecoin circles.
Bridging is definitely not in its final stage. Just as older technologies have been eclipsed by current ones, newer methods will arise to dominate the future of bridging. Consequently, it is vital to create system that are adaptable to these advances.