Gm! 👋

This document aims to give an overview of the xERC20 Bridge Token standard, specifically aiming to cover why it needs to exist, how the standard works, and current progress on submitting it for public review as an ERC.

Table of Contents

• Background on Bridging Tokens
  • Minting a Representative Token
  • Liquidity Pools
  • Comparison of Approaches & Tradeoffs
• xERC20 Design Goals & Rationale
  • Where does Fungibility Come From?
• How xERC20 Works
  • Components
  • Architecture & Flow
• Why Should You Use xERC20s?
• Standardization Status
• Next Steps

Background on Bridging Tokens

At a high level, there are two primary approaches to bridging ERC20 tokens. All bridges (including canonical bridges) use one or a combo of both of these methods.

Minting a Representative Token

In this model, the bridge locks or burns a token on the origin chain, and then mints a representation of the token at the destination.

<aside> 💡 Contrary to popular opinion, there is fundamentally no difference in trust model between burn/mint or lock/mint bridging. This makes sense if you think about it: ERC20 balances are a simple mapping(address=>uin256). It ultimately doesn’t affect security if the mapping stores bridged balance at address(0) or a specific contract address, since the bridge has permissions to update the whole mapping regardless.

</aside>

All canonical bridges use this approach. For example, the Optimism bridge mints a representative of USDT when USDT is transferred to the bridge address on L1. Some other examples of representative tokens:

• Other canonical bridges: the Arbitrum rollup bridge, Polygon PoS bridge, etc.
• Multichain-minted tokens. e.g. anyUSDC
• L0 OFTs, Axelar axlTokens, etc.

<aside> 🔒 Note: There are security implications to any representative token you mint across chains - you are always beholden to the security risk of the bridge that minted the token. In our example above, when you hold USDT on Optimism, you take on the risk of the Optimism bridge.

This is why, in general, users prefer to hold and use the canonical token on each domain which comes from the canonical bridge (as these bridges already underpin the security of the whole chain anyway).

</aside>

Liquidity Pools