Implement Connext's xERC20 Standard

[nambrot]

xERC20 Standard

xERC20, pioneered by Connext, is a simple extension to the ERC-20 interface that enables token issuers to maintain control and flexibility over their token as they navigate the bridge risk landscape. xERC20 users can flexibly whitelist and rate limit different bridges over time.

Hyperlane enables permissionless chain expansion, and is looking to add support for xERC20. In this way xERC20 users can mint their assets wherever Hyperlane is deployed.

To achieve this we are looking for support building a Hyperlane xERC20 adapter. Implementing the following work for the token standard needs of xERC20. would also address the USDC standard below.

Bounty

This bounty captures the work necessary for Chain deployers to take advantage of Hyperlane's permissionless nature, while being compatible with Connext's standard from day 1. In this model, Hyperlane can be used to pass messages back and forth between the L1 and the L2. Users will interact with a modified version of the Hyperlane Warp Router UI to bridge the ERC20. Tokens will be directly minted and burned.

Acceptance Criteria

To complete this bounty, PRs should be merged in and a test deployment should demonstrate the functionality

Engineering Lift

Prerequisites

• Hyperlane deployed to both L1 and L2
• Hyperlane messages being passed automatically

Tasks

1. Deploy the XERC20 + XERC20Factory to the L2.
2. Create a HyperlaneXERC20Adapter contract. It should:
   • Follow the warp router interface for initiating a crosschain transfer, and burn the xerc20 + dispatch a hyperlane message.
   • Handle inbound hyperlane messages and mint the xerc20
3. (optional) Audit the HyperlaneXERC20Adapter contract.
4. Enlist the HyperlaneXERC20Adapter contract as a bridge on L1 and L2.
5. Update hyperlane ui to point to adapter contract.
6. Deploy hyperlane ui.

Tradeoffs + Assumptions

• Does not require chain operator buy-in.
• Does not require a lockbox.
• No tokens are locked, only minted and burned.
• Not subject to withdrawal timers on optimistic chains.
• Requires UI hosting (connext or hyperlane).
• Potentially requires an audit of the hyperlane adapter contracts.
• Requires hyperlane deployment and message passing (fees unclear here).
• Interface that is deployed will not be compatible with the IOptimismMintableERC20 (i.e. standard op-stack bridge)
• Supports L2 -> L2 transfers if hyperlane does.

Bonus Scope - Circle USDC

Circle's USDC is a major asset that brings many benefits to a chain ecosystem. Circle has their own token bridging solution called CCTP which facilitates USDC burn and mints across supported chains https://www.circle.com/en/cross-chain-transfer-protocol. CCTP is the desired mechanism for USDC since there are no additional trust assumptions necessary. However, it is very difficult to get the official USDC (with Circle's first-party native mints and burns) from day 1 for a chain and native USDC requires specific token contracts which is why USDC migration has been a significant thing to plan around like on Arbitrum

Circle has created the Bridged USDC Standard to prevent this problem from happening by outlining the requirements for possible native support later down the line (which would avoid the token ecosystem migration).

Recommended Steps

While there is a lot of flexibility on how this could be implemented, here is a recommended path of action for USDC, similar to the xERC20 work:

• Create a HyperlaneUSDCMinter contract
  • Should extend from TokenRouter (You can mostly follow the HypERC20 template
  • HyperlaneUSDCMinter should be able to receive a WarpRoute message from a HypErc20Collateral contract on the collateral chain and mint on a FiatToken (i.e. TokenRouters _transferTo function)
  • HyperlaneUSDCMinter should burn on FiatToken after called transferRemote (i.e. TokenRouter's _transferFromSender function)
• Support the deployment of FiatTokenProxy and HyperlaneUSDCMinter on the new chain in the CLI via a new synthetic type in the CLI/SDK
  • CLI: https://github.com/hyperlane-xyz/hyperlane-monorepo/blob/985adc91eb8e573174d7462932445b2af8c4b163/typescript/cli/src/deploy/warp.ts#L164
  • SDK Deployer: https://github.com/hyperlane-xyz/hyperlane-monorepo/blob/7d530fd4eb5d8256d1700713c54c3881d9d249c8/typescript/sdk/src/token/deploy.ts#L210
  • Set HyperlaneUSDCMinter as a minter via the masterMinter (in general move all permissions to the configured owner so that they can be transferred to Circle in the future)
• Ensure that the SDK's TokenAdapters work for HyperlaneUSDCMinter
• Ensure that the Warp Template still works for HyperlaneUSDCMinter

[jmrossy]

Adding a few more pointers here:

Like other token adapters, the new EvmHypUsdcMinterAdapter adapater should fully implement the IHypTokenAdapter interface.

Once that's done, define a new TokenStandard for this (suggest EvmHypUsdcMinter) and update the maps in this file. Then update the Token class to wire up the standard to the adapter.

[yorhodes]

I think this can be implemented agnostically to FiatToken FiatToken.mint FiatToken.burn this token variant would work with any contract that supports this mint and burn interface https://docs.openzeppelin.com/contracts/2.x/api/token/erc20#ERC20Mintable https://docs.openzeppelin.com/contracts/2.x/api/token/erc20#ERC20Burnable

[avious00]

this bounty is no longer available and was completed without bounty compensation by Abacus Works dev

[yorhodes]

completed without bounty compensation

😿