Detailed Explanation of Cross-Chain Token Standard xERC20: Mitigating Interoperability Risks Starting from Token Sovereignty

avatar
Jessica
1 years ago
This article is approximately 1028 words,and reading the entire article takes about 2 minutes
Rethinking "bridge" from first principles.

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

Since July 7th, the total amount of funds flowing out of Multichain has reached $265 million, distributed across Ethereum, BNB Chain, Polygon, Avalanche, Arbitrum, Optimism, Fantom, Cronos, and Moonbeam chains. $65.82 million has been frozen by Circle and Tether, and 1,296,990.99 ICE (approximately $1.62 million) has been burned by the token issuer.

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

Detailed Explanation of Cross-Chain Token Standard xERC20: Mitigating Interoperability Risks Starting from Token Sovereignty

What is token sovereignty and how can it be abstracted?

Currently, token issuers typically choose two bridging solutions:

1. "Typical" bridging (such as rollup bridges) in collaboration with liquidity networks like Connext or Hop. This is relatively secure but requires liquidity, leading to slippage and high liquidity costs.

Detailed Explanation of Cross-Chain Token Standard xERC20: Mitigating Interoperability Risks Starting from Token Sovereignty

2. Use a third-party mint/burn system, such as Multichain or L 0 OFT. This solves the liquidity problem, but it permanently locks the issuer's security on the underlying bridge. It also undermines fungibility: for example, using the bridge of Arbitrum will generate "different" tokens.

Detailed Explanation of Cross-Chain Token Standard xERC20: Mitigating Interoperability Risks Starting from Token Sovereignty

Why not let multiple bridges use the same token? Arjun explains that this is detrimental to both security and fungibility. If two bridges each hold 100 USDT on L 1, it is not possible to transfer 200 USDT from L 2 to L 1 through only one bridge. If both bridges are hacked, the 200 USDT will be lost.

xERC 20 rethinks bridging from first principles, where token issuers are penalized when bridges are hacked. This means token issuers should decide: which tokens are "typical," supported bridges, and the risk tolerance of each bridge. These considerations are collectively referred to as "token sovereignty."

There are currently: MakerDAO's DAI Teleport mechanism, fraxfinance's Frax Ferry, circle's CCTP, tBTC_project, and AngleProtocol, all of which have considered token sovereignty, but these examples are highly customized.

xERC 20 is a simple, minimal extension of the ERC-20 interface:

  • Allowing bridges in the token issuer's approved list to call the token's burn/mint interface.

  • Flexible setting of minting limits.

  • "Lockbox": a simple wrapping contract that aggregates liquidity of the main chain token and provides a direct adoption path for existing ERC 20.

Detailed Explanation of Cross-Chain Token Standard xERC20: Mitigating Interoperability Risks Starting from Token Sovereignty

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

The token issuer decides which bridge to support for a specific domain (L 1 or L 2), and over time, gains confidence in the security of different options and adjusts their preferences. If a bridge is hacked or has vulnerabilities, the issuer's risk is limited to the fee cap of that bridge. The issuer can seamlessly remove the bridge without subjecting users to a painful and time-consuming migration process.

Improving the user experience and bridge incentive mechanism

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

  • Bridges no longer have a monopoly on liquidity, which asymmetrically favors projects with significant funds available for incentives;

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

  • Liquidity and security scalability issues associated with adding many new domains are alleviated. New cryptocurrencies no longer need to bootstrap liquidity for each supported asset – this is particularly important as we rapidly move towards a world with thousands of interconnected domain names.

xERC 20 compatibility

  • Compatible with all existing tokens through the Lockbox wrapper;

  • Widely supported by existing third-party bridges with burn/mint interfaces;

  • Common typical bridgers. In most cases, Arbitrum, Optimism, Polygon, ZkSync, and GnosisChain all have direct (permissionless) pathways for xERC 20 support.

Detailed Explanation of Cross-Chain Token Standard xERC20: Mitigating Interoperability Risks Starting from Token Sovereignty

Concerns of Developers

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

How would this work for tokens without governance layers, like WETH?

This would give token issuers with governance mechanisms some additional, perhaps unnecessary, governance power. In some cases, issuers may be unable or unwilling to exercise this power in practice.

This may also mean the need for some meta-governance layer to determine which account should have bridge governance rights over a given token, as you can't just rely on the existence of owner() and each token's owner() being correct.

Arjun responded to this, saying that the core goal of the proposal is to address the trade-off between liquidity/circulability and security, particularly for long-tail assets, as these tokens cannot generate enough fee income from organic trading volume to sustain LP across many different chains. WETH doesn't have this problem since it's one of the most common bridged assets, apart from USDT and USDC.

"In the long run, I think LSDs like wstETH may be used as the 'transport' layer for cross-chain interaction, and/or WETH will be completely replaced by tokenized versions of ETH."

Furthermore, another developer, gpersoon, and auryn both believe that continuously deploying and managing tokens across chains would increase management overhead. In response to this, Arjun proposes the following solutions:

  • First, governance risks around controlling deployed cross-chain tokens already exist. However, these tokens are currently owned by the minting bridge, not the project. This is one of the key issues this approach seeks to address;

  • Implementing the management of cross-chain tokens is essentially the same as DAOs controlling their own cross-chain protocols. More and more DAOs are already using multiple identities and/or canonical bridges to achieve this functionality;

  • Even introducing dependencies on the standard bridge is not ideal. The proposal was primarily designed with rollups in mind, where there is less controversy in trusting the governance of the standard bridge. However, based on current data from DAO operations, this issue can be resolved using methods such as Hashi for multi-message aggregation (MMA), and/or utilizing configurable cross-chain message optimistic delay. Within this delay range, the security committee elected by the DAO can veto fraudulent messages.

According to the latest news, Connext has announced today that projects deploying xERC20 will be fully compatible with the finalized ERC-7281 specification, enabling 1:1 token transfers with 0 slippage between chains. Additionally, the DeFi lending protocol Alchemix Finance has adopted this standard. Therefore, we will have the opportunity to observe and test the security and usability of this standard thoroughly in practice.

Original article, author:Jessica。Reprint/Content Collaboration/For Reporting, Please Contact report@odaily.email;Illegal reprinting must be punished by law.

ODAILY reminds readers to establish correct monetary and investment concepts, rationally view blockchain, and effectively improve risk awareness; We can actively report and report any illegal or criminal clues discovered to relevant departments.

Recommended Reading
Editor’s Picks