---
sip: 102
network: Optimism
title: Support SNX on L2 with Optimism
status: Implemented
author: Justin J Moses (@justinjmoses)
created: 2020-12-09T00:00:00.000Z
type: Governance
---

## Simple Summary

<!--"If you can't explain it simply, you don't understand it well enough." Simply describe the outcome the proposed changes intends to achieve. This should be non-technical and accessible to a casual community member.-->

Enable SNX to be used on layer 2 (L2) via Optimism

## Abstract

<!--A short (~200 word) description of the proposed change, the abstract should clearly describe the proposed change. This is what *will* be done if the SIP is implemented, not *why* it should be done or *how* it will be done. If the SIP proposes deploying a new contract, write, "we propose to deploy a new contract that will do x".-->

Integrate with Optimism to enable the staking of `SNX` on L2 - an environment with faster transaction throughput and much cheaper gas costs.

## Motivation

<!--This is the problem statement. This is the *why* of the SIP. It should clearly explain *why* the current state of the protocol is inadequate.  It is critical that you explain *why* the change is needed, if the SIP proposes changing how something is calculated, you must address *why* the current calculation is innaccurate or wrong. This is not the place to describe how the SIP will address the issue!-->

As most users are aware, Ethereum has a major issue with scalability. The recent DeFi summer of 2020 caused gas prices to surge, pricing out a large number of holders who could not justify spending so much of their Ether to transact. Eth 2.0 is coming, and with it, [a rollup-centric approach to scaling](https://ethereum-magicians.org/t/a-rollup-centric-ethereum-roadmap/4698):

> the Ethereum ecosystem is likely to be all-in on rollups (plus some plasma and channels) as a scaling strategy for the near and mid-term future. - Vitalik Buterin

After investigating the various options, and considering the trajectory of Eth 2.0, Optimism was deemed to be the best fit for Synthetix's needs. In short, Optimism's Virtual Machine (the OVM) allows contract code from L1 to be ported to L2 wholesale, with only minor modifications. For more details on the choice of L2 provider, please see the blog post [Why Optimism?](https://blog.synthetix.io/why-optimism/)

In order to tease out any challenges integrating with a new layer 2 technology, a [testnet trial](https://blog.synthetix.io/optimistic-ethereum-l2-testnet/) has been underway on the Goerli testnet since late September. This trial has tested connecting a custom L2 deployment of Synthetix to one on Goerli, and supported deposits, withdrawals and staking. After a couple of months working closely with the Optimism team, the code is ready to be released on mainnet.

## Specification

> Note: This SIP proposes using L2 for staking only. Future proposals may well introduce support for exchanging as well.

<!--The specification should describe the syntax and semantics of any new feature, there are five sections
1. Overview
2. Rationale
3. Technical Specification
4. Test Cases
5. Configurable Values
-->

### Overview

<!--This is a high level overview of *how* the SIP will solve the problem. The overview should clearly describe how the new feature will be implemented.-->

The creation of two new contracts - a deposit contract for L1 and withdrawal for L2.

1. A bridge contract on L1: `SynthetixBridgeToOptimism` that supports the following:

   - When invoked by a user for a deposit of SNX, will hold the SNX as a deposit, will burn any escrowed L1 SNX and send a message to L2 representing the deposited SNX and escrow entries
   - When distributed with SNX rewards, will hold the SNX as a deposit, and send a message to L2 representing the SNX to be distributed as rewards to L2
   - When invoked with a relayed message of withdrawal from L2, will relinquish the SNX to the account

2. A bridge contract on L2: `SynthetixBridgeToBase` that supports the following:
   - When invoked by a user for a withdrawal of SNX, will burn the SNX on L2 and send a message to L1 representing the SNX to withdraw
   - When invoked with a relayed message of deposit from L1, will mint the SNX to the user on L2 and populate escrow entries matching what was previously on L1
   - When invoked with a relayed message of SNX rewards from L1, will mint this SNX right into the `RewardsDistribution` contrat for the upcoming claim period

Further, a polymorphic approach to existing contracts needs to be considered (see Limitations of the OVM below). By utilizing polymorphism and the contract labeling within the Synthetix protocol, we can allow for different implementations of key contracts. These include:

- `EtherCollateral` replaced with an empty shell (no native Ether support)
- `SupplySchedule` replaced with a `FixedSupplySchedule` that allows for a fixed amount at construction time (as SNX on L2 will purely be a representation of the SNX in the L1 deposit contract and have no monetary policy)
- `Synthetix` replaced with `MintableSynthetix` to allow for the minting and burning of SNX on L2 due to messages from the L2 bridge (as regular SNX cannot be minted outside the regular supply schedule)
- `DebtCache` replaced with `RealtimeDebtCache` to ignore debt caching in L2
- `RewardEscrowV2` replaced with `ImportableRewardEscrowV2` allow escrow entries on L2 to be imported from L1 (coming with [SIP-60](./sip-60.md))

### Rationale

<!--This is where you explain the reasoning behind how you propose to solve the problem. Why did you propose to implement the change in this way, what were the considerations and trade-offs. The rationale fleshes out what motivated the design and why particular design decisions were made. It should describe alternate designs that were considered and related work. The rationale may also provide evidence of consensus within the community, and should discuss important objections or concerns raised during discussion.-->

In essence Optimism is a virtual blockchain, connected to and supported by L1. In order for state to enter L2, it needs to be passed in by a transaction to L1. These transactions include ERC20 deposits, as well as more sophisticated payloads of structured data.

In order for existing users to utilize L2, their L1 SNX needs to find its way to L2. To this end, this SIP proposes creating an ERC20 deposit contract for SNX with custom features to migrate escrow entries.

#### Limitations of the OVM

Due to the nature of on-chain fraud proofs, certain limitations are in place to enable trustless verification of state transitions within the EVM.

- _Contract size limits_: in order to run in the OVM, contracts must be transpiled using the ovm transpiler, adding wrapping bytecode to contracts and expanding size. This only affects contracts near to the 24KB limit of EIP-170. Mitigation: switch to subclass of the contract with stubs for unused L2 functionality.
- Contract deployment limits: contracts and the construction code need to fit within approximately 7.5m, as to be instantiated within the fraud proofs execution manager. Mitigation: the overhaul and removal of complex constructor logic in [SIP-100](./sip-100.md)
- No native Ether: the OVM uses wETH instead of ETH for all payments. Mitigation: removal of unused `EtherCollateral` and `Depot` contrats from L2 deploy.
- No self-destruct: the OVM transpiler does not allow the use of `selfdestruct`. As [this opcode is problematic](https://twitter.com/VitalikButerin/status/1301390479968202752?s=20) in Ethereum in general, the mitigation is to remove support for this feature altogether in all Synthetix contracts.
- Compiler safety checks: when a contract's constructor arguments are read as potential opcodes, dangerous pairings can occur, proventing their instantiation in the execution manager for fraud proofs. Mitigation: on deployment, prevent contract creation with dangerous opcodes in the address (by analyzing after creation).

### Technical Specification

<!--The technical specification should outline the public API of the changes proposed. That is, changes to any of the interfaces Synthetix currently exposes or the creations of new ones.-->

```solidity
interface ISynthetixBridgeToOptimism {
    // invoked by users on L1
    function deposit(uint amount) external;

    // invoked by users that want to also migrate their escrow
    function depositAndMigrateEscrow(uint256 depositAmount, uint256[] calldata entryIDs) external;

    // invoked by a generous L1 user (the synthetixDAO)
    function rewardDeposit(uint amount) external;

    // implementation of RewardsDistributionRecipient (for potential future use)
    function notifyRewardAmount(uint256 amount) external;

    // invoked by the relayer on L1
    function completeWithdrawal(address account, uint amount) external;

    // restricted owner function to migrate to a new bridge
    function migrateBridge(address newBridge) external;


}

interface ISynthetixBridgeToBase {
    // invoked by users on L2
    function initiateWithdrawal(uint amount) external;

    // invoked by the relayer on L2
    function mintSecondaryFromDeposit(address account, uint amount) external;

    // invoked by the relayer on L2
    function mintSecondaryFromDepositForRewards(uint amount) external;

    // invoked by the relayer on L2
    function importVestingEntries(
        address account,
        uint256 escrowedAmount,
        VestingEntry[] calldata vestingEntries
    ) external;
}
```

> Note: in order to connect these bridge contracts to the Optimism messengers, a proposal to add to the AddressResolver is as follows:
>
> For the external Optimism messenger contracts, the `ext:Messenger` label be imported to that layer's `AddressResolver`. These can be configured at deploy time.
>
> For each bridge to indicate the other as a message recipient, the target layer can act as a prefix. I.e. the L1 bridge needs to know about `ovm:SynthetixBridgeToBase` and the L2 bridge needs to know about its counterpart, the `base:SynthetixBridgeToOptimism`. As these dependencies are circular, they can be configured soon after deployment of the protocol on both layers.

### Test Cases

<!--Test cases for an implementation are mandatory for SIPs but can be included with the implementation..-->

TBD

### Configurable Values (Via SCCP)

<!--Please list all values configurable via SCCP under this implementation.-->

As this SIP only proposes supporting `SNX` staking on L2, there will be no trading rewards to claim on L2. Thus only SNX rewards are relevant here, and those will only exist if they are sent to L2 by a benevolent holder - such as the synthetixDAO.

## Copyright

Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/).