No worries about secure cross-chain transactions? Understanding the xERC20 cross-chain token standard in one article.

Understanding the xERC20 cross-chain token standard in one article no worries about secure cross-chain transactions.

Author: Jessica

On July 25th, Layer 2 interoperability protocol Connext announced the launch of a cross-chain token standard, xERC20 (ERC7281), aimed at improving the security of token cross-chain transactions. The protocol was proposed by Arjun, a contributor to Connext. Arjun was inspired by the impact diffusion of the Multichain vulnerability.

Since July 7th, a total of $265 million has flowed out of Multichain and is distributed across Ethereum, BNBChain, Polygon, Avalanche, Arbitrum, Optimism, Fantom, Cronos, and Moonbeam chains. Among them, $65.82 million has been frozen by Circle and Tether, and 1,296,990.99 ICE (approximately $1.62 million) has been destroyed by the token issuer.

Arjun believes that bridged tokens face systemic risks, and the underlying potential issue is token sovereignty.

• UniswapX Opening the Gateway to Uniswap V4 DeFi Experimental Base
• Twitter renamed X, Musk ignites the X universe! From AI to exploring space, the prototype of a universal app emerges.
• Tokyo and Kyoto, the rising encrypted ‘twin stars

What is token sovereignty and how can it be abstracted?

Currently, token issuers usually choose two bridging solutions:

1. “Typical” bridging (such as rollup bridges) and cooperation with liquidity networks such as Connext or Hop. This is relatively secure but requires liquidity, which introduces slippage and high liquidity costs.

2. Use third-party mint/burn systems such as Multichain or L0 OFT. This solves the liquidity problem but permanently locks the issuer to the security of the underlying bridging mechanism, and it also undermines fungibility: for example, using the Arbitrum bridging mechanism would result in “different” tokens.

So why not let multiple bridging mechanisms use the same token? Arjun explains that this is detrimental to both security and fungibility. If two bridges hold 100 USDT each on L1, it would not be possible to transfer 200 USDT from L2 to L1 through only one bridge. If both bridges are hacked, the 200 USDT would be lost.

xERC20 rethinks bridging from first principles, where the token issuer is punished when the bridging mechanism is hacked. This means that the token issuer should decide: which tokens are “typical,” which bridges are supported, and the risk tolerance of each bridge. These considerations are collectively referred to as “token sovereignty.”

There are currently examples such as MakerDAO’s DAITeleport mechanism, fraxfinance’s FraxFerry, Circle’s CCTP, tBTC_project, and AngleProtocol that have considered the issue of token sovereignty, but these examples are highly customized.

xERC20 is a simple and minimal extension of the ERC-20 interface:

• Allow bridging mechanisms in the token issuer’s whitelist to call the token’s burn/mint interface.

• Flexibly set minting limits.

• “Lockbox”: a simple wrapper contract that integrates the liquidity of the main chain token and provides a direct adoption pathway for existing ERC20 tokens.

According to this proposal, ownership of the token will be transferred from the bridge (specification or third party) to the token issuer itself.

The token issuer decides which bridge to support for a specific domain (which can be L1 or L2) and gradually adjusts their preferences as they gain more confidence in the security of different options. If a bridge is hacked or has vulnerabilities, the issuer’s risk will be limited to the maximum fee of that bridge. The issuer can seamlessly remove the bridge without the need for users to go through a painful and time-consuming migration process.

Improving User Experience and Bridge Incentive Mechanism

• Bridges can now compete in terms of security, defining better issuer-defined fee limits for specific tokens and incentivizing them to adopt best security practices with minimal trust;

• Bridges no longer monopolize liquidity, which asymmetrically benefits projects with a large amount of funds for incentives;

• There is no longer slippage in cross-domain token transfers, providing users with better predictability and developers with more convenient cross-domain composability;

• Scalability issues related to liquidity and security associated with adding many new domains are alleviated. New cryptocurrencies no longer need to launch liquidity for each supported asset — this is particularly important as we are rapidly moving towards a world with thousands of interconnected domains.

xERC20 compatibility

• Compatible with all existing tokens through the Lockbox wrapper;

• Wide support for existing third-party bridges with burn/mint interfaces;

• Commonly used typical bridges. In most cases, Arbitrum, Optimism, Polygon, ZkSync, and GnosisChain have direct (unpermissioned) paths for xERC20 support.

Developer Concerns

On the Ethereum Magicians forum, developer auryn expressed overall support for this proposal, but also had some concerns:

How would this work for tokens without a governance layer, such as WETH?

This gives token issuers with governance mechanisms some additional, perhaps unnecessary, governance power. In some cases, issuers may not be able or willing to exercise this power in practice.

This may also mean the need for some meta-governance layer to decide which account should have bridge governance rights for a given token, as you cannot rely solely on the presence of owner() and each token’s owner() is correct.

Arjun responded that the core goal of this proposal is to solve the trade-off between liquidity/circulation and security, especially for long-tail assets, as these tokens cannot generate enough fee income from organic trading volume to sustain LP across many different chains. WETH does not have this problem, as it is one of the most common bridging assets besides USDT and USDC.

“In the long run, I believe LSDs like wstETH could be used as a “transport” layer for cross-chain interactions, and/or WETH could be completely replaced by tokenized versions of ETH.”

In addition, another developer, gpersoon and auryn, both believe that continuous cross-chain deployment and token management will increase management costs. Arjun proposes the following solutions:

• Firstly, there is already governance risk surrounding the control of deployed cross-chain tokens. However, these tokens are currently owned by the minting bridge, not the project. This is one of the key issues that this approach is trying to address;

• The implementation of managing cross-chain tokens is fundamentally similar to DAOs controlling their own cross-chain protocols. More and more DAOs have been using multiple identities and/or canonical bridges to achieve this functionality;

• Introducing dependence on canonical bridges is not ideal, even though it was primarily considered in the design of this proposal for the case of rollups, where there is less controversy in trusting canonical bridges for governance. However, according to the actual data of DAOs currently running, this issue can be addressed through multi-message aggregation (MMA) methods such as Hashi and/or using configurable cross-chain message optimistic delay, within which a security committee elected by the DAO can veto fraudulent messages.

According to the latest news, Connext has stated that projects deploying xERC20s through Connext today will be fully compatible with the final ERC-7281 standard, achieving 1:1 token transfers with 0 slippage between chains. In addition, the DeFi lending protocol Alchemix Finance has adopted this standard. Therefore, in the future, we will have the opportunity to observe and test the security and usability of this standard in practice.

We will continue to update Blocking; if you have any questions or suggestions, please contact us!