This proposal will grant a Uniswap v3 BSL exemption to the Nethermind team to deploy Uniswap v3 onto StarkNet mainnet.
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.
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.
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.
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.
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.
Will deploy on mainnet after StarkNet regenesis (Q1 2023)
Transpilation, optimization, and testing of non-core contracts are underway.
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.
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.
Development of an interface
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.
As Warp continues to improve, Nethermind will consider the benefits of a native Cairo rewrite of specific Uniswap v3 contracts.
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:
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.
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.
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.
This proposal will grant a Uniswap v3 BSL exemption to the Nethermind team to deploy Uniswap v3 onto StarkNet mainnet.
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.
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.
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.
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.
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.
Will deploy on mainnet after StarkNet regenesis (Q1 2023)
Transpilation, optimization, and testing of non-core contracts are underway.
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.
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.
Development of an interface
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.
As Warp continues to improve, Nethermind will consider the benefits of a native Cairo rewrite of specific Uniswap v3 contracts.
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:
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.
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.
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.
Hi Deven,
This is a great proposal.
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!
Excellent :heart_eyes: :heart: :sparkling_heart: I cheer with you
great to hear that especially from uniswap team..i am in
Hi Deven,
This is a great proposal.
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!
Excellent :heart_eyes: :heart: :sparkling_heart: I cheer with you
great to hear that especially from uniswap team..i am in
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:
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:
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.
A lot of the above questions were answered and addressed in the StarkNet <> Uniswap Community Call
A lot of the above questions were answered and addressed in the StarkNet <> Uniswap Community Call
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).
Potentially the Uniswap Community can take inspiration from AAVE aToken bridge to StarkNet and MakerDAO StarkNet DAI bridge processes for StarkNet deployment.
The edit window on the original post has closed. Here is an updated overview:
The edit window on the original post has closed. Here is an updated overview:
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.
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.
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?
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.
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.
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:
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:
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.
A lot of the above questions were answered and addressed in the StarkNet <> Uniswap Community Call
A lot of the above questions were answered and addressed in the StarkNet <> Uniswap Community Call
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).
Potentially the Uniswap Community can take inspiration from AAVE aToken bridge to StarkNet and MakerDAO StarkNet DAI bridge processes for StarkNet deployment.
The edit window on the original post has closed. Here is an updated overview:
The edit window on the original post has closed. Here is an updated overview:
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.
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.
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?
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.
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.
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).
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)
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.
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).
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)
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.
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.
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.
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.)
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.
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.
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.
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.
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.)
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.
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.
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.
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.
