LI.FI: The Stablecoin Bridge Almanac 2023

Preview

Twitter threads, conference talks, and whispered conversations among those building in the “multi-chain reality” are riddled with all sorts of questions about stablecoin bridges.

Do stablecoin bridges represent the potential solution, or end-game, for interop? Will stablecoins bridges dominate cross-chain volume and render liquidity networks obsolete? Could stablecoin bridges actually complement existing bridges by boosting capital efficiency and improving user experience? Are the trust assumptions that come with relying on centralized stablecoin issuers for cross-chain transactions worth the upgrade in capital efficiency and UX?

This article analyzes these questions by examining different stablecoin bridge designs based on how they work, their benefits, roadmap, adoption rate, and potential risk factors. By providing a comprehensive analysis, we aim to give readers an informed perspective on how stablecoin bridges may shape the future of bridging in crypto.

Let’s dive in!

What Are Stablecoin Bridges?

As the name suggests, stablecoin bridges facilitate the transfer of stablecoins across chains.

In a way, one can think about stablecoin bridges as systems that ‘teleport’ assets from one chain to another.

Why Are Stablecoin Bridges Being Created?

• Numerous wrapped or synthetic versions of stablecoins exist across chains – The existence of multiple wrapped stablecoins on a single chain creates confusion for users and developers, as it can be difficult to identify which wrapped stablecoin is being used for the majority of DeFi activities there. For example, at the time of writing, 11 different versions of USDC exist on Solana’s Jupiter Exchange.

Source: USDC on Jupiter Exchange

Stablecoin bridges are the single source of truth for what stablecoin should be used for DeFi activities on each chain the bridge supports. This is helpful because it decreases confusion for users and mitigates third-party bridge risk associated with wrapped stablecoins for developers, users, and dApps (which we will go into more detail on below).

• Users need to trust third-party issuers (lock and mint bridges) on different chains – Without stablecoin bridges, users need to rely on third-party bridges to facilitate stablecoin transfers across chains. If these third-party issuers are compromised or paused due to maintenance, it can have severe repercussions for the users in the form of loss of funds and the stablecoin’s reputation. For instance, a compromised third-party bridge could potentially mint an unlimited amount of wrapped stablecoin, leading to substantial losses for users and negatively impacting an entire blockchain. The reliance on third-party entities is eliminated by stablecoin bridges, as users instead depend directly on the stablecoin issuer, which they are already doing by holding the stablecoin initially.
• Evident demand for stablecoins on different chains and industry buy-in – While the availability of wrapped stablecoins on different chains poses UX challenges, it serves as an indication of customer demand for these stablecoins on specific chains. Stablecoin issuers like Circle and Maker have received feedback from large ecosystem participants (Circle’s Joao Reginatto here and dYdX’s Antonio Juliano here) indicating that many chains want to adopt a stablecoin bridge, if possible. Additionally, the heavy use of wrapped stablecoins further validates the necessity of stablecoin bridges and motivates their implementation.
• Liquidity pools are inefficient – One of the common ways stablecoins are moved across chains is via liquidity pool based bridges, wherein (and this is a generalized explanation) bridges incentivize liquidity providers to deposit large amounts of a stablecoin in smart contracts on multiple chains. From there, users who want to bridge stablecoins can do so by paying the LPs a fee to lock and unlock stablecoins from this big pool on their behalf. LP-based bridges are good for users because they allow for users to get exposure to native stablecoins without wrappers. However, incentivizing LPs to deposit stablecoins into a bridge mechanism is expensive for the protocol (and, therefore, the end-user). Additionally, total stablecoin volume is constrained by the amount of a stablecoin found in a certain pool and a certain time.

Benefits of Stablecoin Bridges

The benefits of stablecoin bridges mirror the difficulties listed above. Overall, the ability to mint stablecoins across different chains enables the following:

• Capital efficiency – It is possible to bridge virtually unlimited amounts of stablecoins between chains without having to maintain liquidity pools or rely on wrapped tokens (which require LPs to lock their assets and bridges to not get hacked, respectively).
• Zero fees – Users can transfer stablecoins between chains without incurring any additional fees other than gas fees, as stablecoin bridges eliminate the need for fees paid to LPs and third-party bridges. (Note: stablecoin bridges may implement their own transaction fees, though this is not industry norm as of now.)
• Fungible assets – Stablecoin bridges lets users hold native assets that are fungible with other assets on different chains, as opposed to holding wrapped or synthetic versions of the asset.
• No slippage – Transactions via stablecoin bridges do not experience slippage, which is typically associated with transferring assets on liquidity pools, because there’s no ‘exchange of assets’ here between LPs and users.
• Minimal trust assumptions – Stablecoin bridges are operated by entities that users are already trusting when using a stablecoin, i.e., the stablecoin issuers. For example, users already trust Circle when they use USDC and MakerDAO when using DAI. In other words, the third party risk for a stablecoin is already baked into the minting process of the stablecoin. With that being said, having the stablecoin issuer also manage permissions for cross-chain transactions is still, in our opinion, a somewhat small additional trust assumption.

An Onchain Use-Case

To fully understand the impact of stablecoin bridges, let’s consider a dApp that wants to bridge 100M USDC from Ethereum to Avalanche.

If a dApp wanted to move 100M USDC between Ethereum and Avalanche, no single liquidity pool-based bridge would be able to handle such a transaction. Take Stargate, which has seen the most volume among LP-based bridges this year. Stargate has over $410M in total value locked on the bridge and has handled millions upon millions of transactions in 2023.

However, Stargate’s top liquidity pool for USDC only holds approximately $55M in liquidity (for example, the largest USDC transaction we were able to generate on Stargate's frontend while writing this article was worth roughly $20,000,000). Therefore, attempting to bridge 100M USDC from Ethereum to Avalanche via Stargate or a different liquidity-pool based bridge is typically not feasible, as there is insufficient liquidity available – forcing a dApp or user to manually bridge multiple times to transfer the required amount.

Source: Stargate

Alternatively, the dApp could attempt the 100M USDC transfer through third-party bridges that use wrappers (such as Multichain’s anyUSDC or Axelar’s axlUSDC). These bridges essentially allow an unlimited number of tokens to be wrapped onto a new chain at any time – with the tradeoff that said wrapped-token is not guaranteed to have liquidity or usefulness once settled on the destination chain. This makes wrapped USDC alternatives a tough pill to swallow for such a large transaction.

On the other hand, stablecoin bridges, which rely on the stablecoin issuer to lock/burn and mint tokens, theoretically offer a clean resource for large scale stablecoin movements. For instance, by using a stablecoin bridge, a dApp could burn 100M of the stablecoin on Ethereum and mint the same amount on Avalanche as soon as the stablecoin issuer (be it centralized or decentralized) confirmed the transaction. This process ensures that the stablecoin can be seamlessly transferred between the two chains without the need for intermediate steps or complex wrapping procedures.

And this is not theoretical – it’s possible for a dApp to do this now via Celer Network's cBridge, which has integrated the USDC stablecoin bridge CCTP.

Source: Celer’s cBridge

This is made possible because cBridge utilizes CCTP's burn and mint mechanism as the underlying mechanism for facilitating the transfer with a ‘base fee’ of 0.3 USDC. This fee is applied to cover the gas cost associated with the transaction, regardless of the transfer amount."

Let’s dive into CCTP now, along with a few other stablecoin bridge designs including Frax Ferry, MakerDAO’s Teleport, and LayerZero’s OFT (via Abracadabra’s MIM).

Circle’s Cross-Chain Transfer Protocol – USDC

The Origins of CCTP

As mentioned above, numerous lock and mint USDC bridging solutions soon emerged and consequently ended up fragmenting liquidity in the form of wrapped assets. Remember, on Solana alone, there are 11 different wrapped versions of USDC, leading to liquidity fragmentation and causing confusion among developers regarding which version to utilize. Circle identified an opportunity to address the challenges of liquidity fragmentation and removing bridge risk while ensuring the fungibility of USDC on all chains.

How it Works – Transaction Lifecycle

CCTP is low-level infrastructure for dApps, wallets, bridges, and messaging platforms to build on top of. End-users, “the normies”, do not need to interact with CCTP directly. Instead, Circle built CCTP to be accessed by dApp frontends. In other words, CCTP is a tool that crypto developers can use to move USDC natively for their users and simplify UX.

CCTP’s design is best understood by breaking down the transaction lifecycle into four parts:

Part 1 – Transaction Initiation (on Source Chain)

User initiates the transaction on the source chain (Chain A) by depositing native USDC into the dApp that has integrated CCTP. The user also provides the recipient wallet address on the destination chain.

Part 2 – dApp Burns Native USDC (on Source Chain)

The dApp facilitates the burn event of the specific USDC amount on the source chain.

Part 3 – Circle Verifies the Burn Event (on Source Chain)

Circle observes and attests to (verifies) the burn event on the source chain. The dApp sends a request to Circle to obtain the attestation, gaining authorization for minting the specified USDC amount on the destination chain.

Part 4 – dApp Mints Native USDC (on Destination Chain)

Using the obtained attestation, the dApp initiates the minting process for USDC. The specified USDC amount is minted on the destination chain (Chain B) and sent to the recipient wallet address.

CCTP Transaction Lifecycle

Trust Assumptions

The following trust assumptions are made in CCTP’s transaction flow:

1) Dependence on Circle for validating transfers

The burn event of USDC on the source chain must be verified by Circle’s attestation service in order to authorize minting of USDC on the destination chain. Thus, user funds are secured by Circle accurately verifying the authenticity of each CCTP transaction.

2) Operational uptime

The end-to-end transaction flow for  CCTP relies directly on Circle’s attestation service. Therefore, any uncertainties surrounding Circle's operations can potentially result in temporary disruptions or delays in facilitating cross-chain transfers through CCTP.

Supported Networks & Adoption

CCTP is supported by:

• Bridge SDKs – Axelar, Celer, Hyperlane, LI.FI, Multichain, Router, Socket, Wanchain, Wormhole.
• Bridge Apps – cBridge, Multichain, Voyager, Wanchain, Jumper, Bungee.
• Wallets – MetaMask
• Others – CCTP is also supported by several dApps and wallets that have integrated the SDKs of the service providers mentioned above.

Resources

You can learn more about Circle’s CCTP through the following resources:

• Official Website
• Developer Docs
• Developer Resources
• Blog Post with Axelar
• Getting Started

Maker Teleport – DAI

The Origins of Teleport

Notably, MakerDAO observed that the emergence of multiple bridges and different versions of its flagship stablecoin DAI created confusion and fragmentation in a multi-chain context, making it challenging for retail users to figure out what version of DAI to use on different chains.

An example of different versions of non-fungible DAI as seen on multichain.xyz

Source: MakerDAO’s multi-chain strategy and roadmap 

The end game? A seamless flow of DAI across multiple chains allowing DAI to move efficiently and securely across chains.

How it Works – Transaction Lifecycle

Maker Teleport lets users transfer DAI between different chains as long as the chains both settle on Ethereum L1. This results in two types of movements:

Teleport L2 → L1 (aka fast withdrawals)

Maker Teleport leverages off-chain Maker Oracle Feeds to establish communication between L1 and L2. As a result, the user's funds are burned on the source chain and minted on the destination chain.

Here’s how a transaction flows via Teleport’s fast path from L2 to L1:

1. Users initiate a bridging transaction from the source chain (remember, this is an L2 → L1 withdrawal).

2. DAI is sent to the L2 bridge and burned.

3. This event is monitored by Maker-controlled L2 node operators (acting as the Maker Oracle Feeds), which generate a signed attestation for it to serve as the proof that the transaction took place.

4. A subsequent mint process is initiated on the L1 as users query the Oracle Network for an attestation and provide it to the Oracle Fast Withdrawal contract.

Transaction Flow via Maker Teleport from L2 to L1

DAI is released from L1 Bridge escrow (to have DAI on L2 in the first place, it had to be put on L1 escrow some time before) and subsequently burned. The settlement process involves transferring DAI from the L1 Bridge to the TeleportJoin mechanism to resolve any accumulated debt.

Moreover, in case the fast withdrawals don’t work as planned and attestations cannot be obtained from Oracles, the user will have to take the slow emergency path and wait for the L2 message to be confirmed on L1. For Optimistic Rollups, this process is typically 7 days.

Teleport L2→L2

Bridging from L2 to L2, follows the same design. Here’s how a transaction flows via Teleport’s fast path from L2 to L2:

1. Users initiate bridging transactions from the source L2.

2. DAI is sent to the L2 bridge and burned.

3. Maker Oracle monitors the event and generates a signed attestation to confirm the transaction.

4. A subsequent mint process is initiated on the destination L2 and funds are sent to the user.

Transaction Flow via Maker Teleport between L2 to L2

The settlement process involves transferring DAI from the L2-A (source chain) bridge on L1 to the L2-B (destination chain) bridge on L1. The DAI in the L2-B bridge on L1 will serve as collateral for the minted DAI on the L2-B. The goal here is to use Ethereum as the settlement layer for security, but the users don’t need to directly interact with the chain for moving funds across L2s.

Trust Assumptions

The following trust assumptions are by Maker Teleport in bridging DAI:

In the event of an Oracle network failure or censorship, user' funds remain secure, and the slow path is adopted as an alternative. Furthermore, even if a user manages to acquire incorrect attestations due to Oracle malfunctions, the worst-case scenario results in bad debt for MakerDAO, as the minted DAI will never be settled.

Therefore, it can be concluded that the safety of user funds is never compromised, and the worst-case scenario either leads to delayed transfers or has consequences like bad debt for MakerDAO.

2) Implementation risks

Supported Networks & Adoption

Resources

You can learn more about Maker Teleport through the following resources:

• Official Repository
• Grant Page
• Introduction Post
• Teleport Oracle Overview
• Maker’s Multichain Strategy and Roadmap

Frax’s Ferry – FRAX

The Origins of Ferry

Frax Finance is focused on issuing innovative stablecoins and building cross-chain infrastructure to support them. They created stablecoins like FRAX, FPI, and frxETH, along with DeFi tools such as Frax Lend, Frax Swap, and Frax Ferry.

However, relying on third-party bridges posed challenges and vulnerabilities to Frax assets, including hacks, bugs, and risks of infinite mints, along with slow transactions on some chains.

• Capped risks through fixed token amounts in bridge contracts.
• No risk of infinite minting of Frax stablecoin assets.
• Better scrutiny of asset movements (enabling the detection and prevention of potential issues).

Launching Frax Ferry was a significant milestone that let users access native FRAX and other stablecoins in the Frax ecosystem on any chain without relying on third-party bridges.

Currently, the team is actively developing Frax Ferry v2, which will incorporate zk proofs and root hashes, thereby further bolstering the system's security.

How it Works – Transaction Lifecycle

Before going into the transaction lifecycle (aka the shipping process) of Ferry, let’s look at some important roles (whitelisted to the core developers of Frax) and terms of the bridge’s architecture:

Terms

• Shipping process – the process of transferring funds from the source chain to the destination chain.
• Batch – All user transactions are stored in the smart contract on the source chain in a ‘Batch’ and are ‘shipped’ to the destination chain every 24 hours.

Roles

• Captain – The Captain is responsible for initiating the shipping process by querying the source chain for transactions to be shipped and has the authority to start the trip.
• Crewmembers – The Crewmembers play a crucial role in validating the batch sent by the Captain. These are bots run by whitelisted entities responsible for checking the batch's validity and can dispute it if they find any discrepancies or issues. One can think of them as ‘Watchers’ typically used in optimistically verified bridging systems.
• First Officer – The First Officer is responsible for executing the non-disputed batches. The First Officer transfers the tokens from the contract to the intended recipients on the other chain.
• Owner – The owner is another whitelisted core developer that can manually manage tokens in the smart contract on the destination chain (by pausing, unpausing, and/or removing batches) and must ensure that it has enough funds.

A general transaction via Ferry goes as follows:

Source: Frax Ferry Docs

3. The user funds are transferred from the source chain to the destination chain once per day (via ‘ferries’); thus, the users must wait 24 hours.

If the Crewmembers identify an invalid batch, they can raise a dispute using the "disputeBatch()" function.

If they do not find any issues with the batch, they can choose not to dispute it and proceed to the next step.

If there’s a mismatch between the funds sent from the source chain and those deposited in the contract on the destination chain, the Owner can manually pause the batch from executing and prevent fraud.

It is essential for the First Officer to ensure that the hash of the transactions matches the hash value provided in the batch.

5. Users receive their tokens on the destination chain.

Trust Assumptions

1. Captain will propose accurate batches.

The Captain could be tricked into sending a batch with a transaction that contains a false hash. In such a scenario, unless the fraudulent transaction is detected by Crewmembers, a malicious transaction could be executed on the destination chain.

2. Crewmember bots will be able to detect fraudulent transactions and maintain uptime.

Users must rely on the Crewmembers bots (run by whitelisted core developers of Frax) to review batches diligently and accurately within the 24 hour waiting period.

In cases where Crewmember bots are offline, censored, or compromised, no one can dispute the Captain’s proposed batches, and a bad batch will be passed to the destination chain.

3. The key roles (like Captain, Crewmembers, Owner, First Officer.) are whitelisted by the team.

Users need to trust that the core developers whitelisted by Frax for these positions are honest and will act in the best interest of the users and the protocol and maintain liveness.

In the Ferry v1, anyone can potentially assume these roles as they can be added via governance. However, no individual or entity has shown interest in undertaking them despite this possibility, according to the team's information. The team's objective in Ferry v2 is to eliminate the need for trust by enabling anyone to fulfil these roles in a permissionless manner.

Supported Networks

Frax Ferry currently supports 14 EVM-chains including Ethereum, Arbitrum, Optimism, Polygon, and several others.

Resources

You can learn more about Frax Ferry through the following resources:

• Official Website
• Official Docs
• Guide: How to use Fraxferry

LayerZero’s Omnichain Fungible Tokens (OFT) – MIM

The Origins of OFT

For token issuers, the OFT standard enables composability across multiple blockchains and the ability to own token contracts, security, and fees. OFT gives token issuers the ability to launch a new token from scratch, but is also backwards compatible with ERC-20 tokens that already exist and lets token issuers deploy OFT contracts on LayerZero supported chains of their choosing.

How it Works – Transaction Lifecycle

OFTs rely on LayerZero’s for messaging across chains and security in general. Therefore, an OFT transaction is confirmed just as any other LayerZero transaction is confirmed, which we will explain in more detail now.

All LayerZero transactions begin with a User Application (UA) starting a transaction (aka doing something on-chain). In the context of a stablecoin like MIM, a transaction might be initiated on Stargate (UA) or Abracadabra’s frontend (UA) and the transaction would be “move MIM from Arbitrum to BNB Chain.”

These transaction details are confirmed on the source chain and are then broken up into multiple parts (proof and block header) via two independent entities, an Oracle and Relayer, in a flow that is facilitated by a LayerZero Endpoint on chain A.

Once the Oracle and Relayer send their respective information from the source chain and the LayerZero Endpoint validates that the information is correct, the message is translated and executed on the destination chain.

In the context of an OFT, the “message” being passed is that of an OFT being locked/burned on the source chain and then minted the destination chain. In other words, when a user transfers an OFT from source chain, the OFT will lock in the ProxyOFT contract on chain A and mint on chain B.

When a user wants to move back, the OFT is burned on chain B chain and unlocked on chain A through the ProxyOFT contract again.

A general transaction on LayerZero would go as follows:

LayerZero Transaction Lifecycle, Source: LayerZero

Trust Assumptions

To understand the trust assumptions of OFTs, one must dive a bit deeper into the architecture that goes into confirming LayerZero transactions. Specifically, there are two trust assumptions that need to be made on the behalf of OFT issuers:

1) One must trust that oracles and relayers are acting independently.

LayerZero relies upon two off-chain entities, an Oracle and a Relayer, to pass messages between the endpoints found on different domains. In this setup, an oracle (like Chainlink) forwards a block header from domain A to domain B, while a separate relayer passes a transaction proof from domain A to domain B. If the two match and the proof is validated by the block header, then the cross-chain message is sent to the destination address.

To summarize the relationship between relayers and oracles:

• The job of a LayerZero oracle is to simply relay generic data (aka block headers) from the source domain to the destination domain. It is a third-party service that can be run via multiple services, with Chainlink being the dominant oracle at the moment.
• The job of a relayer, which is also a third-party entity, is to fetch the proof of a specified transaction. Notably, under the parameters laid out by LayerZero, anyone can be a relayer, which helps make sure it is a decentralized system. However, as currently constructed, LayerZero Labs runs the most used relayer, part of the default configuration

The only condition that matters for Oracles and Relayers is that they are run independently and do not collude. If they do not collude, LayerZero is secure.

2) One must trust that LayerZero smart contracts are written correctly and do not have any bugs.

LayerZero’s existence starts as “Endpoint” contracts found on supported chains. These endpoints are implemented as a series of smart contracts that allow domains to communicate with each other, with each chain having its own “Library” in the LayerZero system. Each Endpoint comes with a messaging library native to the domain the Endpoint sits on, along with a proxy, which makes sure the Endpoint uses the correct library version. Once deployed, the Endpoints are like smart contracts that cannot be shut down, allowing for an immutable flow of messages.

Potential Drawbacks of OFTs

1) Infinite Mint Risk

It can be argued that the OFT standard is a whitelabel mint/burn bridge, and suffers from the same issues as all mint/burn bridges, namely (which we’ve already seen occur in various bridge hacks): if LayerZero messages/receipts are forged or corrupted, OFT can be minted infinitely everywhere. In other words, OFT security is built on top of LayerZero, and if LayerZero is hacked, then so are OFT-wrapped stablecoins.

Infinite token minting would cause major short-term consequences for DeFi. For example, any protocol using MIM for borrowing, lending, or liquidity would be potentially compromised– even if long-term consequences could be mitigated by re-minting a token or blacklisting erroneously minted tokens (this would require a DAO vote, a chain rollback, or some sort of centralized decision by an OFT token issuer).

2) Social Consensus Risk

OFT is a welcome token standard for developers and token issuers because it is relatively easy to implement, gives tokens instant exposure to LayerZero chains, and relies on LayerZero’s security.

This is awesome! But there are drawbacks, especially in light of stablecoins, because there is technically nothing stopping large whale holders of a token like USDC, MIM, or USDT to create an OFT version of USDC, MIM, or USDT, as OFT is simply a wrapper for a token (which is something that stablecoin bridges were built to disrupt in the first place).

For instance, when it comes to transferring MIM across different chains, the current "best practice" is to utilize the OFT standard, as preferred by Abracadabra, the token issuer behind MIM.

That being said, it is theoretically possible for large MIM holders or LayerZero’s competitors to coordinate and initiate a fork away from the existing token standard.

While the likelihood of this scenario unfolding is low, it remains a possibility, especially in situations where differing opinions arise within specific communities and there’s no resolution. For example, if the project team chooses a particular bridge for minting assets, but significant stakeholders express dissatisfaction with the decision, they may opt to use a different bridge as the token wrapper, effectively creating a fork of the token standard.

Note: this type of risk applies to all token standards, including ERC20 tokens, as they are all open-source and can potentially be wrapped by community segments and claimed as the 'original' token based on social consensus.

Supported Networks & Adoption

LayerZero is available on Meter, Arbitrum Nova, Tenet, Moonriver, zkSync Era, Canto, Polygon zkEVM, OKT, CoreDAO, Intain, Metis, Klaytn, Gnosis, Fuse, Moonbeam, Celo, Dexalot, Harmony, DFK, Fantom, Optimism, Arbitrum, Polygon, Aptos, Avalanche, BNB Chain, and Ethereum.

Therefore, OFTs are available on all of those chains. However, as of now MIM is only available on chains chosen by Abracadabra.

Source: LayerZero: Expand or Die I Avalanche Summit II

Over the recent months, OFTs have seen significant growth and adoption.

Source: LayerZero: Expand or Die I Avalanche Summit II

Resources

You can learn more about LayerZero’s OFT standard and MIM through the following resources:

• LayerZero Docs
• Abracadabra Blog Post

So What Do Stablecoin Bridges Mean for Other Bridges?

Contrary to the initial expectations of Crypto Twitter, the advent of stablecoin bridges doesn’t necessarily indicate the end for liquidity pool-based bridges.

While stablecoins make up a large portion of bridging volume, they are not the sole assets users want to bridge. Native tokens like ETH, MATIC, SOL and other bluechip assets like BTC also comprise a significant portion of historical bridging volume, thereby even if stablecoin bridges end up taking 100% of the share of bridging of their token, there’s a sustainable case for liquidity-pool based bridges.

However, it’s unlikely that stablecoin bridges will make up 100% of bridging volume. For example, stablecoin bridges, due to their finality requirements, are slower compared to liquidity pool bridges. For example, in the scenario below, transferring 10,000 USDC from Ethereum to Avalanche can be done at a lower cost via Circle’s CCTP. However, this route is slower compared to liquidity-pool based bridges like Stargate.

Source: Jumper.exchange

With CCTP, users need to wait for finality confirmation on Ethereum before they can bridge their funds, whereas with Stargate LPs can front the liquidity instantly without waiting for finality confirmation. This preserves the value proposition of speed that liquidity pool bridges offer.

In addition to liquidity pool-based bridges, there is also a way to survive for wrapped-asset based bridges like Multichain due to systemic arbitrage. For example, if Multichain can move fast enough and deploy endpoints on a new chain before a stablecoin bridge supports that chain, Multichain could see stablecoin volume through their bridge during the period before the stablecoin bridge launches support there.

In fact, stablecoin bridges can benefit liquidity-network bridges by enhancing their capital efficiency. This is best illustrated by the example by the Across team:

“In the optimistic roll-up case, we currently rely on the 7 day canonical bridge to move funds back from L2 to L1 to keep our pools at their targets; we expect that stablecoin proprietary bridges will have a much quicker bridge time than some of the canonical bridges (especially L2->L1, as evidenced by the speed of CCTP) and we can use these proprietary bridges without introducing any additional security assumptions since users are already holding the token.”

Moreover, stablecoin bridges will remove the burden of fees paid to LPs for maintaining liquidity.

This, in turn, allows bridges to allocate their revenue more effectively and redirect it to other areas. For instance, for bridges that compensate LPs with their own tokens (e.g, Stargate with $STG), this would result in reduced emissions of the STG token to pay out LPs, benefiting both the protocol and its tokenholders – by reducing reliance on the emission of new STG tokens into circulation, the functioning of the protocol becomes less dependent on this mechanism. Bridges could also choose to redirect token emissions to other pools, thereby incentivizing deeper liquidity for non-stablecoin assets.

We anticipate that in the future, liquidity pool-based bridges will integrate stablecoin bridges like CCTP and Maker Teleport, replacing the liquidity pools for the stablecoins, resulting in substantial cost savings on liquidity maintenance (we’re already seeing this being done by bridges like cBridge).

Although this vision is currently constrained by the limited number of supported chains by most stablecoin bridges, we expect that as stablecoin bridges make progress on their roadmaps and expand connectivity across various chains, integrating them will become a no-brainer for any liquidity-pool based bridge. This development could have several positive outcomes for the ecosystem as a whole:

1. Stablecoin bridges would witness increased adoption, leading to an expansion of stablecoin supply—a win for stablecoin issuers.
2. Liquidity pool-based bridges could reduce their expenses and become more capital efficient by eliminating the need for maintaining liquidity for stablecoins through LP fees.
3. LPs of liquidity-pool based bridges can use stablecoin bridges to rebalance assets on different chains.
4. Users would benefit from more cost-effective and in some cases (depending on the chain’s finality times), faster bridging of stablecoins, enhancing their experience.
5. Bridge aggregators, such as LI.FI, would benefit from reliable, low-cost, and efficient routes for stablecoins (currently the preferred assets for bridging activities). For example, USDC has accounted for 37% of cross-chain transactions at LI.FI since 2022.
6. dApp developers would be able to leverage stablecoin bridges through aggregators and messaging protocols to build cross-chain experiences with stablecoins.

In the long run, the emergence of stablecoin bridges and bridge token standards like LayerZero's OFTs may have the potential to reduce the prominence of liquidity pool-based bridges as they have clear benefits for the overall ecosystem. However, it is important to note that liquidity pool-based bridges will remain relevant within the multi-chain ecosystem due to their notable advantages in terms of asset support flexibility and speed. Thus, while their influence may be somewhat diminished, liquidity pool-based bridges will continue to serve a valuable role in facilitating seamless cross-chain transactions.

Closing Thoughts

Stablecoin bridges are a noteworthy innovation holding the potential to bring significant benefits to the crypto ecosystem and shape the future of how assets are bridged across chains. As these solutions mature and become more comprehensive, we expect them to witness substantial adoption, benefiting both stablecoin issuers and the overall ecosystem. Like with Circle and CCTP, we see a future where many stablecoins will adopt a burn-and-mint mechanism to control their stablecoin supply across chains, enabling native availability and transferability across multiple chains. However, rather than all stablecoin issuers developing their own stablecoin bridging solutions, there is a strong possibility of them leveraging bridge token standards to achieve similar advantages, much like how Abracadabra decided to utilze the OFT standard.

We foresee a future where asset-based bridges (stablecoin bridges for stablecoins and other assets leveraging token bridge standards offered by the many messaging protocols) and liquidity-pool based bridges benefit from each other, and improve efficiency of asset flows across the multi-chain ecosystem.

Note: Currently, bridge aggregation protocols have not been able to establish this dominance as bridges like Stargate continue to maintain a significant share of volume and user adoption in the bridging niche.

— — —

A sincere thank you to the Circle, Frax, LayerZero, and Maker team for diligently reviewing their respective sections. We would also like to thank the Across, deBridge, and Stargate teams for their valuable insights. Their expertise and perspectives have provided valuable clarity and enhanced our understanding of the subject matter. Lastly, thank you to purplepill (Blockworks Research) for his feedback and suggestions.

Disclaimer: The views and opinions expressed in this article are solely those of LI.FI’s Research Team and do not necessarily reflect the official policy or position of any organization, company, or individual mentioned herein.

The information provided is for general informational purposes only and should not be construed as professional advice. Readers are advised to conduct their own research and analysis before making any decisions based on the content of this article.