SIP-311: snxUSD Teleporters (V3)
Author | |
---|---|
Status | Vote_Pending |
Type | Governance |
Network | Ethereum & Optimism |
Implementor | MEB (@barrasso), Daniel Beal (@dbeal-eth) |
Release | TBD |
Proposal | Loading status... |
Created | 2022-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 totransferCrossChain()
and what theCcipRouter
returns asgetFee()
.
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
andCcipRouter.getFee()
).
ccipReceive(Any2EVMMessage calldata message)
- Verify that the
srcChainId
andsender
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
andgetFee()
) 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 aMessageExecuted
event.
Configurable Values (Via SCCP)
- Every deployment of Synthetix must be configured with the addresses of the
CcipRouter
s andCcipTokenPool
s for each chain, such that it can verify the sender of messages that request minting snxUSD.
Copyright
Copyright and related rights waived via CC0.