LI.FI: The Stablecoin Bridge Almanac 2023
CMC Research

LI.FI: The Stablecoin Bridge Almanac 2023

31m
Created 8mo ago, last updated 8mo ago

In this research column, LI.FI examines different stablecoin bridge designs based on how they work, their benefits, roadmap, adoption rate and potential risk factors.

LI.FI: The Stablecoin Bridge Almanac 2023

Table of Contents

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!

Join us in showcasing the cryptocurrency revolution, one newsletter at a time. Subscribe now to get daily news and market updates right to your inbox, along with our millions of other subscribers (that’s right, millions love us!) — what are you waiting for?

What Are Stablecoin Bridges?

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

Specifically, stablecoin bridges move stablecoins from one chain to another via burn and mint mechanisms controlled by the stablecoin issuer. In other words, a stablecoin bridge is the native (sometimes called canonical) bridge for a certain stablecoin that acts as the single source of truth for minting stablecoins on different chains. This is powerful because having a single entity (centralized or decentralized) in charge of minting a stablecoin enhances capital efficiency for the stablecoin, as there is no longer a need for third party bridges to wrap, lock, or provide liquidity for said stablecoin.

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?

Stablecoin bridges were developed to address several crucial inefficiencies in the multi-chain reality:
  • 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

Circle has always had a multi-chain view of the ecosystem, which is evident in the launch of USDC on different chains over the past few years. Originally, USDC launched on Ethereum in 2018 and expanded to other chains like Algorand and Solana as early as 2020, much before the ‘multi-chain narrative’ had taken shape in the ecosystem. Since then, Circle has launched USDC on several chains, including Avalanche, Stellar, Tron, Hedera in 2021, Flow in 2022, Arbitrum in 2023, and is making headway on its plans of launching USDC on Optimism, NEAR, Statemint and Cosmos via Noble. Circle’s strong commitment to multi-chain expansion arises from their belief that each blockchain harbors the unique potential for innovation and distinct customer experiences. Thus, by positioning USDC as an omnichain digital dollar, Circle aimed to establish USDC as a ubiquitous presence across chains.

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.

Circle actively engaged with the crypto ecosystem and sought feedback from key projects across chains. The response was positive, with stakeholders expressing their willingness to adopt a solution that could provide a fungible USDC experience on different chains. As a result, Circle decided to launch Cross-Chain Transfer Protocol (CCTP), a permissionless onchain protocol for moving USDC natively across chains. CCTP enables a standardized and fungible USDC experience for developers building on multiple 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

Circle’s CCTP is currently live on Ethereum and Avalanche and will go live on Arbitrum this week, with plans to expand to additional chains throughout 2023.

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.
This framework is primarily based on the work by Circle in the CCTP marketing material. Within this framework, each layer relies on the layers beneath it to provide essential functionality.

Resources

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

Maker Teleport – DAI

The Origins of Teleport

MakerDAO’s multi-chain strategy and roadmap is based on the belief that while Ethereum is likely to become a global settlement layer in crypto, it is unlikely that all on-chain activity will be concentrated only on mainnet – as rapid innovation and development are happening across various rollups.

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 

Consequently, MakerDAO decided to leverage its unique position in the multi-chain ecosystem to provide cheap access to DAI across chains by controlling the narrative around the DAI brand and ensuring fungibility. As a result, MakerDAO launched Maker Teleport, a stablecoin bridge owned and operated by MakerDAO that bridges DAI across the multi-chain crypto landscape while maintaining the full fungibility and security that made DAI popular in the first place.

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)

Bridging from L2 to L1 is costly and slow because transaction finality for Optimistic Rollups takes anywhere from one to two weeks.

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:

1) Dependence on Maker’s Oracle Network for validating transactions – Every transfer made through Teleport requires verification of the burn event by node operators within Maker's Oracle network. Consequently, users must depend on the proper functioning of Oracles to successfully receive their funds on the destination chain via the fast path.

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

Although this risk applies to any stablecoin bridge, protocol, or smart contract across DeFi, it is important to emphasize it here. In the past, Teleport experienced a temporary shutdown on Starknet due to a minor implementation issue that had the potential to temporarily block certain teleport withdrawals on L1.

Supported Networks & Adoption

Maker Teleport is currently live on Ethereum, Optimism, and Arbitrum with plans to expand to other chains like Scroll, zkSync Era, Polygon zkEVM, among others in 2023. It was also deployed on Starknet in 2022 but had to be temporarily shut down due to the identification of a minor issue.
The development of Teleport has been indefinitely postponed due to restructuring within Maker, as the protocol engineering team responsible for its construction has been disbanded.

Resources

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

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.

Frax Ferry was introduced to facilitate the movement of Frax stablecoins across chains, ensuring tight pegs and fungibility of their stablecoins.
Initially, Ferry relied on third-party bridges like Wormhole and Multichain to facilitate quick transfers by minting wrapped versions of stablecoins (anyFRAX, wormFRAX) on the destination chain.

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.

To overcome these challenges, a slower yet more secure bridging mechanism, Frax Ferry, was introduced, which ensured the stability and uninterrupted functioning of the Frax Protocol. It offered benefits such as:
  • 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).
To further enhance security, Ferry underwent an audit conducted by Trail of Bits in 2022.

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.

Looking ahead, Frax plans to launch Fraxchain, consolidating infra products like Ferry and stablecoins onto its own L2, creating a user-friendly ecosystem.

How it Works – Transaction Lifecycle

Unlike the other stablecoin bridges mentioned in this article, Frax Ferry is a bridging system hosted as a front-end on the Frax application that end-users can directly interact with.

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

1. User initiates the transaction on the Ferry frontend and tokens are sent to Ferry’s contract on the source chain. The transaction is stored in the smart contract with other user transactions – this set of transactions is known as a batch.
2. The Captain queries the transactions on the source chain and starts the shipping process by sending a batch containing the start and end details of the trip, along with a hash value, using the "depart()" function.

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.

During this time, the Crewmember bots validate the batch sent by the Captain and dispute it if they find any discrepancies.

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.

4. The funds arrive on the destination chain and are stored in Ferry’s smart contract. At this step, it is possible for the Owner a whitelisted core developer of Frax) to manually manage the tokens in the smart contract – It is their responsibility to ensure that it has the required user funds sent from the source chain.

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.

5. Once the Crewmembers and the Owner have reviewed the batch and not raised any disputes, the First Officer can execute the batch by providing the transactions as calldata. This process is carried out using the "disembark()" function.

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:

LayerZero’s Omnichain Fungible Tokens (OFT) – MIM

Note: OFT is a different version of a stablecoin bridge than we’ve covered so far, as it is a token standard chosen by Abracadabra, rather than a stablecoin bridge created by Abracadabra. As such, the set of trust assumptions are more nuanced and this section will be longer. Other messaging bridges, such as Axelar, Hyperlane, and Wormhole have also released token standards that, if adopted by a major stablecoin, would have similar trust assumptions to OFTs. However, as of publishing no other major stablecoin has chosen to use a messaging bridge for omnichain connectivity.

The Origins of OFT

Built on top of LayerZero, Omnichain Fungible Token (OFT) is a token standard (aka an extensible token contract) that enables tokens to be externally composed in any type of dApps, across any DeFi ecosystem, just like an ERC-20. OFT is LayerZero’s attempt at creating a unified token standard for all protocols and blockchains.

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.

In terms of stablecoins, the OFT standard received its first stablecoin deployment via Abracadabra’s “Magic Internet Money” (MIM) – a stablecoin that is soft-pegged to the US dollar and minted against crypto-based collateral. Branded as an “omnistable,” MIM is an OFT that is available to be moved without fees across every LayerZero supported chain.

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

For a more in-depth explanation, please refer to our previous assessment of LayerZero in our article analyzing arbitrary messaging bridges!

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.

As noted in a recent research report by Uniswap, this Oracle and Relayer configuration can be customized by teams depending on the use-case. In the context of OFTs, we are assuming that security will be prioritized and that OFT transactions should be secured by the most secure configuration for LayerZero, which involves Chainlink’s Decentralized Oracle Network (DON) consisting of four reputable legal entities and a Relayer operated by LayerZero. However, if somehow, Oracles and Relayers end up colluding even in this secure configuration, LayerZero’s security structure, and, therefore the OFT standard, is majorly compromised.

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.

Nevertheless, it is crucial to acknowledge that the trust assumption mentioned here is not exclusive to LayerZero alone; it applies to any bridging system. It’s also important to note that LayerZero’s code has undergone multiple audits and LayerZero has a $15M bug bounty program on Immunefi.

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).

Note: this risk applies to all token standards built on any messaging bridge. To address and minimize such risks, teams building on top of LayerZero can implement Pre-Crime, a mechanism developed by LayerZero Labs to defend against hacks, and establish contract specific restrictions.

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.

However, because OFT is an open-source token standard, that means that anyone can launch an OFT. For example, Avalanche recently created BTC.b, a token that represents Bitcoin on Avalanche and is now an OFT that can be traded across any LayerZero chain. In other words, Avalanche created a bridge between Bitcoin and Avalanche, called the resulting minted token BTC.b and then used LayerZero to extend BTC.b to almost every EVM chain.

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.

As we have covered before, LayerZero’s OFT standard is currently supported by TradeJoe (JOE), PancakeSwap (CAKE), and Stargate (STG) launched a version of their token as an OFT. Avalanche also issued a version of Bitcoin (BTC.b) as an OFT. Most recently, PEPE joined the OFT club, releasing $PEPE as an OFT on Ethereum, BNBChain, and Arbitrum.

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:

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.

Moreover, it is worth noting that native bridges have been present in the ecosystem from some time that provide comparable cost-to-speed trade-offs, characterized by low cost but slow execution, similar to stablecoin bridges. Despite that, liquidity-pool based bridges continue to play a vital role in the ecosystem

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.

Ultimately, we believe that for user-centric bridging protocols, it will effectively come down to which front-end is able to attract the most users. Right now, this ability greatly varies across bridges depending on fees, liquidity, slippage, tokens, chains, etc. But, in the future, as burn-and-mint mechanisms gain adoption across multi-chain assets, these differences would likely be mitigated, leading to competition among bridges and bridging-related interfaces based on factors like user experience and convenience. In this regard, we believe aggregation protocols like Jumper.Exchange possess a notable advantage due to aggregation superpowers, positioning them as the preferred platform for users requiring fund bridging. This enables them to build strong user retention strategies by becoming the hub for all bridging activity.

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.

This article contains links to third-party websites or other content for information purposes only (“Third-Party Sites”). The Third-Party Sites are not under the control of CoinMarketCap, and CoinMarketCap is not responsible for the content of any Third-Party Site, including without limitation any link contained in a Third-Party Site, or any changes or updates to a Third-Party Site. CoinMarketCap is providing these links to you only as a convenience, and the inclusion of any link does not imply endorsement, approval or recommendation by CoinMarketCap of the site or any association with its operators. This article is intended to be used and must be used for informational purposes only. It is important to do your own research and analysis before making any material decisions related to any of the products or services described. This article is not intended as, and shall not be construed as, financial advice. The views and opinions expressed in this article are the author’s [company’s] own and do not necessarily reflect those of CoinMarketCap.
2 people liked this article