[RFC] Deploy Uniswap V3 on StarkNet

[devenmatthews]

Summary

This proposal will grant a Uniswap v3 BSL exemption to the Nethermind team to deploy Uniswap v3 onto StarkNet mainnet.

• StarkNet is a permissionless ZK-rollup that inherits security from Ethereum mainnet. StarkNet runs CairoVM, a virtual machine optimized for generating zero-knowledge proofs about L2 state transitions. Cairo is the high-level language used for writing smart contracts on StarkNet.
• Warp is a transpiler from Solidity to Cairo developed by a team at Nethermind. Nethermind has successfully used Warp to transpile the Uniswap v3 Core contracts to Cairo. Uniswap v3 Core is currently running on a local StarkNet testnet, passing all provided tests. The Nethermind team may use Warp to transpile the Uniswap v3 codebase and deploy it on StarkNet.

About StarkNet

StarkNet is a permissionless, general-purpose Zk-rollup developed by StarkWare. StarkNet uses STARKs to securely generate and succinctly verify proofs about state transitions on the L2 and use those proofs to update the state root on Ethereum Mainnet securely. STARKs enable StarkNet state to be secured by Ethereum Mainnet consensus in a cheap and scalable way.

StarkNet runs ZK-compatible virtual machine CairoVM, allowing applications on StarkNet high levels of computational scalability. Cairo, the high-level language native to the CairoVM, directly compiles into opcodes that can efficiently be evaluated in a ZK-circuit to generate succinct validity proofs about state changes.

Ecosystem

StarkNet’s unique approach to L2 scaling has unlocked an impressive level of computational scalability, and several novel features not native to the EVM. One of the most notable features is that StarkNet has native account abstraction(AA), meaning there is no distinction between EOAs and account contracts. There are several wallets and tools that utilize AA on StarkNet; AA has been praised as an essential feature in achieving mass adoption. The unique tooling and scalability enabled by StarkNet make it highly qualified for a Uniswap v3 deployment.

There are 100+ projects currently being built on StarkNet, natively in Cairo. Here is a non-exhaustive list of projects building on StarkNet.

About Warp

Warp is a Solidity to Cairo transpiler developed by Nethermind. While developer tooling around Cairo, StarkNet’s native language, is rapidly growing, it is not yet up to par with the thriving ecosystem that encapsulates Solidity. Warp’s goal is to enable developers to leverage StarkNet’s computational scalability, unique features, and vast tooling for Solidity development. Warp is an efficient transpiler that can port over large codebases written in Solidity to Cairo to run on StarkNet. Warp passes all relevant semantic tests provided by the Solidity compiler.

The Warp team has already transpiled the Solidity codebase of Uniswap v3 Core to Cairo. The transpiled contracts are running on a local StarkNet testnet, passing all provided tests. While this is a massive achievement for the Warp project, we expect to achieve far greater computational scalability through refinements to Warp and upcoming upgrades to StarkNet.

Timeline

If passed, the community can expect to have Uniswap v3 fully deployed and supported on StarkNet mainnet by Q2 2023. The Nethermind team could be ready to deploy a transpiled and tested version of Uniswap v3 Core in Cairo on StarkNet mainnet today. While this deployment is entirely viable, some key optimizations are coming that will allow a StarkNet Uniswap v3 deployment to best enjoy the benefits of the StarkNet Ecosystem. Here is an outline of our current timeline and the reasoning behind it.

1. Will deploy our current version of v3-core in cairo on StarkNet public testnet in the coming weeks to allow community testing while we continue work simultaneously to improve the efficiency of Warp and UniStark.

2. Will deploy on mainnet after StarkNet regenesis (Q1 2023)

   • forced transactions from L1. L1 contracts can call L2 contracts without the possibility of censorship. I.e., censorship-resistant guarantees for cross-chain governance proposals
   • gas metering: more dynamic fee market on StarkNet.

3. Transpilation, optimization, and testing of non-core contracts are underway.

   • We’ve proven core functionality of Uniswap v3; we are currently working on all additional contracts that will support the v3 deployment, such as periphery

4. Warp’s efficiency is still improving every day. Some key optimizations can be made to the transpiled Uniswap core contracts to better leverage the computational efficiency provided by Cairo and further reduce gas costs. Currently, Warp is working on being completely compatible with Cairo 1.

5. Cairo 1 has native support for basic constructs like loops and if-else statements without unnecessary variable copying. Once Warp targets Cairo 1, it can leverage the efficient native implementation of these features. Additionally, Cairo 1 adds support for recoverable errors used by the periphery contracts.

6. Development of an interface

   • StarkNet and CarioVM introduce unique tooling, such as Argent and Braavos Account Abstraction wallets.
   • Nethermind is developing a usable Uniswap v3 interface for our StarkNet deployment to ensure users can easily interact with these contracts on day one as the official front end is being integrated.

7. Additional efforts to bring over Uniswap v3 liquidity managers, liquidity providers, and other critical infrastructure that will help the Uniswap v3 deployment on StarkNet thrive.

8. As Warp continues to improve, Nethermind will consider the benefits of a native Cairo rewrite of specific Uniswap v3 contracts.

Proposal

StarkNet offers high computational scalability and unique design decisions, strictly secured by Ethereum consensus. With the advent of Warp, this proposal offers an easy and ethical route for Uniswap to leverage the StarkNet ecosystem and tooling. StarkNet is Ethereum aligned and believes the goals of our ecosystem align with that of Uniswap.

Benefits to Uniswap:

1. Deploy Uniswap on a zk-rollup with a thriving and growing ecosystem.
2. Reduced gas costs on Uniswap transactions.
3. Expand beyond the EVM while still maintaining Ethereum alignment.
4. Interoperability with a plethora of novel tooling being built on StarkNet.
5. Potential v3 applications enabled by StarkNet’s computational scalability, such as advanced oracle support, etc.
6. Access to native account abstraction

StarkNet Security & Bridges

Zk-rollups have been recognized as the gold standard for Ethereum scaling solutions. This recognition comes from the strong security guarantees of zk-validity proofs about L2 state transitions. Because of the strong cryptographic guarantees around zero-knowledge proof generation and verification, we can be sure the sequencer cannot propose invalid L2 state transitions. StarkNet allows for secure native general message passing between L1<>L2- leveraging validity proofs such that the sequencer, the actor responsible for L1<>L2 message passing, cannot lie about the state or create false messages from the origin chain. The only malicious activity possible is that the sequencer can stop sending messages, freezing L1<>L2 communication. After StarkNet regenesis, users can force L2 transactions from L1 without consent from the sequencer. The sequencer is currently run and maintained by Starkware but there is a plan to decentralize the sequencer role in 2023.

RFC on Uniswap’s non-EVM-native Deployment Procedure

As a contender for the first non-EVM-native deployment of Uniswap, we want to help define the alternative-VM deployment strategy of the Uniswap DAO through our proposal.

Executing code on its non-native VM introduces risks that aren’t present in native execution; there must be some translation between the original Uniswap v3 EVM bytecode and the bytecode of the VM being executed on. The translation can take place at different layers of abstraction: at a high level via transpiler or manual rewrite (see Warp; AAVE v3 Cairo aToken bridge); or at a bytecode level, like non-bytecode equivalent zkEVMs (see type 3/4 zkEVMs on Vitalik.ca).

This additional risk should be accounted for through additional audits, bug bounty programs, beta periods of limited liquidity, or other means. We are asking the Uniswap community to use this proposal to analyze and define the risk tolerance and best practices around non-EVM-native deployments. The team at Nethermind is committed to being transparent about the risks associated with expanding Uniswap to non-EVM-native environments and defining appropriate measures alongside the Uniswap community.

We hope to deploy Uniswap v3 on StarkNet and help the community set precedence for future non-EVM-native deployments of the codebase.

License Exemption

This proposal will grant Demerzel Solutions Limited, the legal entity behind Nethermind, an exemption from Uniswap Labs Business Source Licence for the Uniswap v3 source code. Provided that this proposal is passed pursuant to the Ethereum layer 1 Uniswap Protocol governance and control process, Demerzel Solutions shall be able to use the Licensed Work to deploy it on StarkNet Mainnet, a layer 2 solution for Ethereum.

[devenmatthews]

Potentially the Uniswap Community can take inspiration from AAVE aToken bridge to StarkNet and MakerDAO StarkNet DAI bridge processes for StarkNet deployment.

[tobyshorin]

Hi Deven, thanks for bringing the proposal.

The AAVE and MakerDAO work were funded by their respective organizations. Is there an expectation of the Nethermind receiving funding to conduct this work? If so, would appreciate if you can clarify that more before the edit window is up on the original proposal text. (We just posted an improved proposal template that has some suggests you can use here.)

A high level understanding at this point would be good, but would expect an itemized budget before moving to the next stage of the proposal.

A beta periods of limited liquidity and a bug bounty commensurate bug bounty seems appropriate. I understand that DAI, USDT, and USDC with a $30k deposit cap are the equivalent assets for AAVE (from this post). Perhaps you or other delegates who know more about the Starkware and the asset ecosystem you are trying to build there can comment on what pools you imagine moving forward with in Uniswap’s case.

[devenmatthews]

Thanks for the comment Toby,

Appreciate Other Internet putting together the improved proposal template- I believe our current proposal does a good job addressing a lot of the new content in the updated format, but will go ahead and add some of the newly added sections for clarity. Do you know the proposal edit window length?

As far as compensation. There isn’t much precedence for this in Uniswap that I’m aware of; then again there isn’t any precedence for non-EVM deployments of Uniswap. Before properly answering this question it becomes really important to understand the risk tolerance of the community concerning development of Uniswap for other VMs.

• Would the DAO be willing to fund (or jointly fund) a bug bounty program, or additional pro-security programs concerning this deployment? It’s important to understand beforehand what the community believes is conditional for alternative-VM deployments as it will greatly impact the overall cost.

As mentioned in the proposal, Nethermind is prepared to deploy Uniswap v3-core on StarkNet using Warp today. While this deployment is completely viable, it is clear to us that additional resources would greatly boost the performance and associated tooling with a StarkNet deployment of Uniswap (Building fuzz testing for warp contracts; Warping over liquidity managers built on top of v3; improving efficiency; exploring native Cairo re-write of specific contracts and following audits; building a frontend supportive of StarkNet Account Abstraction wallets).

It’s also important to note that Nethermind is not StarkWare (the founding company behind StarkNet) or the StarkNet Foundation (the foundation which oversees the layer 2’s development and decentralization). All current development on “UniStark” (our internal name for this project) is through grants we have received to develop the Warp tooling itself, not grants specifically for this Uniswap deployment. We are happy to continue through with a proper funding proposal once we have clarity on

• Would responsibility for funding this work fall on the Uniswap Foundation, Uniswap Community, or even Uniswap Labs?

• Is there any precedence for this that we are missing?

• Does the community feel comfortable with a bug bounty program and capped liquidity period or are there additional costs we must consider to meet the Uniswap communities standards

If the community does not have strong opinions about point 3. We can draft an updated funding proposal on our own with expected cost of audits and required security features; though we wanted to have this conversation in the open, as it is likely to become precedence for future non-EVM-native deployments of Uniswap code.

I think the only strong requirement before the community grants Nethermind a license to deploy is defining any contingencies unique to the security of alternative-VM deployments. This way Nethermind can be assured the community feels comfortable with the security of our deployment and can work separately to source funding to meet these requirements.

[devenmatthews]

For a limited liquidity period:
$30k asset cap following AAVE’s lead seems like a great place to start conversation.
ETH, USDC, DAI, USDT are target assets for initial pools.
Gonna call on some StarkNet defi giga-brains to weigh in on discussion about the best approach for initial pools during a limited liquidity period.

Current v3 bug bounty is ran by labs and is listed at $2.25MM USDC max for a bug.
Nethermind would be unable to support a program of this size on its own. Will seek clarity from Uniswap Foundation, Uniswap Labs, StarkWare, StarkNet Foundation, and Uniswap DAO to explore the willingness for a joint effort and ideal size/time-frame of the program following the end of limited liquidity period. Imagine this would need to be some function of the total assets locked in StarkNet v3 pools.

Would appreciate community input on how to gauge size of the bounty program; as well as field any alternative suggestions/considerations.

[HolysoulTH]

Excellent
I cheer with you

[devenmatthews]

The edit window on the original post has closed. Here is an updated overview:

Encompassed in this proposal

• Nethermind will deploy a transpiled version of Uniswap v3 on StarkNet testnet

• Following community testing and mentioned optimizations, Nethermind will deploy a Cairo 1 compatible Uniswap v3 on StarkNet mainnet controlled by Uniswap L1 governance with limited liquidity caps ($30k) and a fixed set of pools.

  • ETH/USDC; ETH/DAI; ETH/USDT are all high quality options. DAI is currently a capped asset on StarkNet, but the cap will potentially be moving up after regenesis. We will be in contact with the Maker community about making an ETH<>DAI pool on StarkNet. If we must commit for the purposes of this proposal, ETH<>USDC is the safest option I believe.

• Nethermind will not be seeking a large level of compensation for this work. We would NOT like to make our deployment license for a limited liquidity pool contingent on funding.

[tobyshorin]

To clarify responsibility for future funding funding this work:

• I think it’s clear that this is an experimental deployment of Uniswap on a new technological substrate and that Nethermind will be liable for any loss of funds that occur.

• The existing bug bounty does not apply to a StarkNet deployment. If Uniswap reps agree to deploy the project I think we also should consider also pre-authorizing an allocation of UNI from the treasury to co-fund a bug bounty as an additional incentive.

• What we are voting on is only deployment of the v3-core onto mainnet, or does this also include periphery contracts? Unclear from the original proposal. Either way, this doesn’t seem like it needs funding from us at this time.

• We should be clear that this vote does not indicate any commitment of funding a native rewrite of Uniswap contracts in Cairo. I will defer to Uniswap Labs counsel to understand whether that would even be covered by the BSL.

Also hopeful some Uniswap defi gigabrains will come out of the woodwork to help us figure out what initial pools would make sense.

[devenmatthews]

Further Explorations not encompassed in this proposal (will be encompassed in a future proposal)

• Following the capped asset period, Nethermind will review if any key optimizations must be made and consider a Cairo re-write and audit for an uncapped mainnnet deployment
• Nethermind will speak with relevant actors to explore a bounty program to be paired with an uncapped deployment
• Nethermind may seek funding to develop further infrastructure to support an uncapped mainnet deployment

[devenmatthews]

Appreciate you engaging in this conversation,

• This proposal does not commit to any funding for Nethermind. Only grants Nethermind an exception to the Uniswap v3 BSL.

• This proposal will be for the deployment of all uniswap contracts that fall under the BSL license, including periphery. The deployment covered in this proposal will have a liquidity cap to reduce risk.

• I’m somewhat confused by the conversation of liability. This proposal (as stated by following comments) will be to deploy Uniswap v3 contracts with a capped liquidity of $30k (tentative number the community must agree upon). Is “Uniswap” current liable for loss of liquidity on other uncapped deployments? i.e. a bug exploited in v3 on mainnet, ZK-Sync’s bytecode interpreter introduces a bug, Optimisms proof system fails and funds are lost. I’m not saying these are likely, but I’d like to understand where liability falls in these scenarios- and what’s legally actionable. I don’t believe the BSL exemption implies anything about liability? If Uniswap has taken liability for all current deployments how does this change when license expires? From my untrained legal perspective, possibly Uniswap Labs assumes some liability when listing on their front-end (which this proposal does not cover).

  • Seems like a solvency fund would reduce concern- but I’m starting to wonder if this is necessary given a primary testnet deployment, max loss capped at $30k on mainnet, and a Nethermind hosted frontend with proper disclaimers about risk.

• The existing bug bounty program by Labs will not encompass this deployment; I was mentioning we would like to explore opening a separate joint bug bounty program (not encompassed in this limited liquidity deployment proposal)

[afshan1190]

great to hear that especially from uniswap team…i am in

[GFXlabs]

Thank you, Deven, for making this proposal.

At a high level, the proposal is to grant Nethermind a legal exemption to utilize the Uniswap v3 code base to develop and launch something that closely resembles Uniswap v3 on Starknet. Overall, GFX Labs would be supportive of the proposal if it were brought to a vote.

Though, we’d like to note that since the code base will differ from the currently deployed Uniswap v3 that it be clear to users that it is a different codebase developed by Nethermind.

It is also worth noting that protocol governance does not control Uniswap.org. Since Uniswap Labs controls the domain, it will be up to them to decide if it should be included and, if so, how it should be shown on their interface. While it is in development, it might be easiest for the Nethermind team run a fork of the Uniswap app.

[bigsky77]

Hi Deven,

This is a great proposal.

Warp is a cutting edge technology that is vital for scaling Ethereum. Today’s zero knowledge virtual machines are highly optimized for prover time and efficiency. While these optimizations are vital, they often come at the expense of strict EVM compatibility. Transpilers such as Warp are the bridge between high-level EVM compatible languages like Solidity and zk-VM optimized languages like Cairo.

This project is extremely important for Starknet, Uniswap, and the Ethereum community as a whole. This isn’t just a routine Uniswap deployment. This is a cutting edge experiment that will have huge implications for the entire ecosystem - especially for our understanding of how complex EVM based systems operate in other environments.

Here are a few considerations that I think will be vital to success:

1.) UI/Frontend - The v3 frontend is a large and complex codebase. Most of the code is built on Web3 React. The Starknet JS ecosystem is robust - but the code will require a lot of work before it reaches 1:1 parity. What is the plan here?

2.) Account Abstraction - This will be vital for on-boarding the next billion users. Starknet already has account abstraction. It would be a huge missed opportunity if we don’t fully explore account abstraction for this Uniswap deployment.

3.) Coordination - Crypto is all about building together and not in isolation. For this project to reach its full potential, there will be many moving parts and lots of complex technologies overlapping. We should think seriously about creating some public/community structures to coordinate across multiple experts, involve relevant teams, and ensure this deployment reaches its full potential.

Huge kudos to the Nethermind team for bringing this proposal forward. Crypto is getting fun again!

[Kydo]

Kydo from Stanford Blockchain here.

Thank you for putting this together, Deven!

We are very supportive of the proposal and would love to see this go forward. Deploying Uniswap V3 to a non-EVM would be an important milestone for the whole industry.

We think there are two things that we would love to see get discussed more before going to a vote:

1. Front-end: how should it be built? (Risk disclosure should be there to signal that this is a very different implementation from the ones people are familiar with)
2. Future uncapping: under what circumstances should the Starknet version be uncapped? (We recommend setting rough KPIs and expectations beforehand to alleviate future coordination costs.)

We are also happy to shelf these questions for now; so that, the nethermine team can start the development process ASAP. We can propose solutions to these important questions at a later date.

[devenmatthews]

A lot of the above questions were answered and addressed in the StarkNet <> Uniswap Community Call

1. Frontend/UI- Nethermind will create a fork of the existing Uniswap frontend and adapt it to our StarkNet testnet deployment.

• As stated in the call- we need to make some heavy changes to the existing use of ethers.js to adapt it to StarkNet ABI calls. For our testnet deployment we will simply be using StarkNet.js, but as we get closer to a mainnet deployment Nethermind will use a version of ethers.js it has adapted to translate solidity ABI → Cairo ABI.
• StarkNet Account Abstraction wallets like Argent and Braavos can be connected to this frontend and interact with our Uniswap StarkNet deployment.
• This is not a simple task, Nethermind will cover the cost of developement, and will be the main milestone before moving towards vote.

2. As for metrics for raising the liquidity cap we have no solid guidance from the community on this.

• I’ll initially suggest a 6 month period where the liquidity cap is moved from 30k → Uncapped incrementally each month:
  30k → 100k → 200k → 500k → 1MM → Uncapped.
  Increasing this often can cause governance fatigue, but ensures a slow progress towards removal of the cap. 6 months is a long probationary period, would hope to get community feedback on if this can be shortened.

3. As for coordination- Nethermind and StarkNet are very much aligned with building out in the open. We will rely on the StarkNet, Uniswap, and broader crypto community to help battle test this deployment.

• Having an accessible testnet deployment and slowly increasing the liquidity cap and is a safe way to do this.
• We are relying on the Cairo community to try to break this thing in a somewhat informal way. While I’m confident in the StarkNet communities willingness to support this initiative informally- we may still explore a bug bounty program.
• A bug bounty program would require capital from non-Nethermind entities (StarkWare, Uniswap). This contingency would greatly delay Nethermind’s development, so it is being left out of this proposal. We’d like to hear the Uniswap communities interest in supplying capital towards a StarkNet Uniswap bug bounty.