How do cross-chain solutions make cross-chain tokens interchangeable?

Written by Alex Hook, Emmanuel Awosika

Compiled by: Glendon, Techub News

This report is divided into two parts. Part 1 outlines the challenges facing the cross-chain field, such as the non-fungibility problem of cross-chain tokens, and analyzes the current main solutions. Solution; 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 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 (cross-chain attacks by hackers have caused losses of more than $2.5 billion), or they may be slow, expensive, and have limited functionality. What's more, the above problems may exist in the same cross-chain bridge at the same time.

In addition, there is also a core problem in the cross-chain field: converting interchangeable tokens (such as ERC-20 standard tokens) through different cross-chain protocols. When tokens are cross-chained to different chains, these tokens will become non-fungible tokens, thereby losing their function as transferable assets. In this article, we’ll explore a solution designed to ensure a token’s fungibility across chains, regardless of where its original contract 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 the token issuer to mint and burn standard token versions of ERC-20 tokens on remote chains, ensuring that users receive what they receive at the destination when bridging ERC-20 tokens. is a fungible version of the token (i.e. two tokens can be exchanged 1:1), even if the tokens are sent across chains via different paths/bridges.

Importantly, a protocol adopting ERC-7281 can maintain control of cross-chain tokens (unlike the current state of bridges that control cross-chain tokens), And the rate of casting operations can be limited, thereby reducing the risk in the event of a cross-chain bridge failure.

Taking USDC as an example, we can find that theoretically the same ERC-20 tokens on different chains are not interchangeable. In Ethereum L2 networks (e.g. Arbitrum, Base, Optimism), Canonical Bridge is often 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 both tokens are minted by the same entity and have the same price, they are technically different, non-fungible tokens and therefore not "interoperable" - although native USDC can be exchanged via Circle Chain Transfer Protocol (CCTP) is used for cross-chain, but cross-chain USDC can only cross-chain back to L1 through a standard bridge.

ERC-7281 solves this problem by introducing ERC-20 extensions, where the deployer of a token can assign and parameterize different cross-chain origins for it. 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 designated to be able to mint tokens according to their logic . To minimize the risk of minters being hacked, deployers can limit the number of tokens each minter can mint and destroy in a specific time period - for more reliable cross-chain bridges (such as standard L2 cross-chain Bridges), higher limits can be set, and for bridges with centralized consensus, lower limits can be set.

Although ERC-7281 is not the first attempt to create a solution for interchangeable cross-chain tokens, it may be able to solve the problems existing in cross-chains, such as providing Trader lock-in, loss of sovereignty of token issuers, high cost of cross-chain tokens guiding liquidity, increased infrastructure overhead, and increased risk of cross-chain failures, etc.

Overview of the cross-chain bridge mechanism

In-depth discussion of non-fungible cross-chain tokens Before asking the question, we need to first understand the reason why cross-chain tokens exist. Therefore, we also need to understand the motivations and operating mechanisms of cross-chain bridges - because the cross-chain bridge provider is the party responsible for creating cross-chain token versions. .

The cross-chain mechanism is a means of transmitting 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, transferring assets (tokens) from one chain to another is undoubtedly the most common use case for bridges that currently interact with users.

Methods to facilitate cross-chain asset transfers vary, but the workflow for cross-chain tokens typically follows one of three high-level patterns:

Lock and Mint Bridge

• User Hope to cross-chain the tokens on its native chain or "source chain" (originally issued chain) to another chain. Since each chain implements a different architecture and protocol design, the two blockchains are not compatible, which prevents users from directly transferring tokens from chain A’s wallet address to chain B’s wallet address.

• The cross-chain bridge provider hosts the tokens stored by users on the native chain in smart contracts and deploys them on the target On-chain token contracts create "wrapped" token versions of native tokens.

• When users wish to reverse cross-chain (target chain → native chain), they return the wrapped tokens to the target chain The target chain will verify this based on the logic in the cross-chain bridge (such as zero-knowledge proof or external arbitration) and release the native tokens from the escrow account on the native chain.

Destruction and minting bridge

• This method does not lock the tokens in custody, but destroys the tokens on the source chain;

• This cross-chain The bridge will mint an equal amount of tokens on the target chain;

• For reverse transfer, the cross-chain tokens are on the target chain are destroyed, and then new tokens are minted on the source chain;

• This can maintain the token while achieving cross-chain transfer total supply.

Atomic Swaps

• Atomic swaps unlock funds with the same private value by locking them with each other, meaning that if either party's secret is leaked, so will the other's. This gives the exchange the property of atomicity.

• Atomicity means that the exchange either completes completely (on both sides) or not at all, thus preventing fraud or partial/failed transfer.

Among the above methods, the first (locking and minting) is currently the most common. Value equivalence between native tokens and corresponding wrapped tokens minted by the bridge enables users to "cross-chain" assets and use tokens on a different chain than the one on which 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 user experience unlocking tool because they greatly simplify people’s on-chain experience and make cryptocurrencies easier to use, especially when combined with on-chain abstraction solutions.

Cross-chain intent allows users to transfer tokens between chains without worrying about the underlying complexities of cross-chain bridges. In an intent-based cross-chain bridge, users deposit funds on the source chain and specify their desired outcome on the target chain (i.e., their “intent”). Professional operators called Fillers or Solvers can accomplish this by sending requested tokens to users on the target chain in advance. The operator then proves that the transfer occurred to claim the funds locked on the source chain as compensation.

Some intent-based cross-chain bridges utilize locking and casting mechanisms internally. In this case, wrapped tokens are minted across the chain bridge, and these tokens are either sent to a filler that satisfies the user's intent, or directly to the user (if no filler intervenes). However, intent-based cross-chain bridges add an extra layer of efficiency through their solver network, but they still essentially rely on the same principles as traditional lock-and-cast bridges.

We can think of each wrapped token (whether created through a traditional cross-chain bridge or an intent-based cross-chain bridge) as an "IOU" issued by the cross-chain bridge provider, promising to obtain from the escrow A certain number of native tokens are released in the 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 escrow tokens on the native chain.

A cross-chain bridge authorized to lock native tokens on the source chain and mint their wrapped tokens on the target chain, ensuring that the total supply of tokens is maintained constant. 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 that application have sufficient trust in the cross-chain bridge provider to support the security of the "real" assets of the wrapped tokens.

Why is a cross-chain bridge needed?

By creating cross-chain tokens, cross-chain bridges can trade with synthetic versions of assets on remote chains, a powerful feature that enables developers People and users alike can take advantage of cross-chain interoperability. These advantages include gaining more liquidity, attracting new users, and providing flexibility to users (users can interact with applications from different chains without hindrance).

To better understand how this works in practice, and why it is important for both developers and users, let's start with a tool called Let’s take the fictional decentralized exchange “BobDEX” as an example. This example will demonstrate how a wrapped token can scale across chains, while highlighting the benefits and potential complexities that may arise:

BobDEX was created by Bob on Ethereum An automated market maker (AMM) exchange 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, which entitles users who provide liquidity to the pool to receive a portion (calculated as a percentage) of the fees paid by DEX users to exchange assets held in the pool.

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 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-cost, high-throughput layer 2 rollup) on Arbitrum, and passed Arbitrum -Ethereum Bridge deploys a wrapped token version of the BOB token (wBOB) on L2. 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 (such as liquidity providers), the difference in applied tokens (wrapped BOB vs. native BOB) does not unimportant. 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 find that this situation is a win-win 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 to this, the benefits of cross-chain bridges are to enhance composable innovation and unlock new use cases that leverage the liquidity of the bridge token. 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 access to deposits: if a user defaults, AliceLend will automatically auction wBOB tokens deposited as collateral to repay Lender. In this case, the buyer liquidating wBOB collateral will assume the role of LP on BobDEX with the same guarantee that wBOB tokens can be redeemed for original BOB tokens at a 1:1 ratio.

Currently, cross-chain bridges are used to ensure interoperability between (previously isolated) Ethereum L2 and to facilitate new applications such as cross-chain lending and cross-chain DEX) provides a feasible solution. However, the cross-chain bridge ecosystem is facing 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 the locking and minting bridge mentioned above seems simple, but in fact, it requires a lot of engineering and mechanism design work. Works normally.

The first challenge is ensuring that the wrapped token version of a cross-chain token is always backed by the native token locked on the source chain. If an attacker mints cross-chain tokens on the remote chain without depositing native tokens on the source chain, the attacker can make the cross-chain tokens available by exchanging (fraudulently minted) wrapped tokens with native tokens on the main chain. The bridge protocol goes bankrupt and prevents legitimate users (who deposited money in the cross-chain bridge contract before minting the wrapped tokens) 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 on the same remote chain by the cross-chain bridge provider Token versions cannot be exchanged with each other at a 1:1 ratio. In this regard, we can use the example of two users trying to exchange tokens across chains through different paths to illustrate the issues related to cross-chain mobile tokens:

< li>

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 Arbitrum and receive 200 axlUSDC on Arbitrum. Alice and Bob come to an agreement where Alice sends 200 USDC to Bob (in exchange for 200 USDT) so that Bob can withdraw 400 USDC to Ethereum.

• Bob tried to withdraw 400 USDC through axlUSDC, but only received 200 USDC, and also received a message stating that the cross-chain bridge protocol Only 200 USDC can be provided to Bob. Bob is confused by this because wrapped ERC-20 tokens are supposed to be "fungible" and there should be no differences that prevent anyone from exchanging ERC-20 tokens at a 1:1 ratio on any application.

• Bob learned a profound lesson from the cross-chain bridge: "Fungible ERC-20 tokens" are not always It means "you can exchange it with other ERC-20 tokens at a 1:1 ratio in different applications." Thus, Bob's attempt to enter into a risky transaction with Alice (because Alice may not return the tokens) completely fails.

Why can't Bob withdraw 400 USDC? Because he and Alice received different packaged versions of the same underlying asset on the target chain, as mentioned above, tokens issued on different chains are incompatible, so the native tokens issued on the non-native chain are The token version is actually an IOU in the cross-chain bridge agreement, promising to pay a corresponding amount of native tokens (depending on the remaining amount) when the user wishes to bridge back to the token's native chain.

Therefore, the value of each cross-chain token is related to the cross-chain bridge responsible for holding the deposit on the main chain and minting the wrapped token on the target chain. Provider hook; Bob's cross-chain bridge provider can only pay Bob 200 USDC because that is the amount he can pay from his deposit; Alice's 200 USDC cannot be withdrawn through Bob's cross-chain bridge provider because it has never been Receive a deposit or issue 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 out a problem with cross-chain bridging, which is that multiple competing cross-chain bridge providers mint multiple non-fungible token versions of the same underlying asset. Additionally, another problem with different ERC-20 tokens of the same asset is that they cannot be traded in a single liquidity pool.

Still using the above example, if we have axlUSDC and USDC.e on the chain, and want to exchange them for ETH, then we must deploy two flows 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 circulate a "standard" version of the token on the target chain, so that Bob and Alice can exchange tokens, and There is no need for everyone to withdraw from the source chain’s bridge. Having a standard token on each chain also benefits developers because users can quickly move between ecosystems without having to deal with issues related to token liquidity.

So, how do we implement a standard version of a token on every chain where it is expected to be used or transferred?

Implementing standard tokens across multiple chains

Create a standard token for each chain Coins are not easy to buy and there are many options, each with their own pros and cons. When creating standard tokens for each chain, we often 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 used and transferable on different chains without running into fungibility issues, you will have 4 options:

1. Mint standard tokens through standard Rollup/Sidechain Bridge

2. Cross-chain through third parties Bridge provider mints standard tokens

3. Mints standard tokens through token issuer bridge

;">4. 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 a token creator, you can also choose to bypass cross-chain bridges entirely and issue tokens natively on each supported chain. Under this approach, instead of relying on wrapped tokens or cross-chain bridge infrastructure, you maintain independent but coordinated token deployments on each chain—i.e., atomic swaps enable trustless exchanges 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, which is mainly suitable for large protocols with large technical resources.

Minting standard tokens through standard rollup/sidechain bridge

If a chain has Standard Bridge (recognized), this chain can grant users who wish to cross-chain from the native chain the right to mint their protocol’s cross-chain tokens. Transactions (deposits and withdrawals) made through the 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.

Although Standard Bridge is minting the Standard Token version of the token, other token versions will still exist. This is because Standard Bridge often has limitations and cannot Provide users with the best experience. For example, bridging from Arbitrum/Optimism to Ethereum via Rollup's standard bridge has a seven-day delay because the transaction must be verified by a validator (and possibly disputed via a fraud proof if invalid), after which Rollup's settlement layer (Ethereum ) will settle a batch of transactions.

Rollup users pursuing efficiency must use other cross-chain bridge providers that can assume ownership of pending Rollup exits and execute at the user's desired destination Provide instant liquidity on-chain. When such bridges use the traditional lock-and-mint model, we end up with multiple wrapper tokens of tokens issued by different protocols and face the same issues described previously.

Sidechains with independent validator sets have lower latency because the block containing the withdrawal transaction is executed once the sidechain's consensus protocol confirms Withdrawal. 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, notthe Validium chain which plans to use Ethereum for settlement . Polygon will become L2 once it switches from sidechains secured by external validators to the Validium chain secured by the Ethereum consensus.

Unfortunately, the side chain bridge also has a common weakness with the Rollup standard bridge: users can only connect between a pair of connected chains. Perform cross-chain. They cannot use standard bridges to cross-chain to other blockchains. Simply put, currently, you cannot bridge Arbitrum to Optimism using the Arbitrum cross-chain bridge, nor bridge Polygon to Avalanche via the Polygon PoS cross-chain bridge.

Using a liquidity bridge to mint standard tokens

Relying on Rollup's native bridge to transfer standard tokens will cause some problems, such as liquidity Poor performance and delayed asset transfers. To address these issues, some protocols work with liquidity bridges to facilitate fast withdrawals and low latency across chains.

Under this arrangement, an authorized liquidity bridge mints wrapper tokens of protocol tokens on the source chain, which are then minted through protocol-owned liquidity pools, Exchange the wrapped token for the standard token of that native token on the target chain.

Standard tokens on the target chain are usually versions minted by the standard sidechain/Rollup bridge, although there are exceptions (discussed later). For example, the standard token for USDT on Optimism is opUSDT minted by Optimism Bridge.

Each liquidity bridge functions similar to a DEX with an automated market maker (AMM), which is used to execute funds stored in different liquidity pools. Exchange between asset pairs. To incentivize liquidity supply, the AMM pool will allocate a portion of the exchange fees to holders of standard tokens locked in the pool contract.

This is similar to Uniswap's model; the only obvious difference is that the asset pair is usually a liquidity bridge pair exchange between cross-chain tokens and standard tokens . For example, after users cross-chain USDT to Optimism through Hop, they will have to redeem hUSDT through the huSDT:opUSDT pool on Optimism.

The workflow of cross-chain through liquidity bridge is as follows:

1. Lock the native token on the source chain

3. Mint cross-chain tokens on the target through the AMM pool Exchange cross-chain tokens into standard tokens on the chain

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 looks like a simple transaction despite the many moving parts involved.

When cross-chain returns to the source chain, the user will destroy the standard token or exchange the standard token with the cross-chain token through AMM, and then destroy the token Coins and provide proof of destruction receipt. Once confirmed, users can withdraw the originally locked native tokens. (As with the previous operation, the tedious details of moving tokens back to the original chain are hidden from the user and managed entirely by the solver).

The advantage of the liquidity bridge is that it solves the delay problem in the Rollup cross-chain bridge; for example, Hop allows specialized institutions called "Bonders" to operate on L2 It proves the validity of the user's withdrawal transaction and bears the cost of withdrawing money from Rollup's L1 bridge. Each Bonder will run a full node for the L2 chain and can determine whether a user's exit transaction will eventually be confirmed on L1, thereby reducing the risk of users initiating fraudulent withdrawals and causing losses to the Bonder.

Unlike standard bridges, Liquidity Bridges also enable users to move between more chains. For example, 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 fee for minting tokens for users on the target L2 chain, which makes Rollup It is more composable and significantly improves the user experience.

Of course, there are some drawbacks to liquidity bridges, which impact the practicality of minting standard tokens on L2/L1 chains using the chain's standard bridge.

Disadvantages of Liquidity Bridge

Slippage

Slippage refers to the difference between the number of tokens expected to be received and the number of tokens actually received when interacting with AMM. Lack of liquidity in 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 swap trades at higher prices. In theory, arbitrageurs are supposed to correct price differences between different asset pools through trading activity, however, this mechanism can be hindered when arbitrage trades involve tokens with less trading activity or lower value.

Also, this will also impact developers building cross-chain applications, as they must consider edge cases where slippage occurs; The number of tokens received on each target chain is too small to complete the cross-chain operation.

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 target chain) exchange without slippage), adopts a strategy of specifying the maximum slippage tolerance, by pre-setting the maximum slippage range acceptable to users and providing them with quotes. While this prevents transaction rollbacks, users will always lose a percentage of their cross-chain tokens, regardless of the liquidity in the bridge's AMM pool.

Liquidity restrictions

A fundamental challenge facing the liquidity bridge is that the target chain must There is sufficient liquidity. Unlike traditional lock-and-mint, where token minting is directly backed by the locked assets, Liquidity Bridge relies 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 cease to function.

• If liquidity is too low, cross-chain operations may stop entirely, preventing users from completing Anticipated transfers;

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

• During periods of greater market volatility or stress, liquidity providers may withdraw funds from the pool , and this is when cross-chain bridge functionality 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 operational.

Liquidity requirements create a circular dependency: the bridge requires large amounts of liquidity to operate reliably, but attracts liquidity providers The applicant will need to demonstrate the continued use and expense 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 across multiple chains.

Incentive mechanism mismatch

The role of the liquidity bridge is that it can cover the The exchange of chain tokens to standard tokens 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 project teams that issue tokens prioritize cross-chain bridges based on liquidity and transaction costs.

Although this can ensure a better user experience for cross-chain project tokens, or users who use cross-chain aggregators to send tokens across chains, according to the flow Sexual selection of cross-chain bridges puts bridges that cannot spend LP incentives at a disadvantage. Furthermore, basing it solely on transaction fees would bias competition in favor of cross-chain bridges that adopt a centralized approach to reduce operating costs and can charge lower fees for cross-chain transactions. In both cases, cross-chain bridges fail to compete on the most important metric – security.

Furthermore, liquidity bridges also disadvantage long-tail assets with less trading activity (making them less likely to attract liquidity providers). Issuers of long-tail tokens (or new tokens with lower cross-chain volume) will either have to build AMM pools and direct liquidity to cover native tokens (cross-chain via liquidity bridges) with standard tokens of the issuer token swaps between LPs, or working with a cross-chain bridge provider to increase financial incentives for LPs to provide liquidity for the asset.

Poor cross-chain user experience

Liquidity bridge is an alternative to standard cross-chain bridge Improved, but not without user experience issues. In addition to the slippage of cross-chain exchanges, users may not be able to immediately complete cross-chain transactions on the target chain because the bridge does not have enough liquidity to cover transactions with standard tokens on the target chain. When a user's token swap message reaches the target chain, the bridge has no way of knowing how liquid the asset pair will be, so this situation is mostly unavoidable.

In this case, the user has two options (neither ideal):

• Wait until the bridge has enough liquidity to complete the swap and withdraw standard tokens. This is less than ideal because there are delays in cross-chain transactions, and because pool liquidity can change arbitrarily over a short period of time, users have no way of knowing whether they will receive the same number of tokens they were originally quoted for.

• Receive cross-chain bridge proprietary tokens (e.g., Hop Bridge’s hUSDT). This is sub-optimal as most applications would prefer to integrate with standard tokens of native tokens (e.g. opUSDT minted by Optimism Bridge) and may not accept wrapped assets from users.

Minting standard tokens through third-party cross-chain bridges

Multi-chain DApps can solve the problem of non-interchangeability of cross-chain tokens by selecting a single cross-chain bridge, that is, minting standard tokens of the DApp token on each chain where the DApp is deployed. In the same way that standard bridges mint project tokens, this approach requires tokens minted on the remote chain to be mapped to 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 in sync with the token supply on the main chain.

On this basis, the problem of non-interchangeability of cross-chain tokens has been solved; as long as users cross-chain through an approved cross-chain bridge provider, They can always be exchanged with other cross-chain tokens at a 1:1 ratio. In addition, this method 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 A standard token version 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 will hardly experience any delays when crossing chains, because the cross-chain bridge provider can receive mint() Immediately after the message, minting of wrapped tokens begins on the target chain.

• Developers can outsource the management of multi-chain token deployment to cross-chain bridge providers without worrying about launching AMM flows Provide incentive programs for liquidity or liquidity.

Currently, some examples of token standards for a single cross-chain bridge provider include LayerZero’s full-chain universal token (OFT), Axelar’s ​​cross-chain token service ( ITS), Celer's xAsset and Multichain's anyAsset. It’s worth mentioning that these examples are proprietary tokens in nature and are not compatible with cross-chain tokens of the same token sent through different cross-chain bridge providers, so this detail also highlights this cross-chain Some issues with the chain token handling method are as follows:

• Provider lock

• Loss of protocol sovereignty

• Bridge High risk of failure

• Customized functions of tokens on the target chain are lost

• Limited to provider-supported chains

• Cannot remain the same on all required chains token address, which may compromise user security or make them vulnerable to phishing attacks

Use standard third-party cross-chain Disadvantages of Bridges

Provider lock-in

Selecting a single cross-chain bridge provider in one or Creating standard tokens on multiple chains could put developers at 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, and cannot switch to another cross-chain bridge at will in the future.

Although it is possible to change cross-chain bridge providers, the cost of replacement 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 Standard versions of BobToken minted on Optimism, Arbitrum and Base. BobToken has a fixed supply of 1,000,000, and cross-chain tokens minted through LayerZero account for 50% of the total supply of BobToken in circulation.

At first, the business was going smoothly until Bob decided to bridge BobToken by competing for a cross-chain service such as Axelar. However, Bob cannot simply say: "I want to switch to Axelar ITS to mint BobToken's standard tokens on Optimism, Base and Arbitrum"; due to the incompatibility of OFT tokens and ITS tokens, Bob may give new and old users Both bring trouble, because the two BobTokens may not be interchangeable (here reintroducing the problem we described earlier). At the same time, applications that integrate with the LayerZero version of BobToken may not be able to accept the Axelar version of BobToken as a replacement, resulting in fragmented liquidity across L2 chains where competing BobToken tokens coexist.

So, if Bob must implement the conversion, what does he need to do?

First, Bob needs to convince the user to send a transaction to unlock the BobToken wrapped token minted through LayerZero, which will destroy the cross-chain OFT token and unlock the ether BobToken on the market. Users can then lock their tokens using Axelar on Ethereum and receive BobToken (the new standard token mapped to the token contract supply on Ethereum) on the target chain. This process is costly for the DAO project management team and creates significant 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 in trouble because if the cross-chain bridge provider fails to comply with the terms of the agreement and has a limited feature suite , lack of broad ecosystem integration, poor user experience, etc., provider lock-in will prevent developers from switching. 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, raising cross-chain fees, or even censoring cross-chain operations.

Loss of protocol sovereignty

The above conclusion on provider lock-in emphasizes Another problem with using standard third-party cross-chain bridges: Token issuers sacrifice control of standard cross-chain tokens for greater convenience and user experience improvements. For example, the BobToken on Ethereum is completely within the control of Bob, because he controls the underlying ERC-20 token contract, but the BobToken on Optimism, Arbitrum and Base are controlled by LayerZero, which owns the rights in these areas. The OFT contract of BobToken standard token is released on the blockchain.

While Bob may expect LayerZero to keep standard tokens consistent with the original design of native tokens, this is not always the case. In the worst-case scenario, BobToken may behave very differently on Ethereum than BobToken on Optimism, because the cross-chain bridge provider implements a completely different version of the token contract - which also brings problems to users of the protocol. problems because the goals and interests of protocol developers and cross-chain bridge providers may diverge.

High risk of cross-chain bridge failure

In the first solution, the token Cross-chains are conducted via each chain’s standard bridge, and a token issuer’s risk from vulnerabilities affecting one cross-chain bridge is limited to that bridge. For example, let’s say a hacker manages to breach a liquidity bridge and mint an unlimited number of wrapped tokens without depositing collateral. In this case, it can only withdraw the maximum available liquidity of the wrapped asset in the liquidity pool (example: Mint cUSDT on Optimism → Swap cUSDT for standard opUSDT → Withdraw opUSDT to Ethereum via fast cross-chain → On Ethereum Exchange it on the market for native USDT).

In the third-party cross-chain bridge model, for token issuers, the risk caused by vulnerabilities affecting partners’ cross-chain bridges is equivalent to The total amount of tokens minted by the attacker on remote chains deployed by the affected bridge. This is entirely possible because standard tokens on one chain can be exchanged for standard tokens issued on other chains at a 1:1 ratio. Examples are as follows:

Suppose an attacker compromises the third-party cross-chain bridge on chain B and mints 1000 tokens (the tokens were originally issued on chain A) without depositing collateral. The attacker's tokens on chain B are not mapped to the main chain contract, so they cannot be withdrawn from chain A. However, it can cross chain to chain C, exchanging 1000 chain B tokens for 1000 chain C tokens - remember that 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 were legitimately minted by users who locked their tokens on Chain A (the token's main chain), which allows an attacker to destroy the tokens on Chain C and withdraw Chain A On the native token, the attacker can finally complete the attack by trading tokens on CEX.

Customized functionality of tokens on the target chain is lost

When using a third-party cross-chain bridge, the token issuer usually also loses Custom functions or token behavior implementation capabilities that exist in its original deployment, such as voting delegation (ZK), rebasing mechanism (stETH, USDM), transfer fee function, blacklist and whitelist functions (USDT, USDC), Suspended transfers and special minting rules or permissions, etc. These common token functions are usually stripped out. This is because cross-chain bridge providers often use standardized ERC-20 implementation contracts, which may not support the original Specialized features present in the token implementation.

The lack of these functions will lead to inconsistencies in the operation of tokens on different chains, which may harm integrated applications that rely on these specific custom functions. . Although promoting the standardization of cross-chain tokens may seem to simplify operations from the perspective of cross-chain bridge providers, in fact this approach weakens the original functions of the tokens and may hinder issuers from using them in the areas covered by their applications. Maintain consistency in token behavior across the entire multi-chain ecosystem.

Limited supported chains

Token issuers rely on their choice of cross-chains Bridge provider's network coverage and expansion plans. If a cross-chain bridge provider does not support the specific blockchain network a token issuer wants to expand to, they are faced with two less-than-ideal choices:

< li>

Wait for the cross-chain bridge provider to add support for the desired chain, which may take a long time or may never be implemented due to high integration costs (e.g. ZKsync Era's EVM inequivalence results in many Dapps never being deployed on it);

• Use different spans for this specific chain Chain bridge providers, but this reintroduces the issues of non-fungible tokens and liquidity fragmentation.

This limitation may severely impact the protocol's growth strategy and ability to attract new users on emerging chains. Be aware that cross-chain bridge providers may prioritize supporting popular chains and ignore smaller or newer networks that may be strategic to token issuers.

Cross-chain token addresses are inconsistent

Due to the particularity of the technology stack (such as not supporting CREATE2), 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 risk: Users must verify different token addresses on each chain, thereby increasing the risk of interacting with fraudulent tokens;< /p>

• Integration complexity: developers must maintain a list of valid token addresses for each network;

< li>

Increased phishing risk: With no consistent addresses to check, bad actors can more easily defraud users with fake coins.

Issue standard tokens through the token issuance bridge

In addition to the solutions mentioned above, if developers wish to maintain maximum control over the cross-chain deployment of the project's tokens, they can manage the issuance of standard token versions of the tokens on the remote chain, which is described as "Trusted token issuer" because the value of each cross-chain token version is closely linked to the token value 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 set up infrastructure to manage the minting and burning of cross-chain tokens (while ensuring that the Global supply is synchronized).

Notable examples of standard (native token) tokens issued by token creators 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 at the same time. CCTP functions similarly and enables cross-chain transfers of native USDC (issued by Circle) through a burning and minting mechanism. In both cases, the token issuer controls the minting and burning of standard tokens.

This approach provides the protocol with full control over cross-chain tokens. It solves the problem of non-fungibility 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 can Everyone in the ecosystem has the same experience when using tokens.

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 standard token issuer bridges allow for capital-efficient, seamless, and secure token transfers between chains.

Of course, this type of solution also has some shortcomings. This model is only suitable for those who have enough capital to deploy standard tokens across chains and maintain cross-chains. Projects with the infrastructure (oracles, guardians, etc.) overhead required to mint and destroy them. 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 (the relationship between cross-chain versions of protocol tokens and protocol security) is friendly because standard tokens are supported The security of a version's native token already depends on the security of the protocol, so users and external developers are not burdened with new trust assumptions. This especially applies to stablecoin bridges operated by issuers such as Circle and Maker (now Sky) - users already trust the stablecoin issuer to have enough assets to cover the cost of exchanging the stablecoin with fiat currency, and therefore trust the stablecoin bridge Security is not difficult.

But it also represents a central point of failure - if the token issuer's bridge infrastructure is compromised, then all tokens circulating in the multi-chain ecosystem The value of standard tokens will be threatened. This also means that only centralized custodians (such as Circle in USDC) can truly implement this model of issuing standard cross-chain tokens.

Final thoughts

Cross-chain asset interchangeability is undoubtedly Rollup interoperability An important component that affects users’ experience of asset transfer between different chains. At the same time, the ability of tokens to remain fungible across chains to remote chains will also impact developer behavior, as certain use cases rely on this feature.

To solve the problem of non-fungible 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 fungibility.

Although these methods solve many specific problems, they cannot solve all problems, and using them to achieve cross-chain asset fungibility is more or less There are some less than ideal trade-offs to be made. So, can we find a better way? The answer is yes.

We believe that ERC-7281 is a new cross-chain asset fungibility solution that enables protocols to be efficiently deployed on multiple chains Standard tokens without sacrificing security, sovereignty or user experience.

ERC-7281's unique design allows multiple (whitelisted) cross-chain bridges to mint standard versions of protocol tokens on each supported chain, while Allows protocol developers to dynamically adjust minting limits per cross-chain bridge. This feature solves 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.

So, in the next part of the cross-chain asset fungibility report, we will go into detail about ERC-7281 (also known as xERC-20), via Compare to other multi-chain standard token designs, analyze xERC-20’s multi-chain standard token approach, and dive into how the xERC-20 token standard can benefit developers and users.

To be continued.