Written by: 2077 Research Translated by: Glendon, Techub News

If you have not read the first part of the series "How to Make Cross-chain Tokens Re-interchangeable", it is recommended to review it first - this section analyzes the root causes of the loss of cross-chain tokens and the systemic challenges it arouses. In the second part, we will focus on the innovative standard of ERC-7281, which enhances reliability by restructuring the cross-chain token transfer mechanism and provides issuers with finer governance permissions.

The previous article has systematically discussed a variety of technical paths to solve the problem of interchangeability of cross-chain tokens, and solve the problems of fragmentation of liquidity and poor user experience caused by non-standard versions of native tokens circulating on non-native chains, including: minting standard versions of native tokens on the target chain through the standard Rollup/sidechain bridge protocol;

Rely on third-party cross-chain services to generate standard versions of native tokens on the target chain;

Standard bridging services independently operated by token issuers, implementing standard cross-chain token minting on the target chain.

The above solutions have their advantages and disadvantages. Therefore, the design philosophy of ERC-7281 (also known as xERC-20) lies in integrating the advantages of each solution, building a more comprehensive, efficient and scalable solution for protocols that hope to achieve cross-chain deployment of tokens, and achieving a breakthrough balance between security, sovereignty and user experience.

What is ERC-7281? ERC-7281: Sovereign cross-chain tokens is a proposal designed to create standard versions of tokens that enable them to be compatible and interchangeable with tokens minted by different cross-chain protocols. The standard introduces the following core functions through the extension of the ERC-20 interface:

Minning and destroying standards ERC-20 token functions;

Governance authority of token holders: 1. Authorize the designated cross-chain bridge provider to perform token minting/destruction operations during cross-chain transfer; 2. Set dynamic minting/destruction limits for each authorized cross-chain provider (for example, setting smaller restrictions on centralized cross-chain to set a safer protocolput higher limits).

In view of the subtle technical differences between the ERC-7281 and the ERC-20 token standards, the standard makers named it "xERC-20". Readers who want a systematic understanding of the standard infrastructure of the ERC-20 token can refer to the technical guide published by OpenZeppelin.

Essentially, each ERC-20 token contract manages the global token supply through standard interfaces, records address holding data, and includes basic functions such as token authorization management, circulation total query, address balance acquisition, etc.

ERC-7281 Token Standard has added an optional "Lockbox" contract module on top of the ERC-20 standard. As a package contract (functional similar to WETH contracts), the Lockbox contract can convert traditional ERC-20 tokens into xERC-20 token versions through the familiar minting and destruction mechanism. This design also enables the ERC-7281 to be backward compatible with existing ERC-20 token contracts that lack a destruction/mint interface and are not upgradeable.

According to the analysis framework of the first part, ERC-7281 can be classified as a cross-chain token minting paradigm of "trust token issuer + trust (approved) cross-chain bridge provider". Its core advantage is that the ERC-7281 tokens deployed across chains are completely controlled by the issuer (different from most cross-chain token solutions that require sovereignty) issuing parties still face the risk of security accidents being approved for cross-chain bridges, but they can manage them by manually selecting and restricting authorized cross-chain bridge providers.

The key breakthrough that this report focuses on issuing tokens can implement dynamic regulation of the minting/destruction quotas of designated cross-chain bridge providers, thereby accurately calibrating the risk exposure of cross-chain security incidents. In addition, ERC-7281 supports a whitelisting mechanism for multi-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 have significantly improved ERC-7281 compared to traditional methods, helping to facilitate cross-chain bridging of protocol tokens and generating for users, interoperability infrastructure providers (especially aggregators) and application developers.Positive second-order effect. The following will provide an in-depth analysis of technical specification details and systematically evaluate the potential advantages and disadvantages of implementing ERC-7281.

ERC-7281 Analysis: Sovereign cross-chain token minting and destruction mechanism for user tokens

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 equal amounts of tokens for it in the target chain. During the minting process, the system will check whether the number of tokens exceeds the minting limit of the bridge. If the verification is passed, the total supply of tokens and the cross-chain bridge minting limit will be updated.

For the existing ERC-20 tokens, we need to use Lockbox logic: the cross-chain bridge provider transfers the ERC-20 tokens deposited by the user to the Lockbox contract to complete the packaging and convert it into xERC-20 tokens. Lockbox then authorizes the provider to mint equal amounts of xERC-20 tokens.

The xERC-20 tokens minted 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 bridge's destruction limit. The bridge's transport layer relays the destroy message to the target chain, and the target chain's cross-chain bridge contract verifies the message and mints an equal amount of xERC-20 tokens to the user address on the chain.

In contrast, in order to cross-chain tokens back to the source chain, the cross-chain bridge provider will destroy the xERC-20 tokens on the target chain and provide the user's address and number of tokens. Destroy receipts are relayed by the transport layer to the source chain. If the destruction message is verified, the cross-chain bridge provider will perform the minting and destruction of xERC-20 tokens for the user on the source chain. The user can retrieve the original ERC-20 tokens after the token contract is confirmed to destroy the credentials. Source chain destruction operations simultaneously reduce the total supply of tokens and the cross-chain bridge destruction limit.

The point is that the xERC-20 contract supports casting operations without credential verification at the technical level. Although this article describes a standard verification process, token issuers can independently choose whether to include cross-chain bridges that have not implemented cross-chain message verification or adopt new verification mechanisms on the whitelist. The final decision-making power depends on the issuer's risk tolerance.

Token minting and destruction rate limiting mechanism

setBridgeLimits function is an insuredThe function protected can only be called by the token contract owner. This function allows setting the address of the bridge contract and specifying the maximum number of tokens that the cross-chain bridge can minting and burning Limits for the user. Owners can dynamically adjust restrictions to flexibly respond to changes in security situations of cross-chain bridge providers. For example:

When there is a vulnerability in the infrastructure of the cross-chain bridge, mintingLimit can be adjusted to control risk exposure;

In contrast, if the cross-chain bridge completes a security upgrade, the casting limit can be increased.

xERC-20 standard also includes the ability to check the destruction and minting restrictions of cross-chain bridges that are approved to handle tokens. "mintingMaxLimitOf" returns the maximum number of tokens that can be minted by a cross-chain bridge, while "burningMaxLimit" returns the maximum number of tokens that can be destroyed by a cross-chain bridge within a specified time. Additionally, these functions show the number of remaining tokens that the cross-chain bridge can destroy and mint before reaching the preset limit.

This design is crucial for cross-chain bridge aggregators - if a cross-chain bridge touches the destruction or casting limit on the source/target chain, it will cause transaction delays or even failures. Therefore, aggregators tend to route requests to cross-chain bridges with sufficient available limits and support target transaction volume.

Rate limit parameter analysis

The "Bridge" structure defined in the xERC-20 token interface standard contains "burningParams" and "mintingParams" (the parameter of the xERC-20 token rate limit function controls how many tokens can be destroyed and minted by the bridge within a predefined time). "maxLimit" defines the maximum limit for token minting and destruction and increases per second at a predefined rate (ratePerSecond).

Here we want to solve a problem that may cause confusion: "maxLimit" (set for destruction and casting restrictions) is the limit on casting and destruction operations within a specific time range, that is, the rate limit for casting and destruction is limited according to predefined thresholds within the preset time window. "currentLimit" defines how much a cross-chain bridge can be cast or destroyed and increases at a predefined rate. In contrast, "maxLimit" defines the number of tokens that cross-chain bridges can mint or destroy every day.

Destruction and minting parameters are mainly related to the token owner (less relationship with the cross-chain bridge provider). However, maximum and current limiting parameters are important considerations for both users and cross-chain bridge providers. For example, the current limit may affect the extent to which users can feel confident using cross-chain protocol bridges without experiencing delays when target links receive xERC-20 tokens.

xERC-20 Lockbox

The initial ERC-20 token does not specify the function of increasing and decreasing token supply (early token economics mostly adopted a fixed total model). Therefore, not every ERC-20 token has minting and destroying capabilities. Since ERC-7281 uses the minting and destruction mechanisms favored by most current cross-chain bridges, backward compatibility with ERC-20 tokens is required through Lockbox.

In the original standard (i.e., the project deployment of a new token contract that implements the IXERC20 interface), the cross-chain bridge provider simply calls mint() to mint for the user on the target chain (after locking the deposit on the source chain). The Lockbox contract borrows from the WETH encapsulated contract design. It implements a deposit() function for depositing the corresponding ERC-20 tokens into Lockbox and implements a withdraw() function for cross-chain bridge providers to unlock ERC-20 tokens after destroying the packaging tokens on the remote chain.

The first two error types ("IXERC-20Lockbox_NotNative" and "IXERC-20Lockbox_Native") that are highlighted in this standard occur when a user tries to deposit the token into the wrong Lockbox contract. Lockbox can be native (or non-native), depending on the type of token it supports.

Native Lockbox holds native tokens, that is, tokens used to pay Gas fees to validators. A typical example of a token with native Lockbox to wrap it into xERC-20 tokens is ETH: wrapping ETH into xERC-20 tokens requires calling Lockbox's depositNative() function and depositing it into ETH to receive ETH token versions compatible with ERC 7281.

Non-native Lockbox can be kept ERC-20 tokens, such as USDC, DAI, WETH, USDT, etc. For example, to mint USDC as xERC-20 tokens, users need to call deposit() on the Lockbox contract after locking USDC. Calling deposit() with ETH causes these funds to be permanently locked, because non-native Lockbox contracts can only wrap and unpack ERC-20 tokens. Additionally, calling depositNative() with ERC-20 tokens produces similar results, as the native Lockbox contract is designed to use native tokens, not ERC-20 tokens.

In this way, Lockbox provides an important layer of compatibility for the standard by packaging the standard ERC-20 tokens into xERC-20 tokens with coin/destruction support. 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, the project may implement an adapter contract.

Adapter Contract

If the cross-chain protocol cannot recognize operations inherent to the xERC‑20 token (minting/destruction, event logging, etc.), the application layer can build the adapter contract. These contracts act as automatic wrappers and unpackers, effectively converting ERC‑20 approval + call behavior into the more detailed casting/destruction 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. Adapter contracts can bridge this compatibility gap by implementing the logic that it deposits tokens into Lockbox to generate the xERC‑20 version on the source chain, and then triggers an exit mechanism to restore to the standard asset after receiving the message on the target chain.

This process ensures that users end up receiving consistent standard tokens without being affected by the encapsulation mechanism supported by the underlying xERC-20. This allows adapters to seamlessly integrate protocols with non-xERC-20 standard cross-chain bridges and increase the scope of interoperable solutions they support.

Why choose ERC-7281? Sovereign cross-chain generationCoin Standard Case

Overall, ERC-7281 has four major goals: 1. Interchangeability: Users who bridge tokens from their native chain to another (L1/L2) chain should always receive the standard version of cross-chain tokens on the target chain. For reasons explained above (such as liquidity decentralization and poor token composability), multiple non-interchangeable versions of the same token circulate in non-native chains are problematic. The initial vision of creating the ERC-20 standard was to ensure that tokens on Ethereum are interchangeable and seamlessly interoperable between applications and Ethereum infrastructure. However, after adopting a rollup-centered extension roadmap, there is a problem of lack of atomic composability, and the creation of many different domains reduces these interchangeability properties. xERC-20 allows the aggregation of various liquidity across rollup bridges into a unified multi-rollup token standard, thus restoring Ethereum’s initial vision.

2. Security: In order to reduce counterparty risks, token issuers must have the right to choose independently and select multiple providers based on the evaluation of the security infrastructure of cross-chain bridge providers. At the same time, the issuer needs to establish an effective risk isolation mechanism - when some bridging service providers encounter security incidents, their impact range should be strictly limited to avoid a single attack causing a complete collapse of the total lock value of the protocol (TVL).

3. Cold start of cross-chain tokens with zero liquidity dependence: Protocol DAO should not be forced to use large amounts of (funded) resources to guide the liquidity of cross-chain tokens as part of a multi-chain expansion plan. Cross-chain based on liquidity is not only unfavorable to user experience, but also as the number of support chains increases rapidly, project parties' expenditure on providing incentives for liquidity may become unfeasible.

4. Sovereign control of token issuers: The issuer shall continue to control the standard version of protocol tokens minted on non-native chains. To solve the problem of irreplaceable cross-chain tokens, it should not be at the cost of transferring control of tokens (especially in controlling the total supply, configuring minting and destruction mechanisms and other management aspects).

Next, we will further expand these goals to understand what benefits ERC-7281 brings to the protocol and the community.

ERC-7281's advantages improve user experience and eliminate liquidity fragmentation

ERC-7281 solves various path dependencies problems. Path dependencies can be chain-specific (e.g., cross-chain from Ethereum toThe ETH from Arbitrum and cross-chain to Optimism is different from the ETH from Ethereum to Optimism and cross-chain to Arbitrum), or is bridge-specific (for example, the ETH from Ethereum to Optimism through Celer is also different from the ETH from Ethereum to Optimism through Connext).

Although path dependence has security value, it seriously damages cross-chain user experience and composability. Taking the cross-chain DEX scenario as an example, if users need to inject capital 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. xERC-20 always maintains interchangeable features regardless of the number of times the user crosses the chain or what kind of cross-chain bridge provider it uses. For example:

users can transfer Arbitrum's encapsulated USDT to Optimism without withdrawing to the Ethereum chain;

After the cross-chain bridge provider destroys the xERC-20 tokens of the Arbitrum chain, they can mint equal tokens in Optimism;

The value of the target chain token always anchors the native asset reserves in Lockbox, maintaining 1:1 rigid redemption.

It is worth noting that ERC-7281 realizes the advantages of standard token deployment similar to Circle CCTP (cross-chain transmission protocol), but does not require the protocol party to centrally custodialize cross-chain assets. Its core value lies in:

Liquidity aggregation: forming a unified market around the standard version of protocol tokens, improving the effectiveness of DeFi applications;

Operational cost reduction: avoid creating segmented markets for different versions of the same asset.

Strengthen the sovereign control of token issuers

xERC-20 is called "sovereign cross-chain tokens" because token issuers do not have to lock in useSpecific options to mint standard versions of tokens and retain control over cross-chain token design and management in cross-chain deployments. ERC-7281 is a hybrid between “minting standard tokens through third-party bridges” and “critical tokens controlled by token issuers” that combines sovereignty, user experience and decentralization.

Projects that use ERC-7281 to deploy tokens across chains can mint standard versions of native tokens through multiple bridges without encountering non-interchangeable packaging versions of the same native asset, resulting in damage to user experience. Such projects also retain a level of control over token cross-chain deployment similar to token issuers, who run internal infrastructure to manage the transfer of standard tokens between domains, as the xERC-20 token contracts and Lockbox (cross-chain bridges are used to lock, mint and destroy tokens for users) are deployed and controlled by the project.

This undervalued feature is very useful when a well-known project issues native tokens on its main chain, especially when users from other ecosystems want to reach the token for different reasons but do not want to hold it on its native chain.

In this case, the project has no ability or willingness to run an 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 third parties that do not necessarily align with the protocol and its community. When implementing cross-chain governance, this situation will become a consideration, allowing cross-chain tokens to vote while voting statistics are performed on native chains; non-consistent cross-chain bridge providers with control of cross-chain tokens become bottlenecks in protocol governance.

For the above reasons, the Earnings Farming Agreement Beefy adopts 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 becomes essential after major cross-chain bridge partners are hacked) and provides more granular control over cross-chain mechanism design. In Beefy's case, ERC-7281's whitelisting feature enables the protocol to select a variety of cross-chain partners and provide users with different options for speed, decentralization, cost and security when bridging mooBIFI tokens.

The incentive mechanism is readjusted to promote open competition and security

Liquidity-based bridges usually favor projects with financial ability to fund liquidity incentives—as token issuers want to spend less on liquidity providers (LP) incentives and provide good cross-chain bridgesUser experience, so liquidity is the most critical factor for protocols that use standard L1/L2 bridges. This also extends to the choice of cross-chain bridge aggregators for cross-chain bridge providers, arguably making it harder 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 cross-chain requirements based on liquidity. Without minting and exchanging non-standard tokens into standard tokens, bridges of any size can be approved to mint projects on the target chain. As token issuers want to minimize the risk of cross-chain failure, more protocols may begin to focus more on the security design of cross-chain bridges rather than prioritizing liquidity.

This inspires open competition because it becomes a situation where the safest bridge wins rather than "let the most liquid bridge wins"; this open competition can take the form of cross-chain bridges competing on other functions other than liquidity/safety (such as fees, API/SDK, application integration, etc.). These features are easier to incorporate into the application from the start because they mainly depend on the expertise of the development team; by contrast, liquidity and cross-chain quantity are harder to start, requiring a combination of business development, capital, industry connections, marketing and other factors.

Provide better risk management for token issuers

ERC-7281 introduces configurable rate limits for token minting and destruction, which greatly improves the risk profile of cooperation with third-party cross-chain protocols that mint standard tokens on non-native chains. If a cooperative cross-chain bridge provider encounters a hacker attack or intrusion, the maximum damage the attacker can cause is equivalent to the limit limit of the damaged bridge. If the token issuer carefully selects the rate limiting parameters, the impact of isolated attacks on a certain cross-chain bridge may be minimized.

In addition, configuring rate limits for each cross-chain bridge can improve the risk assessment process of the protocol DAO. The adoption of ERC-7281 makes risk assessment more dynamic. Projects still require due diligence on cross-chain bridge providers to select appropriate rate-limiting attributes; however, the risk assessment timeline can be shortened. Rather than spending months analyzing multiple cross-chain bridges to select one, the project party can select multiple cross-chain bridge providers and set different casting restrictions based on the security assessment. The token issuer can then conduct a security review to determine whether to increase or decrease the minting restrictions of selected cross-chain bridge partners, or withdraw the minting rights from a cross-chain bridge (e.g., in response to hacking attacks or vulnerability disclosures).

ERC-7281 also reduces the obstacles faced by projects that want to adopt cross-chain bridge security technology but are reluctant to fully adopt a technology unless the technology is tested and rigorously scrutinized by the community (i.e., the dilemma of innovators). Suppose that cross-chain bridge providers have proposed a new infrastructure that can significantly improve security. In this case, the agreement can "test" by allocating limited coin rights to the bridge and gradually increasing the coin limit for the bridge as confidence in the proposed system design increases.

Just like eliminating liquidity-related concerns, eliminating the need for 100% trust in the cross-chain bridge technology stack before minting rights can create equal competition between new entrants and old players—old players are motivated to iterate better security approaches, as token issuers now have the flexibility to withdraw coin rights and reassign them to smaller projects, which show higher commitment to security and decentralization.

At the same time, this also eliminates another risk factor for agreements that cooperate with third-party cross-chain bridges: Despite the rapid disclosure and discovery of vulnerabilities and problems in cross-chain bridge security, selected cross-chain bridge providers may still stop innovating in security because it knows that token issuers cannot implement penalties (e.g., rapid migration to another cross-chain bridge provider), and it is difficult to perform such activities.

Improving composability among ecosystems

Because liquidity-based bridging pricing is unpredictable, it is difficult to build complex application workflows that require routing tokens through any number of chains today. For example, a bridge aggregator from Ethereum → Linea → Base has two options:

Because liquidity-based cross-chain bridge pricing is unpredictable, it is very difficult to build complex application workflows that require routing tokens through any number of links. For example, the cross-chain bridge aggregator from Ethereum → Linea → Base has two options:

set the slippage tolerance parameter and perform cross-link routing pricing based on the minimum number of tokens to be received on each chain (depending on the amount of liquidity available when the cross-chain message arrives at each layer);

does not set the slippage tolerance parameter, and if the number of tokens received on one or more chains is less than the expected number, then logic is created to obtain on-chain liquidity (e.g. through DEX).

In contrast, by examining the mintingLimit and burningLimit of the cross-chain bridge that allows minting a specific token, the bridge aggregator can know in advance how many tokens should be in each domain in a cross-chain transaction.

Authentic, during the period between transaction broadcasting and transactions reaching a domain, a cross-chain bridge may reach maxLimit—which means that the user cannot receive standard tokens on the target chain. However, ERC-7281 is still an improvement in this regard for the following reasons:

If the cross-chain bridge provider reaches mintingLimit during the transaction, the cross-chain transaction will be suspended and retry after the rate limit parameter is adjusted. Unlike today's liquidity bridges, users do not receive a proprietary packaged version of the standard token.

The cross-chain bridge aggregator has higher predictability for when cross-chain transactions are executed and the expected number of tokens. Since mintingLimit and burningLimit are configured to use blocks as time measures (as shown in the Rate Limit Parameters section), it is easy to calculate when the cross-chain bridge will start minting and destroying tokens again; by contrast, predicting when liquidity in the cross-chain bridge will increase is tantamount to playing "Russian roulette".

Unpredictable changes in liquidity also mean retrying the unpredictability of cross-chain transaction pricing. Suppose a cross-chain bridge aggregator (or another application) quotes the cross-chain exchange based on the current price of the token pair in the cross-chain bridge liquidity pool (this price is based on total pool liquidity). However, due to a sharp decline in pool liquidity, the transaction cannot be executed. Suppose the transaction is suspended and retry later. In this case, the app developer cannot know if the previous quote is still accurate or if liquidity will reach the same level as the user first submitted a transaction.

While cross-chain xERC-20 tokens are not affected by liquidity changes, users can be confident that cross-chain transactions will not create slippages—even if they will not be executed immediately.

The cross-chain bridge aggregator is not the only aggregator that benefits from this composability improvement; any cross-chain application can leverage the interchangeability of the xERC-20 tokens to create more attractive applications.

Due to path dependency issues, it is not easy to implement this at present. Suppose the developer wants to open a lending position on Arbitrum DEX from Ethereum cross-chain ETH, and use the profit to buy NFT on Optimism, and then cross-chain back to Ethereum. In the process, developers must ensure integration with cross-chain bridge providers on these chains, as users cannot easily exchange proprietary versions. When the project adopts xERC-20, its cross-chain tokens are replaceable, the situation changes.

This workflow is similar to the token issuer cross-chain bridge described earlier. Taking Circle CCTP as an example:

Circle's cross-chain transmission protocol allows users to have a unified, standard version of USDC token without being trapped in the ecosystem of different chains. All cross-chain transmissions are processed through their protocol using destruction and casting schemes.

However, CCTP is a centralized protocol, and the operator of Circle is the only entity authorized to destroy and mint its USDC tokens, but xERC-20 can eliminate the risk of trust by allowing multiple entities with various security mechanisms to operate cross-chain transmission.

Supporting Ethereum's vision of Rollup-centered, multi-chain future

ERC-7281 can also accelerate Ethereum's rollup-centered roadmap, giving projects confidence to deploy tokens on new EVM L2s, which may lack the strong security of existing L2 chains. For example, the standard bridge of the stage 0 rollup is not very secure because Ethereum L1 does not guarantee the security of the bridge. Token projects can be deployed gradually to such chains by granting limited coin rights to the Standard Bridge and adding coin restrictions after rollup enters Phase 1.

This process can continue until L2 reaches stage 2 (the maximum decentralization and security of rollups are achieved). Through this mechanism, protocols can be deployed on newly launched chains in a risk-minimized way, which benefits the Ethereum ecosystem as it makes it easier for the new L2 to guide token liquidity and applications, while encouraging project parties to innovate more in the rollup design field.

Potential drawbacks of Implementing ERC-7281 The cost increase of DAO project management team

Although ERC-7281 is very attractive for the protocol, but DAO may hesitate to adopt it due to the huge operating costs incurred in managing the xERC-20 tokens. The DAO project team must bear a significant operational overhead to manage the xERC-20 tokens in various deployments.

Gerard Persoon In Managing Cross-Chain Tokens on a Large Number of Chain, Gerard Persoon lists an incomplete list of one-time and repetitive tasks that the protocol must perform after migrating from ERC-20 to xERC-20:

One ​​proposed solution is that DAO outsources some of the tasks associated with managing cross-chain xERC-20 tokens to third-party services, but this is simply a trade-off between a cost of human resources and the cost of hiring services.

Suppose a protocol uses internal infrastructure to manage cross-chain tokens (for example, deploying separate token contracts for each chain and controlling minting and destruction). 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 to be worrying.

Managing xERC-20 tokens will bring an increase in management costs to protocols and community members that cannot be ignored. For example, cross-chain bridge restrictions require active monitoring and evaluation of cross-chain bridge security in order to adjust casting restrictions based on this information, while decisions regarding cross-chain bridge restrictions (or revocation/allocation of casting rights) may require DAO votes (if such decisions need to be made frequently, DAO members may feel voting fatigue).

However, this should not be considered a value judgment of ERC-7281. Each project has different risk profiles, long-term goals and resources—all these factors 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 issuing xERC-20 tokens and choose to use custodial multi-chain token cross-chain services like Axelar's ITS (Cross-chain Token Service) or Wormhole's NTT (Native Token Transfer). More mature projects may have the resources to manage the operating costs of issuing xERC-20 tokens and may think that the control provided by ERC-7281 is worthy of the burden ofResponsible for the additional overhead of managing cross-chain tokens.

Migrating existing tokens to the xERC-20 standard is difficult

For projects that do not have a minting/destroying interface or cannot use IERC20 by upgrading token contracts, and already have standard versions of native tokens circulating on non-native chains, migration to xERC-20 tokens is a long and heavily coordinated process and involves a complex network of participants, including token holders, exchanges (DEX and CEX), partner bridges, and a variety of applications integrated with traditional ERC-20 tokens. Even if this part of the work is done, the protocol still has to bear the cost of unpacking the 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 Lockbox in order to mint packaged xERC-20 for users. However, the phase-out of the older ERC-20 may occur soon and involves another long-term process, communicating with the community around a timeline for freezing the new (old version) ERC-20 token minting. Again, from a protocol perspective, this may be worth it – although the benefits may not be enough to justify the cost of coordinating an ecosystem to the xERC20 version compatible with the protocol token.

DAO governance has greater risk profile

Managing xERC-20 tokens on multiple domains using ERC-7281 requires monitoring the DAO of the protocol for active governance. This includes setting parameters such as minting restrictions, upgrading Lockbox contracts, and suspending minting or destroying tokens. These decisions are sensitive and should be managed by the DAO to avoid liability for closed-door decisions.

ERC-7281 is designed to allow protocols to control these decisions, rather than third-party cross-chain bridges. This is necessary because DAO already manages tokens on its native chain, so extending governance to tokens on other chains is reasonable for protocols and communities seeking such control. However, some protocols may not want to have such additional DAO control due to concerns about governance and stability.

Lido, for example, faces scrutiny on governance issues, and increasing control over token management increases the risk of governance takeover. If a project integrates all ERC-20 tokens into a single Lockbox and is managed by a DAO, governance attacks can have a wide range of impacts. Attackers can control Lockbox and introduce a malicious cross-chain bridge provider without minting restrictions, making the xERC-20 tokens on other chains worthless.

This situation is similar to the Multichain vulnerability, where the vulnerability in the Multi-party Computing (MPC) signature infrastructure enables hackers to compromise the main Multichain addresses that hold native tokens on Ethereum and Dogecoin—these tokens that support tokens minted on non-native chains such as Fantom and Moonriver, resulting in the "domino effect" that causes projects elsewhere to suffer losses from attacks on Multichain smart contracts on Ethereum and Dogecoin.

Incompatible with protocols that maximize decentralization

ERC-7281 meets the requirements when tokens are issued by protocols with token governance or centralized entities (such as Circle's USDC or CZKC stablecoin). However, if the protocol is maximally decentralized and lacks formal governance, it is of little value—Liquity’s LUSD stablecoin is an example of tokens that are difficult to compatible with the xERC-20 standard.

xERC-20 Tokens require entities to decide on specific parameters, such as minting and destruction restrictions, and make decisions about whether to whitelist certain cross-chain bridge providers. This means that the existence of xERC-20 tokens requires continuous governance. For projects that want to decentralize key components of the protocol, such as DAO's token contracts, over time, this can raise problems and complicate the decentralization plan.

Vulnerabilities related to core components (Lockbox contracts and cross-chain bridge providers) pose greater risks

The above mentioned how path dependencies work and why it ensures that vulnerabilities affecting chain A do not affect chain B, or that vulnerabilities in bridge A do not affect bridge B on chain B. The ERC-7281 standard eliminates path dependencies, which brings benefits, but also raises security trade-offs.

Because tokens minted by different cross-chain bridge providers are interchangeable between cross-chain bridges, the maximum liquidity available in cross-chain bridges no longer represents the greatest possible impact of cross-chain bridge vulnerabilities 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 the token issuer can use to compensate for fraudulent minting losses;Nevertheless, from a review point of view, the selected rate limit may be too conservative.

If a cross-chain bridge with high limitations is attacked, its impact may be significant, and even affects users who use other cross-chain bridges that mint the same token. Therefore, the protocol can reduce risk by allocating the minting rights to multiple cross-chain bridges (so the number of tokens a cross-chain bridge provider can mint compared to other cross-chain bridges), but avoiding risk in this way may reduce efficiency, as each cross-chain bridge requires independent evaluation by the DAO team and coordinate with more cross-chain bridges, which in turn increases the management costs mentioned above.

In addition, Lockbox contracts managed by DAO may also introduce adverse contagious effects in the event of a governance attack. And even with secure DAO governance, errors in native/non-native Lockbox contracts on the token main chain can cause just as many problems. In contrast, this problem is alleviated because the vault contract (the Lockbox contract equivalent of the cross-chain bridge provider) only holds tokens bridging through the corresponding cross-chain bridge, because a vulnerability in a provider's vault contract will only affect users who deposit tokens in the cross-chain bridge.

Cost of ecosystem integration

The additional management efforts brought by the ERC-7281 standard also affect application developers and service providers using project 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 these mapped registries may be helpful, it is challenging to establish such registries without taking centralization risks or putting xERC-20 adopters at risk.

The risk comes from an attacker who may add malicious contracts to the token registry and trick users and developers into sending tokens to the wrong address. This could lead to token theft on L2 and L1 networks. Exchanges face similar challenges, as forged tokens can cause serious problems such as abnormal behavior of tokens, which is different from standard tokens that have been reviewed.

Summary

ERC-7281 standard provides a compelling solution to the non-interchangeable cross-chain token problem and provides capabilities to enhance user experience, decentralization, security and cross-chain design flexibility. Some of these features directly affect the feasibility of rollup-centric roadmaps, making xERC-20 Standards become the critical infrastructure of the Ethereum L2 ecosystem.

Currently, key players in multiple cross-chain bridge areas 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 (such as Circle) with existing token cross-chain mechanisms have shown interest in the ERC-7281 standard to solve the challenges posed by unauthorized tokens to users and developers. It is worth mentioning that for developers who follow the ERC-7281 standard discussion or want to integrate xERC-20, the Fellowship of Ethereum Magicians and xERC-20 websites, as well as the xERC-20 launch pad, a tool for aggregating the creation, monitoring and management of xERC-20 tokens, will be important sources of information and tools.