Blockchain at Berkeley is creating this proposal in partnership with Nomad to Deploy Uniswap V3 on Moonbeam.
The Temperature Check for this proposal passed with 8.3M UNI voting Yes on the Snapshot. We now move to the Consensus Check phase to collect further feedback in advance of an on-chain vote.
In support of furthering the vision of Multichain Uniswap, we propose that the Uniswap community vote to authorize the deployment of Uniswap V3 to Moonbeam. We hope this proposal will serve as an example to create a generalizable, trust-minimized approach to cross-chain deployments, with the goal of supporting a multichain Uniswap ecosystem.
Moonbeam is a Polkadot parachain which features EVM-compatibility, allowing it to serve as a port-of-entry for Ethereum-native apps to participate in the greater Polkadot ecosystem. Deploying on Moonbeam will expand the Uniswap community to include users of the Polkadot ecosystem, helping Uniswap on its journey to become a leading product in the multichain world.
Moonbeam is a reputable chain which has enjoyed high stability and considerable activity since its launch in January, making it a great fit for Uniswap’s trusted brand.
Moonbeam is an EVM-compatible smart contract parachain of the Polkadot network; it is optimized for cross-chain use cases and natively interoperable applications. EVM compatibility and a comprehensive tool suite of integrations like Etherscan, The Graph, Chainlink, and more, allow developers to deploy existing Solidity smart contracts and apps to Moonbeam with minimal changes. Moonbeam also extends the EVM with native cross-chain integrations powered by Polkadot’s XCM, allowing Moonbeam apps to interact with assets and services from other chains in the Polkadot ecosystem in a trust-minimized way.
Moonbeam was the first parachain to go live on the Polkadot network, launching on January 11 this year. Like Moonriver, its sister parachain on Kusama, Moonbeam is expected to accumulate developer and user activity from the 100+ projects building DApps and protocols on the network.
We believe that the timing is perfect for Uniswap V3 to deploy on Moonbeam.
Uniswap has been deployed on Ethereum, Polygon, Arbitrum, and Optimism, giving it great coverage within Ethereum and its most popular L2s. However, Uniswap has not yet expanded beyond the greater Ethereum ecosystem.
Unlike the other deployment targets, Moonbeam represents a much larger target market — Polkadot users. The growth potential of the Polkadot ecosystem is reflected in part by the fact that Polkadot consistently ranks in the top ecosystems for developer activity, despite having just enabled parachains auctions in December 2021. The Polkadot community has grown in parallel with the Ethereum community, and shares many of the same values — decentralization, censorship resistance, open access to finance, to name a few. However, the two communities have largely been discrete, and deploying Uniswap on Moonbeam brings them together in a meaningful way.
Moonbeam is the de facto DeFi hub for Polkadot. Blue chip DeFi projects have deployed or committed to deploying to Moonbeam, including Sushiswap, Lido, Curve, Chainlink and Covalent. As the ecosystem develops, we believe that deploying Uniswap V3 will position it to become a premier AMM on Moonbeam, and, more broadly, a large liquidity hub for the entire Polkadot ecosystem. This represents a massive opportunity to capture this untapped market, which could mean significant fee revenue for LPs and UNI token holders.
The Nomad team has worked on this proposal because Nomad and Connext have already been deployed as Moonbeam’s main bridging solutions, and have begun to drive cross-chain liquidity from Ethereum into Moonbeam. By deploying Uniswap V3 on Moonbeam, Nomad would be able to route even more liquidity into Uniswap pools and additionally facilitate cross-chain communication for Uniswap governance.
Decentralized cross-chain governance is a topic we are excited about working on within the Uniswap ecosystem. As Uniswap Labs highlighted in their post about Multichain Uniswap, it is important that new chains have a trust-minimized arbitrary message passing solution to facilitate secure, decentralized governance of a deployment of Uniswap. The Moonbeam community already uses Nomad and Connext to bridge ERC-20 tokens from Ethereum; despite Moonbeam having only been live for two months, $35M TVL is currently bridged to Moonbeam via Nomad, with over $250M in total volume since deployment. However, Nomad is more than just a protocol for token bridging; at its core, Nomad is a protocol for trust-minimized arbitrary message passing, and Uniswap V3 deployed on Moonbeam can leverage Nomad for governance.
We have worked with developers at Uniswap Labs to research, understand, and document the current state of cross-chain governance for Uniswap deployments. It became clear that, currently, cross-chain governance solutions have been patched together differently for all three of the chains that Uniswap is deployed on, leading to significant complexity and overhead for governance participants who wish to execute proposals governing deployments on other chains. This problem will multiply as Uniswap is deployed to more chains.
Nomad can provide an out-of-the-box solution for this problem. Nomad’s own contracts are governed by a decentralized cross-chain governance app built on its arbitrary message passing rails. This application can be tailored for the purpose of governing Uniswap deployments on chains other than Ethereum mainnet. Rather than attempting to introduce this change on all chains at once, however, we can demonstrate the value of this solution in a de-risked manner by leveraging it first for a new deployment, Moonbeam.
As part of this proposal, Nomad, via a grant from the Moonbeam Foundation, will commit $2,500,000 to the Uniswap Grants Program to help grow the Multichain Uniswap ecosystem.
Through collaborative discussions with members of the Uniswap community, we learned that there were likely higher-leverage ways to enrich the Uniswap community than just providing liquidity mining rewards. As Uniswap develops into a multi-chain ecosystem, we want to support developers working to create high-quality multichain apps building on-top of Uniswap, and better multichain experiences for Uniswap users. These grants will promote long-term protocol development, developer activity and innovation towards this goal.
To borrow language from the Uniswap Grants + Gitcoin announcement, we hope for this initiative to fund “bounties, hackathons, and grants” for “developers, designers, community organizers and other web3 builders” working on multi-chain projects which improve, extend, promote or build upon Unsiwap in a cross-chain manner.
Examples of projects that could be funded with this grant include:
We are so excited to see what members of the Uniswap community come up with to leverage this grant!
We are excited about the possibility of the Uniswap community entering the Polkadot ecosystem via a V3 deployment on Moonbeam. To reiterate, we feel that this is a fantastic opportunity for the following reasons:
We are excited to engage with the Uniswap community and governance process to discuss more around bringing Uniswap V3 to Moonbeam. Please let us know any and all feedback and criticism, so that we can improve this proposal and expand Uniswap into Moonbeam and Polkadot!
Blockchain at Berkeley is creating this proposal in partnership with Nomad to Deploy Uniswap V3 on Moonbeam.
The Temperature Check for this proposal passed with 8.3M UNI voting Yes on the Snapshot. We now move to the Consensus Check phase to collect further feedback in advance of an on-chain vote.
In support of furthering the vision of Multichain Uniswap, we propose that the Uniswap community vote to authorize the deployment of Uniswap V3 to Moonbeam. We hope this proposal will serve as an example to create a generalizable, trust-minimized approach to cross-chain deployments, with the goal of supporting a multichain Uniswap ecosystem.
Moonbeam is a Polkadot parachain which features EVM-compatibility, allowing it to serve as a port-of-entry for Ethereum-native apps to participate in the greater Polkadot ecosystem. Deploying on Moonbeam will expand the Uniswap community to include users of the Polkadot ecosystem, helping Uniswap on its journey to become a leading product in the multichain world.
Moonbeam is a reputable chain which has enjoyed high stability and considerable activity since its launch in January, making it a great fit for Uniswap’s trusted brand.
Moonbeam is an EVM-compatible smart contract parachain of the Polkadot network; it is optimized for cross-chain use cases and natively interoperable applications. EVM compatibility and a comprehensive tool suite of integrations like Etherscan, The Graph, Chainlink, and more, allow developers to deploy existing Solidity smart contracts and apps to Moonbeam with minimal changes. Moonbeam also extends the EVM with native cross-chain integrations powered by Polkadot’s XCM, allowing Moonbeam apps to interact with assets and services from other chains in the Polkadot ecosystem in a trust-minimized way.
Moonbeam was the first parachain to go live on the Polkadot network, launching on January 11 this year. Like Moonriver, its sister parachain on Kusama, Moonbeam is expected to accumulate developer and user activity from the 100+ projects building DApps and protocols on the network.
We believe that the timing is perfect for Uniswap V3 to deploy on Moonbeam.
Uniswap has been deployed on Ethereum, Polygon, Arbitrum, and Optimism, giving it great coverage within Ethereum and its most popular L2s. However, Uniswap has not yet expanded beyond the greater Ethereum ecosystem.
Unlike the other deployment targets, Moonbeam represents a much larger target market — Polkadot users. The growth potential of the Polkadot ecosystem is reflected in part by the fact that Polkadot consistently ranks in the top ecosystems for developer activity, despite having just enabled parachains auctions in December 2021. The Polkadot community has grown in parallel with the Ethereum community, and shares many of the same values — decentralization, censorship resistance, open access to finance, to name a few. However, the two communities have largely been discrete, and deploying Uniswap on Moonbeam brings them together in a meaningful way.
Moonbeam is the de facto DeFi hub for Polkadot. Blue chip DeFi projects have deployed or committed to deploying to Moonbeam, including Sushiswap, Lido, Curve, Chainlink and Covalent. As the ecosystem develops, we believe that deploying Uniswap V3 will position it to become a premier AMM on Moonbeam, and, more broadly, a large liquidity hub for the entire Polkadot ecosystem. This represents a massive opportunity to capture this untapped market, which could mean significant fee revenue for LPs and UNI token holders.
The Nomad team has worked on this proposal because Nomad and Connext have already been deployed as Moonbeam’s main bridging solutions, and have begun to drive cross-chain liquidity from Ethereum into Moonbeam. By deploying Uniswap V3 on Moonbeam, Nomad would be able to route even more liquidity into Uniswap pools and additionally facilitate cross-chain communication for Uniswap governance.
Decentralized cross-chain governance is a topic we are excited about working on within the Uniswap ecosystem. As Uniswap Labs highlighted in their post about Multichain Uniswap, it is important that new chains have a trust-minimized arbitrary message passing solution to facilitate secure, decentralized governance of a deployment of Uniswap. The Moonbeam community already uses Nomad and Connext to bridge ERC-20 tokens from Ethereum; despite Moonbeam having only been live for two months, $35M TVL is currently bridged to Moonbeam via Nomad, with over $250M in total volume since deployment. However, Nomad is more than just a protocol for token bridging; at its core, Nomad is a protocol for trust-minimized arbitrary message passing, and Uniswap V3 deployed on Moonbeam can leverage Nomad for governance.
We have worked with developers at Uniswap Labs to research, understand, and document the current state of cross-chain governance for Uniswap deployments. It became clear that, currently, cross-chain governance solutions have been patched together differently for all three of the chains that Uniswap is deployed on, leading to significant complexity and overhead for governance participants who wish to execute proposals governing deployments on other chains. This problem will multiply as Uniswap is deployed to more chains.
Nomad can provide an out-of-the-box solution for this problem. Nomad’s own contracts are governed by a decentralized cross-chain governance app built on its arbitrary message passing rails. This application can be tailored for the purpose of governing Uniswap deployments on chains other than Ethereum mainnet. Rather than attempting to introduce this change on all chains at once, however, we can demonstrate the value of this solution in a de-risked manner by leveraging it first for a new deployment, Moonbeam.
As part of this proposal, Nomad, via a grant from the Moonbeam Foundation, will commit $2,500,000 to the Uniswap Grants Program to help grow the Multichain Uniswap ecosystem.
Through collaborative discussions with members of the Uniswap community, we learned that there were likely higher-leverage ways to enrich the Uniswap community than just providing liquidity mining rewards. As Uniswap develops into a multi-chain ecosystem, we want to support developers working to create high-quality multichain apps building on-top of Uniswap, and better multichain experiences for Uniswap users. These grants will promote long-term protocol development, developer activity and innovation towards this goal.
To borrow language from the Uniswap Grants + Gitcoin announcement, we hope for this initiative to fund “bounties, hackathons, and grants” for “developers, designers, community organizers and other web3 builders” working on multi-chain projects which improve, extend, promote or build upon Unsiwap in a cross-chain manner.
Examples of projects that could be funded with this grant include:
We are so excited to see what members of the Uniswap community come up with to leverage this grant!
We are excited about the possibility of the Uniswap community entering the Polkadot ecosystem via a V3 deployment on Moonbeam. To reiterate, we feel that this is a fantastic opportunity for the following reasons:
We are excited to engage with the Uniswap community and governance process to discuss more around bringing Uniswap V3 to Moonbeam. Please let us know any and all feedback and criticism, so that we can improve this proposal and expand Uniswap into Moonbeam and Polkadot!
Thanks @pennblockchain .
Dynamic Approach to Quorum Setting By dynamic approach, I simply mean that the quota could be defined as 51% of outstanding UNI. This way, as we go out in time and more UNI is issued, there is less of a need to keep increasing the numerical value of the quorum threshold via governance proposals. For example, if outstanding UNI is 100M, the quorum is 51M. When it increases to 200M UNI outstanding, the quorum would automatically adjust to 102M UNI.
Thanks @pennblockchain .
Dynamic Approach to Quorum Setting By dynamic approach, I simply mean that the quota could be defined as 51% of outstanding UNI. This way, as we go out in time and more UNI is issued, there is less of a need to keep increasing the numerical value of the quorum threshold via governance proposals. For example, if outstanding UNI is 100M, the quorum is 51M. When it increases to 200M UNI outstanding, the quorum would automatically adjust to 102M UNI.
Size of large UNI voters Do you have information on how big (measured in million UNI) were the largest blocks of votes in each of the five prior proposals? I think this is also useful information for deciding where the quorum should be.
Thought on size of quorum I'm not sure the quorum needs to be very large. There is a defined voting process that takes some days. So I don't see how small groups can easily get a proposal through. Ultimately, the rest of the community will know and can just vote against. Maybe I'm missing a specific concern that you see?
Thanks for the clear post.
Is this proposal coming as a response to a specific concern/incident (I assume not if only three proposals have been passed)? I just wanted to confirm.
Some considerations in setting the quorum:
Thanks for the clear post.
Is this proposal coming as a response to a specific concern/incident (I assume not if only three proposals have been passed)? I just wanted to confirm.
Some considerations in setting the quorum:
As a rule of thumb, one approach would be to set the quorum equal to a majority of all outstanding votes (i.e. 50%). Has this been considered as a more dynamic approach than setting a fixed number?
How does this proposed increased quorum of 60M compare to the largest blocks of votes (in the five historical votes that were held)? [I'm a bit new, so perhaps you could link to where I can see a breakdown of the voting on the five proposals.]
Thanks @pennblockchain .
Dynamic Approach to Quorum Setting By dynamic approach, I simply mean that the quota could be defined as 51% of outstanding UNI. This way, as we go out in time and more UNI is issued, there is less of a need to keep increasing the numerical value of the quorum threshold via governance proposals. For example, if outstanding UNI is 100M, the quorum is 51M. When it increases to 200M UNI outstanding, the quorum would automatically adjust to 102M UNI.
Thanks @pennblockchain .
Dynamic Approach to Quorum Setting By dynamic approach, I simply mean that the quota could be defined as 51% of outstanding UNI. This way, as we go out in time and more UNI is issued, there is less of a need to keep increasing the numerical value of the quorum threshold via governance proposals. For example, if outstanding UNI is 100M, the quorum is 51M. When it increases to 200M UNI outstanding, the quorum would automatically adjust to 102M UNI.
Size of large UNI voters Do you have information on how big (measured in million UNI) were the largest blocks of votes in each of the five prior proposals? I think this is also useful information for deciding where the quorum should be.
Thought on size of quorum I'm not sure the quorum needs to be very large. There is a defined voting process that takes some days. So I don't see how small groups can easily get a proposal through. Ultimately, the rest of the community will know and can just vote against. Maybe I'm missing a specific concern that you see?
Thanks for the clear post.
Is this proposal coming as a response to a specific concern/incident (I assume not if only three proposals have been passed)? I just wanted to confirm.
Some considerations in setting the quorum:
Thanks for the clear post.
Is this proposal coming as a response to a specific concern/incident (I assume not if only three proposals have been passed)? I just wanted to confirm.
Some considerations in setting the quorum:
As a rule of thumb, one approach would be to set the quorum equal to a majority of all outstanding votes (i.e. 50%). Has this been considered as a more dynamic approach than setting a fixed number?
How does this proposed increased quorum of 60M compare to the largest blocks of votes (in the five historical votes that were held)? [I'm a bit new, so perhaps you could link to where I can see a breakdown of the voting on the five proposals.]
I think if you guys put together a proposal to upgrade to Governor Bravo and a 2-day review period that it would go through governance. If you try to buddle it with a proposal quorum threshold change it becomes a lot less likely to get passed. I suggest breaking it up into two proposals. Take the easy win with the Bravo upgrade and then try to do the quorum change.
PS: Who is on the Penn team? Send me a dm on Twitter if you want to talk more about governance.
I think if you guys put together a proposal to upgrade to Governor Bravo and a 2-day review period that it would go through governance. If you try to buddle it with a proposal quorum threshold change it becomes a lot less likely to get passed. I suggest breaking it up into two proposals. Take the easy win with the Bravo upgrade and then try to do the quorum change.
PS: Who is on the Penn team? Send me a dm on Twitter if you want to talk more about governance.
Adding on to @monet-supply: If Uniswap changes to Governor Bravo, it can add a review period (Compound uses a 2-day period) which is a huge upgrade to protocol/goverance safety. The review period allows everyone to check the proposal before voting and set up their governance tokens for voting.
Not sure if this is specifically address elsewhere in the proposal, but I strongly believe we should switch from Governor Alpha to Governor Bravo as part of any future governance parameter change (such as this proposed quorum increase). This brings a few benefits, mainly from not needing to migrate to a new contract for parameter changes:
Adding on to @monet-supply: If Uniswap changes to Governor Bravo, it can add a review period (Compound uses a 2-day period) which is a huge upgrade to protocol/goverance safety. The review period allows everyone to check the proposal before voting and set up their governance tokens for voting.
Not sure if this is specifically address elsewhere in the proposal, but I strongly believe we should switch from Governor Alpha to Governor Bravo as part of any future governance parameter change (such as this proposed quorum increase). This brings a few benefits, mainly from not needing to migrate to a new contract for parameter changes:
@monet-supply @Getty We agree that our proposal should include an upgrade to the Governor Bravo contract along with the change to the quorum. Since incorporating this change would likely significantly alter our initial proposal, we plan to deploy a new Consensus Check that pivots the proposal to also include the above suggestions under the theme of improving the efficiency and security of the Uniswap governance process. We encourage voters to abstain from this specific Consensus Check, and await our new Consensus Check.
Thank you to the community for all the suggestions. We are always open to hearing out fellow community members, and actively incorporating their feedback.
Thanks Pinotio.com for your engagement. Absolutely, would love to clarify.
The proposal is not stemming from one specific incident, but rather a growing trend towards increased vote delegation and governance participation to the extent that a 40M UNI quorum is now too low as a bar to ensure proper consensus.
Thanks Pinotio.com for your engagement. Absolutely, would love to clarify.
The proposal is not stemming from one specific incident, but rather a growing trend towards increased vote delegation and governance participation to the extent that a 40M UNI quorum is now too low as a bar to ensure proper consensus.
Relevant to 2), historical participation stats on the five historical governance proposals ordered from most recent to oldest: DeFi Education Fund (June 2021): 79.6M FOR, 15M AGAINST Reduce proposal submission threshold (June 2021): 90M FOR, 0M AGAINST Uniswap Grants (December 2020): 60M FOR, 0M AGAINST Retroactive Proxy Airdrop (November 2020): 37.5M FOR, 1.2M AGAINST Reduce submission and quorum threshold (October 2020): 39.5M FOR, 0.7M AGAINST
It is clear that the quorum must be raised from the initial 40M threshold in September 2020, given the recent participation rates of >90M UNI. Even back in December, participation had reached 60M.
In response to 1), it would be great if you could clarify what you mean by a more dynamic approach. Currently, even if a proposal surpasses the quorum threshold, it must still achieve a majority FOR to be passed. For example, with a 40M quorum in place (status quo), if a proposal gets 50M FOR and 51M AGAINST, it won't be able to pass as it has not fetched a majority of all outstanding votes. We won't be changing this mechanism. The quorum threshold simply acts as a safety net. For example, with a 40M quorum in place, if a proposal gets 30M FOR and 25M AGAINST, despite achieving majority approval the proposal would not be able to pass as it has not yet reached the quorum.
The quorum should be high enough so that VCs, their proxies/delegates and team members cannot reach it without support from the greater tokenholder community.
There is no point in raising the quorum until we have more transparency into what that number is - of course, taking vesting into consideration.
The quorum should be high enough so that VCs, their proxies/delegates and team members cannot reach it without support from the greater tokenholder community.
There is no point in raising the quorum until we have more transparency into what that number is - of course, taking vesting into consideration.
Due to clear VC dominance in this token ecosystem, raising it to 60m would just be a symbolic gesture at this point.
@monet-supply @Getty We agree that our proposal should include an upgrade to the Governor Bravo contract along with the change to the quorum. Since incorporating this change would likely significantly alter our initial proposal, we plan to deploy a new Consensus Check that pivots the proposal to also include the above suggestions under the theme of improving the efficiency and security of the Uniswap governance process. We encourage voters to abstain from this specific Consensus Check, and await our new Consensus Check.
Thank you to the community for all the suggestions. We are always open to hearing out fellow community members, and actively incorporating their feedback.
Thanks Pinotio.com for your engagement. Absolutely, would love to clarify.
The proposal is not stemming from one specific incident, but rather a growing trend towards increased vote delegation and governance participation to the extent that a 40M UNI quorum is now too low as a bar to ensure proper consensus.
Thanks Pinotio.com for your engagement. Absolutely, would love to clarify.
The proposal is not stemming from one specific incident, but rather a growing trend towards increased vote delegation and governance participation to the extent that a 40M UNI quorum is now too low as a bar to ensure proper consensus.
Relevant to 2), historical participation stats on the five historical governance proposals ordered from most recent to oldest: DeFi Education Fund (June 2021): 79.6M FOR, 15M AGAINST Reduce proposal submission threshold (June 2021): 90M FOR, 0M AGAINST Uniswap Grants (December 2020): 60M FOR, 0M AGAINST Retroactive Proxy Airdrop (November 2020): 37.5M FOR, 1.2M AGAINST Reduce submission and quorum threshold (October 2020): 39.5M FOR, 0.7M AGAINST
It is clear that the quorum must be raised from the initial 40M threshold in September 2020, given the recent participation rates of >90M UNI. Even back in December, participation had reached 60M.
In response to 1), it would be great if you could clarify what you mean by a more dynamic approach. Currently, even if a proposal surpasses the quorum threshold, it must still achieve a majority FOR to be passed. For example, with a 40M quorum in place (status quo), if a proposal gets 50M FOR and 51M AGAINST, it won't be able to pass as it has not fetched a majority of all outstanding votes. We won't be changing this mechanism. The quorum threshold simply acts as a safety net. For example, with a 40M quorum in place, if a proposal gets 30M FOR and 25M AGAINST, despite achieving majority approval the proposal would not be able to pass as it has not yet reached the quorum.
The quorum should be high enough so that VCs, their proxies/delegates and team members cannot reach it without support from the greater tokenholder community.
There is no point in raising the quorum until we have more transparency into what that number is - of course, taking vesting into consideration.
The quorum should be high enough so that VCs, their proxies/delegates and team members cannot reach it without support from the greater tokenholder community.
There is no point in raising the quorum until we have more transparency into what that number is - of course, taking vesting into consideration.
Due to clear VC dominance in this token ecosystem, raising it to 60m would just be a symbolic gesture at this point.
