How To Make Cross-Chain Tokens Fungible Again: Part I

Introduction

The modular maxis say the future of crypto is a million (or more) interconnected domains and users hopping between blockchains like Alice traipsing through Wonderland. Why stick with one chain if you can access cutting-edge tech, novel applications, moonshot returns on staking/liquidity provision, high performance, and ultra-low transaction fees on other blockchains? 

But moving between blockchains is much more complicated than Alice’s trip through Wonderland, primarily due to limitations inherent in current approaches to blockchain interoperability (e.g., cross-chain bridges). In particular, cross-chain bridges today are either insecure ($2.5B+ lost in bridge hacks), slow, expensive, or limited in functionality—or display a mix of properties from the list. 

Other issues plaguing the bridging industry are more subtle but still enough to turn the modular maxi’s dream of a multi-chain ecosystem into a nightmare for users and developers—an example of this is how fungible tokens (like ERC-20s) become non-fungible when bridged to different chains via various cross-chain protocols hence hurting its features as a transferable asset. In this article, we will explore a solution that seeks to preserve token fungibility across chains regardless of where a token’s origin contract exists: ERC-7281: Sovereign-Bridged Tokens.  

ERC-7281 extends ERC-20—the de facto standard for creating fungible tokens in Ethereum—to enable the minting and burning of canonical representations of ERC-20 tokens on remote domains by multiple bridges approved by token issuers. This ensures that users bridging an ERC-20 token receive fungible versions of the token at the destination (i.e., two tokens can be exchanged 1:1), even when tokens are sent cross-chain via different routes/bridges. Importantly, protocols that adopt ERC-7281 maintain control of bridged tokens (unlike the status quo where the bridge controls a bridged token) and can rate-limit minting operations to reduce exposure in the event of a bridge failure.

Let’s use USDC as an example of infungibility among in theory identical ERC-20 tokens across different chains. In Ethereum Layer 2 (L2) networks, such as Arbitrum, Base, Optimism, it’s common to use the canonical bridge to move popular ERC-20 tokens from the Ethereum L1 to these chains. These versions of L1-originating L2 tokens are commonly called just “bridged [insert token name].” 

In the case of USDC, the common symbols are USDC.e, USDC.b, and so on. Over time, Circle expands its USDC deployments to other chains, including L2s, where USDC is already live via the canonical bridge. Even though these two tokens are minted by the same entity and have the same price, they’re technically different, infungible tokens, thus are not “interoperable”—while native USDC can be bridged via Circle’s CCTP bridge, the bridged USDC can only be bridged back to the L1 via the canonical bridge.

ERC-7281 fixes this by introducing an ERC-20 extension where the deployers of the token can assign and parametrize different sources of bridging for it. In the example above, Circle could deploy a universal USDC token on all L2s, where the canonical bridges (e.g., Circle Mint, Circle CCTP, and other approved bridges) are all assigned as capable of minting the tokens according to their logic. To minimize the risks of minters getting hacked, the deployer can limit how many tokens each minter can mint and burn in the specific time period—with more reliable bridges, such as the canonical L2 one, having higher limits, and bridges with centralized consensus having lower ones.

While ERC-7281 isn’t the first attempt at creating fungible cross-chain tokens, it fixes problems associated with previous proposals—such as vendor lock-in, loss of sovereignty for token issuers, high costs of bootstrapping liquidity for bridged tokens, infrastructure overhead, and increased exposure to bridge failures. 

This two-part report will examine the rationale for introducing a sovereign-bridged token standard and provide a comprehensive overview of the ERC-7281 (also known as xERC-20) specification. We’ll also discuss the positive benefits and potential drawbacks of implementing ERC-7281 for users, developers, infrastructure providers, and other actors in the Ethereum ecosystem. 

A refresher on blockchain bridges

Before diving into the problem of non-fungible bridged tokens, it helps to understand why bridged tokens exist in the first place. This, in turn, requires understanding the motivation for and operation of blockchain bridges—since bridge operators are the ones responsible for creating bridged token versions. 

A bridge is a mechanism for transferring information between blockchains. Besides purely monetary information, bridges can pass any useful information such as token rates and smart contract state on other chains. However, transferring assets (tokens) from one chain to another is the most common use case for users interacting with a bridge today.

Approaches to facilitating cross-chain asset transfers vary, but token bridging workflows usually follow one of three high-level patterns:

Lock and mint bridges

• A user wants to bridge a token from its native or "home" chain (where it was initially issued) to another chain. The two blockchains aren’t interoperable, as each chain implements different architectures and protocol designs, which prevents the user from transferring tokens directly from a wallet address on chain A to a wallet address on chain B.

• The bridge operator escrows tokens deposited by the user on the origin chain in a smart contract and creates a "wrapped" representation of the native token via a token contract deployed at the target chain.

• When the user wishes to bridge in the reverse direction (destination chain → origin chain), they return the wrapped tokens to the bridge on the destination chain, which verifies this according to the logic in the bridge (e.g. ZK proofs or an external quorum) and releases the original tokens from escrow on the home chain.

Burn and mint bridges

• Instead of locking tokens in escrow, this approach burns (destroys) the tokens on the source chain;

• The bridge then mints an equivalent amount on the destination chain;

• For the reverse trip, the bridged tokens are burned on the destination chain before new tokens are minted on the source chain;

• This maintains the total token supply while enabling cross-chain transfers.

Atomic swaps

• This approach directly exchanges assets on the source chain for assets on the destination chain with another party. 

• Atomic swaps work via mutually locking funds with the same secret value to unlock them, which means that if on any side the secret was revealed, it can also be revealed on the other. This gives the swaps the atomicity property.

• Atomicity means that the swap either completes fully (on both sides) or not at all, preventing fraud or partial/failed transfers.

 

The first approach (lock and mint) is currently the most common. The equivalence in value between a native token and its corresponding wrapped representation minted by a bridge is what allows users to "transfer" assets cross-chain and use a token on a separate chain from where it was initially issued.

However, new designs—such as intent-based bridging—have become quite popular. “Intents” allow users to express desired outcomes for transactions (“swap 100 USDC for 100 DAI”) instead of outlining specific steps for achieving outcomes. Intents have emerged as a powerful UX unlock as they greatly simplify the onchain experience for people and make crypto easier to use, particularly when paired with chain abstraction solutions. 

Cross-chain intents allow users to transfer tokens between chains without worrying about the underlying complexity of bridging. In intent-based bridges, users deposit funds on the source chain and specify their desired outcome on the destination chain (their “intent”). Specialized operators called "fillers" or "solvers" can fulfill this intent by sending the requested tokens to the user on the destination chain in advance. The operators then prove the transfer occurred to claim the locked funds on the source chain as reimbursement.

Some intent-based bridges leverage lock-and-mint mechanisms under the hood. In this case, the bridge mints wrapped tokens that are sent either to the filler who fulfilled the user's intent—or directly to the user if no filler stepped in. While intent-based bridges add an extra layer of efficiency through their solver network, they still fundamentally rely on the same principles as traditional lock-and-mint bridges.

We can think of each wrapped token, whether created through traditional or intent-based bridging, as an IOU from the bridge operator promising to release an amount of the underlying token from the escrow contract. The value of these wrapped assets directly correlates with the bridge operator's (perceived) capacity to process requests from holders to withdraw native tokens escrowed on the token's home chain.

The bridge authorized to lock the underlying tokens on the source chain and mint their wrapped representations on the destination chain ensures that the token's total supply remains constant. For one unit of the underlying token, exactly one unit of the corresponding wrapped token is minted, and vice versa. If an application accepts a wrapped token as a medium of exchange or uses wrapped assets as currency, the application's developers and users trust the bridge provider to secure the "real" assets backing the wrapped token. 

Why do we need bridges?

The ability to transact with a synthetic version of an asset on a remote chain—enabled by bridges creating representations of the asset—is a powerful feature and allows developers and users alike to utilize the benefits of cross-chain interoperability. Some of these benefits include access to more liquidity, exposure to new users, and flexibility for users (who can interact with favorite apps from different chains without friction).

To better understand how this works in practice and why it matters for both developers and users, let's examine a concrete example using a fictional decentralized exchange called BobDEX. This example will demonstrate how wrapped tokens enable cross-chain expansion while highlighting both the benefits and potential complications that can arise:

BobDEX is an Automated Market Maker (AMM) exchange that Bob created on Ethereum to enable trustless swaps between different assets. BobDEX has a native token, $BOB, which doubles as a governance token and an LP reward token. In the latter case, BobDEX issues BOB tokens to liquidity providers (LPs), entitling users supplying liquidity to a pool to a percentage of fees paid by DEX users swapping assets deposited in the pool. 

BobDEX’s market share has grown significantly, but Ethereum L1’s limitations hinder further growth. For example, some users don’t want to use BobDEX on Ethereum due to high gas fees and transaction delays; similarly, other users wish exposure to the price of $BOB tokens without having to hold native $BOB tokens on Ethereum. 

To solve the problem, Bob deploys a version of BobDEX on Arbitrum (a low-fee, high-throughput Layer 2 (L2) rollup) and deploys a wrapped version of the BOB token (wBOB) on L2 via the Arbitrum-Ethereum bridge. BobDEX on Arbitrum is identical to BobDEX on Ethereum, except it uses wBOB—not native BOB tokens—for LP rewards and governance. 

The difference in application tokens (wrapped BOB vs. native BOB) doesn’t make a difference from the perspective of users (e.g., liquidity providers) interacting with BobDEX on Arbitrum. Since wBOB tokens are backed by actual BOB tokens held in the Arbitrum-Ethereum bridge, wBOB token holders can easily swap for native BOB ERC-20 tokens on Ethereum by interacting with the bridge contract. 

The situation is a win-win for Bob and users:

1. Bob can attract more users, especially users who want low gas fees and fast transaction confirmations when trading on BobDEX

2. LPs can earn rewards from supplying liquidity to BobDEX without dealing with Ethereum’s high gas costs and long confirmation times

3. Hodlers can buy wBOB tokens on the market to profit from changes in the price of BOB tokens without interacting with the BOB ERC-20 contract on Ethereum

The benefits of bridging also extend to enhancing composable innovation and unlocking new use cases that leverage the liquidity of a bridged token. For instance, Alice can create a lending protocol called AliceLend on Arbitrum that accepts wBOB as collateral from borrowers to expand the utility of wBOB and create a new market for lending and borrowing. 

Lenders supplying liquidity to AliceLend are certain of receiving deposits: if a user defaults on a loan, AliceLend automatically auctions wBOB tokens deposited as collateral to reimburse lenders. In this case, buyers of liquidated wBOB collateral assume the role of LPs on BobDEX and have the same guarantee that wBOB tokens can be exchanged 1:1 for original BOB tokens.

Cross-chain bridging in its current form has provided a workable solution to ensuring interoperability between (previously siloed) Ethereum L2s and facilitating novel applications (e.g., cross-chain lending and cross-chain DEXes). But the bridging ecosystem is currently grappling with limitations that hinder further growth, such as the non-fungibility of cross-chain tokens—we’ll explore this problem in detail subsequently.

Why do bridged tokens become non-fungible?

The lock-and-mint bridging workflow described previously looks simple on paper but, in reality, requires a lot of engineering and mechanism design effort to work correctly. 

The first challenge is ensuring that wrapped versions of a bridged token are always backed by native tokens locked on the source chain. If an attacker mints representations of a token at a remote chain without depositing native tokens at the source chain, it can render the bridge insolvent by swapping (fraudulently minted) wrapped tokens with native tokens on the home chain and preventing legitimate users — who deposited in the bridge contract before minting wrapped tokens — from withdrawing deposits. 

The second challenge is more nuanced and derives from the nature of bridged tokens: two representations of a token minted by bridge providers at the same remote chain cannot be exchanged 1:1 for another. We can use another example of two users trying to exchange tokens bridged through different routes to illustrate this aspect of the problem associated with moving tokens across chains:

• Alice bridges USDC from Ethereum to Arbitrum via the canonical Arbitrum bridge and receives 200 USDC.e on Arbitrum, while Bob bridges USDC to Arbitrum via Axelar and receives 200 axlUSDC on Arbitrum. Alice and Bob enter an agreement for Alice to send 200 USDC to Bob (in exchange for 200 USDT) so that Bob can withdraw 400 USDC to Ethereum. 

• Bob tries to withdraw 400 USDC via axlUSDC and only receives 200 USDC, along with a message explaining that the bridge only has 200 USDC it can give Bob. Bob is confused as the wrapped ERC-20 tokens are supposed to be “fungible” and shouldn’t exhibit disparities that prevent anyone from exchanging ERC-20 tokens 1:1 on any application. 

• Bob learns a hard lesson about cross-chain bridging: “fungible ERC-20 token” doesn’t always mean “you can exchange this token 1:1 with other ERC-20 tokens across applications”. Bob’s attempt to do risky business with Alice—risky since Alice may not return the tokens—goes spectacularly wrong. 

Bob after getting rugged on a swap 

Why can’t Bob withdraw 400 USDC if he and Alice received wrapped versions of the same underlying asset on the destination chain? You’ll recall we mentioned that tokens issued on different chains are incompatible, so the representation of a native token issued on a non-native chain is an IOU from the bridge promising to pay back an amount of the native tokens (depending on how much is left) when the user wishes to bridge back to the token’s native chain. 

The value of every bridged token is thus tied to the bridge provider responsible for holding deposits on the home chain and minting representations on the destination chain; Bob’s bridge provider can only pay Bob 200 USDC as that is the amount it has funds to cover from its deposit; Alice’s 200 USDC cannot be withdrawn through Bob’s bridge provider as it never received the deposit or issued an IOU to Alice. Alice must withdraw her locked USDC from the Arbitrum on Ethereum and bridge through Bob’s bridge provider before Bob can access the remaining tokens. 

Bob and Alice’s dilemma points to a problem with bridging between domains where multiple non-fungible representations of an underlying asset are minted by competing bridge providers. The other one problem with different ERC-20 representations of the same asset is that they can’t be traded in a single liquidity pool. 

Using the previous example, if we have axlUSDC and USDC.e on the chain and want to swap them into ETH and vice versa, we must deploy two liquidity pools—ETH/axlUSDC and ETH/USDC.e. This leads to a so-called “liquidity fragmentation” probem—a situation where the trading pools have smaller liquidity than they could otherwise have because there are multiple pools that suit essentially the same trading pair.

The solution is to have a single “canonical” version of a token circulating on the destination chain so that Bob and Alice can exchange tokens without each person withdrawing from the bridge at the source chain. Having a canonical token per chain also benefits developers, as users can quickly move between ecosystems without dealing with issues around token liquidity. 

So, how do we go about implementing canonical versions of a token on each chain it expects to be used on and transferred between? The next section explains some of the popular approaches to creating canonical tokens on multiple chains. 

Implementing canonical tokens across different chains 

Creating a canonical token per chain is not straightforward, and multiple options exist with varying tradeoffs and advantages. When creating a canonical token per chain, we usually need to think about who to trust about the existence of IOUs backing the value of a particular token. Suppose you are the creator of a token and you want it to be usable and transferable across different chains without running into issues around fungibility; you have four options:

1. Mint canonical tokens via canonical rollup/sidechain bridges

2. Mint canonical tokens via a third-party bridge provider

3. Mint canonical tokens via a token-issuer bridge

4. Direct multi-chain issuance with atomic swaps

The first three options rely on various bridging mechanisms to facilitate cross-chain movement of tokens. However, as a token creator, you can also choose to bypass bridging entirely by issuing the token natively on each supported chain. Under this approach, rather than relying on wrapped tokens or bridge infrastructure, you maintain separate but coordinated token deployments across chains—with atomic swaps enabling trustless exchange between chains. 

This approach requires sophisticated infrastructure to maintain liquidity across chains and facilitate atomic swaps, however. The complexity of managing multiple native deployments has historically limited this approach to larger protocols with substantial technical resources.

1. Mint canonical tokens via canonical rollup/sidechain bridges 

If a chain has a canonical (enshrined) bridge, you can assign the right to mint representations of your protocol’s token for users who want to bridge from the native chain. Transactions routed through the chain’s canonical bridge (deposits and withdrawals) are typically validated by the chain’s validator set, which provides stronger guarantees that deposits on the home chain credibly back all minted representations. 

Although the canonical bridge is minting the canonical representation of a token, other representations will still exist. This happens simply because canonical bridges often have limitations that prevent them from offering users the best experience. For example, bridging from Arbitrum/Optimism to Ethereum via the rollup’s canonical bridge incurs a seven-day delay as transactions must be validated by verifiers—and possibly disputed by a fraud proof, if invalid—before the rollup’s settlement layer (Ethereum--settles a transaction batch. 

Rollup users who want quicker exits must use other bridge providers who can assume ownership of pending rollup exits and provide upfront liquidity on the user’s desired target chain. When such bridges use the traditional lock-and-mint model, we end up with multiple wrapped representations of a token issued by different protocols and face the same problems described previously.

Sidechains with independent validator sets have lower latency as withdrawals are executed once the sidechain’s consensus protocol confirms a block containing a withdrawal transaction. The Polygon PoS bridge is an example of a canonical bridge connecting a sidechain to different domains (including Ethereum rollups and Ethereum mainnet). 

Note: We refer to the original Polygon PoS chain, not the planned validium chain that will use Ethereum for settlement. Polygon will become an L2 once the switch from a sidechain secured by external validators to a validium secured by Ethereum consensus is complete. 

However, sidechain bridges also share a weakness with rollup canonical bridges: users can only bridge between a pair of connected chains. They cannot bridge to other blockchains using the canonical bridge. For example, you cannot bridge from Arbitrum to Optimism today using the Arbitrum Bridge or bridge from Polygon to Avalanche via the Polygon PoS bridge. 

1.1. Mint canonical tokens using liquidity bridges 

Relying on a rollup’s native bridge for moving canonical tokens comes with several issues, such as poor liquidity and delays on asset movement. protocols work around this issue by working with liquidity bridges to facilitate speedy withdrawals and low-latency bridging*.

Under this arrangement, approved liquidity bridges  (a) mint wrapped  representations of a protocol’s token on the source chain (b) swap wrapped tokens for the canonical representation at the destination via a protocol-owned liquidity pool. 

The canonical representation of the token on the destination chain is usually the version minted by the canonical sidechain/rollup bridge, although exceptions exist (as we’ll see later). For example, the canonical version of USDT on Optimism is opUSDT minted by the Optimism Bridge. 

Each liquidity bridge functions like a DEX with an Automated Market Maker (AMM) to execute swaps between pairs of assets deposited in different liquidity pools. To incentivize liquidity provision, AMM pools share a portion of swap fees to holders who lock up canonical tokens in the pool contracts.

This is similar to Uniswap’s model; the only noticeable difference is that asset pairs are usually the liquidity bridge’s representation of a token against the canonical representation. For example, a user that bridges USDT to Optimism via Hop will have to swap hUSDT on Optimism via the huSDT:opUSDT pool. 

The workflow for bridging via a liquidity bridge will look like this: 

• Lock native tokens on source chain 

• Mint bridge representation of native token on target chain 

• Swap bridged representation with canonical representation on target chain via AMM pool 

• Send canonical tokens to the user 

This process is similar for all liquidity bridges (Across, Celer, Hop, Stargate, etc.). However, it is usually abstracted away from the end-user—particularly by solvers/fillers—and will feel like a single transaction despite involving many moving parts. 

When bridging back to the source chain, the user burns the canonical representation or swaps the canonical token with the bridge representation via the AMM before burning that representation and providing the proof-of-burn receipt. Once confirmed, the user can withdraw the native tokens locked at the beginning. (Just like the previous operation, the dirty details of moving tokens back to the original chain is hidden from the user and managed by solvers).

Liquidity bridging is excellent, mainly because it fixes the problem of latency in rollup bridging; for example, Hop allows specialized parties known as “Bonders” to attest to the validity of a user’s withdrawal transaction on L2 and front the cost of withdrawing from the rollup’s L1 bridge. Each Bonder runs a full node for the L2 chain and can determine if a user’s exit transaction will eventually be confirmed on L1, reducing the risk that a user initiates a fraudulent withdrawal and causes losses for the Bonder. 

Liquidity bridges also enable users to move between more chains, unlike canonical bridges; for example, Hop allows users to bridge between Arbitrum and Optimism without having to withdraw to Ethereum first. Just like fast L2→L1 bridging, fast L2→L2 bridging requires Bonders to run a full node for the source L2 chain to confirm withdrawals before fronting the cost of minting tokens for a user on the destination L2 chain. This enables more composability between rollups and drastically improves the user experience, as users can move tokens across rollups without issues. 

But liquidity bridging also has downsides that affect the utility of using a chain’s enshrined bridge to mint the canonical representation of a token on an L2/L1 chain.

Drawbacks of liquidity bridges

1. Slippage

Slippage is a difference in the amount of tokens expected and received when interacting with an AMM. Slippage occurs due to AMMs pricing swaps according to the current liquidity in a pool — the pricing is such that equilibrium is maintained between the pool’s balance of each asset in a pair after a swap is complete, which can change between the time a user initiates a trade and the exchange is executed. 

Low liquidity for bridged assets can also increase slippage; if the pool doesn’t have enough liquidity to rebalance one side of the pool, a large trade may shift the price by a large margin and result in users executing swaps at higher prices. Arbitrageurs are expected to help correct disparities between pools trading the same asset but may be discouraged from arbitrage trades involving tokens with low trading activity/value. 

This also impacts developers building cross-chain applications as they must account for edge cases in which slippage occurs; the user cannot complete a cross-chain operation due to receiving lower amounts of a token on one or more destination chains. 

Applications like bridge aggregators (who cannot know if a liquidity bridge will have enough liquidity to cover a swap at the destination chain without slippage) work around the problem by specifying a maximum slippage tolerance and using that to inform quotes provided to users. While this prevents transaction reverts, users always lose some percentage of the bridged token — irrespective of the liquidity in a bridge’s AMM pools.

2. Liquidity Constraints

A fundamental challenge with liquidity bridges is the absolute requirement for sufficient liquidity on the destination chain. Unlike traditional lock-and-mint bridges where token minting is backed directly by locked assets, liquidity bridges depend on available tokens in AMM pools to complete cross-chain transfers. When liquidity falls below critical thresholds, the entire bridging mechanism can effectively cease to function.

• Bridge operations can halt entirely if liquidity drops too low, preventing users from completing their intended transfers;

• Users may be forced to split large transfers into smaller transactions to avoid depleting pool liquidity;

• During periods of high volatility or market stress, liquidity providers may withdraw from pools, precisely when bridge functionality is most needed;

• The bootstrapping of new token pairs becomes particularly challenging, as significant initial liquidity is required to make the bridge operational.

The liquidity requirement creates a circular dependency: bridges need substantial liquidity to function reliably, but attracting liquidity providers requires demonstrating consistent bridge usage and fee generation. This chicken-and-egg problem is particularly acute for new or less frequently traded tokens, which may struggle to maintain sufficient liquidity across multiple chains.

3. Misaligned Incentives

A liquidity bridge is helpful to the extent it can cover swaps from the bridged representation to the canonical token on the destination chain without users incurring excessive slippage; the gas costs of interacting with the bridge also determine a liquidity bridge’s value from a user’s perspective. Thus, bridge aggregators and project teams, issuing a token, prioritize bridges based on the amount of liquidity and transaction costs.

While this ensures users bridging a project’s tokens or using a bridge aggregator to send tokens cross-chain have better UX, selecting bridges based on liquidity places bridges unable to spend on liquidity provider (LP) incentives at a disadvantage. Furthermore, selecting bridges based on pure transaction fees biases the competition in favor of bridges that adopt a centralized approach to reduce operational costs and can charge lower fees on bridging transactions. In both cases, bridges aren’t competing on arguably the most important metric: security. 

Liquidity-based bridges also disfavor long-tail assets with lower trading activity (making them less likely to attract LPs). Issuers of long-tail tokens (or new tokens with low bridging volumes) will either have to set up AMM pools and bootstrap liquidity to cover swaps of native tokens (bridged via a liquidity bridge) against the canonical representation of the issuer’s token or work with bridge operators to increase financial incentives for LPs to supply liquidity for that asset. 

4. Poor bridging UX

Liquidity bridges are an improvement on canonical bridges but aren’t without UX issues as well. Besides enduring slippage on cross-chain swaps, users may be unable to complete a bridging transaction immediately on the destination chain because the bridge doesn’t have enough pool liquidity to cover trade with the canonical token on the destination chain. Bridges cannot know how much liquidity for an asset pair will exist by the time a user’s message to swap tokens reaches the destination chain, so this edge case is mostly unavoidable. 

Users have two choices in this situation (both suboptimal): 

• Wait until the bridge has enough liquidity to complete the swap and withdraw canonical tokens. This is suboptimal because of the delay endured in bridging transactions and because a user cannot know if they’ll receive the same amount of tokens quoted initially since pool liquidity can change arbitrarily in very short periods. 

• Receive the bridge’s proprietary token representation (e.g., hUSDT for Hop Bridge). This is suboptimal as most applications will prefer to integrate with the canonical representation of a native token (e.g., opUSDT minted by the Optimism Bridge) and may not accept the user’s wrapped asset. 

2. Mint canonical tokens via a a canonical third-party bridge 

A multi-chain dapp can work around the issue of non-fungible bridged tokens by selecting a single bridge to mint canonical representations of the dapp’s token on every chain where the dapp is deployed. As with canonical bridges minting approved representations of a project’s token, this approach requires mapping tokens minted on remote chains to the token contract deployed on the project’s home chain—ensuring the token supply remains the same globally. The bridge provider must track the minting and burning of a token and ensure minting and burning operations stay in sync with the token supply on the home chain. 

Using a single bridge provider offers more flexibility for project teams, especially as third-party bridges are incentivized to support bridging between a broader range of ecosystems compared to canonical bridges that only connect to at most one chain. If a bridge exists on all chains where an application is deployed, users can quickly move cross-chain without needing to withdraw back to the home chain; a bridge provider only has to ensure that the tokens minted on destination chain A are burned before a user mints tokens on destination chain B and canonical tokens on-chain B are (re)mapped to the token on the home chain. 

The problem of non-fungible bridged tokens is also eliminated; provided users bridge through the approved bridge provider, they can always exchange them 1:1 with other bridged tokens. This approach further fixes the problems of liquidity-based bridging in the canonical bridge model:

• Users don’t suffer slippage on bridge transactions as the bridge provider doesn’t have to convert its representation against a canonical representation via an AMM—the bridge provider’s token is the canonical representation of the bridged token on every domain. The value of these representations is pegged to the value of tokens locked by the bridge provider on the token’s native chain. 

• Users suffer little to no delays on bridging as the bridge provider can mint wrapped representations on the destination chain immediately after the mint() message arrives at the destination. 

• Developers can outsource managing multi-chain token deployments to bridge operators without worrying about bootstrapping AMM liquidity or liquidity provision incentive programs. 

Some examples of single-bridge-provider tokens in the wild include LayerZero’s Omnichain Fungible Token (OFT), Axelar’s Interchain Token Service (ITS), Celer’s xAsset, and Multichain’s anyAsset. All examples are essentially proprietary tokens and are incompatible with the representations of the same token sent via a different bridge provider. This subtle detail highlights some issues with this approach to handling bridged tokens. Namely the following:

• Vendor lock-in

• Loss of sovereignty

• High exposure to bridge failures

• Loss of token’s custom features on the target chains

• Being limited to vendor’s supported chains

• Inability to maintain the same token address on all desired chains, which may hurt user security or pose them vulnerable to phishing

Drawbacks of using canonical third-party bridges

1. Vendor lock-in

Selecting a single bridge provider to mint canonical representations on one or more chains exposes developers to the risk of vendor lock-in. As each bridge provider mints a proprietary representation compatible with only its infrastructure (and integrated ecosystem projects), the single-bridge-provider model effectively locks a token issuer to a specific bridging service without the option to switch to another bridge in the future. 

It is possible to switch bridge providers, but the switching costs are high enough to discourage most projects from going this route. To give a rough idea, suppose a developer (whom we’ll call Bob) has issued a token (BobToken) on Ethereum and chooses LayerZero OFT to mint canonical versions of BobToken on Optimism, Arbitrum, and Base. BobToken has a fixed supply of 1,000,000 tokens, and bridged tokens minted via LayerZero account for 50% of the total supply of BobTokens in circulation. 

The business arrangement smoothly proceeds until Bob decides users are better off bridging BobTokens via a competing bridge service (e.g., Axelar). However, Bob cannot simply up and say, “I’m switching to Axelar ITS to mint canonical representations of BobToken on Optimism, Base, and Arbitrum”; since OFT tokens and ITS tokens are incompatible, Bob risks creating headaches for both old users and new users as two BobTokens potentially are not fungible(reintroducing the problem we described earlier). Moreover, applications integrated with LayerZero’s version of BobToken cannot accept Axelar’s version of BobToken as a substitute—which fragments liquidity for BobToken on various chains where competing representations of BobToken co-exist. 

To make the transition possible, Bob needs to convince users to unwrap wrapped representations of BobToken minted through LayerZero by sending a transaction that burns bridged OFT tokens and unlocks BobTokens on Ethereum. Users can now switch to the new canonical representation of BobToken by locking tokens with Axelar on Ethereum and receiving canonical BobTokens (mapped to the token contract’s supply on Ethereum) on the destination chain. This is both cost-intensive and incurs massive coordination and operational overhead for DAO project management teams, so sticking to the chosen provider is usually the safest option. 

However, this leaves developers like Bob in a problematic position as vendor lock-in makes it impossible to switch if a bridge provider fails to uphold the terms of the agreement, has a limited feature suite, lacks expansive ecosystem integrations, offers poor UX, etc. It also provides bridges with near-infinite leverage: the bridge provider can do arbitrary things like rate-limit users bridging BobTokens without clear reasons, raise bridging fees, or even censor bridging operations. Bob’s hands are tied in this case, as making a clean break from a faulty canonical third-party bridge is as complex as staying in the business relationship. 

2. Loss of sovereignty for protocols

The concluding part of the previous section on vendor lock-in highlights another issue with using a canonical third-party bridge: token issuers trade off control of canonical bridged tokens in exchange for greater convenience and UX improvements. To use the previous example: BobToken on Ethereum is entirely within Bob’s control as he controls the underlying ERC-20 token contract, but BobToken on Optimism, Arbitrum, and Base are controlled by LayerZero, which owns the OFT contract that issues canonical representations of BobToken on those blockchains. 

While Bob might expect LayerZero to align canonical representations with the original design of the native token, this may not always be the case. In worst-case scenarios, the behavior of BobToken on Ethereum may diverge significantly from that of BobToken on Optimism because the bridge provider implements a radically different version of the token contract—creating problems for the protocol’s users. This problem may also be exacerbated by principal-agent dynamics where the goals and interests of a protocol and the bridge provider diverge.

3. High exposure to bridge failures

In the first approach, where tokens are bridged cross-chain through each chain’s canonical bridge, the risk to the token issuer from an exploit affecting one bridge is contained to that bridge. For example, suppose a hacker manages to compromise one liquidity bridge and mint infinite amounts of a wrapped token without depositing collateral. In that case, it can only withdraw up to the maximum liquidity available for the wrapped asset in liquidity pools (e.g., minting cUSDT on Optimism → swap cUSDT for canonical opUSDT → withdraw opUSDT to Ethereum via fast bridge → exchange for native USDT on Ethereum). 

In the third-party canonical bridge model, the risk to a token issuer from an exploit affecting the partner bridge is equivalent to the total amount of tokens an attacker mints on remote chains where the affected bridge has a deployment. This is possible because every canonical representation on all chains can be exchanged 1:1 for canonical tokens issued on other chains:

Suppose an attacker compromises a third-party bridge on chain B and mints 1000 tokens (where the token is issued initially on chain A) without depositing collateral. The attacker’s tokens on chain B aren’t mapped to the home chain contract, so it cannot withdraw from chain A. Still, it can bridge to chain C and exchange 1000 chain B tokens for 1000 chain C tokens—remember, each cross-chain token is compatible and fungible as they originate from the same bridge service. The chain C tokens are mapped to the home chain contract as they were legitimately minted by users that locked tokens on chain A (the token’s home chain), allowing the attacker to burn tokens on chain C and withdraw native tokens on chain A and potentially complete the itinerary by exchanging the tokens via a CEX or fiat offramp. 

(Source)

Loss of custom token features

When using a canonical third-party bridge, token issuers often lose the ability to implement custom features or token behaviors that exist in their original deployment. This happens because bridge providers tend to use standardized ERC-20 implementation contracts that may not support specialized functionality present in the original token implementation. 

Common token features like vote delegation (ZK), rebasing mechanisms (stETH, USDM), fee-on-transfer capabilities (memecoins), blacklisting and whitelisting functions (USDT, USDC), pausable transfers, and special minting rules or permissions are often stripped away when tokens are bridged through a third-party provider, as the bridged version will typically use a basic ERC-20 implementation. This loss of functionality creates inconsistencies in how the token operates across different chains and can potentially break integrations that depend on these custom features. 

The standardization of bridged tokens, while simpler from the bridge provider's perspective, effectively reduces the token's capabilities and can hamper the issuer's ability to maintain consistent token behavior across the entire multi-chain ecosystem of their application. Such issues can make cross-chain expansions a nightmare for developers and represent an obstacle to realizing the dream of apps living on multiple chains. 

Limited supported chains

Token issuers become dependent on their chosen bridge provider's network coverage and expansion plans. If the bridge provider doesn't support a particular blockchain network that the token issuer wants to expand to, they face two suboptimal choices:

• Wait for the bridge provider to add support for the desired chain, which may take a long time or never happen due to high costs of integration (e.g. ZKsync Era’s EVM inequivalence that has led many dapps to never deploy on it)

• Use a different bridge provider for that specific chain, which reintroduces the problem of non-fungible tokens and liquidity fragmentation

This limitation can significantly impact a protocol's growth strategy and ability to reach new users on emerging chains. Bridge providers may prioritize supporting popular chains while neglecting smaller or newer networks that could be strategically important for the token issuer.

Inconsistent cross-chain token token addresses

Third-party bridge providers may deploy bridged tokens with different addresses on each chain due to peculiarities of their tech stack—for example, no support for CREATE2. Lack of address consistency, in turn, creates many UX problems:

• Security risks: Users must verify different token addresses on each chain, increasing the risk of interacting with fraudulent tokens;

• Integration complexity: Developers must maintain lists of valid token addresses for each network;

• Increased phishing risk: Bad actors can more easily trick users with fake tokens since there's no consistent address to check against.

These drawbacks, combined with the previously discussed issues of vendor lock-in, loss of sovereignty, and high exposure to bridge failures, highlight the significant limitations of relying on canonical third-party bridges for cross-chain token deployments. This understanding helps set the stage for why alternative solutions like ERC-7281 are needed to address these challenges in a more comprehensive way.

3. Mint canonical tokens via token-issuer bridge 

If a developer wants to maintain maximum control of cross-chain deployments of a project’s token, it can manage the issuance of canonical representations of the token on remote chains. This is described as “trust the token issuer,” as the value of every bridged representation of the token is tied to tokens locked on the token’s home chain by the protocol responsible for issuing the original version of the token on the source chain. 

For that approach to work, the token issuer must set up infrastructure to manage the minting and burning of bridged tokens cross-chain (while ensuring global supply remains in sync via canonical mapping). 

Notable examples of canonical representations of a token issued by the token creator are MakerDAO’s Teleport and Circle’s Cross-Chain Transfer Protocol (CCTP). Teleport allows users to move canonical DAI between Ethereum and various Ethereum rollups via fast-path and slow-path operations. DAI is burned on one chain and minted on the target chain. CCTP functions similarly and enables cross-chain transfers of native USDC (issued by Circle) via a burn-and-mint mechanism. In both cases, the token issuer controls the minting and burning of canonical representations of a token. 

This approach offers complete control of bridged tokens for protocols. And it fixes the problem of non-fungible representations of the same token in the most effective way possible—only one canonical version of the token (minted by the issuer at the destination chain) exists, which ensures users have the same experience using a token on every ecosystem the token issuer supports. 

With this approach, applications also benefit from the elimination of liquidity fragmentation caused by unofficial, bridged representations of a protocol’s token floating in the same ecosystem. Developers can also build more robust cross-chain applications (e.g., cross-chain swaps and cross-chain lending) as canonical token-issuer bridges allow for capital-efficient, seamless, and secure movement of tokens between chains. 

The downside to canonical token-issuer bridges, however, is that this model is only feasible for projects with enough capital to cover the overhead of deploying a token cross-chain and maintaining infrastructure (oracles, keepers, etc.) required to perform cross-chain minting and burning. This also has the somewhat undesirable effect of tightly coupling the security of bridged assets with the protocol’s security model. 

This relationship (between bridged versions of a protocol’s tokens and the protocol’s security) is amicable since the safety of native tokens backing canonical representations already depends on the protocol’s security so users and external developers aren’t taking on new trust assumptions. This is especially true of stablecoin bridges operated by issuers like Circle and Maker (now Sky)—users already trust stablecoin issuers to have enough assets to cover redemption of stablecoins for fiat currencies, so trusting the security of a stablecoin bridge isn’t difficult. 

But it also represents a central point of failure—if the token issuer’s bridge infrastructure is compromised, the value of all canonical representations circulating in the multi-chain ecosystem is in jeopardy. This also implies that only centralized custodians (e.g., Circle in the case of USDC) can implement this model of issuing canonical bridged tokens.

Final thoughts

As shown in this report, cross-chain asset fungibility is an important part of rollup interoperability with implications for the experience of moving between different chains. The ability of tokens to remain fungible when bridged to remote chains also impacts the developer experience as certain use-cases depend on this feature. 

Different solutions have been proposed to solve the problem of infungible cross-chain tokens–many of which we’ve covered in this report. This includes minting canonical tokens via native (enshrined) bridges, using a dedicated third-party bridge to mint canonical tokens across multiple chains, and using a protocol-owned bridge to facilitate movement of tokens and preserve fungibility. 

While these approaches solve specific problems, they fail to address all issues and using them to enable cross-chain asset fungibility requires some undesirable tradeoffs. Can we find a better approach? The answer is yes. 

ERC-7281 is a new approach to cross-chain asset fungibility that mitigates tradeoffs associated with existing approaches. Also known as xERC-20, ERC-7281 enables protocols to efficiently deploy canonical tokens on multiple chains without trading off security, sovereignty, or user experience. 

ERC-7281’s unique design allows multiple (whitelisted) bridges to mint canonical versions of a protocol’s tokens on every supported chain while allowing protocol developers to dynamically adjust minting limits on a per-bridge basis. This feature solves many of the problems associated with historical proposals for multichain canonical tokens—including liquidity fragmentation, incentive alignment, UX concerns, bridge security risks, customizability (of cross-chain tokens), and more.   

The next—and final—part of our two-part report on cross-chain asset fungibility will cover ERC-7281 in detail and explore how the xERC-20 token standard can benefit developers and users. We’ll compare ERC-7281 to other designs for multichain canonical tokens, explore xERC-20’s approach to multichain canonical tokens, and highlight considerations for protocols and developers looking to build on the standard. 

Stay tuned!