Port Sushiswap onto an Arbitrum Rollup


Let’s deploy Sushiswap on an Arbitrum Rollup.


First of all, what is an Arbitrum Rollup?

Arbitrum Rollup can scale any Ethereum contract. It’s the ideal scaling solution for many DeFi apps and any application which is open to public participation. Arbitrum Rollup contracts enjoy the fully trustless security of the underlying blockchain, all while simultaneously increasing the dapp’s capacity and greatly reducing costs.

By simply taking the Uniswap contracts and frontend, the Arbitrum team has already deployed a version of Uniswap (called Arbiswap) on their testnet which has proven a 55x reduction in gas usage with opportunity to reduce it even further.

The testnet is live, with another on the way, however, in terms of mainnet deployment, on Feb 3 2021 their CTO wrote:

We don’t want to confirm a target until we’re confident, but we’re currently working on heavily security auditing the project, and once we get a clean bill of health there, we’ll be ready to go. That said, there’s a lot of complexity so it’s a bit hard to know when that will happen

Despite the uncertainty around the mainnet release date, I would like to see the Sushiswap team experiment with the Arbitrum testnet now so that it could be deployed live when the Arbitrum mainnet launches.

I expect votes or arguments against this proposal will likely focus on why other L2 solutions for Sushiswap may be superior to an Arbitrum Rollup. To address that briefly, when compared to Optimism, another popular L2 solution, Arbitrum Rollup evidently reduces gas usage on equivalent swap transactions by an additional ~92%.


It is clear that L2 solutions are a necessary upgrade, and as this should not require much effort from our dev team, I believe the benefits far outweigh any effort spent bringing this to life, even if only on the testnet for now.

As gas fees continue to grow and discourage swaps from large and small participants alike, deploying Sushiswap on an Arbitrum rollup would encourage more swaps from all market participants which benefits everyone in the Sushi ecosystem.

Additionally, Arbitrum is powered by Chainlink nodes, therefore I expect we would see a wave of additional support and lasting loyalty for Sushiswap from the LINK marines if this proposal moves forward.

More detailed specs about the development process of porting to the Arbitrum Rollup testnet are available here, however, the porting process is described to be extremely simple:

It’s not complicated at all! It’s as easy as changing your RPC endpoint to https://kovan2.arbitrum.io/rpc .

Our devs should deploy the Sushiswap contracts and frontend on an Arbitrum Rollup as a potential L2 solution.

Our devs should not spend time testing Sushiswap on an Arbitrum Rollup.


Should we deploy Sushiswap on an Arbitrum Rollup
  • Yes
  • No

0 voters


I think this is a great idea all around with essentially no downside risk. The Sushiswap smart contract suite can be deployed onto the Arbitrum testnet today without any modifications to the code, meaning it would require extremely minimal development effort from the dev team, essentially just deploying the existing contracts and some mock ERC20 tokens.

This would allow both devs and users to test SushiSwap on L2 to see what the gas costs look like ahead of the Arbitrum mainnet and how much transactional bandwidth is provided. You don’t even need to ask the Arbitrum team for permission to deploy on their testnet, it’s entirely permissionless unlike some other Rollups.

Layer 2 is inevitable for DeFi so I’m curious about what others think regarding this proposal.


I think the most advantageous move to an L2 is one that the entire Yearn Ecosystem makes.

If Yearn, Sushi, Cream, Alpha, and all the rest could coordinate their developments to bring the entire Ecosystem to the same L2 that would increase the user stickyness for the entire yearn Ecosystem.

I don’t think I’d want to vote on this either way without knowing what the bigger picture plan is for the rest of the teams.


I really hope the devs are considering this given that Ethereum has now seemingly course corrected to a rollup-centric roadmap

Further, although this video link is older, Ed delivered in a pretty succinct format the benefits of Arbitrum, specifically how performant it is which left me intrigued and excited for the mainnet release.

1 Like

Check out the explanation from the MonteCarloDEX team as to why they chose Arbitrum over other L2 solutions. It also acknowledges zkRollups as an option in the future.

The Developer Friendliness section is compelling:

Arbitrum provides a completely EVM-compatible developing environment and node API. We have deployed MCDEX V2 on Arbitrum’s permissionless testnet without revising a single line of code . Infrastructures including The Graph work smoothly as well. In contrast, OVM requires developers to revise the code when dealing with timing-related operations. Moreover, a bigger problem is that OVM requires team approval at an early stage, which restricts the developer’s exploration freedom.

TLDR: They went with Arbitrum now because it is the optimal rollup solution available today which requires no code changes or anyone’s permission. Additionally,

as the ZK-Rollup technology develops, the Offchain Labs team is planning to add ZK proofs to Arbitrum, thus incorporating the benefits of zero-knowledge technology into their rollup solution.

To me this seems like an approach the entire Yearn ecosystem could take as well.


We are already making architecture plans with regard to L2. We are focusing on zk rollup style L2s that have EVM support. Unfortunately, optimistic rollups have a challenge period that prevents us from performing withdraws for approx. 1 week. The mitigation strategy for that of using bonded LPs is not suitable for SushiSwap since it breaks the composability of the L1 <> L2 calls.


Totally agree with this approach as well. Yearn is also concerned with the challenge period of optimistic rollups.


Hi Joseph, where could we learn more about some of the zk rollup style L2’s that Sushi/Yearn are considering?

I think most of the communications with regard to rollups have happened one on one. We are looking and StarkNet and zksync currently