By Alex Hook and Emmanuel Awosika
Compiled by: Glendon, Techub News
This report is divided into two parts. Part 1 outlines the challenges faced in the cross-chain field, such as the non-interchangeability of cross-chain tokens, and analyzes the current main solutions; Part 2 will explore the sovereign cross-chain token standard ERC-7281 and analyze the benefits and potential disadvantages of implementing ERC-7281 for users, developers, infrastructure providers and other participants in the Ethereum ecosystem.
Currently, cross-chain operations still face many challenges due to the inherent limitations of blockchain interoperability methods such as cross-chain bridges. For example, cross-chain bridges may have security risks (hacker cross-chain attacks have caused losses of more than $2.5 billion), or face problems such as slow speed and high fees, as well as limited functionality. What's more, the above problems may exist simultaneously in the same cross-chain bridge.
In addition, there is a core problem in the cross-chain field: when interchangeable tokens (such as ERC-20 standard tokens) are transferred to different chains through different cross-chain protocols, these tokens become non-interchangeable tokens, thus losing their function as transferable assets. In this article, we will explore a solution that aims to ensure the interchangeability of tokens across chains regardless of where the original contract of the token exists: the sovereign cross-chain token standard ERC-7281.
ERC-7281 (also known as xERC-20) is an extension of ERC-20, a standard for creating fungible tokens on Ethereum. ERC-7281 allows multiple bridges approved by token issuers to mint and destroy standard token versions of ERC-20 tokens on remote chains to ensure that when users bridge ERC-20 tokens, they receive a fungible version of the token at the destination (i.e., the two tokens can be exchanged 1:1), even if the tokens are sent across chains via different paths/bridges.
Importantly, protocols adopting ERC-7281 can maintain control of cross-chain tokens (unlike the current state where the bridge controls cross-chain tokens) and can limit the rate of minting operations, thereby reducing the risk of cross-chain bridge failure.
Taking USDC as an example, it can be found that there is non-interchangeability between theoretically identical ERC-20 tokens on different chains. In Ethereum L2 networks (such as Arbitrum, Base, Optimism), a canonical bridge is usually used to transfer popular ERC-20 tokens from Ethereum L1 to these chains. These L2 tokens derived from L1 are often referred to as "cross-chain [insert token name]".
For USDC, common token symbols are USDC.e, USDC.b, etc. Although the two tokens are minted by the same entity and have the same price, they are technically different, non-interchangeable tokens and therefore not "interoperable" - while native USDC can be cross-chained through Circle's Cross-Chain Transfer Protocol (CCTP), cross-chain USDC can only cross-chain back to L1 through the standard bridge.
ERC-7281 solves this problem by introducing an ERC-20 extension where deployers of tokens can assign and parameterize different cross-chain sources for them. In the above example, Circle can deploy a universal USDC token on all L2s, where standard cross-chain bridges (such as Circle Mint, Circle CCTP, and other approved cross-chain bridges) are all designated as being able to mint tokens according to their logic. To minimize the risk of minters being hacked, deployers can limit the number of tokens that each minter can mint and destroy in a specific time period - higher limits can be set for more reliable cross-chain bridges (such as standard L2 cross-chain bridges), and lower limits can be set for bridges with centralized consensus.
While ERC-7281 is not the first attempt to create a solution for fungible cross-chain tokens, it may be able to solve problems that exist in cross-chain, such as provider lock-in, loss of sovereignty of token issuers, high costs of bootstrapping liquidity for cross-chain tokens, increased infrastructure overhead, and increased risk of cross-chain failures.
Overview of the cross-chain bridge mechanism
Before we dive into the issue of non-interchangeable cross-chain tokens, it’s important to understand why cross-chain tokens exist in the first place. Therefore, we also need to understand the motivations of cross-chain bridges and how they work — since the cross-chain bridge provider is the party responsible for creating cross-chain versions of tokens.
Cross-chain mechanisms are a means of transferring information between blockchains. In addition to pure monetary information, cross-chain bridges can also pass any other useful information, such as token exchange rates and smart contract status on other chains. However, for the current bridges that interact with users, transferring assets (tokens) from one chain to another is undoubtedly the most common use case.
Methods for facilitating cross-chain asset transfers vary, but the workflow for token cross-chain transfers generally follows one of three high-level patterns:
Locking and Minting Bridge
Users want to cross-chain tokens on their native chain or "source chain" (the chain where they were originally issued) to another chain. Since each chain implements different architectures and protocol designs, the two blockchains are not compatible, which makes it impossible for users to directly transfer tokens from the wallet address of chain A to the wallet address of chain B.
The cross-chain bridge provider hosts the tokens deposited by users on the native chain in a smart contract and creates a "wrapped" token version of the native token through the token contract deployed on the target chain.
When users want to cross chains in the opposite direction (target chain → native chain), they return the wrapped tokens to the cross-chain bridge on the target chain. The target chain verifies this based on the logic in the cross-chain bridge (such as zero-knowledge proof or external arbitration) and releases the native tokens from the escrow account on the native chain.
Destruction and Minting Bridge
Instead of locking tokens in escrow, this approach destroys tokens on the source chain;
The cross-chain bridge will mint an equal amount of tokens on the target chain;
For reverse transfers, cross-chain tokens are destroyed on the target chain and new tokens are minted on the source chain;
This allows cross-chain transfers to be achieved while maintaining the total token supply.
Atomic Swaps
Atomic swaps unlock funds with the same secret value by locking them together, which means that if the secret of either party is compromised, the secret of the other party is also compromised. This gives the swap the property of atomicity.
Atomicity means that an exchange is either fully completed (on both sides) or not completed at all, thus preventing fraud or partial/failed transfers.
Of the above methods, the first one (locking and minting) is currently the most common. The value equivalence between the native token and the corresponding wrapped token minted by the bridge enables users to "transfer" assets across chains and use tokens on a chain different from the chain where they were originally issued.
However, new designs, such as intent-based cross-chain bridges, have become very popular. Intents allow users to express the desired outcome of a transaction (exchange 100 USDC for 100 DAI) rather than outlining specific steps to achieve the outcome. Intents have become a powerful UX unlocking tool because they greatly simplify people’s on-chain experience and make cryptocurrencies easier to use, especially when combined with chain abstraction solutions .
Cross-chain intents allow users to transfer tokens between chains without having to worry about the underlying complexity of a cross-chain bridge. In an intent-based cross-chain bridge, users deposit funds on the source chain and specify the results they expect on the target chain (i.e., their "intention"). Specialized operators called "fillers" or "solvers" can fulfill this intention by sending the requested tokens to users on the target chain in advance. The operator then proves that the transfer has occurred to claim the funds locked on the source chain as compensation.
Some intention-based cross-chain bridges utilize a lock-and-mint mechanism internally. In this case, the bridge mints wrapped tokens that are either sent to fillers that satisfy the user’s intent or directly to the user (if no fillers are involved). However, intention-based cross-chain bridges add an additional layer of efficiency through their solver network, but they still fundamentally rely on the same principles as traditional lock-and-mint bridges.
We can think of each wrapped token (whether created through a traditional cross-chain bridge or an intentional cross-chain bridge) as an "IOU" issued by the cross-chain bridge provider, promising to release a certain number of native tokens from the escrow contract. The value of these wrapped assets is directly related to the cross-chain bridge provider's (perceived) ability to process withdrawal requests from holders of escrow tokens on the native chain.
A cross-chain bridge that is authorized to lock native tokens on the source chain and mint its wrapped tokens on the target chain ensures that the total supply of tokens remains unchanged. For one unit of the native token, exactly one unit of the corresponding wrapped token is minted, and vice versa. If an application accepts wrapped tokens as a medium of exchange or uses wrapped assets as currency, the developers and users of the application will fully trust the cross-chain bridge provider to support the security of the "real" assets of the wrapped tokens.
Why do we need a cross-chain bridge?
By creating cross-chain tokens, cross-chain bridges can trade with synthetic versions of assets on remote chains, which is a powerful feature that enables developers and users to take advantage of the benefits of cross-chain interoperability. These benefits include access to more liquidity, attracting new users, and providing users with flexibility (users can interact with applications from different chains without any obstacles).
To better understand how this works in practice and why it is critical for developers and users alike, let’s take a fictitious decentralized exchange called “BobDEX” as an example. This example will demonstrate how wrapped tokens can enable cross-chain scaling, while highlighting both the benefits and potential complications that can arise:
BobDEX is an automated market maker (AMM) exchange created by Bob on Ethereum, designed to enable trustless exchange between different assets. BobDEX has a native token, BOB, which is both a governance token and a liquidity provider (LP) reward token. In the latter case, BobDEX issues BOB tokens to LPs, making users who provide liquidity to the pool entitled to a portion of the fees paid by DEX users to exchange assets deposited in the pool (calculated as a percentage).
But as BobDEX’s market share has grown significantly, the limitations of Ethereum L1 have hindered its further growth. For example, some users do not want to use BobDEX on Ethereum due to high gas fees and transaction delays; similarly, other users want to get exposure to BOB tokens but do not want to hold native BOB tokens on Ethereum.
To solve this problem, Bob deployed a version of BobDEX (a low-fee, high-throughput Layer 2 Rollup) on Arbitrum, and a wrapped token version of the BOB token (wBOB) on L2 via the Arbitrum-Ethereum bridge. BobDEX on Arbitrum is the same as BobDEX on Ethereum, but it uses wBOB (instead of the native BOB token) as the LP reward and governance token.
For users interacting with BobDEX on Arbitrum (e.g. liquidity providers), the difference in application tokens (wrapped BOB vs. native BOB) is not important. This is because wBOB tokens are backed by actual BOB tokens held in the Arbitrum-Ethereum bridge, so wBOB token holders can easily redeem native BOB ERC-20 tokens on Ethereum by interacting with the bridge contract.
We can see that this situation is a win-win situation for Bob and the user:
1. Bob can attract more users, especially those who want lower gas fees and fast transaction confirmation when trading on BobDEX;
2. LPs can earn returns by providing liquidity to BobDEX without having to deal with Ethereum’s high gas costs and long confirmation times;
3. Investors can purchase wBOB tokens on the market to profit from BOB token price changes without interacting with the BOB ERC-20 contract on Ethereum.
In addition, the benefits of cross-chain bridges are to enhance composable innovation and unlock new use cases that leverage the liquidity of bridged tokens. For example, Alice can create a lending protocol called "AliceLend" on Arbitrum that accepts the borrower's wBOB as collateral to expand the utility of wBOB and create a new lending market.
Lenders who provide liquidity to AliceLend are assured of receiving their deposits: if a user defaults, AliceLend automatically auctions the wBOB tokens deposited as collateral to repay the lender. In this case, the buyer who liquidates the wBOB collateral will assume the role of an LP on BobDEX, with the same guarantee that wBOB tokens can be redeemed for the original BOB tokens at a 1:1 ratio.
Currently, cross-chain bridges provide a viable solution for ensuring interoperability between (previously isolated) Ethereum L2s and facilitating new applications such as cross-chain lending and cross-chain DEX. However, the cross-chain bridge ecosystem is facing limitations that hinder its further growth, such as the non-interchangeability of cross-chain tokens.
Why would cross-chain tokens become non-interchangeable?
The cross-chain workflow of the locking and minting bridge mentioned above may seem simple, but in reality, it requires a lot of engineering and mechanism design work to work properly.
The first challenge is to ensure that the wrapped token version of the cross-chain token is always backed by the native token locked on the source chain. If an attacker mints a cross-chain token on the remote chain without depositing the native token on the source chain, then the attacker can bankrupt the cross-chain bridge protocol by exchanging the (fraudulently minted) wrapped token with the native token on the main chain, and prevent legitimate users (who deposited in the cross-chain bridge contract before the wrapped token was minted) from withdrawing their deposits.
The second challenge is more subtle and stems from the nature of cross-chain tokens: two versions of the same token minted by a cross-chain bridge provider on the same remote chain cannot be exchanged with each other at a 1:1 ratio. To illustrate the problems associated with moving tokens across chains, we can use the example of two users trying to swap tokens across chains through different paths:
Alice bridges USDC from Ethereum to Arbitrum via the standard Arbitrum bridge and receives 200 USDC.e on Arbitrum, while Bob cross-chains USDC to Arbitrum via Axelar and receives 200 axlUSDC on Arbitrum. Alice and Bob reach an agreement where Alice sends 200 USDC to Bob (in exchange for 200 USDT) so that Bob can withdraw 400 USDC to Ethereum.
Bob tries to withdraw 400 USDC through axlUSDC, but only receives 200 USDC, along with a message that the cross-chain bridge protocol can only provide 200 USDC to Bob. Bob is confused by this because wrapped ERC-20 tokens are supposed to be “interchangeable” and there should be no discrepancies that prevent anyone from exchanging ERC-20 tokens 1:1 on any application.
Bob learned a hard lesson from the cross-chain bridge: “interchangeable ERC-20 tokens” does not always mean “you can exchange them 1:1 with other ERC-20 tokens in different applications.” As a result, Bob’s attempt to conduct a risky transaction with Alice (because Alice might not return the tokens) completely failed.
Why can’t Bob withdraw 400 USDC? Because he and Alice received different wrapped versions of the same underlying asset on the target chain. As mentioned above, tokens issued on different chains are incompatible, so the token version of the native token issued on the non-native chain is actually an IOU of the cross-chain bridge protocol, promising to pay the corresponding number of native tokens (depending on the remaining number) when the user wants to bridge back to the native chain of the token.
Therefore, the value of each cross-chain token is tied to the cross-chain bridge provider responsible for holding deposits on the main chain and minting wrapped tokens on the target chain; Bob's cross-chain bridge provider can only pay Bob 200 USDC because this is the amount it can pay from the deposit; Alice's 200 USDC cannot be withdrawn through Bob's cross-chain bridge provider because it never received the deposit or issued an "IOU" to Alice. Alice must withdraw her locked USDC from Arbitrum on Ethereum and bridge it through Bob's cross-chain bridge provider before Bob can access the remaining tokens.
Bob and Alice’s dilemma points to a problem with cross-chain bridging, where multiple competing cross-chain bridge providers mint multiple non-interchangeable versions of tokens for the same underlying asset. Another problem with different ERC-20 tokens of the same asset is that they cannot be traded in a single liquidity pool.
Using the above example, if we have axlUSDC and USDC.e on the chain and want to exchange them for ETH, we must deploy two liquidity pools - ETH/axlUSDC and ETH/USDC.e, which leads to the so-called "liquidity fragmentation" problem - that is, trading pairs that could have been in the same liquidity pool are split into different pools.
The solution to this problem is to have a “standard” version of the token circulating on the target chain, so that Bob and Alice can exchange tokens without each having to withdraw from the bridge to the source chain. Having a standard token on each chain also benefits developers because users can move quickly between ecosystems without having to deal with issues related to token liquidity.
So how do we achieve a standard version of a token on every chain it’s expected to be used or transferred?
Implementing standard tokens across multiple chains
Creating a standard token for each chain is not an easy task, and there are multiple options, each with its own advantages and disadvantages. When creating a standard token for each chain, we usually need to think about who should be trusted to confirm the existence of the IOU (promissory note) behind the value of a specific token. Assuming you are the creator of a token and want the token to be usable and transferable on different chains without encountering interchangeability issues, you will have 4 options:
1. Minting standard tokens through standard Rollup/Sidechain Bridge
2. Minting standard tokens through third-party cross-chain bridge providers
3. Minting standard tokens through the Token Issuer Bridge
4. Direct multi-chain issuance using atomic swaps
The first three options rely on various cross-chain bridge mechanisms to facilitate the movement of tokens across chains. However, as a token creator, you can also choose to bypass cross-chain bridges entirely and issue tokens natively on each supported chain. Under this approach, you do not rely on wrapped tokens or cross-chain bridge infrastructure, but instead maintain independent but coordinated token deployments on each chain - i.e. atomic swaps enable trustless exchange between chains.
However, this approach requires complex infrastructure to maintain cross-chain liquidity and facilitate atomic swaps. Historically, the complexity of managing multiple native deployments has limited the scope of this approach, and it is mainly suitable for large protocols with extensive technical resources.
Minting standard tokens via standard Rollup/sidechain bridge
If a chain has a standard bridge (recognized), the chain can grant the right to mint its protocol cross-chain tokens to users who wish to cross from their native chain. Transactions (deposits and withdrawals) made through a chain's standard bridge are typically verified by the chain's validator set, which provides stronger guarantees that deposits on the main chain reliably support all minted token versions.
While the Standards Bridge is minting the Standards Token version of the token, other token versions will still exist because Standards Bridges often have limitations that do not provide the best experience for users. For example, bridging from Arbitrum/Optimism to Ethereum via Rollup’s Standards Bridge will have a seven-day delay because transactions must be validated by validators (and potentially disputed via fraud proofs if invalid) before the Rollup’s settlement layer (Ethereum) settles a batch of transactions.
Rollup users seeking efficiency must use alternative cross-chain bridge providers that can take ownership of pending Rollup exits and provide instant liquidity on the user’s desired target chain. When such bridges use the traditional lock-and-mint model, we end up with multiple wrapped tokens of tokens issued by different protocols and face the same problems described above.
Sidechains with independent validator sets have lower latency because withdrawals are executed once the block containing the withdrawal transaction is confirmed by the sidechain’s consensus protocol. The Polygon PoS bridge is an example of a standard bridge that connects sidechains to different domains, including Ethereum Rollup and Ethereum mainnet.
Note: We are referring to the original Polygon PoS chain, not the Validium chain that plans to use Ethereum for settlement . Polygon will become L2 once it switches from a sidechain secured by external validators to the Validium chain secured by Ethereum consensus.
Unfortunately, sidechain bridges also share a weakness with the Rollup standard bridge: users can only cross between a pair of connected chains. They cannot cross to other blockchains using the standard bridge. In short, currently, you cannot bridge Arbitrum to Optimism using the Arbitrum cross-chain bridge, nor can you bridge Polygon to Avalanche via the Polygon PoS cross-chain bridge.
Minting Standard Tokens Using Liquidity Bridge
Relying on Rollup’s native bridge to transfer standard tokens brings some problems, such as poor liquidity and delayed asset transfers. To address these issues, some protocols work with liquidity bridges to facilitate fast withdrawals and low-latency cross-chain.
Under this arrangement, an authorized liquidity bridge mints wrapped tokens of a protocol token on a source chain, and then redeems the wrapped tokens for standard tokens of that native token on a target chain through a protocol-owned liquidity pool.
The standard token on the target chain is usually a version minted by the standard sidechain/Rollup bridge, although there are exceptions (mentioned later). For example, the standard token for USDT on Optimism is opUSDT minted by Optimism Bridge.
Each liquidity bridge functions like a DEX with an automated market maker (AMM) to perform swaps between asset pairs stored in different liquidity pools. To incentivize liquidity provision, the AMM pool distributes part of the swap fees to holders who lock standard tokens in the pool contract.
This is similar to the model of Uniswap; the only obvious difference is that the asset pair is usually a liquidity bridge pair between a cross-chain token and a standard token. For example, after a user cross-chains USDT to Optimism through Hop, he will have to exchange it for hUSDT through the huSDT:opUSDT pool on Optimism.
The workflow of cross-chain through liquidity bridge is as follows:
1. Lock the native tokens on the source chain
2. Cross-chain tokens minted on the target chain
3. Exchange cross-chain tokens to standard tokens on the target chain through the AMM pool
4. Send standard tokens to users
The process is similar for all liquidity bridges (Across, Celer, Hop, Stargate, etc.), but to the end user, the process feels like a simple transaction despite the many moving parts involved.
When crossing back to the source chain, the user destroys the standard token or exchanges the standard token for the cross-chain token through an AMM, then destroys the token and provides a proof of destruction receipt. Once confirmed, the user can withdraw the original locked native token. (As with the previous operation, the tedious details of moving the token back to the original chain are hidden from the user and are completely managed by the solver).
The advantage of a liquidity bridge is that it solves the latency problem in Rollup cross-chain bridges; for example, Hop allows specialized institutions called "Bonders" to prove the validity of user withdrawal transactions on L2 and bear the cost of withdrawing funds from Rollup's L1 bridge. Each Bonder runs a full node for the L2 chain and can determine whether the user's exit transaction will eventually be confirmed on L1, thereby reducing the risk of users initiating fraudulent withdrawals and causing losses to Bonders.
Unlike standard bridges, liquid bridges also enable users to move between more chains. For example, Hop allows users to cross-chain between Arbitrum and Optimism without having to withdraw to Ethereum first. Just like fast L2 to L1 bridging, fast L2 to L2 bridging also requires Bonders to run a full node for the source L2 chain to confirm withdrawals and then prepay the minting token fees for users on the target L2 chain, which makes Rollups more composable and significantly improves the user experience.
Of course, there are some drawbacks to liquidity bridges, which will affect the practicality of minting standard tokens on L2/L1 chains using the chain's standard bridge.
Disadvantages of Liquidity Bridge
Slippage
Slippage is the difference between the expected number of tokens received and the actual number of tokens received when interacting with an AMM. Insufficient liquidity of cross-chain assets can also increase slippage; if there is not enough liquidity in the pool to rebalance, large transactions can significantly change prices, causing users to execute swaps at higher prices. In theory, arbitrageurs should correct price differences between different asset pools through trading activity, however, this mechanism may be hindered when arbitrage trades involve tokens with less trading activity or lower value.
This will also affect developers building cross-chain applications, as they must consider edge cases where slippage occurs; a user may be unable to complete a cross-chain operation due to a low number of tokens received on one or more target chains.
To deal with this problem, applications like cross-chain aggregators (which have no way of knowing whether the liquidity bridge has enough liquidity to cover the swap on the target chain without slippage) have adopted a strategy of specifying the maximum slippage tolerance, providing quotes to users by pre-setting the maximum slippage range acceptable to them. While this prevents trades from being rolled back, users will always lose a certain percentage of cross-chain tokens, regardless of the liquidity in the bridge's AMM pool.
Liquidity restrictions
A fundamental challenge facing liquidity bridges is that there must be sufficient liquidity on the target chain. Unlike traditional lock-and-mint, where token minting is directly backed by locked assets, liquidity bridges rely on available tokens in the AMM pool to complete cross-chain transfers. When liquidity drops below a critical threshold, the entire cross-chain mechanism may actually stop functioning.
If liquidity is too low, cross-chain operations may stop entirely, preventing users from completing intended transfers.
Users may be forced to split large transfers into smaller transactions to avoid depleting the liquidity of the pool;
During periods of greater market volatility or stress, liquidity providers may withdraw funds from the pool, which is when the cross-chain bridge function is most needed;
Launching new token pairs becomes particularly challenging because a large amount of initial liquidity is required to make the cross-chain bridge work.
Liquidity requirements create a circular dependency: a bridge needs a lot of liquidity to operate reliably, but attracting liquidity providers requires demonstrating sustained usage and fee generation of the bridge. This chicken-and-egg problem is particularly acute for new tokens or tokens that trade less frequently, which may struggle to maintain sufficient liquidity on multiple chains.
Mismatched incentives
The role of a liquidity bridge is that it can cover the exchange from a cross-chain token to a standard token on the target chain without causing excessive slippage for users; from the user's perspective, the Gas cost of interacting with the bridge also determines the value of the liquidity bridge. Therefore, cross-chain aggregators and token-issuing project teams will prioritize cross-chain bridges based on liquidity and transaction costs.
While this ensures a better user experience for cross-chain project tokens, or for users who use cross-chain aggregators to send tokens across chains, selecting cross-chain bridges based on liquidity puts cross-chain bridges that cannot spend on LP incentives at a disadvantage. Additionally, basing the competition solely on transaction fees favors cross-chain bridges that take a centralized approach to reduce operating costs and can charge lower fees for cross-chain transactions. In both cases, cross-chain bridges are not competing on the most important metric: security.
Additionally, liquidity bridges are not conducive to long-tail assets with low trading activity (making them less likely to attract liquidity providers). Issuers of long-tail tokens (or new tokens with low cross-chain volume) must either build AMM pools and bootstrap liquidity to cover swaps between the native token (crossed via the liquidity bridge) and the standard token of the issuer's token, or work with cross-chain bridge providers to increase financial incentives for LPs to provide liquidity for that asset.
Poor cross-chain user experience
Liquidity bridges are an improvement over standard cross-chain bridges, but they are not without UX issues. In addition to the slippage of cross-chain swaps, users may not be able to complete cross-chain transactions on the target chain immediately because the bridge does not have enough liquidity to cover transactions with standard tokens on the target chain. When the user's token swap message arrives on the target chain, the bridge has no way of knowing how much liquidity the asset pair will have, so this situation is mostly unavoidable.
In this case, the user has two options (neither of which is ideal):
Wait until the bridge has enough liquidity to complete the swap and withdraw the standard token. This is less than ideal because there is latency in cross-chain transactions, and because pool liquidity can change arbitrarily in a very short period of time, users have no way of knowing whether they will receive the same amount of tokens that were originally quoted.
Receive a cross-chain bridge’s proprietary token (e.g., hUSDT for Hop Bridge). This is suboptimal, as most applications prefer to integrate with a standard token for their native token (e.g., opUSDT minted by Optimism Bridge) and may not accept a user’s wrapped asset.
Minting standard tokens through third-party cross-chain bridges
Multi-chain DApps can solve the problem of cross-chain token non-interchangeability by choosing a single cross-chain bridge, that is, minting a standard token of the DApp token on each chain where the DApp is deployed. Like the way the standard bridge mints project tokens, this approach requires mapping the tokens minted on the remote chain to the token contract deployed on the project's main chain to ensure that the global token supply remains consistent. The cross-chain bridge provider must track the minting and destruction of tokens and ensure that these operations are synchronized with the token supply on the main chain.
On this basis, the problem of cross-chain tokens being non-interchangeable is solved; as long as users cross-chain through approved cross-chain bridge providers, they can always exchange with other cross-chain tokens at a 1:1 ratio. In addition, this approach also solves the liquidity-based cross-chain problem in the standard bridge model:
Users will not suffer slippage losses in cross-chain transactions because cross-chain bridge providers do not need to convert their cross-chain tokens into standard tokens through AMM - the tokens supported by cross-chain bridge providers are the standard token versions on each chain. The value of these standard tokens is linked to the value of the tokens locked by the provider on the native chain.
Users will experience almost no delay when crossing chains, as the cross-chain bridge provider can immediately start minting wrapped tokens on the target chain after receiving the mint() message.
Developers can outsource the management of multi-chain token deployments to cross-chain bridge providers without having to worry about launching AMM liquidity or liquidity provision incentive programs.
Currently, some examples of token standards for single cross-chain bridge providers include LayerZero's All-Chain Universal Token (OFT), Axelar's Inter-Chain Token Service (ITS), Celer's xAsset, and Multichain's anyAsset. It is worth mentioning that these examples are essentially proprietary tokens and are not compatible with cross-chain tokens of the same token sent through different cross-chain bridge providers. Therefore, this detail also highlights some problems with this cross-chain token processing method, as follows:
Provider lock-in
Loss of agreement sovereignty
High risk of bridging failure
Custom functionality of the target chain’s tokens is lost
Limited to chains supported by the provider
Inability to maintain the same token addresses on all desired chains, which could compromise user security or make them vulnerable to phishing attacks
Disadvantages of using standard third-party cross-chain bridges
Provider lock-in
Choosing a single cross-chain bridge provider to create a standard token on one or more chains can expose developers to the risk of provider lock-in. Since each cross-chain bridge provider creates a proprietary token that is only compatible with its infrastructure (and integrated ecosystem projects), a single cross-chain bridge provider effectively locks token issuers into a specific cross-chain bridge service, without the ability to switch to another cross-chain bridge at will in the future.
Although it is possible to switch cross-chain bridge providers, the cost of switching is high enough to prevent most projects from choosing this path.
For example, suppose a developer (let’s call him Bob) issues a token (BobToken) on Ethereum and chooses LayerZero OFT to mint the standard version of BobToken on Optimism, Arbitrum, and Base. BobToken has a fixed supply of 1,000,000, and cross-chain tokens minted by LayerZero account for 50% of the total supply of BobToken in circulation.
At first, business goes smoothly until Bob decides to bridge BobToken through competing cross-chain services such as Axelar. However, Bob cannot simply say: "I'm going to switch to Axelar ITS to mint standard tokens of BobToken on Optimism, Base, and Arbitrum"; since OFT tokens and ITS tokens are incompatible, Bob may cause trouble for both new and old users because the two BobTokens may not be interchangeable (reintroducing the problem we described earlier here). At the same time, applications that integrate with the LayerZero version of BobToken may not accept the Axelar version of BobToken as a substitute, which will lead to the dispersion of liquidity on various L2 chains where BobToken competing tokens coexist.
So, if Bob has to make the switch, what does he need to do?
First, Bob needs to convince users to send transactions to unwrap the BobToken wrapped tokens minted through LayerZero, which destroys the cross-chain OFT tokens and unlocks the BobToken on Ethereum. Users can then lock tokens using Axelar on Ethereum and receive new standard tokens of BobToken (mapped to the token contract supply on Ethereum) on the target chain. This process is costly for the DAO project management team and generates huge coordination and operational overhead, so sticking with the original provider is usually the safest option.
On the other hand, developers like Bob may also be trapped because provider lock-in will prevent developers from switching if the cross-chain bridge provider fails to comply with the terms of the agreement, has a limited feature set, lacks broad ecosystem integration, has a poor user experience, etc. During this period, the cross-chain bridge provider can also do arbitrary things, such as limiting the user rate of cross-chain BobToken without clear reasons, increasing cross-chain fees, or even censoring cross-chain operations.
Loss of agreement sovereignty
The conclusion section above about provider lock-in highlights another problem with using standard third-party cross-chain bridges: token issuers sacrifice control of standard cross-chain tokens for greater convenience and improved user experience. For example, BobToken on Ethereum is completely under Bob’s control because he controls the underlying ERC-20 token contract, but BobToken on Optimism, Arbitrum, and Base is controlled by LayerZero, which owns the OFT contract that issues BobToken standard tokens on these blockchains.
While Bob may expect LayerZero to align the standard token with the original design of the native token, this is not always the case. In the worst case, BobToken on Ethereum may behave very differently from BobToken on Optimism because the cross-chain bridge provider implements a completely different version of the token contract - which also causes problems for users of the protocol, as the goals and interests of the protocol developers and the cross-chain bridge provider may diverge.
High risk of cross-chain bridge failure
In the first solution, tokens are cross-chained via a standard bridge on each chain, and the risk to the token issuer from a vulnerability affecting one cross-chain bridge is limited to that bridge. For example, suppose a hacker manages to compromise a liquidity bridge and mints an unlimited number of wrapped tokens without depositing collateral. In this case, it can only extract the maximum available liquidity of the wrapped assets in the liquidity pool (e.g. mint cUSDT on Optimism → exchange cUSDT for standard opUSDT → withdraw opUSDT to Ethereum via a fast cross-chain → exchange for native USDT on Ethereum).
In the third-party cross-chain bridge model, the risk to the token issuer caused by a vulnerability affecting the partner cross-chain bridge is equivalent to the total amount of tokens minted by the attacker on the remote chain deployed by the affected bridge. This is entirely possible because the standard tokens on one chain can be exchanged 1:1 for the standard tokens issued on the other chain, as shown below:
Suppose an attacker compromises a third-party cross-chain bridge on chain B and mints 1,000 tokens (the tokens were originally issued on chain A) without depositing collateral. The attacker's token on chain B is not mapped to the main chain contract, so it cannot be withdrawn from chain A. However, it can cross-chain to chain C and exchange 1,000 chain B tokens for 1,000 chain C tokens - remember, these standard cross-chain tokens are all compatible and interchangeable because they come from the same cross-chain bridge service. Chain C tokens are mapped to the main chain contract because they are legitimately minted by users who locked tokens on chain A (the main chain of the token), which allows the attacker to destroy the tokens on chain C and withdraw the native tokens on chain A. Finally, the attacker can complete the attack by trading tokens through CEX.
Custom functionality of the target chain’s tokens is lost
When using a third-party cross-chain bridge, token issuers also typically lose the ability to implement custom functionality or token behaviors that existed in their original deployment, such as voting delegation (ZK), rebasing mechanisms (stETH, USDM), transfer fee functionality, blacklist and whitelist functionality (USDT, USDC), suspendable transfers, and special minting rules or permissions. These common token features are typically stripped out because cross-chain bridge providers often use standardized ERC-20 implementation contracts, which may not support specialized functionality that exists in the original token implementation.
The lack of these features will lead to inconsistent operation of tokens on different chains, which may harm integrated applications that rely on these specific custom features. Although promoting the standardization of cross-chain tokens may seem to simplify operations from the perspective of cross-chain bridge providers, in fact, this practice weakens the original functionality of tokens and may hinder issuers from maintaining consistent token behavior across the entire multi-chain ecosystem covered by their applications.
Limited supported chains
Token issuers rely on the network coverage and expansion plans of their chosen cross-chain bridge provider. If the cross-chain bridge provider does not support the specific blockchain network that the token issuer wants to expand to, they will face two undesirable options:
Waiting for cross-chain bridge providers to add support for the desired chain, which may take a long time or may never happen due to high integration costs (e.g. the EVM inequality of ZKsync Era caused many Dapps to never be deployed on it);
Use a different cross-chain bridge provider for that specific chain, but this would reintroduce the problem of non-fungible tokens and liquidity fragmentation.
This limitation could severely impact the protocol’s growth strategy and ability to attract new users on emerging chains. It should be noted that cross-chain bridge providers may prioritize supporting popular chains while ignoring small or new networks that may be strategically important to token issuers.
Cross-chain token addresses are inconsistent
Due to the particularity of the technology stack (for example, CREATE2 is not supported) , third-party cross-chain bridge providers may use different addresses to deploy cross-chain tokens on each chain. The lack of address consistency has caused many user experience issues:
Security risks: Users must verify different token addresses on each chain, increasing the risk of interacting with fraudulent tokens;
Integration complexity: Developers must maintain a list of valid token addresses for each network;
Increased phishing risk: With no consistent addresses to check, bad actors can more easily defraud users with fake tokens.
Issue standard tokens through the token issuance bridge
In addition to the solutions mentioned above, if developers want to maintain maximum control over the cross-chain deployment of project tokens, they can manage the issuance of standard token versions of tokens on the remote chain. This is described as a "trusted token issuer" because the value of each cross-chain token version is closely linked to the value of the tokens locked by the protocol responsible for issuing the original version of the token on the source chain.
For this approach to work, token issuers must build infrastructure to manage the minting and burning of tokens across chains (while ensuring that global supply remains in sync via standard mappings).
Well-known examples of standard tokens issued by token creators (native tokens) are MakerDAO’s Teleport and Circle’s Cross-Chain Transfer Protocol (CCTP) . Teleport allows users to move standard DAI between Ethereum and various Ethereum rollups. DAI is destroyed on one chain and can be minted on the target chain. CCTP functions similarly and enables cross-chain transfers of native USDC (issued by Circle) through a destruction and minting mechanism. In both cases, the token issuer controls the minting and destruction of the standard token.
This approach provides the protocol with full control over cross-chain tokens. It solves the problem of non-interchangeability of the same token in the most efficient way - there is only one standard version of the token (minted by the issuer on the target chain), which ensures that users have the same experience when using the token in every ecosystem supported by the token issuer.
Using this approach, applications can also eliminate liquidity fragmentation issues caused by unofficial cross-chain tokens in the same ecosystem. Developers can also build more robust cross-chain applications (e.g., cross-chain swaps and cross-chain lending) because the standard token issuer bridge allows capital-efficient, seamless, and secure token transfers between chains.
Of course, this type of solution also has some disadvantages. This model is only suitable for projects that have sufficient capital to deploy standard tokens across chains and maintain the infrastructure (oracle, guardian, etc.) required for cross-chain minting and destruction. At the same time, this also brings some less than ideal effects, which is to closely integrate the security of cross-chain assets with the security model of the protocol.
Objectively speaking, this relationship (between the cross-chain version of the protocol token and the security of the protocol) is friendly, because the security of the native token supporting the standard token version already depends on the security of the protocol, so users and external developers do not take on new trust assumptions. This is especially true for stablecoin bridges operated by issuers such as Circle and Maker (now Sky) - users already trust that the stablecoin issuer has enough assets to pay the cost of exchanging fiat currency for stablecoins, so trusting the security of the stablecoin bridge is not a difficult task.
However, it also represents a central point of failure - if the bridge infrastructure of the token issuer is compromised, the value of all standard tokens circulating in the multi-chain ecosystem will be threatened. This also means that only centralized custodians (such as Circle in USDC) can truly realize this model of issuing standard cross-chain tokens.
Final Thoughts
Cross-chain asset interchangeability is undoubtedly an important part of Rollup interoperability, affecting the user experience of asset transfer between different chains. At the same time, the ability of tokens to remain interchangeable when crossing chains to remote chains will also affect developer behavior because certain use cases rely on this feature.
To solve the problem of non-interchangeable cross-chain tokens, the industry has proposed different solutions, including minting standard tokens through native (implemented) bridges, using dedicated third-party bridges to mint standard tokens across multiple chains, and using protocol-owned bridges to facilitate the movement of tokens and maintain interchangeability.
Although these methods solve many specific problems, they cannot solve all problems, and using them to achieve cross-chain asset interchangeability requires making some less than ideal trade-offs. So, can we find a better way? The answer is yes.
We believe that ERC-7281 is a new cross-chain asset interchangeability solution that enables protocols to efficiently deploy standard tokens on multiple chains without sacrificing security, sovereignty, or user experience.
The unique design of ERC-7281 allows multiple (whitelisted) cross-chain bridges to mint standard versions of protocol tokens on each supported chain, while allowing protocol developers to dynamically adjust minting limits based on each cross-chain bridge. This feature solves many issues associated with historical proposals for multi-chain standard tokens, including liquidity fragmentation, incentive alignment, user experience issues, cross-chain bridge security, and customizability of cross-chain tokens.
Therefore, in the next part of the Cross-Chain Asset Fungibility Report, we will take a detailed look at ERC-7281 (also known as xERC-20), analyze xERC-20’s multi-chain standard token approach by comparing it to other multi-chain standard token designs, and dive into how the xERC-20 token standard benefits developers and users.
To be continued.
