SIP-352: Deploy SNX token as xERC20 for crosschain bridging

Simple Summary

Deploy SNX xERC20 and Lockbox to facilitate bridging between Ethereum and Base and allow for additional fast bridge solutions while retaining sovereignity.

Abstract

This propsal aims to implements ERC-7281, as known as the xERC20 standard, by deploying xERC-20 SNX on Ethereum and Base with SNX Lockbox on Ethereum.

xERC20 tokens are ERC-20 tokens which can be transferred with no slippage across chains without compromising on security.

Contrary to other proprietary crosschain standards, token issuers always retain control and sovereignty over their tokens This ability will allow Synthetix to whitelist specific bridges, giving them the rights to mint same representation of crosschain token. This allows for fine-grained control over minting/burning limits for each bridge. Limit potential damage should a security breaches happens.

Motivation

As SIP-350 and SIP-351 compete to provide fast bridging solutions for SNX, while improving user experience on waiting times, has created vendor lock-in. With many such cases from bridge imploding like Multichain. Recovering from those problems takes time and requires integration to redeploy everything which isn't ideal. By setting up xERC-20, Synthetix can add or remove bridges with canonical fallback while retaining same integration and liquidity,

Specification

Overview

The deployment on Ethereum consists of: xERC-20 token - Factory Repo Lockbox And the deployment on Base only needs to have xERC-20 token deployed on the rollup. This is to conform SNX into the burn-and-mint model for bridging. The specification for Lockbox is an ERC-20 wrapper inspired by WETH. The important part for xERC-20 is the bridge parameter and mint.burn function, controlled by governance and mint and burn function, only callable by Lockbox and bridges.

   /**
   * @notice Updates the limits of any bridge
   * @dev Can only be called by the owner
   * @param _mintingLimit The updated minting limit we are setting to the bridge
   * @param _burningLimit The updated burning limit we are setting to the bridge
   * @param _bridge The address of the bridge we are setting the limits too
   */
   function setLimits(address _bridge, uint256 _mintingLimit, uint256 _burningLimit) external;

   /**
   * @notice Mints tokens for a user
   * @dev Can only be called by a minter
   * @param _user The address of the user who needs tokens minted
   * @param _amount The amount of tokens being minted
   */
   function mint(address _user, uint256 _amount) external;

   /**
   * @notice Burns tokens for a user
   * @dev Can only be called by a minter
   * @param _user The address of the user who needs tokens burned
   * @param _amount The amount of tokens being burned
   */
   function burn(address _user, uint256 _amount) external;

The flow of bridging from Ethereum => Base is:

1. The user deposits tokens into Lockbox and mint xERC-20.
2. Bridge burns user's xERC-20 on Ethereum.
3. Bridge mints xERC-20 token on Base and credit to the user.

The flow of bridging from Base => Ethereum is:

1. Bridge burns user's xERC-20 on Base.
2. Bridge mints xERC-20 on Ethereum and credit to the user.
3. Users withdraw ERC-20 from the lockbox.

Importantly, all these steps can be abstracted from the user.

Rationale

Benefits

• Capital efficiency:

enables 0 slippage crosschain movements without any requirement to bootstrap liquidity in advance. No AMMs are required at all.

• Independence and Flexibility:

xERC20 is a bridge-agnostic open standard, providing token issuers the ability to retain control and sovereignty over their tokens, and the flexibility to use multiple bridges at the same time

• Granular security control

Security can be isolated per chain, per bridge and minting limits. Since the limits are enforced in the token contracts, you can effectively set per-chain limits as well, simply by having different limits for each bridge on each chain. The ability to add 3rd party bridges in the whitelist allows users to move tokens out of L2s without using the native bridges, providing a fast experience.

• Faster deployment, enhanced functionalities

Using the xERC20 would allow the DAO to easily and more cost-effectively deploy and launch to 1000 rollups with a simplified process, and enable additional functionalities like crosschain staking.

Risks

xERC-20 smart contracts have been tested and audited; as every smart contract they might be subject to vulnerabilities. However, we believe the risk is low as the standard is a light extension to the ERC-20 interface, and is already used in production by several projects.

What impacts the risk curve are the bridges that get whitelisted.

• If the Synthetix DAO decides to only whitelist native bridges, this would effectively have the same trust assumptions as bridging a token to the L2.
• If the DAO decides to whitelist other 3rd party bridges, this increases the risk for SNX. The xERC20 standard doesn’t enhance the security of the single bridge, but it allows to clearly confine the risk exposure for each bridging provider.

Example of deployed xERC20 token:

• Beefy mooBIFI is deployed with canonical bridge, Axlar, LayerZero and Chainlink's CCIP.
• Alchemix has whitelisted Connext and the native bridge.

Technical Specification

As a extension of ERC-20, token user can used it like any other token. For bridge aggreagtor, it will have to aware of each bridge limit from function defined within xERC20. For the bridge, it will have to call mint/burn function of xERC20.

Test Cases

N/A

Configurable Values (Via SCCP)

N/A

Copyright

Copyright and related rights waived via CC0.