SIP-311: snxUSD Teleporters (V3)

Author
StatusImplemented
TypeGovernance
NetworkEthereum & Optimism
ImplementorMEB (@barrasso), Daniel Beal (@dbeal-eth)
ReleaseTBD
ProposalLoading status...
Created2022-11-01

Simple Summary

This SIP proposes the addition of a cross-chain transfer function to the snxUSD token.

Abstract

Leveraging cross-chain messaging, Synthetix is able to implement highly efficient digital asset transfer via teleportation. In its simplest form, this entails burning snxUSD on a source chain, sending a cross-chain message containing the amount burned, and minting that quantity of tokens on the destination chain. A teleportation fee can be collected and distributed to backers of snxUSD. Teleporters will initially be deployed on the networks where Synthetix already exists (i.e. Ethereum & Optimism).

Motivation

As liquidity in DeFi continues to move across various L2s, it is increasingly important for protocols to create chain-agnostic abstractions. Given that Synthetix is currently deployed on two chains, the ability to transfer assets bi-directionally (without a challenge verification period imposed by roll-ups, e.g.) would already be a very valuable feature for the protocol.

Teleporters were originally proposed in SIP-204, but implementation was postponed due to the lack of decentralized cross-chain messaging solutions available. This proposal entails the use of the Cross-Chain Interoperability Protocol (CCIP). Because Synthetix is already dependent on Chainlink's infrastructure for price feed oracles, this proposal doesn't create any trust assumptions with additional third parties.

Teleporters are an improvement over AMM-based cross-chain bridging solutions because there is no slippage incurred from liquidity available on destination chains. Instead, the protocol can apply a fee structure at the discretion of governance, further incentivizing stakers to back the stablecoin.

Technical Specification

Overview

Teleporters involve adding transferCrossChain and ccipReceive functions to the snxUSD token with appropriate validations and fee capture functionality.

Rationale

We propose making the transfer function available on the snxUSD proxy, rather than the core system proxy. This is an extension of the ERC-20 interface (which already essentially includes a "same-chain" transfer function).

Using CCIP for token transfers

In addition to the new functions outlined in the technical specification below, this SIP also proposes that Chainlink's CCIP token pools be granted permission to mint and burn snxUSD in order to facilitate the cross-chain token transfers. This method allows for multiple benefits as described below:

Composability & Commercial Opportunity

Token transfers using the CCIP token pools provide Synthetix the opportunity in the future, if desired, to open up Chainlink's private snxUSD Token Pool which would allow third parties to transfer snxUSD (even in combination with other tokens and/or data). In this scenario, there is also potential to set up a rev-share model between CCIP and Synthetix (as snxUSD token issuer) for third-party CCIP snxUSD token transfers, creating a shared incentive for increased snxUSD token transfer volume over CCIP.

Enhanced security via the Active Risk Management (ARM) Network

With token transfers, the ARM Network has access to additional transaction information (i.e. token, amount) that enable it to perform additional risk management policies which cannot be implemented for arbitrary messaging. The ARM rule set will evolve over time into more advanced logic to identify and mitigate additional risks.

Enhanced security via Rate Limits

In contrast to arbitrary messaging, CCIP token transfers provide configurable rate limits per token pool per lane, which are set up in alignment with the token issuer. This feature is part of the heavily audited CCIP code base and only available for token transfers. CCIP token transfers also benefit from increased security via the global rate limits (across token pools), so not every token’s rate limit could be exploited at maximum in a worst case scenario.

Fee Collection

This proposal entails collecting fees in ETH, rather than snxUSD, for the following reasons:

  • Users will always receive the same amount of snxUSD that they have transferred.
  • This is the most efficient method to collect fees, as no additional token transfers are involved in the transaction.
  • Users are already paying ETH for gas fees to execute the transaction.
  • Reduces code complexity since the CcipRouter handles the fee calculation for the execution of the specified message.
  • Users are automatically refunded the difference between the msg.value that the user passes to transferCrossChain() and what the CcipRouter returns as getFee().

Future SIPs could involve additional fee payment methods (such as snxUSD), alternative fee structures, and circuit-breaking functionality for added security.

Implementation

Implementation entails adding two new functions to the snxUSD token module:

transferCrossChain(uint64 destChainId, address to, uint256 amount) external payable returns (uint256 gasTokenUsed)

  • Confirm that the sender has a sufficient balance of snxUSD to transfer.

Approve the amount of snxUSD to be transferred to the CCIP Router.

  • Encode the snxUSD token address and amount, and call ccipSend.
  • Refunds any left over gas token (i.e. the difference between msg.value and CcipRouter.getFee()).

ccipReceive(Any2EVMMessage calldata message)

  • Verify that the srcChainId and sender data in the message correspond to a legitimate deployment of the snxUSD token.
  • Transfer the amount of minted snxUSD tokens to the destination address, as specified in the message's data.

Note that this function must conform to the existing CCIP interface.

Test Cases

Relevant tests will be developed during implementation, including but not limited to:

Unit Tests

Two new unit tests are added to test the new contracts. These tests will mock the required external interfaces (i.e. CcipRouter and CcipTokenPool).

For USDTokenModule:

  • It reverts transactions coming from an unauthorized address (i.e. non-CCIP address).
  • It reverts if the sender does not have enough snxUSD balance or allowance.
  • It gets deployed and registered correctly.
  • It applies the expected USD parameters.

For CcipReceiverModule:

  • It reverts if caller is not the CcipRouter.
  • It reverts if chain is not supported.
  • It reverts if message sender on other chain is not self.
  • It forwards message to specified caller.

Integration Tests

One integration test to cover the initiation of a cross-chain transfer.

  • Verify the CcipRouter has enough allowance to transfer tokens.
  • Verify the CcipRouter burns the correct amount of snxUSD on the source chain.
  • Verify it refunds the correct amount of left over gas (i.e. difference between msg.value and getFee()) to the caller.
  • Verify it correctly invokes CcipRouter.ccipSend() with the expected encoded data.
  • Verify it emits a TransferCrossChainInitiated event with the expected values.

Manual Tests

  • Deploy and test on two or more networks using fresh instances of V3.
  • Confirm source/destination transactions are correct using the CCIP explorer.
  • Confirm the CcipRouter (on destination) emits a MessageExecuted event.

Configurable Values (Via SCCP)

  • Every deployment of Synthetix must be configured with the addresses of the CcipRouters and CcipTokenPools for each chain, such that it can verify the sender of messages that request minting snxUSD.

Copyright and related rights waived via CC0.