Author: 2077 Research
Compiled by: Glendon, Techub News
If you haven’t read the first part of the series “How to Make Cross-Chain Tokens Interchangeable Again” , it is recommended to read it first - it analyzes in detail the root causes of the loss of interchangeability of cross-chain tokens and the systemic challenges it has caused. In the second part, we will focus on the innovative standard ERC-7281, which reconstructs the cross-chain token transfer mechanism, enhances reliability, and provides issuers with more refined governance rights.
The previous article has systematically discussed a variety of technical paths to solve the problem of cross-chain token interchangeability, and to solve the problems of liquidity fragmentation and poor user experience caused by non-standard versions of native tokens circulating on non-native chains, including:
A standard version of the native token minted on the target chain via a standard Rollup/sidechain bridge protocol;
Rely on third-party cross-chain services to generate a standard version of the native token on the target chain;
A standard bridging service independently operated by the token issuer to realize standard cross-chain token minting on the target chain.
All of the above solutions have their advantages and disadvantages. Therefore, the design philosophy of ERC-7281 (also known as xERC-20) is to integrate the advantages of each solution to build a more comprehensive, efficient and scalable solution for protocols that expect to deploy tokens across chains, and to achieve a breakthrough balance while ensuring security, sovereignty and user experience.
What is ERC-7281? ERC-7281: Sovereign Cross-Chain Tokens is a proposal to create a standard version of tokens that makes them compatible and interchangeable with tokens minted by different cross-chain protocols. The standard introduces the following core features by extending the ERC-20 interface:
Functionality for minting and destroying standard ERC-20 tokens;
Governance rights of token holders: 1. Authorize designated cross-chain bridge providers to perform token minting/destruction operations during cross-chain transfers; 2. Set dynamic minting/destruction limits for each authorized cross-chain bridge provider (for example, set smaller limits for centralized cross-chains and higher limits for more secure protocols).
Given the subtle technical differences between ERC-7281 and the ERC-20 token standard, the standard setters named it "xERC-20". Readers who want to systematically understand the ERC-20 token standard infrastructure can refer to the technical guide released by OpenZeppelin.
In essence, each ERC-20 token contract manages the global token supply by implementing a standard interface, records address holdings, and includes basic functions such as token authorization management, total circulation query, and address balance acquisition.
The ERC-7281 token standard adds an optional "Lockbox" contract module on top of the ERC-20 standard. As a wrapper contract (similar in function to the WETH contract), the Lockbox contract can convert traditional ERC-20 tokens into xERC-20 token versions through the familiar minting and destruction mechanisms. This design also makes ERC-7281 backwards compatible with existing ERC-20 token contracts that lack a destruction/minting interface and are not upgradeable.
According to the analytical framework in the first part, ERC-7281 can be classified as a cross-chain token minting paradigm of "trusting the token issuer + trusting the (approved) cross-chain bridge provider". Its core advantages are:
Cross-chain ERC-7281 tokens are fully controlled by the issuer (unlike most cross-chain token solutions that require the transfer of sovereignty)
Issuers still face the risk of approved cross-chain bridges experiencing security incidents, but they can manage this by manually selecting and restricting authorized cross-chain bridge providers.
The key breakthrough discussed in this report is that token issuers can dynamically adjust the minting/destruction quota of designated cross-chain bridge providers, thereby accurately calibrating the risk exposure of cross-chain security incidents. In addition, ERC-7281 supports a whitelist mechanism for multiple cross-chain bridge providers, allowing different providers to mint the same standard token across chains, effectively reducing the issuer's path dependence on a single provider.
These two features make ERC-7281 a significant improvement over traditional methods, helping to facilitate cross-chain bridging of protocol tokens and have positive second-order effects on users, interoperability infrastructure providers (especially aggregators), and application developers. The following article will analyze the technical specification details in depth and systematically evaluate the potential advantages and disadvantages of implementing ERC-7281.
ERC-7281 Explanation: Sovereign Cross-Chain Tokens
User token minting and destruction mechanism
According to the ERC-7281 standard, the project needs to deploy a new ERC20 compatible token contract that complies with the "IXERC20 interface". After the cross-chain bridge provider destroys the tokens deposited by the user on the source chain, it can mint an equal amount of tokens for them on the target chain. During the minting process, the system will check whether the number of tokens exceeds the minting limit of the bridge. If it passes the verification, the total token supply and the cross-chain bridge minting limit will be updated.
For existing ERC-20 tokens, we need to adopt Lockbox logic: the cross-chain bridge provider transfers the ERC-20 tokens deposited by users to the Lockbox contract for packaging and converts them into xERC-20 tokens. Lockbox then authorizes the provider to mint an equal amount of xERC-20 tokens.
The xERC-20 tokens minted by the bridge on the target chain are destroyed on the source chain using the "burn() function". This process ensures that the number of tokens destroyed does not exceed the destruction limit of the bridge. The transport layer of the bridge relays the destruction message to the target chain. The cross-chain bridge contract of the target chain verifies the message and mints an equal amount of xERC-20 tokens to the user address on that chain.
Conversely, in order to cross the token back to the source chain, the cross-chain bridge provider will destroy the xERC-20 token on the target chain and provide the user's address and token quantity. The destruction receipt is relayed to the source chain by the transport layer. If the destruction message is verified, the cross-chain bridge provider will perform the minting and destruction operations of the xERC-20 token for the user on the source chain. Once the token contract confirms the destruction certificate, the user can retrieve the original ERC-20 token. The source chain destruction operation simultaneously reduces the total token supply and the cross-chain bridge destruction limit.
The point is that xERC-20 contracts technically support minting without credential verification. While this article describes the standard verification process, token issuers can choose to whitelist cross-chain bridges that do not implement cross-chain message verification or use new verification mechanisms. The final decision depends on the issuer's risk tolerance.
Token minting and destruction rate limit mechanism
The setBridgeLimits function is a protected function that can only be called by the token contract owner. This function allows setting the address of the bridge contract and specifies the maximum number of tokens that the cross-chain bridge can mint for the user (mintingLimit) and burn (burningLimit). The owner can dynamically adjust the limits to flexibly respond to changes in the security posture of the cross-chain bridge provider. For example:
When vulnerabilities are found in the cross-chain bridge infrastructure, the mintingLimit can be lowered to control risk exposure;
On the contrary, if the cross-chain bridge completes the security upgrade, the minting limit can be increased.
The xERC-20 standard also includes functions to check the destruction and minting limits of cross-chain bridges that are allowed to handle tokens. "mintingMaxLimitOf" returns the maximum number of tokens that the cross-chain bridge can mint, while "burningMaxLimit" returns the maximum number of tokens that the cross-chain bridge can burn in a specified time. In addition, these functions also show the remaining number of tokens that the cross-chain bridge can destroy and mint before reaching the preset limits.
This design is critical for cross-chain bridge aggregators - if a cross-chain bridge hits the destruction or minting limit on the source chain/target chain, it will cause transaction delays or even failures. Therefore, aggregators tend to route requests to cross-chain bridges that have sufficient available limits and support the target transaction volume.
Rate Limit Parameter Analysis
The "Bridge" structure defined in the xERC-20 token interface standard contains "burningParams" and "mintingParams" (parameters of the xERC-20 token rate limit function that control how many tokens the bridge can burn and mint in a predefined time). "maxLimit" defines the maximum limit for token minting and burning, and increases every second at a predefined rate (ratePerSecond).
Here we want to address a potentially confusing issue: "maxLimit" (set for destruction and minting limits) is a limit on minting and destruction operations within a specific time frame, that is, a rate limit on minting and destruction based on a predefined threshold within a preset time window. "currentLimit" defines how much the cross-chain bridge can mint or destroy, and increases at a predefined rate. In contrast, "maxLimit" defines the number of tokens that the cross-chain bridge can mint or destroy per day.
The burn and mint parameters are primarily relevant to token owners (and to a lesser extent to bridge providers). However, the maximum and current limit parameters are important considerations for both users and bridge providers. For example, the current limit may affect the extent to which a user can confidently use a cross-protocol bridge without experiencing delays in receiving xERC-20 tokens on the target link.
xERC-20 Lockbox
The initial ERC-20 tokens did not specify the function of increasing and decreasing the token supply (early token economics mostly adopted a fixed total model). Therefore, not every ERC-20 token has the minting and destruction functions. Since ERC-7281 uses the minting and destruction mechanism favored by most current cross-chain bridges, it is necessary to achieve backward compatibility with ERC-20 tokens through Lockbox.
In the original standard (i.e., a project deploys a new token contract that implements the IXERC20 interface), the cross-chain bridge provider only needs to call mint() to mint tokens for users on the target chain (after locking the deposit on the source chain). The Lockbox contract draws on the design of the WETH wrapper contract. It implements a deposit() function to deposit the corresponding ERC-20 token into the Lockbox, and implements a withdraw() function for the cross-chain bridge provider to unlock the ERC-20 token after destroying the wrapped token on the remote chain.
The first two error types highlighted in this standard (“IXERC-20Lockbox_NotNative” and “IXERC-20Lockbox_Native”) occur when a user attempts to deposit tokens into the wrong lockbox contract. A lockbox can be either native (or non-native), depending on the type of token it supports.
The native Lockbox holds the native token, which is the token used to pay gas fees to validators. A typical example of a token that has a native Lockbox to wrap it into an xERC-20 token is ETH: Wrapping ETH into an xERC-20 token requires calling the Lockbox's depositNative() function and depositing ETH to receive an ERC 7281-compatible version of the ETH token.
Non-native Lockbox can custody ERC-20 tokens such as USDC, DAI, WETH, USDT, etc. For example, to mint USDC into xERC-20 tokens, the user needs to call deposit() on the Lockbox contract after locking USDC. Calling deposit() with ETH will cause those funds to be permanently locked because non-native Lockbox contracts can only wrap and unwrap ERC-20 tokens. Additionally, calling depositNative() with an ERC-20 token will produce similar results because the native Lockbox contract is designed to work with native tokens, not ERC-20 tokens.
In this way, by wrapping standard ERC-20 tokens into xERC-20 tokens with minting/burning support, Lockbox provides an important compatibility layer for the standard. However, in some cases, such as integrating other cross-chain solutions into xERC-20, it is not feasible to just use Lockbox and return the wrapped token. For this reason, projects may implement adapter contracts.
Adapter Contract
If the cross-chain protocol does not recognize operations inherent to xERC-20 tokens (minting/burning, event logging, etc.), the application layer can build adapter contracts. These contracts can act as automatic wrappers and unwrappers, effectively converting ERC-20 approval + call behavior to the more nuanced minting/burning scheme required by the xERC-20 standard.
This is necessary because many cross-chain protocols (such as Chainlink’s CCIP) are still optimized for traditional ERC‑20 behavior. The adapter contract can bridge this compatibility gap by implementing the following logic: it deposits the token into the Lockbox to generate an xERC‑20 version on the source chain, and then after receiving a message on the target chain, triggers the exit mechanism to revert to a standard asset.
This process ensures that users ultimately receive a consistent standard token, regardless of the packaging mechanism supported by the underlying xERC-20. In this way, adapters can enable protocols to seamlessly integrate with non-xERC-20 standard cross-chain bridges and increase the range of interoperable solutions they support.
Why choose ERC-7281? The case for a sovereign cross-chain token standard
In general, ERC-7281 has four major goals:
1. Interchangeability: Users bridging a token from its native chain to another (L1/L2) chain should always receive the standard version of the cross-chain token on the target chain. Having multiple non-interchangeable versions of the same token circulating in a non-native chain is problematic for the reasons explained earlier (e.g., fragmented liquidity and poor token composability). The original vision for creating the ERC-20 standard was to ensure that tokens on Ethereum were interchangeable and seamlessly interoperable between applications and Ethereum infrastructure. However, after adopting a rollup-centric scaling roadmap, the lack of atomic composability emerged, and the creation of many different domains degraded these interchangeability properties. xERC-20 allows liquidity from various cross-rollup bridges to be aggregated into a unified multi-rollup token standard, restoring Ethereum's initial vision.
2. Security: In order to reduce counterparty risk, token issuers must have the right to choose independently and access multiple providers based on the evaluation of the cross-chain bridge provider's security infrastructure. At the same time, the issuer needs to establish an effective risk isolation mechanism - when some bridge service providers encounter security incidents, the scope of their impact should be strictly limited to avoid a single attack that causes a complete collapse of the total locked value (TVL) of the protocol.
3. Cold start of cross-chain tokens with zero liquidity dependency: Protocol DAOs should not be forced to devote a large amount of (financial) resources to bootstrapping the liquidity of cross-chain tokens as part of a multi-chain expansion plan. Liquidity-based cross-chain is not only detrimental to user experience, but as the number of supported chains increases rapidly, the project party’s spending on liquidity provision incentives may become unfeasible.
4. Sovereign control of token issuers: Issuers should continue to control the standard version of protocol tokens minted on non-native chains. Solving the problem of non-fungible cross-chain tokens should not come at the expense of giving up control of tokens (especially management aspects such as controlling total supply, configuring minting and destruction mechanisms, etc.).
Next, we will expand on these goals to understand what benefits ERC-7281 brings to the protocol and the community.
Advantages of ERC-7281
Improving user experience and eliminating liquidity fragmentation
ERC-7281 solves various path dependency issues. Path dependencies can be chain-specific (e.g. ETH from Ethereum to Arbitrum to Optimism is different than ETH from Ethereum to Optimism to Arbitrum) or bridge-specific (e.g. ETH from Ethereum to Optimism via Celer is different than ETH from Ethereum to Optimism via Connext).
Although path dependence has security value, it seriously damages the cross-chain user experience and composability. Taking the cross-chain DEX scenario as an example, if users need to inject funds into the liquidity pools of Optimism and Arbitrum at the same time, they will not be able to achieve automated operations due to differences in asset representation between chains (such as opETH and arbETH).
ERC-7281 completely eliminates this problem by introducing xERC-20 tokens. No matter how many times a user crosses the chain or what cross-chain bridge provider they use, xERC-20 always remains interchangeable. For example:
Users can transfer Arbitrum’s wrapped USDT to Optimism without withdrawing it to the Ethereum chain;
After the cross-chain bridge provider destroys the xERC-20 tokens of the Arbitrum chain, it can mint an equal amount of tokens in Optimism;
The value of the target chain token is always anchored to the native asset reserves in the Lockbox, maintaining a 1:1 rigid redemption.
It is worth noting that ERC-7281 achieves the advantages of standard token deployment similar to Circle CCTP (Cross-Chain Transfer Protocol), but does not require the parties to the agreement to centrally manage cross-chain assets. Its core value lies in:
Liquidity aggregation: forming a unified market around the standard version of the protocol token to improve the utility of DeFi applications;
Operational cost reduction: Avoid creating fragmented markets for different versions of the same asset.
Strengthening the sovereign control of token issuers
xERC-20 is called a "sovereign cross-chain token" because the token issuer does not have to lock in a standard version of the token using specific options and retains control over the design and management of the cross-chain token in cross-chain deployments. ERC-7281 is a hybrid between "standard tokens minted through a third-party bridge" and "standard tokens minted through a bridge controlled by the token issuer", combining sovereignty, user experience, and decentralization.
Projects that use ERC-7281 to deploy tokens across multiple chains can mint standard versions of native tokens across multiple bridges without encountering issues with non-interchangeable wrapped versions of the same native asset, which can lead to a compromised user experience. Such projects also retain a similar level of control over cross-chain deployment of tokens as token issuers, who run internal infrastructure to manage the transfer of standard tokens between domains, because the xERC-20 token contract and Lockbox (which the cross-chain bridge uses to lock, mint, and destroy tokens for users) are deployed and controlled by the project.
This underrated feature is very useful in situations where a well-known project issues a native token on its main chain, especially when users from other ecosystems want to get exposure to the token for different reasons but do not want to hold it on its native chain.
In this case, the project does not have the ability or willingness to run internal cross-chain infrastructure for each chain to ensure 1:1 compatibility between cross-chain tokens, nor does it want to hand over control of its tokens to a third party that is not necessarily aligned with the protocol and its community. This situation becomes a consideration when implementing cross-chain governance, allowing voting with cross-chain tokens while counting votes on the native chain; non-consistent cross-chain bridge providers with control of cross-chain tokens become a bottleneck for protocol governance.
For the reasons stated above, yield farming protocol Beefy adopted the xERC-20 standard. As stated in the project’s cross-chain bridge documentation, ERC-7281 provides the project with more cross-chain token options (which became necessary after the hack of the main cross-chain bridge partner) and provides more granular control over the design of cross-chain mechanisms. In Beefy’s case, the whitelisting feature of ERC-7281 enables the protocol to select a variety of cross-chain partners and provide users with different options that optimize for speed, decentralization, cost, and security when bridging mooBIFI tokens.
Realigning incentives to promote open competition and security
Liquidity-based bridges generally favor projects that have the financial ability to fund liquidity incentives - since token issuers want to spend less on liquidity provider (LP) incentives and provide a good cross-chain bridge user experience, liquidity becomes the most critical factor for protocols using standard L1/L2 bridges. This also extends to the cross-chain bridge aggregator's choice of cross-chain bridge providers, which arguably makes it more difficult for new cross-chain services (even those with secure infrastructure) to compete with more mature cross-chain protocols.
ERC-7281 solves this problem by eliminating the need for liquidity-based cross-chain transactions. Instead of minting and exchanging non-standard tokens for standard tokens, bridges of any size can be approved to mint project tokens on the target chain. As token issuers want to minimize the risk of cross-chain failures, more protocols may begin to pay more attention to the security design of cross-chain bridges rather than prioritizing liquidity.
This incentivizes open competition because it becomes a case of "let the most secure bridge win" rather than "let the bridge with the most liquidity win"; this open competition can take the form of cross-chain bridges competing on features other than liquidity/security (such as fees, API/SDK, application integration, etc.). These features are easier to incorporate into applications from the beginning because they depend primarily on the expertise of the development team; in contrast, liquidity and cross-chain volume are more difficult to launch and require a combination of business development, funding, industry connections, marketing, etc.
Provide better risk management for token issuers
ERC-7281 introduces configurable rate limits for token minting and burning, which greatly improves the risk profile of working with third-party cross-chain protocols that mint standard tokens on non-native chains. If a cooperating cross-chain bridge provider is hacked or compromised, the maximum damage the attacker can cause is equal to the limit of the compromised bridge. If the token issuer carefully chooses the rate limit parameters, an isolated attack on a cross-chain bridge may have minimal impact on the solvency of the protocol.
Additionally, configuring rate limits for each cross-chain bridge can also improve the risk assessment process of the protocol DAO. Adopting ERC-7281 makes risk assessment more dynamic. Projects still need to conduct due diligence on cross-chain bridge providers to select appropriate rate limit attributes; however, the risk assessment timeline can be shortened. Instead of spending months analyzing multiple cross-chain bridges to select one, project parties can select multiple cross-chain bridge providers and set different casting limits based on security assessments. Token issuers can then conduct a security review to determine whether to increase or decrease the casting limit of a selected cross-chain bridge partner, or withdraw casting rights from a certain cross-chain bridge (for example, in response to a hacker attack or vulnerability disclosure).
ERC-7281 also reduces the barriers faced by projects that want to adopt cross-chain bridge security technology, but are reluctant to fully adopt a technology until it has been battle-tested and rigorously vetted by the community (i.e., the innovator's dilemma). Suppose a cross-chain bridge provider proposes a new infrastructure that allegedly greatly improves security guarantees. In this case, the protocol can "test the waters" by allocating limited minting rights to the bridge and gradually increasing the bridge's minting limit as confidence in the proposed system design grows.
Just like eliminating liquidity-related concerns, removing the need for protocols to 100% trust the cross-chain bridge technology stack before allocating minting rights can create an equal playing field between new entrants and old players - old players have an incentive to iterate better security methods because token issuers now have the flexibility to withdraw minting rights and reallocate them to smaller projects, while the latter demonstrate a higher commitment to security and decentralization.
At the same time, this also eliminates another risk factor faced by protocols working with third-party cross-chain bridges: despite the speed at which vulnerabilities and issues in cross-chain bridge security are disclosed and discovered, the selected cross-chain bridge provider may still stop innovating in security because it knows that the token issuer cannot enforce punitive measures (for example, quickly migrate to another cross-chain bridge provider) and it is very difficult to enforce such activities.
Improving composability between ecosystems
Building complex application workflows that require routing tokens through any number of chains is difficult today due to unpredictable liquidity-based bridge pricing. For example, a bridge aggregator from Ethereum → Linea → Base has two options:
Building complex application workflows that need to pass through any number of Ann-Router tokens is difficult today due to unpredictable pricing of liquidity-based cross-chain bridges. For example, a cross-chain bridge aggregator from Ethereum → Linea → Base has two options:
Set slippage tolerance parameters and perform cross-chain routing pricing based on the minimum number of tokens a user will receive on each chain (depending on the amount of liquidity available when the cross-chain message reaches each layer);
No slippage tolerance parameters are set, and logic is created to obtain on-chain liquidity (e.g. through a DEX) if the amount of tokens received on one or more chains is lower than the expected amount.
In contrast, by checking the mintingLimit and burningLimit of the cross-chain bridge that allows minting of specific tokens, the bridge aggregator can know in advance how many tokens should be in each domain in the cross-chain transaction.
Granted, in the time between a transaction being broadcast and it arriving at a domain, the cross-chain bridge may reach maxLimit — meaning users cannot receive standard tokens on the target chain. But ERC-7281 is still an improvement in this regard for the following reasons:
If the cross-chain bridge provider reaches the mintingLimit while a transaction is in progress, the cross-chain transaction will be paused and retried after the rate limit parameters are adjusted. Unlike today's liquidity bridges, users will not receive proprietary wrapped versions of standard tokens.
The cross-chain bridge aggregator has a higher degree of predictability about when cross-chain transactions will be executed, and the expected amount of tokens. Since mintingLimit and burningLimit are configured to use blocks as a measure of time (as shown in the rate limit parameters section), it is easy to calculate when the cross-chain bridge will start minting and burning tokens again; in contrast, predicting when liquidity in the cross-chain bridge will increase is tantamount to playing "Russian roulette".
Unpredictable changes in liquidity also mean unpredictable pricing for retried cross-chain trades. Suppose a cross-chain bridge aggregator (or another application) quotes a cross-chain swap based on the current price of a token pair in the cross-chain bridge liquidity pool (this price is based on total pool liquidity). However, due to a sharp drop in pool liquidity, the trade cannot be executed. Suppose the trade is paused and retried later. In this case, the application developer has no way of knowing whether the previous quote is still accurate or whether liquidity will reach the same level as when the user first submitted the trade.
Cross-chain xERC-20 tokens are not subject to liquidity changes, so users can be confident that cross-chain trades will not incur slippage — even if they are not executed immediately.
Cross-chain bridge aggregators are not the only ones that benefit from this improved composability; any cross-chain application can leverage the fungibility of xERC-20 tokens to create more compelling applications.
However, it is not easy to achieve this at present due to path dependency issues. Suppose a developer wants to cross-chain ETH from Ethereum, open a lending position on Arbitrum DEX, and use the profit to buy NFTs on Optimism, and then cross-chain back to Ethereum. In this process, the developer must ensure integration with cross-chain bridge providers on these chains, because users cannot easily exchange proprietary versions. This changes when projects adopt xERC-20 and their cross-chain tokens are fungible.
This workflow is similar to the token issuer cross-chain bridge described above, taking Circle CCTP as an example:
Circle's cross-chain transfer protocol allows users to have a unified, standard version of the USDC token without being trapped in the ecosystem of different chains. All cross-chain transfers are handled through its protocol using a burning and minting scheme.
However, CCTP is a centralized protocol, and Circle’s operators are the only entities authorized to destroy and mint its USDC tokens, but xERC-20 can eliminate trust risks by allowing multiple entities with various security mechanisms to operate cross-chain transfers.
Support Ethereum’s vision of a Rollup-centric, multi-chain future
ERC-7281 can also accelerate Ethereum’s rollup-centric roadmap, giving projects the confidence to deploy tokens on new EVM L2s that may lack the strong security of existing L2 chains. For example, standard bridges for Phase 0 rollups are less secure because Ethereum L1 does not guarantee the security of bridges. Token projects can gradually deploy to such chains by granting limited minting rights to standard bridges and increasing minting limits after rollups enter Phase 1.
This process can continue until L2 reaches stage 2 (the highest stage of rollup decentralization and security). Through this mechanism, the protocol can be deployed on newly launched chains in a risk-minimizing manner, which is beneficial to the Ethereum ecosystem because it makes it easier for new L2s to guide token liquidity and applications while encouraging projects to innovate more in the field of rollup design.
Potential drawbacks of implementing ERC-7281
Increased costs for DAO project management teams
While ERC-7281 is very attractive for protocols, DAOs may be hesitant to adopt it due to the huge operational costs of managing xERC-20 tokens. DAO project teams must bear a lot of operational overhead to manage xERC-20 tokens across various deployments.
Gerard Persoon in Managing Cross-Chain Tokens on a Large Number of Chains provides a non-exhaustive list of one-off and recurring tasks that protocols must perform after migrating from ERC-20 to xERC-20:
One proposed solution is for the DAO to outsource some of the tasks associated with managing cross-chain xERC-20 tokens to a third-party service, but this is simply a trade-off between the cost of human resources and the cost of hiring a service.
Suppose a protocol previously used internal infrastructure to manage cross-chain tokens (e.g., deploying separate token contracts for each chain and controlling minting and burning). In this case, ERC-7281 does not seem to be a fundamental change. However, projects that are accustomed to outsourcing the management of core cross-chain infrastructure to cross-chain bridge development teams will find the additional workload worrying.
Managing xERC-20 tokens will impose non-negligible additional management costs on the protocol and community members. For example, cross-chain bridge restrictions require active monitoring and assessment of the security of the cross-chain bridge in order to adjust the minting limit based on this information, and decisions about cross-chain bridge restrictions (or the revocation/allocation of minting rights) may require a DAO vote (if such decisions need to be made frequently, DAO members may experience voting fatigue).
However, this should not be viewed as a value judgment on ERC-7281. Each project has a different risk profile, long-term goals, and resources — factors that together determine whether the long-term benefits of adopting ERC-7281 outweigh the short-term and ongoing costs.
For example, smaller projects may find it more expensive to manage the issuance of xERC-20 tokens and choose to use a managed multi-chain token cross-chain service like Axelar’s ITS (Interchain Token Service) or Wormhole’s NTT (Native Token Transfer). More mature projects may have the resources to manage the operational costs of issuing xERC-20 tokens and may decide that the control provided by ERC-7281 is worth the additional overhead of managing cross-chain tokens.
Difficulty in Migrating Existing Tokens to the xERC-20 Standard
For projects that do not have a minting/burning interface or cannot upgrade their token contracts to use IERC20, and already have a standard version of their native token circulating on a non-native chain, migrating to xERC-20 tokens is a long and heavily coordinated process involving a complex network of participants, including token holders, exchanges (DEX and CEX), partner bridges, and various applications that integrate with traditional ERC-20 tokens. Even if this part of the work is completed, the protocol still needs to bear the cost of unpacking ERC-20 into xERC-20 to complete the migration process.
As explained in the ERC-7281 standard discussion, existing tokens need to be locked in a lockbox in order to mint wrapped xERC-20s for users. However, the retirement of old ERC-20s may happen soon and involve another long process of communicating with the community around a timeline for freezing the minting of new (old) ERC-20 tokens. Again, this may be worthwhile from the protocol's perspective - although the benefits may also not be enough to justify the cost of coordinating the entire ecosystem to migrate to a version of xERC20 that is compatible with the protocol's tokens.
DAO governance is more risky
Managing xERC-20 tokens on multiple domains using ERC-7281 requires active governance by a DAO that oversees the protocol. This includes setting parameters such as minting limits, upgrading the Lockbox contract, and pausing minting or burning tokens. These decisions are sensitive and should be managed by a DAO to avoid liability for decisions made behind closed doors.
ERC-7281 is designed to give the protocol control over these decisions, rather than a third-party cross-chain bridge. This is necessary because DAOs already manage tokens on their native chain, so extending governance to tokens on other chains makes sense for protocols and communities seeking this control. However, some protocols may not want to have this additional DAO control due to concerns about governance and stability.
For example, Lido has faced scrutiny for governance issues, and increasing control over token management increases the risk of governance takeover. If a project consolidates all ERC-20 tokens into a lockbox and manages it under a DAO, a governance attack could have widespread effects. An attacker could take control of the lockbox and introduce a malicious cross-chain bridge provider with no minting limits, rendering xERC-20 tokens on other chains worthless.
The situation is similar to the Multichain vulnerability, where a vulnerability in the multi-party computation (MPC) signature infrastructure allowed hackers to compromise the main Multichain addresses that hold native tokens on Ethereum and Dogecoin - tokens that support tokens minted on non-native chains such as Fantom and Moonriver, creating a "domino effect" that caused projects elsewhere to suffer losses due to attacks on Multichain smart contracts on Ethereum and Dogecoin.
Incompatible with maximally decentralized protocols
ERC-7281 is only compliant when the token is issued by a protocol with token governance or a centralized entity (such as Circle’s USDC or CZKC stablecoins). However, it is less valuable if the protocol is maximally decentralized and lacks formal governance - Liquity’s LUSD stablecoin is an example of a token that is difficult to make compatible with the xERC-20 standard.
xERC-20 tokens require entities to decide on specific parameters, such as minting and burning limits, and make decisions such as whether to whitelist certain cross-chain bridge providers. This means that the existence of xERC-20 tokens requires ongoing governance. For projects that hope to decentralize key components of the protocol (such as the DAO's token contract) over time, this may cause problems and complicate decentralization plans.
Vulnerabilities related to core components (Lockbox contract and cross-chain bridge provider) pose greater risks
We have already mentioned how path dependency works and why it ensures that a vulnerability affecting chain A does not affect chain B, or a vulnerability in bridge A on chain A does not affect bridge B on chain B. The ERC-7281 standard eliminates path dependency, which brings benefits but also raises security trade-offs.
Since tokens minted by different cross-chain bridge providers are interchangeable across chains, the maximum liquidity available in the cross-chain bridge no longer represents the maximum impact that a cross-chain bridge vulnerability could have on token issuers. The authors of the ERC-7281 standard recommend setting a rate limit for cross-chain bridge providers based on the amount that token issuers can use to compensate for fraudulent minting losses; however, in retrospect, the selected rate limit may be too conservative.
If a high-limit cross-chain bridge is attacked, the impact could be significant, even affecting users of other cross-chain bridges that mint the same token. Therefore, the protocol can reduce risk by distributing minting rights to multiple cross-chain bridges (so that the number of tokens that a cross-chain bridge provider can mint is not too large compared to other cross-chain bridges), but avoiding risk in this way may reduce efficiency because each cross-chain bridge requires independent evaluation by the DAO team and coordination with more cross-chain bridges, which in turn increases the management costs mentioned above.
Additionally, Lockbox contracts managed by a DAO may also introduce adverse contagion effects in the event of a governance attack. Even with secure DAO governance, bugs in native/non-native Lockbox contracts on the token mainchain can cause just as many problems. In contrast, this problem is mitigated by the fact that Treasury contracts (the equivalent of Lockbox contracts for cross-chain bridge providers) only hold tokens bridged through the corresponding cross-chain bridge, as a bug in a provider's Treasury contract will only affect users who have deposited tokens in that cross-chain bridge.
The cost of ecosystem integration
The additional management work brought by the ERC-7281 standard also affects application developers and service providers who use the project's xERC-20 tokens. Cross-chain bridge aggregators need to track the mapping relationship between xERC-20 tokens and their corresponding Lockbox contracts to prevent problems such as spam tokens and spoofing attacks. While a registry of these mappings may help, it is challenging to establish such a registry without taking on centralization risks or exposing xERC-20 adopters to threats.
The risk comes from the fact that attackers may add malicious contracts to the token registry and trick users and developers into sending tokens to the wrong addresses. This may lead to token thefts on both L2 and L1 networks. Exchanges face similar challenges as counterfeit tokens may cause serious problems such as abnormal token behavior, which is different from audited standard tokens.
Summarize
The ERC-7281 standard provides a compelling solution to the problem of non-interchangeable cross-chain tokens and offers features that enhance user experience, decentralization, security, and flexibility in token cross-chain design. Some of these features directly impact the feasibility of the rollup-centric roadmap, making the xERC-20 standard a critical infrastructure for the Ethereum L2 ecosystem.
Currently, several key players in the cross-chain bridge space, including Hyperlane, Omni, Sygma, Router Protocol, and Everclear, have committed to adopting the ERC-7281 standard, indicating that the proposal has received widespread attention. Even some mature token issuers that already have cross-chain mechanisms for tokens (such as Circle) have shown interest in the ERC-7281 standard to address the challenges that unapproved tokens pose to users and developers. It is worth mentioning that for developers who are concerned about the ERC-7281 standard discussion or want to integrate xERC-20, the Fellowship of Ethereum Magicians and the xERC-20 website , as well as the xERC-20 Launchpad (a tool for aggregating the creation, monitoring, and management of xERC-20 tokens) will be important sources of information and tools.
