Written by: Alex Hook, Emmanuel Awosika
Translated by: Glendon, Techub News
This report is divided into two parts. Part 1 outlines the challenges faced in the cross-chain space, such as the issue of non-fungibility of cross-chain tokens, and analyzes the current major solutions; Part 2 will explore the sovereign cross-chain token standard ERC-7281 and analyze the benefits and potential drawbacks of implementing ERC-7281 for users, developers, infrastructure providers, and other participants in the Ethereum ecosystem.
Currently, cross-chain operations still face numerous challenges due to the inherent limitations of blockchain interoperability methods (such as cross-chain bridges). For example, cross-chain bridges may have security vulnerabilities (losses from cross-chain attacks have exceeded $2.5 billion), or they may face issues of slow speeds and high costs, as well as limited functionality. Even more concerning, these issues may coexist within the same cross-chain bridge.
In addition, there is a core dilemma in the cross-chain space: when transferring fungible tokens (such as ERC-20 standard tokens) across different chains via different cross-chain protocols, these tokens become non-fungible, thus losing their function as transferable assets. In this article, we will explore a solution aimed at ensuring the fungibility of tokens across chains, regardless of where the original contract resides: the sovereign cross-chain token standard ERC-7281.
ERC-7281 (also known as xERC-20) is an extension of ERC-20, which is a standard for creating fungible tokens on Ethereum. ERC-7281 allows multiple bridges approved by the token issuer to mint and burn standard token versions of ERC-20 tokens on remote chains, ensuring that users receive a fungible version of the token (i.e., the two tokens can be exchanged 1:1) when bridging ERC-20 tokens, even if these tokens are sent across chains via different paths/bridges.
Importantly, protocols adopting ERC-7281 can maintain control over cross-chain tokens (unlike the current bridges that control the state of cross-chain tokens) and can limit the rate of minting operations, thereby reducing the risk of failures in cross-chain bridges.
Taking USDC as an example, it can be observed that there is non-fungibility between theoretically identical ERC-20 tokens on different chains. In Ethereum L2 networks (such as Arbitrum, Base, Optimism), standard bridges (Canonical Bridge) are typically used to transfer popular ERC-20 tokens from Ethereum L1 to these chains. These L2 tokens originating from L1 are often referred to as "cross-chain [insert token name]."
For USDC, common token symbols include USDC.e, USDC.b, etc. Although these two tokens are minted by the same entity and have the same price, they are technically different, non-fungible tokens, and thus are not "interoperable"—while native USDC can be transferred across chains via Circle's Cross-Chain Transfer Protocol (CCTP), cross-chain USDC can only be bridged back to L1 through standard bridges.
ERC-7281 addresses this issue by introducing an ERC-20 extension, where the token deployer can assign and parameterize different cross-chain sources. In the aforementioned example, Circle can deploy a universal USDC token across all L2s, with standard cross-chain bridges (such as Circle Mint, Circle CCTP, and other approved cross-chain bridges) designated as capable of minting tokens according to their logic. To minimize the risk of minting being compromised by hackers, deployers can limit the number of tokens each minter can mint and burn within a specific time frame—higher limits can be set for more reliable cross-chain bridges (like standard L2 cross-chain bridges), while 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 address existing issues in cross-chain operations, such as provider lock-in, loss of sovereignty for token issuers, high costs of guiding liquidity for cross-chain tokens, increased infrastructure overhead, and heightened risks of cross-chain failures.
Overview of Cross-Chain Bridge Mechanisms
Before delving into the issue of non-fungible cross-chain tokens, it is necessary to understand the reasons for the existence of cross-chain tokens, and thus we need to comprehend the motivations and operational mechanisms of cross-chain bridges—because cross-chain bridge providers are the parties responsible for creating versions of cross-chain tokens.
Cross-chain mechanisms are means of transmitting information between blockchains. In addition to purely monetary information, cross-chain bridges can also convey any other useful information, such as token exchange rates and smart contract states on other chains. However, for the bridges currently interacting 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 typically follows one of the following three high-level patterns:
Lock and Mint Bridge
Users wish to transfer tokens from 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, these two blockchains are incompatible, preventing users from directly transferring tokens from a wallet address on chain A to a wallet address on chain B.
The cross-chain bridge provider will hold the tokens deposited by the user on the native chain in a smart contract and create a "wrapped" token version of the native token by deploying a token contract on the target chain.
When users wish to reverse the cross-chain (target chain → native chain), they return the wrapped tokens to the cross-chain bridge on the target chain, which will verify this based on the logic in the cross-chain bridge (such as zero-knowledge proofs or external arbitration) and release the native tokens from the custody account on the native chain.
Burn and Mint Bridge
This method does not lock tokens in custody but instead burns the tokens on the source chain;
The cross-chain bridge will mint an equivalent amount of tokens on the target chain;
For reverse transfers, the cross-chain tokens are burned on the target chain, and new tokens are minted on the source chain;
This can maintain the total supply of tokens while achieving cross-chain transfers.
Atomic Swaps
Atomic swaps unlock funds by mutually locking them with the same secret value, meaning that if the secret of either party is leaked, the secret of the other party will also be leaked. This endows the swap with the property of atomicity.
Atomicity means that the swap either completes fully (on both sides) or does not complete at all, thus preventing fraud or partial/failed transfers.
Among the aforementioned methods, the first one (lock and mint) is currently the most common. The value equivalence between the native tokens and the corresponding wrapped tokens minted by the bridge allows users to "transfer" assets across chains and use the tokens on a chain different from the one 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 expected outcome of a transaction (e.g., exchanging 100 USDC for 100 DAI) rather than outlining the specific steps to achieve that outcome. "Intents" have become a powerful user experience unlocking tool, as they greatly simplify the 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 worrying about the underlying complexities of cross-chain bridges. In intent-based cross-chain bridges, users deposit funds on the source chain and specify the expected outcome on the target chain (i.e., their "intent"). Specialized operators known as "Fillers" or "Solvers" can fulfill this intent by preemptively sending the requested tokens to users on the target chain. Subsequently, the operators prove that the transfer has occurred to claim the funds locked on the source chain as compensation.
Some intent-based cross-chain bridges internally utilize the lock and mint mechanism. In this case, the cross-chain bridge mints the wrapped tokens, which are either sent to the fillers who fulfill the user's intent or directly sent to the user (if no fillers are involved). However, intent-based cross-chain bridges add an extra layer of efficiency through their solver networks, but they fundamentally still rely on the same principles as traditional lock and mint bridges.
We can view each wrapped token (whether created through traditional cross-chain bridges or intent-based cross-chain bridges) as an "IOU" issued by the cross-chain bridge provider, promising to release a certain amount of native tokens from the custody contract. The value of these wrapped assets is directly related to the cross-chain bridge provider's (perceived) ability to handle withdrawal requests from holders of the native tokens in custody on the native chain.
Cross-chain bridges authorized to lock native tokens on the source chain and mint their wrapped tokens on the target chain can ensure that the total supply of tokens remains unchanged. For one unit of 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 that application will fully trust the cross-chain bridge provider to secure the "real" assets of the wrapped tokens.
Why Do We Need Cross-Chain Bridges?
By creating cross-chain tokens, cross-chain bridges can trade with synthetic versions of assets on remote chains, a powerful feature that allows both developers and users to leverage the advantages of cross-chain interoperability. These advantages include gaining more liquidity, attracting new users, and providing flexibility for users (who can interact seamlessly with applications from different chains).
To better understand how this works in practice and why it is crucial for both developers and users, let’s illustrate with a fictional decentralized exchange called "BobDEX." This example will demonstrate how wrapped tokens enable cross-chain scalability while highlighting the potential benefits and complexities that may arise:
BobDEX is an automated market maker (AMM) exchange created by Bob on Ethereum, designed for trustless exchanges between different assets. BobDEX has a native token, BOB, which serves as both a governance token and a liquidity provider (LP) reward token. In the latter case, BobDEX issues BOB tokens to LPs, allowing users who provide liquidity to the pool to earn a portion (calculated as a percentage) of the fees paid by DEX users for exchanging assets stored in the pool.
However, as BobDEX's market share significantly grows, the limitations of Ethereum L1 hinder its further expansion. For example, due to high gas fees and transaction delays, some users are reluctant to use BobDEX on Ethereum; similarly, other users want to access BOB tokens but do not wish to hold native BOB tokens on Ethereum.
To address this issue, Bob deployed a version of BobDEX on Arbitrum (a low-fee, high-throughput Layer 2 Rollup) and deployed a wrapped token version of BOB (wBOB) on L2 through the Arbitrum-Ethereum bridge. The BobDEX on Arbitrum is the same as the one 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 (such as liquidity providers), the difference in token applications (wrapped BOB vs. native BOB) is not significant. This is because the wBOB token is backed by the actual BOB tokens held in the Arbitrum-Ethereum bridge, allowing wBOB token holders to 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 for both Bob and the users:
Bob can attract more users, especially those looking for lower gas fees and faster transaction confirmations when trading on BobDEX;
LPs can earn rewards by providing liquidity to BobDEX without dealing with the high gas costs and longer confirmation times on Ethereum;
Investors can purchase wBOB tokens on the market, profiting from price changes in BOB tokens without interacting with the BOB ERC-20 contract on Ethereum.
In addition, the benefits of cross-chain bridges also lie in enhancing composable innovation and unlocking new use cases for utilizing bridged token liquidity. For example, Alice can create a lending protocol called "AliceLend" on Arbitrum that accepts wBOB from borrowers as collateral, expanding the utility of wBOB and creating a new lending market.
Lenders providing liquidity to AliceLend can be confident in receiving their deposits: if a user defaults, AliceLend will automatically auction off the wBOB tokens deposited as collateral to repay the lenders. In this case, buyers liquidating the wBOB collateral will take on the role of LPs on BobDEX, with the same assurance that wBOB tokens can be exchanged for the original BOB tokens at a 1:1 ratio.
Currently, cross-chain bridges provide viable solutions to ensure interoperability between previously isolated Ethereum L2s and facilitate new applications (such as cross-chain lending and cross-chain DEX). However, the cross-chain bridge ecosystem faces limitations that hinder its further growth, such as the issue of non-fungibility of cross-chain tokens.
Why Do Cross-Chain Tokens Become Non-Fungible?
The cross-chain workflow of lock and mint bridges mentioned above may seem straightforward, but in reality, it requires significant engineering and mechanism design work to function properly.
The first challenge is ensuring that the wrapped token version of the cross-chain token is always backed by the native tokens locked on the source chain. If an attacker mints cross-chain tokens on a remote chain without depositing native tokens on the source chain, the attacker could bankrupt the cross-chain bridge protocol by exchanging (fraudulently minted) wrapped tokens for native tokens on the main chain, preventing legitimate users (who deposited in the cross-chain bridge contract before minting wrapped tokens) from withdrawing their deposits.
The second challenge is more subtle and arises from the nature of cross-chain tokens: the two versions of the same token minted by cross-chain bridge providers on the same remote chain cannot be exchanged on a 1:1 basis. To illustrate the issues related to moving tokens across chains, we can use an example of two users attempting to exchange tokens across chains via different paths:
Alice bridges USDC from Ethereum to Arbitrum through the standard 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 agree that Alice will send 200 USDC to Bob (in exchange for 200 USDT) so that Bob can withdraw 400 USDC to Ethereum.
Bob attempts to withdraw 400 USDC using axlUSDC but only receives 200 USDC, along with a message stating that the cross-chain bridge protocol can only provide Bob with 200 USDC. Bob is confused because the wrapped ERC-20 tokens should be "fungible," and there should be no discrepancies preventing anyone from exchanging ERC-20 tokens at a 1:1 ratio across any application.
Bob learns a profound lesson from the cross-chain bridge: "fungible ERC-20 tokens" do not always mean "you can exchange them at a 1:1 ratio with other ERC-20 tokens in different applications." Thus, Bob's attempt to engage in a risky trade with Alice (since Alice might not return the tokens) completely fails.
Why couldn't Bob withdraw 400 USDC? Because he and Alice received different wrapped versions of the same underlying asset on the target chain, as mentioned earlier, tokens issued on different chains are incompatible. Therefore, the token version of the native token issued on a non-native chain is essentially an IOU from the cross-chain bridge protocol, promising to pay the corresponding amount of native tokens when the user wishes to bridge back to the native chain (depending on the remaining amount).
Thus, 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 that is the amount it can pay from the deposits; 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.
The predicament of Bob and Alice highlights an issue with cross-chain bridging, namely that multiple competing cross-chain bridge providers mint multiple non-fungible token versions for the same underlying asset. Additionally, different ERC-20 tokens for the same asset cannot be traded within a single liquidity pool.
Using the previous example, if we have axlUSDC and USDC.e on-chain and want to exchange them for ETH, we must deploy two liquidity pools—ETH/axlUSDC and ETH/USDC.e—leading to the so-called "liquidity fragmentation" problem, where trading pairs that could have been in the same liquidity pool are split into different pools.
To address this issue, the solution is to circulate a "standard" version of the token on the target chain, allowing Bob and Alice to exchange tokens without everyone needing to withdraw from the source chain's bridge. Having a standard token on each chain also benefits developers, as users can move quickly between ecosystems without dealing with issues related to token liquidity.
So, how do we achieve a standard version of the token on each chain where it is 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 various options, each with its pros and cons. When creating standard tokens for each chain, we typically need to consider whom to trust to confirm the existence of the IOU (promissory note) behind the specific token's value. Suppose you are the creator of the token and want it to be usable and transferable across different chains without encountering fungibility issues; you will have four options:
Mint standard tokens through a standard Rollup/sidechain bridge.
Mint standard tokens through a third-party cross-chain bridge provider.
Mint standard tokens through the token issuer's bridge.
Use atomic swaps for direct multi-chain issuance.
The first three options rely on various cross-chain bridge mechanisms to facilitate the cross-chain movement of tokens. However, as the token creator, you can also choose to completely bypass cross-chain bridges and natively issue tokens on each supported chain. In this approach, you do not rely on wrapped tokens or cross-chain bridge infrastructure but maintain independent yet coordinated token deployments across various chains—meaning atomic swaps can enable trustless exchanges between chains.
However, this approach requires complex infrastructure to maintain cross-chain liquidity and facilitate atomic swaps. From past experiences, the complexity of managing multiple native deployments limits the applicability of this method, making it primarily suitable for large protocols with substantial technical resources.
Minting Standard Tokens Through Standard Rollup/Sidechain Bridges
If a chain has a standard bridge (recognized), it can grant users wishing to cross-chain from the native chain the right to mint its protocol's cross-chain tokens. Transactions (deposits and withdrawals) conducted through the chain's standard bridge are typically validated by the chain's validator set, providing a stronger assurance that deposits on the main chain reliably back all minted token versions.
Although the standard bridge is minting a standard token version, other token versions will still exist because standard bridges often have limitations that prevent them from providing the best experience for users. For example, bridging from Arbitrum/Optimism to Ethereum through the Rollup's standard bridge incurs a seven-day delay because transactions must be validated by the validators (which can be disputed through fraud proofs), after which the Rollup's settlement layer (Ethereum) will settle a batch of transactions.
Efficiency-seeking Rollup users must rely on other cross-chain bridge providers that can take ownership of pending Rollup exits and provide instant liquidity on the desired target chain. When such bridges use the traditional lock-and-mint model, we ultimately end up with multiple wrapped tokens issued by different protocols, facing the same issues described earlier.
Sidechains with independent validator sets have lower latency because once the consensus protocol of the sidechain confirms a block containing withdrawal transactions, the withdrawals are executed. The Polygon PoS bridge is an example of a standard bridge connecting sidechains to different domains (including Ethereum Rollups and the Ethereum mainnet).
Note: We refer to the original Polygon PoS chain, not the Validium chain planned to use Ethereum for settlement. Once switching from a sidechain protected by external validators to a Validium chain protected by Ethereum consensus, Polygon will become L2._
Unfortunately, sidechain bridges also share a common weakness with Rollup standard bridges: users can only cross-chain between a pair of connected chains. They cannot use the standard bridge to cross-chain to other blockchains. Simply put, currently, you cannot use the Arbitrum cross-chain bridge to bridge Arbitrum to Optimism, nor can you bridge Polygon to Avalanche through the Polygon PoS cross-chain bridge.
Minting Standard Tokens Using Liquidity Bridges
Relying on the native bridges of Rollups to transfer standard tokens brings some issues, such as poor liquidity and asset transfer delays. To address these problems, some protocols collaborate with liquidity bridges to facilitate rapid withdrawals and low-latency cross-chain transfers.
In this arrangement, authorized liquidity bridges mint wrapped tokens of the protocol's tokens on the source chain, and then exchange the wrapped tokens for the standard tokens of the native tokens on the target chain through liquidity pools owned by the protocol.
The standard tokens on the target chain are typically versions minted by standard sidechain/Rollup bridges, although exceptions exist (which will be mentioned later). For example, the standard token for USDT on Optimism is opUSDT, minted by the Optimism Bridge.
Each liquidity bridge functions similarly to a DEX with an automated market maker (AMM) for executing exchanges between asset pairs stored in different liquidity pools. To incentivize liquidity provision, AMM pools allocate a portion of the exchange fees to holders of standard tokens locked in the pool contract.
This is similar to the model of Uniswap; the only notable difference is that the asset pairs are typically exchanges between cross-chain tokens and standard tokens in the liquidity bridge. For instance, after a user bridges USDT to Optimism via Hop, they must exchange hUSDT through the huSDT:opUSDT pool on Optimism.
The workflow for cross-chain transfers through liquidity bridges is as follows:
Lock native tokens on the source chain.
Mint cross-chain tokens of the native tokens on the target chain.
Exchange cross-chain tokens for standard tokens on the target chain through the AMM pool.
Send standard tokens to the user.
The processes of all liquidity bridges (Across, Celer, Hop, Stargate, etc.) are similar, but for end users, despite involving many moving parts, this process feels like a simple transaction.
When crossing back to the source chain, users will either burn the standard tokens or exchange the standard tokens for cross-chain tokens through the AMM, then burn that token and provide proof of destruction receipt. Once confirmed, users can withdraw the originally locked native tokens. (As with previous operations, the cumbersome details of moving tokens back to the original chain are hidden from users and are entirely managed by the solver).
The advantage of liquidity bridges is that they solve the latency issues present in Rollup cross-chain bridges; for example, Hop allows specialized entities known as "Bonders" to prove the validity of user withdrawal transactions on L2 and bear the costs of withdrawing from the Rollup's L1 bridge. Each Bonder runs a full node for the L2 chain and can determine whether the user's exit transaction will ultimately be confirmed on L1, thereby reducing the risk of users initiating fraudulent withdrawals that could cause losses for the Bonder.
Unlike standard bridges, liquidity bridges also enable users to move between more chains. For instance, Hop allows users to cross-chain between Arbitrum and Optimism without first withdrawing to Ethereum. 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 costs for tokens on the target L2 chain for users, enhancing the composability between Rollups and significantly improving the user experience.
Of course, liquidity bridges also have some drawbacks that affect the practicality of using standard bridges to mint standard tokens on L2/L1 chains.
Drawbacks of Liquidity Bridges
Slippage
Slippage refers to the difference between the expected amount of tokens received when interacting with an AMM and the actual amount received. Insufficient liquidity for cross-chain assets can also increase slippage; if there is not enough liquidity in the pool to rebalance, large trades may significantly alter prices, causing users to execute swap transactions at higher prices. Theoretically, arbitrageurs should correct price discrepancies between different asset pools through trading activity; however, this mechanism may be hindered when arbitrage trades involve tokens with low trading activity or value.
Moreover, this also affects developers building cross-chain applications, as they must consider edge cases where slippage occurs; users may be unable to complete cross-chain operations due to receiving fewer tokens on one or more target chains.
To address this issue, applications like cross-chain aggregators (which cannot know whether liquidity bridges have enough liquidity to cover exchanges on the target chain without slippage) adopt a strategy of specifying a maximum slippage tolerance, providing quotes based on a pre-set maximum slippage range acceptable to users. While this can prevent transaction rollbacks, users will always incur a certain percentage loss of cross-chain tokens, regardless of the liquidity in the bridge's AMM pool.
Liquidity Constraints
A fundamental challenge faced by 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 AMM pools to complete cross-chain transfers. When liquidity falls below a critical threshold, the entire cross-chain mechanism may effectively cease to operate.
If liquidity is too low, cross-chain operations may completely stop, preventing users from completing their intended transfers;
Users may be forced to split large transfers into smaller transactions to avoid depleting the liquidity of the funds pool;
During periods of high market volatility or stress, liquidity providers may withdraw funds from the pool, which is precisely when cross-chain bridge functionality is most needed;
Initiating new token pairs becomes particularly challenging, as substantial initial liquidity is required to get the cross-chain bridge operational.
Liquidity requirements create a cycle of dependency: bridges need substantial liquidity to operate reliably, but attracting liquidity providers requires demonstrating ongoing usage and fee generation of the bridge. This "chicken or egg" problem is particularly severe for new tokens or those with low trading frequency, as they may struggle to maintain sufficient liquidity across multiple chains.
Incentive Misalignment
The role of liquidity bridges is to facilitate the exchange from cross-chain tokens to standard tokens on the target chain without causing excessive slippage for users; from the user's perspective, the gas costs associated with interacting with the bridge also determine the value of the liquidity bridge. Therefore, cross-chain aggregators and project teams issuing tokens prioritize cross-chain bridges based on liquidity and transaction costs.
While this can ensure a better user experience for cross-chain project tokens or users sending tokens across chains using cross-chain aggregators, choosing cross-chain bridges based on liquidity can disadvantage those that cannot spend on LP incentives. Additionally, relying solely on transaction fees can lead to competition favoring centralized methods to reduce operational costs, allowing cross-chain bridges to charge lower fees for cross-chain transactions. In both cases, cross-chain bridges do not compete on the most critical metric—security.
Furthermore, liquidity bridges are also unfavorable for 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 establish AMM pools and guide liquidity to cover the swaps between native tokens (via liquidity bridges) and the standard tokens of the issuer's tokens, or collaborate 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 user experience issues. In addition to slippage in cross-chain exchanges, users may not be able to complete cross-chain transactions immediately on the target chain because the bridge lacks sufficient liquidity to cover transactions with the standard tokens on the target chain. When the user's token swap message arrives at the target chain, the bridge cannot know how much liquidity there will be for the asset pair, making this situation largely unavoidable.
In this case, users have two options (neither of which is ideal):
Wait for the bridge to have enough liquidity to complete the swap and withdraw the standard tokens. This is not ideal because cross-chain transactions have delays, and since pool liquidity can change arbitrarily in a short time, users cannot know if they will receive the same amount of tokens as initially quoted.
Receive proprietary tokens from the cross-chain bridge (e.g., hUSDT from Hop Bridge). This is not ideal because most applications prefer to integrate with the standard token of the native asset (e.g., opUSDT minted by the Optimism Bridge) and may not accept the user's wrapped assets.
Minting Standard Tokens Through Third-Party Cross-Chain Bridges
Multi-chain DApps can solve the issue of non-fungibility of cross-chain tokens by choosing a single cross-chain bridge to mint the standard token of the DApp on each chain where the DApp is deployed. Similar to the way standard bridges mint project tokens, this method requires mapping the tokens minted on remote chains to the token contracts deployed on the project's main chain to ensure that the global token supply remains consistent. Cross-chain bridge providers must track the minting and burning of tokens and ensure that these operations are synchronized with the token supply on the main chain.
On this basis, the issue of non-fungibility of cross-chain tokens is resolved; as long as users cross-chain through approved cross-chain bridge providers, they can always exchange at a 1:1 ratio with other cross-chain tokens. Additionally, this method also addresses the liquidity-based cross-chain issues present in the standard bridge model:
Users do not suffer slippage losses in cross-chain transactions because cross-chain bridge providers do not need to convert their tokens to standard tokens through AMM—the tokens supported by the cross-chain bridge provider are the standard token versions on each chain. The value of these standard tokens is tied to the value of the tokens locked by the provider on the native chain.
Users encounter almost no delays when crossing chains because cross-chain bridge providers can immediately start minting wrapped tokens on the target chain upon receiving the mint() message.
Developers can outsource the management of multi-chain token deployments to cross-chain bridge providers without worrying about launching AMM liquidity or liquidity provision incentive programs.
Currently, examples of token standards from single cross-chain bridge providers include LayerZero's Omni-Chain Fungible 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 the cross-chain tokens of the same token sent through different cross-chain bridge providers, highlighting some issues with this cross-chain token handling method, specifically:
Provider lock-in
Loss of protocol sovereignty
High risk of bridge failure
Loss of custom functionality for tokens on the target chain
Limited to chains supported by the provider
Inability to maintain the same token address across all required chains, which may compromise user security or make them susceptible to phishing attacks
Disadvantages of Using Standard Third-Party Cross-Chain Bridges
Provider Lock-In
Choosing a single cross-chain bridge provider to create standard tokens on one or more chains may expose developers to the risk of provider lock-in. Since each cross-chain bridge provider creates proprietary tokens that are 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, preventing them from easily switching to another cross-chain bridge in the future.
While it is possible to change cross-chain bridge providers, the cost of switching is often high enough to deter most projects from taking that route.
For example, suppose a developer (let's call him Bob) issues a token (BobToken) on Ethereum and chooses LayerZero OFT to mint standard versions of BobToken on Optimism, Arbitrum, and Base. BobToken has a fixed supply of 1,000,000 tokens, and the cross-chain tokens minted through LayerZero account for 50% of the total circulating supply of BobToken.
Initially, business progresses smoothly until Bob decides to bridge BobToken through a competing cross-chain service (e.g., Axelar). However, Bob cannot simply say, "I want 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 create trouble for both new and existing users, as the two BobTokens may not be interchangeable (reintroducing the issue we described earlier). Meanwhile, applications integrated with the LayerZero version of BobToken may also not accept the Axelar version of BobToken as a substitute, leading to fragmented liquidity across various L2 chains where BobToken competes.
So, if Bob must implement the conversion, what does he need to do?
First, Bob needs to persuade users to send transactions to unwrap the wrapped tokens of BobToken minted through LayerZero, which will destroy the cross-chain OFT tokens and unlock BobToken on Ethereum. Subsequently, users can lock tokens on Ethereum using Axelar and receive new standard tokens of BobToken (mapped to the token contract supply on Ethereum) on the target chain. This process is both costly for the DAO project management team and generates significant coordination and operational overhead, making it usually safer to stick with the original provider.
On the other hand, developers like Bob may also find themselves in a bind because if the cross-chain bridge provider fails to adhere to protocol terms, has limited functionality, lacks extensive ecosystem integration, or provides a poor user experience, provider lock-in will prevent developers from switching. During this time, the cross-chain bridge provider could 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 Protocol Sovereignty
The conclusion regarding provider lock-in above emphasizes another issue with using standard third-party cross-chain bridges: token issuers sacrifice control over standard cross-chain tokens for greater convenience and improved user experience. For example, BobToken on Ethereum is entirely 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 holds the OFT contract for publishing standard tokens of BobToken on these blockchains.
While Bob may expect LayerZero to keep the standard tokens aligned with the original design of the native tokens, this is not always the case. In the worst-case scenario, the behavior of BobToken on Ethereum may differ significantly from that of BobToken on Optimism because the cross-chain bridge provider has implemented a completely different version of the token contract—this also poses 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 crossed through the standard bridge of each chain, and the risks faced by token issuers due to vulnerabilities affecting a cross-chain bridge are 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 withdraw the maximum available liquidity of the wrapped assets in the liquidity pool (e.g., minting cUSDT on Optimism → swapping cUSDT for standard opUSDT → quickly cross-chain withdrawing opUSDT to Ethereum → exchanging for native USDT on Ethereum).
In the third-party cross-chain bridge model, the risk to token issuers from vulnerabilities affecting partner cross-chain bridges is equivalent to the total amount of tokens minted on the remote chain where the affected bridge is deployed. This is entirely possible because standard tokens on one chain can be exchanged 1:1 for standard tokens issued on other chains, as illustrated below:
Suppose an attacker compromises a third-party cross-chain bridge on chain B and mints 1,000 tokens without depositing collateral (the tokens were originally issued on chain A). The attacker's tokens on chain B are not mapped to the main chain contract, so they cannot withdraw from chain A. However, they can cross-chain to chain C, exchanging 1,000 tokens from chain B for 1,000 tokens from chain C—remember, these standard cross-chain tokens are compatible and interchangeable because they come from the same cross-chain bridge service. The tokens on chain C 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 tokens), allowing the attacker to destroy the tokens on chain C and withdraw the native tokens on chain A, ultimately enabling the attacker to complete the attack by trading the tokens on a CEX.
Loss of Custom Functionality for Tokens on the Target Chain
When using third-party cross-chain bridges, token issuers often lose the custom functionalities or token behaviors that exist in their original deployments, such as voting delegation (ZK), rebase mechanisms (stETH, USDM), transfer fee functionalities, blacklist and whitelist functionalities (USDT, USDC), pausable transfers, and special minting rules or permissions. These common token functionalities are often stripped away because cross-chain bridge providers tend to use standardized ERC-20 implementation contracts, which may not support the specialized functionalities present in the original token implementations.
The absence of these functionalities can lead to inconsistencies in how tokens operate across different chains, potentially harming integrated applications that rely on these specific custom features. While from the perspective of cross-chain bridge providers, promoting the standardization of cross-chain tokens seems to simplify operations, in reality, this approach undermines the original functionalities of the tokens and may hinder issuers from maintaining consistency in token behavior across the entire multi-chain ecosystem covered by their applications.
Limited Supported Chains
Token issuers depend on the network coverage and expansion plans of their chosen cross-chain bridge providers. If the cross-chain bridge provider does not support the specific blockchain networks that the token issuer wants to expand to, they will face two undesirable options:
Wait for the cross-chain bridge provider to add support for the required chain, which may take a long time or may never happen due to high integration costs (for example, the EVM incompatibility of ZKsync Era has led to many DApps never being deployed on it);
Use a different cross-chain bridge provider for that specific chain, which would reintroduce the issues of non-interchangeable tokens and fragmented liquidity.
This limitation can severely impact the protocol's growth strategy and its ability to attract new users on emerging chains. It is important to note that cross-chain bridge providers may prioritize supporting popular chains while neglecting smaller or newer networks that may hold strategic significance for token issuers.
Inconsistent Cross-Chain Token Addresses
Due to the peculiarities of the tech stack (e.g., not supporting CREATE2), third-party cross-chain bridge providers may deploy cross-chain tokens at different addresses on each chain, leading to a lack of address consistency that triggers 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 valid list of token addresses for each network;
Increased Phishing Risks: Without a consistent address to check, malicious actors can more easily deceive users with fake tokens.
Issuing Standard Tokens Through Token Issuers' Bridges
In addition to the solutions mentioned above, if developers wish to maintain maximum control over the cross-chain deployment of project tokens, they can manage the issuance of standard token versions on remote chains, which is described as "trusted token issuers," because the value of each cross-chain token version is closely tied to the value of the tokens locked by the protocol responsible for issuing the original version on the source chain.
To make this method work, token issuers must establish infrastructure to manage the minting and burning of cross-chain tokens (while ensuring global supply synchronization through standard mapping).
Notable examples of standard tokens issued by token creators (native tokens) include 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 while being minted on the target chain. CCTP functions similarly, enabling cross-chain transfers of native USDC (issued by Circle) through a minting and burning mechanism. In both cases, the token issuers control the minting and burning of standard tokens.
This method provides the protocol with complete control over cross-chain tokens. It effectively addresses the issue of non-interchangeability of the same token—there is only one standard version of the token (minted by the issuer on the target chain), ensuring that users have the same experience when using the token across every ecosystem supported by the token issuer.
Using this method, applications can also eliminate the liquidity fragmentation issues caused by unofficial cross-chain tokens within the same ecosystem. Developers can build more robust cross-chain applications (e.g., cross-chain exchanges and cross-chain lending) because the standard token issuer's bridge allows for capital-efficient, seamless, and secure token transfers between chains.
Of course, such solutions also have some drawbacks; this model is only suitable for projects with sufficient capital to deploy standard tokens across chains and to maintain the infrastructure required for cross-chain minting and burning (oracles, guardians, etc.). At the same time, it also brings about some undesirable effects, namely closely tying the security of cross-chain assets to the security model of the protocol.
Objectively speaking, this relationship (between the cross-chain version of the protocol token and the protocol's security) is friendly because the security of the native tokens supporting the standard token version already depends on the security of the protocol, so users and external developers do not bear new trust assumptions. This is especially true for stablecoin bridges operated by issuers like Circle and Maker (now Sky)—users already trust that stablecoin issuers have sufficient assets to cover the costs of exchanging stablecoins for fiat currency, so trusting the security of stablecoin bridges is not difficult.
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 (like Circle in USDC) can truly realize this model of issuing standard cross-chain tokens.
Final Thoughts
The interchangeability of cross-chain assets is undoubtedly an important component of Rollup interoperability, affecting the user experience of asset transfers between different chains. At the same time, the ability of tokens to maintain interchangeability when crossing to remote chains will also influence developer behavior, as certain use cases depend on this feature.
To address the issue of non-interchangeable cross-chain tokens, the industry has proposed various solutions, including minting standard tokens through native (implemented) bridges, using dedicated third-party bridges to mint standard tokens across multiple chains, and utilizing protocol-owned bridges to facilitate token movement while maintaining interchangeability.
Although these methods solve many specific problems, they do not address all issues, 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 solution for cross-chain asset interchangeability that enables protocols to effectively deploy standard tokens across 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 functionality addresses many issues related to historical proposals for multi-chain standard tokens, including liquidity fragmentation, incentive consistency, user experience issues, cross-chain bridge security, and the customizability of cross-chain tokens.
Therefore, in the next section of the report on cross-chain asset interchangeability, we will provide a detailed overview of ERC-7281 (also known as xERC-20), analyze the multi-chain standard token approach of xERC-20 by comparing it with other multi-chain standard token designs, and explore how the xERC-20 token standard benefits developers and users.
To be continued.
免责声明：本文章仅代表作者个人观点，不代表本平台的立场和观点。本文章仅供信息分享，不构成对任何人的任何投资建议。用户与作者之间的任何争议，与本平台无关。如网页中刊载的文章或图片涉及侵权，请提供相关的权利证明和身份证明发送邮件到support@aicoin.com，本平台相关工作人员将会进行核查。
