# Initialize cWBTCv3 on Ethereum Mainnet
## Proposal summary
Compound Growth Program [AlphaGrowth] proposes the deployment of Compound III to the Mainnet network. This proposal takes the governance steps recommended and necessary to initialize a Compound III WBTC market on Mainnet; upon execution, cWBTCv3 will be ready for use. Simulations have confirmed the market’s readiness, as much as possible, using the [Comet scenario suite](https://github.com/compound-finance/comet/tree/main/scenario). The new parameters include setting the risk parameters based off of the [recommendations from Gauntlet](https://www.comp.xyz/t/add-market-wbtc-on-mainnet/5644/9).
Further detailed information can be found on the corresponding [proposal pull request](https://github.com/compound-finance/comet/pull/954), [deploy market GitHub action run](https://github.com/woof-software/comet/actions/runs/13254078631/job/36997674406) and [forum discussion](https://www.comp.xyz/t/add-market-wbtc-on-mainnet/5644).
## ENS TXT record update
[USDS on Base proposal](https://www.tally.xyz/gov/compound/proposal/395?govId=eip155:1:0x309a862bbC1A00e45506cB8A802D1ff10004c8C0) is active on the moment of pushing this proposal. The proposal reached the quorum and we expect that the proposal will be executed without fail. In case we need to cancel proposal 395, we need to cancel this proposal too
[USDC on Linea proposal](https://www.tally.xyz/gov/compound/proposal/401) is active on the moment of pushing this proposal. We expect proposal 401 will reach the quorum and will be executed successfully. In case we need to cancel proposal 401, we need to cancel this proposal too.## Proposal Actions
The first proposal action sets the CometFactory for the new Comet instance in the existing Configurator.
The second action configures the Comet instance in the Configurator.
The third action deploys an instance of the newly configured factory and upgrades the Comet instance to use that implementation.
The fourth action configures the existing rewards contract for the newly deployed Comet instance.
The fifth action reduces Compound’s [cWBTC](https://etherscan.io/address/0xC11b1268C1A384e55C48c2391d8d480264A3A7F4) reserves and transfers it to Timelock, in order to seed the market reserves for the cWBTCv3 Comet.
The sixth action transfers reserves from Timelock to the cWBTCv3 Comet.
The seventh action updates the ENS TXT record `v3-official-markets` on `v3-additional-grants.compound-community-licenses.eth`, updating the official markets JSON to include the new Ethereum Mainnet cWBTCv3 market.
# Add mETH as collateral into cUSDTv3 on Mainnet
## Proposal summary
Compound Growth Program [AlphaGrowth] proposes to add mETH into cUSDTv3 on Ethereum network. This proposal takes the governance steps recommended and necessary to update a Compound III USDT market on Ethereum. Simulations have confirmed the market’s readiness, as much as possible, using the [Comet scenario suite](https://github.com/compound-finance/comet/tree/main/scenario). The new parameters include setting the risk parameters based on the [recommendations from Gauntlet](https://www.comp.xyz/t/add-meth-market-on-ethereum/5647/5).
Further detailed information can be found on the corresponding [proposal pull request](https://github.com/compound-finance/comet/pull/918) and [forum discussion](https://www.comp.xyz/t/add-meth-market-on-ethereum/5647).
## Proposal Actions
The first action adds mETH asset as collateral with corresponding configurations.
The second action deploys and upgrades Comet to a new version.
# Add cbBTC as collateral into cWETHv3 on Ethereum
## Proposal summary
Compound Growth Program [AlphaGrowth] proposes to add cbBTC into cWETHv3 on Ethereum network. This proposal takes the governance steps recommended and necessary to update a Compound III WETH market on Ethereum. Simulations have confirmed the market’s readiness, as much as possible, using the [Comet scenario suite](https://github.com/compound-finance/comet/tree/main/scenario). The new parameters include setting the risk parameters based off of the [recommendations from Gauntlet](https://www.comp.xyz/t/add-collateral-cbbtc-to-weth-market-on-base-and-mainnet/5689/2).
Further detailed information can be found on the corresponding [proposal pull request](https://github.com/compound-finance/comet/pull/923) and [forum discussion](https://www.comp.xyz/t/add-collateral-cbbtc-to-weth-market-on-base-and-mainnet/5689).
## Proposal Actions
The first proposal action adds cbBTC asset as collateral with corresponding configurations.
The second action deploys and upgrades Comet to a new version.
# Add cbBTC as collateral into cWETHv3 on Ethereum
## Proposal summary
Compound Growth Program [AlphaGrowth] proposes to add cbBTC into cWETHv3 on Ethereum network. This proposal takes the governance steps recommended and necessary to update a Compound III WETH market on Ethereum. Simulations have confirmed the market’s readiness, as much as possible, using the [Comet scenario suite](https://github.com/compound-finance/comet/tree/main/scenario). The new parameters include setting the risk parameters based off of the [recommendations from Gauntlet](https://www.comp.xyz/t/add-collateral-cbbtc-to-weth-market-on-base-and-mainnet/5689/2).
Further detailed information can be found on the corresponding [proposal pull request](https://github.com/compound-finance/comet/pull/923) and [forum discussion](https://www.comp.xyz/t/add-collateral-cbbtc-to-weth-market-on-base-and-mainnet/5689).
## Proposal Actions
The first proposal action adds cbBTC asset as collateral with corresponding configurations.
The second action deploys and upgrades Comet to a new version.
sendMessage(address,bytes,uint32)# Add USDT and USDC as collateral into cWETHv3 on Optimism
## Proposal summary
Compound Growth Program [AlphaGrowth] proposes to add USDT and USDC into cWETHv3 on Optimism network. This proposal takes the governance steps recommended and necessary to update a Compound III WETH market on Optimism. Simulations have confirmed the market’s readiness, as much as possible, using the [Comet scenario suite](https://github.com/compound-finance/comet/tree/main/scenario). The new parameters include setting the risk parameters based off of the [recommendations from Gauntlet](https://www.comp.xyz/t/add-dai-usdc-and-usdt-as-collaterals-to-weth-comets-on-mainnet-and-arbitrum/5415/2).
Further detailed information can be found on the corresponding [proposal pull request](https://github.com/compound-finance/comet/pull/900) and [forum discussion](https://www.comp.xyz/t/add-dai-usdc-and-usdt-as-collaterals-to-weth-comets-on-mainnet-and-arbitrum/5415).
## Proposal Actions
The first proposal action adds USDT and USDC to the WETH Comet on Optimism. This sends the encoded `addAsset` two times and `deployAndUpgradeTo` calls across the bridge to the governance receiver on Optimism.
depositETHTo(address,uint32,bytes)sendMessage(address,bytes,uint32)# Initialize cWETHv3 on Optimism
## Proposal summary
Compound Growth Program [AlphaGrowth] proposes the deployment of Compound III to the Optimism network. This proposal takes the governance steps recommended and necessary to initialize a Compound III WETH market on Optimism; upon execution, cWETHv3 will be ready for use. Simulations have confirmed the market’s readiness, as much as possible, using the [Comet scenario suite](https://github.com/compound-finance/comet/tree/main/scenario). The new parameters include setting the risk parameters based on the [recommendations from Gauntlet](https://www.comp.xyz/t/add-market-eth-on-optimism/5274/5).
Further detailed information can be found on the corresponding [proposal pull request](https://github.com/compound-finance/comet/pull/882), [deploy market GitHub action run](https://github.com/woof-software/comet/actions/runs/9941213214/job/27464571077) and [forum discussion](https://www.comp.xyz/t/add-market-eth-on-optimism/5274).
## Proposal Actions
The first action bridges 10 ETH as seed reserves from Mainnet Timelock to Optimism L2 Timelock using OpL1StandardBridge.
The second action sets the Comet configuration and deploys a new Comet implementation on Optimism. This sends the encoded `setFactory`, `setConfiguration` and `deployAndUpgradeTo` calls across the bridge to the governance receiver on Optimism. It also calls `setRewardConfig` on the Optimism rewards contract, to establish Optimism’s bridged version of COMP as the reward token for the deployment and set the initial supply speed to be 4 COMP/day and borrow speed to be 3 COMP/day. The last two steps are to wrap ETH into WETH and transfer seed reserves into Comet
The third action updates the ENS TXT record `v3-official-markets` on `v3-additional-grants.compound-community-licenses.eth`, updating the official markets JSON to include the new Optimism cWETHv3 market.
# Add weETH as collateral into cWETHv3 on Mainnet
## Proposal summary
Compound Growth Program [AlphaGrowth] proposes to add weETH into cWETHv3 on Ethereum network. This proposal takes the governance steps recommended and necessary to update a Compound III WETH market on Ethereum. Simulations have confirmed the market’s readiness, as much as possible, using the [Comet scenario suite](https://github.com/compound-finance/comet/tree/main/scenario). The new parameters include setting the risk parameters based on the [recommendations from Gauntlet weETH](https://www.comp.xyz/t/add-weeth-market-on-ethereum/5179/3).
Further detailed information can be found on the corresponding [proposal pull request](PR - https://github.com/compound-finance/comet/pull/869) and [forum discussion weETH](https://www.comp.xyz/t/add-weeth-market-on-ethereum/5179).
## Proposal Actions
The first proposal action adds weETH asset as collateral with corresponding configurations.
The second action sets new Annual Supply Interest Rate Slope High to 100%.
The third action sets new Annual Borrow Interest Rate Slope High to 115%.
The fourth action deploys and upgrades Comet to a new version.
# Update Uni v3/v2 Deployment Process (March 2024)
**Authors: Uniswap Accountability Committee**
## TLDR:
* Today, Uniswap governance, via the timelock address, has the ability to declare a new v3/v2 deployment as official/canonical
* The DAO has set a precedent for approving EVM-based deployments over the past 2 years
* This proposal seeks to give the Uniswap Accountability Committee multisig agency over altering the v3-deployments.uniswap.eth & v2deployments.uniswap.eth subdomains
* This will allow the Committee to edit these text records whenever a new v3/v2 deployment is complete without having to go through an onchain vote
* To accommodate for this change, we are also proposing an alteration to the current deployment governance process (see “New Proposed Deployment Process” below) to increase efficiency
* The DAO will retain the right to assign incentive distributions from the treasury to these deployments via an onchain vote
* The DAO will maintain ownership of the primary domain, uniswap.eth, and thus have the ability to revoke the Committee's subdomain permissions through a governance vote–this assures proper checks and balances
## Background:
Over the past two years, the DAO has approved numerous EVM-based deployments for Uniswap v3. There has only been one instance of a deployment proposal that did not pass the off-chain stage due to not meeting quorum: [Fantom](https://snapshot.org/#/uniswapgovernance.eth/proposal/0x98e08d94e1174b0bfa2350c616d3cf2fb8f5e56c56c03dc0ae58fd29a6b29265). We believe that this sets a precedent for optimistically acknowledging incoming EVM-based deployments as canonical. The same precedent can be set for v2 since there was a recent proposal to [deploy v2 across all target chains with v3](https://www.tally.xyz/gov/uniswap/proposal/58) in one fell swoop.
The v3-deployments.uniswap.eth & v2deployments.uniswap.eth ENS subdomains act simply as records of the v3/v2 deployments that the DAO has “blessed”. From a legal as well as technical perspective, alterations to the subdomain don’t hold any weight–it’s merely a place onchain that the DAO can recognize v3/v2 deployments across various EVM chains. This way, there’s a public place to keep track of which deployments are official. Such recognition is important because it allows users and developers to ensure that the contracts they’re interacting with are representative of the real Uniswap (i.e. the Uniswap fork that has been approved by the DAO), thereby ensuring security and consistency across each fork.
When the DAO currently approves deployments onchain, only the v3-deployments.uniswap.eth & v2deployments.uniswap.eth text records are being altered. The actual contract deployment is completed by a third party, like [@GFXlabs](https://gov.uniswap.org/u/gfxlabs). In fact, the deployment has to be completed prior to the onchain vote since the text record alterations requires the
* The destination chain’s network number
* Bridge sender contract address on mainnet associated with the deployment
* UniswapV3Factory/UniswapV2Factory address on the destination chain
### Current Deployment Process:
* If a chain wants to deploy Uniswap, they typically connect with either the Foundation, the Accountability Committee, a delegate, or any adjacent party
* Anyone is able to author an RFC, whether it be a delegate, the destination chain themselves, or whoever else. That RFC is posted on the forum for a minimum of seven days to allow a discussion to transpire
* A temperature check takes place, allowing the DAO to either approve or deny the deployment of Uni v3/v2 on the given chain
* Once passed, the v3/v2 contracts are deployed on the destination chain–the deployer collaborates with an approved bridge provider if the EVM chain is not an L2 (i.e. doesn’t already have a canonical bridge)
* The onchain vote takes place, recognizing the deployed contracts as official on the subdomain
## Our Proposal
**We are proposing to enable the Uniswap Accountability Committee multisig to alter the subdomains as soon as a deployment’s RFC passes the 7-day discussion period–given there are no major points of contention during the RFC phase.** The RFC should give ample time to the DAO to make a decision regarding the deployment without having to partake in a 4+ week governance ordeal. And to make sure voters have a say in this process, we are including a 5-day challenge period that will be a part of the onboarding package temperature check–this will allow voters to voice their dissenting opinion regarding a deployment.
Currently, the Uniswap DAO, more specifically the timelock address (0x1a9C8182C09F50C8318d769245beA52c32BE35BC) owns AND manages both subdomains. This proposal would make the Accountability Committee the manager of the subdomains. If at any time the DAO would like to alter the manager again or regain control, this can be done via an onchain vote since the timelock still owns the subdomains.
### New Proposed Deployment Process:
**Step 1**
* If a chain wants to deploy Uniswap, they typically connect with either the Foundation, the Accountability Committee, a delegate, or any adjacent party
* Anyone is able to author an RFC, whether it be a delegate, the destination chain themselves, or whoever else. That RFC is posted on the forum for a minimum of seven days to allow a discussion to transpire
* The deployer can either have the contracts deployed at this point or not–if the deployment is complete, then include the contracts in the RFC
* **If no issues arise in the RFC, then the deployment will be viewed as approved, and a 5-day challenge period will be rolled into the onboarding package snapshot vote**
**Step 2 (Work for the Deployer and Accountability Committee)**
* If deployment hasn’t already been completed, then it must be done after the RFC phase
* As soon as contracts are deployed and verified, ensuring that the bytecode of the deployed contracts matches the bytecode of the mainnet contracts, the Committee will comment on the RFC confirming that the contracts have been verified 
* The Committee will then hold a temperature check to see if there’s interest in deploying incentives on the new fork–this vote also acts as the challenge period
* **Once the snapshot is completed, and the vote is not subject to a majority veto, the Committee has the authority to write the relevant text to the subdomain**
* The Committee will comment on the RFC confirming that the subdomain has been properly updated
* An onchain vote will then take place to send the selected amount of capital to the Committee multisig for distribution on the target chain
## Technical Implementation:
The onchain proposal needs to include the function calls below to grant the Accountability Committee write permissions to the subdomains. The DAO will maintain ownership of the primary domain, uniswap.eth, and thus have the ability to revoke the Committee's permissions through a governance vote and establish checks and balances.
**For Uniswap v3 Subdomain:**
setOwner(
  node = 0x0b9638d2c5bd4528d603562a1fa1e734fe1b88e680f448d779531e9bc2b55f12, 
  owner = 0x3B59C6d0034490093460787566dc5D6cE17F2f9C
)
**For Uniswap v2 Subdomain:**
setOwner(
  node = 0x30e9fa72b4d7d40be0f8809d748497121d5f38ebf8700a7d2e303074e9ccf1a5, 
  owner = 0x3B59C6d0034490093460787566dc5D6cE17F2f9C
)
## Next Steps:
*The Accountability Committee will retroactively alter the subdomain text record for any deployments that are approved and haven't been included in the subdomains after the approval of this proposal. The Committee will also add the text for deployments that did not go through the formal governance process from the* [*Uniswap Revitalization and Growth*](https://gov.uniswap.org/t/uniswap-revitalization-and-growth/22616) *proposal.*
# Initialize cUSDCv3 on Scroll
This proposal takes the governance steps recommended and necessary to initialize a Compound III USDC market on Scroll; upon execution, cUSDCv3 will be ready for use. Simulations have confirmed the market’s readiness, as much as possible, using the [Comet scenario suite](https://github.com/compound-finance/comet/tree/main/scenario). Although real tests have also been run over the Goerli/Scroll Alpha bridge, this will be the first proposal to actually bridge from Ethereum mainnet to Scroll mainnet, and therefore includes risks not present in previous proposals.
Although the proposal sets the entire configuration in the Configurator, with parameters based off of the [recommendations from Gauntlet](https://www.comp.xyz/t/deploy-compound-iii-on-scroll/4917/3).
Further detailed information can be found on the corresponding [proposal pull request](https://github.com/compound-finance/comet/pull/824) and [forum discussion](https://www.comp.xyz/t/deploy-compound-iii-on-scroll/4917).
## Proposal Actions
The first proposal action sets the Comet configuration and deploys a new Comet implementation on Scroll. This sends the encoded `setConfiguration` and `deployAndUpgradeTo` calls across the bridge to the governance receiver on Scroll. It also calls `setRewardConfig` on the Scroll rewards contract to establish Scroll’s bridged version of COMP as the reward token for the deployment (note that rewards speeds have been set to 0, as Gauntlet has recommended to hold off on including rewards in the comet deployment for now).
The second action approves Scroll’s [L1USDCGateway](https://etherscan.io/address/0xf1AF3b23DE0A5Ca3CAb7261cb0061C0D779A5c7B) to take Timelock's USDC, in order to seed the market reserves through the bridge.
The third action deposits 10K USDC from mainnet to the Scroll L1USDCGateway contract to bridge to Comet.
The fourth action updates the ENS TXT record `v3-official-markets` on `v3-additional-grants.compound-community-licenses.eth`, updating the official markets JSON to include the new Scroll cUSDCv3 market.
# [Gauntlet] 2024-03-11: Compound V2 Deprecation (Phase 10) - Part 1
Michigan Blockchain is publishing the following proposal on behalf of Gauntlet.
# Simple Summary
For Phase 10 of the v2 deprecation, Gauntlet recommends the following borrow cap and reserve factor adjustments:
| Symbol | Current Borrow Cap | Current Borrow Cap USD | Recommended Borrow Cap | Recommended Borrow Cap USD |
| --- | --- | --- | --- | --- |
| DAI | - | - | 80,000,000 | $80 M |
| UNI * | 700,000 | $7.379 M | 25,000 | $0.264 M |
| TUSD | - | - | 650,000 | $0.650 M |
| USDC | - | - | 100,000,000 | $100 M |
| COMP * | 18,000 | $1.439 M | 2,500 | $0.200 M |
| ETH | 100,000 | $322.464 M | 10,000 | $32 M |
| USDP | - | - | 3,000,000 | $3 M |
| LINK * | 125,000 | $2.362 M | 9,000 | $0.170 M |
| USDT | - | - | 180,000,000 | $180 M |
* indicates supply for this asset is paused
| Symbol | Current Reserve Factor | Recommended Reserve Factor |
| --- | --- | --- |
| COMP | 25.00% | 50.00% |
| UNI | 25.00% | 50.00% |
| LINK | 25.00% | 50.00% |
| SUSHI | 25.00% | 50.00% |
**Gauntlet will not be able to include all the recommendations within the original forum post because of the limiting number of transactions per proposal allowed via Compound goverance. Gauntlet will be breaking this proposal into 2 parts.**
## Motivation
In this September 2022 snapshot vote, the community voted to start deprecating certain assets on the Compound v2 markets. After our analysis, Gauntlet recommends the following borrow caps and reserve factor adjustments to further deprecate the v2 market.
[Full proposal and forum discussion](https://www.comp.xyz/t/gauntlet-v2-deprecation-phase-10-2-27-24/5025)
<sub> By approving this proposal, you agree that any services provided by Gauntlet shall be governed by the terms of service available at gauntlet.network/tos. <sub>
setText(bytes32,string,string)# Initialize cUSDCv3 on Scroll
This proposal takes the governance steps recommended and necessary to initialize a Compound III USDC market on Scroll; upon execution, cUSDCv3 will be ready for use. Simulations have confirmed the market’s readiness, as much as possible, using the [Comet scenario suite](https://github.com/compound-finance/comet/tree/main/scenario). Although real tests have also been run over the Goerli/Scroll Alpha bridge, this will be the first proposal to actually bridge from Ethereum mainnet to Scroll mainnet, and therefore includes risks not present in previous proposals.
Although the proposal sets the entire configuration in the Configurator, with parameters based off of the [recommendations from Gauntlet](https://www.comp.xyz/t/deploy-compound-iii-on-scroll/4917/3).
Further detailed information can be found on the corresponding [proposal pull request](https://github.com/compound-finance/comet/pull/824) and [forum discussion](https://www.comp.xyz/t/deploy-compound-iii-on-scroll/4917).
## Proposal Actions
The first proposal action sets the Comet configuration and deploys a new Comet implementation on Scroll. This sends the encoded `setConfiguration` and `deployAndUpgradeTo` calls across the bridge to the governance receiver on Scroll. It also calls `setRewardConfig` on the Scroll rewards contract to establish Scroll’s bridged version of COMP as the reward token for the deployment (note that rewards speeds have been set to 0, as Gauntlet has recommended to hold off on including rewards in the comet deployment for now).
The second action approves Scroll’s [L1USDCGateway](https://etherscan.io/address/0xf1AF3b23DE0A5Ca3CAb7261cb0061C0D779A5c7B) to take Timelock's USDC, in order to seed the market reserves through the bridge.
The third action deposits 10K USDC from mainnet to the Scroll L1USDCGateway contract to bridge to Comet.
The fourth action updates the ENS TXT record `v3-official-markets` on `v3-additional-grants.compound-community-licenses.eth`, updating the official markets JSON to include the new Scroll cUSDCv3 market.
# Deploy Uniswap V3 on Rootstock
# **Proposal Motivation**
We [<u>Michigan Blockchain</u>](https://twitter.com/UMichBlockchain) are submitting this proposal to facilitate the integration of Uniswap V3 on Rootstock (RSK), the first Bitcoin sidechain. Rootstock combines the security of Bitcoin and the functionality of Ethereum. This amalgam is enabled by RSK’s implementation of a merged mining architecture and an EVM-compatible execution environment. Unlike most deployments during the bear market, RSK has doubled-down on this initiative, allocating a total of $3 million for bootstrapping liquidity across various pools.
What’s more is that the [<u>IOV Labs</u>](https://www.iovlabs.org/) team (the research and development group behind RSK) has been closely collaborating with both [<u>GFX Labs</u>](https://twitter.com/labsGFX) and [<u>Wormhole</u>](https://wormhole.com/) to ensure that this deployment is completed seamlessly. They have taken all of the necessary technical steps to be eligible for finalizing this deployment. The relevant v3 contracts are now deployed on RSK (see “Deployment Details”), along with pools for trading RBTC (1:1 with $BTC), RIF, and wETH, all accessible using the [<u>Oku Trade front-end</u>](https://oku.trade/app/rootstock/pool/0xd2ffe51ab4e622a411abbe634832a19d919e9c55?utm_source=uniswap\&utm_medium=forum\&utm_campaign=rootstocktemp). This deployment has already aggregated over [<u>$1.1M of TVL</u>](https://oku.trade/info/rootstock/overview?utm_source=uniswap\&utm_medium=forum\&utm_campaign=rootstocktemp) and is seeing[<u> upwards of $540k in daily volume</u>](https://oku.trade/info/rootstock/overview?utm_source=uniswap\&utm_medium=forum\&utm_campaign=rootstocktemp) over the past two weeks. Plus, the Wormhole integration is in place to facilitate any cross-chain governance messaging. The final hurdle is to officiate this proposal through the Uniswap governance process, and recognize this as the canonical v3 deployment on RSK.
### **Introducing Uniswap to the Bitcoin Space**
We’ve been in contact with IOV Labs for the past couple of months regarding this deployment. Our teams have had back and forth conversations regarding the merits and drawbacks of bringing Uniswap to a Bitcoin sidechain, which, admittedly, has limited mindshare among DeFi users across other EVM chains. Currently, there are two divergent user profiles when it comes to Bitcoin. The first is the staunch Bitcoin Maxi. This person views $BTC as the one and true cryptocurrency, with a notable preference for highly secure and isolated systems. Conversely, we have the DeFi users. Most of their activity takes place on the EVM, and their objective is financial gain using various onchain instruments–staking, liquidity provision, borrowing/lending, yield farming, perpetuals, etc. Security is important to everyone, at least idealistically speaking, but users’ actions often indicate a preference for profiteering in the face of taking a degree of risk.
However, we think that there may be a market in between these two that Uniswap–and DeFi protocols in general–could help service. It could very well be the case that users who want to conduct DeFi transactions using $BTC will do so through dapps launched on RSK. The security guarantees using the merged-mining setup make interacting with $BTC on RSK ($RBTC) more secure than using $BTC on alternative smart contract platforms. Although it may be a reaching assumption that users will have the motivation to prioritize security to such an extent, easy access to RSK via wallets like Metamask make it frictionless for users to jump between ETH and RSK. The potential concern here, however, is liquidity fragmentation. That is, unless, a certain market of users exclusively uses RSK for all things BTC.
# **Proposal Stakeholders**
The following list of stakeholders is present to transparently communicate which entities and individuals are involved in proposal creation and implementation.
**Proposer:** [**<u>Michigan Blockchain</u>**](https://twitter.com/umichblockchain?lang=en)
*This entity is responsible for authoring the proposal & managing the governance process*
**Deployer:** [**<u>IOV Labs</u>**](https://www.iovlabs.org/) **+** [**<u>GFX Labs</u>**](https://twitter.com/labsGFX)
*This entity is responsible for the technical deployment of the contracts on the target chain*
* The IOV Labs team is responsible for the innovation behind Rootstock
* GFX Labs helped deploy the v3 contracts on RSK and has a track record of safely deploying Uniswap v3 on various EVM-compatible chains
**Frontend:** [**<u>Oku Trade</u>**](https://oku.trade/app/rootstock/pool/0xd2ffe51ab4e622a411abbe634832a19d919e9c55?utm_source=uniswap\&utm_medium=forum\&utm_campaign=rootstocktemp)
*The initial frontend where users can interact with the new Uniswap v3 deployment*
* Oku is built and managed by GFX Labs
* Oku was seeded by a Uniswap Foundation grant in 2022
* Oku supports eight chains and continues to aid Uniswap’s expansion to new protocols
Note: Oku Trade has become the DAO’s go-to third party front-end for Uniswap deployments since the canonical front-end is owned and operated by Uniswap Labs
**Bridge Provider:** [**<u>Wormhole</u>**](https://wormhole.com/)
*This is the cross-chain messaging solution selected for this deployment*
* Wormhole serves as the governance messaging provider to four Uniswap deployments: BNB, Celo, Gnosis, and Moonbeam. This would be their fifth integration
* Wormhole’s summary from the [<u>Uni Bridge Assessment Report</u>](https://uniswap.notion.site/Bridge-Assessment-Report-0c8477afadce425abac9c0bd175ca382): “The analysis of Wormhole concluded it satisfies the requirements of the Uniswap DAO’s cross-chain governance use case…the set of validators includes many reputable entities, and both the number of validators and security thresholds are set at satisfactory levels. Moreover, the implementation of the protocol and operational security practices are well considered.”
**Target Chain:** [**<u>Rootstock</u>**](https://rootstock.io/) **(Bitcoin Sidechain)**
*This is the chain that v3 contracts are deployed on*
**Proposal Sponsor:** [**<u>Michigan Blockchain</u>**](https://twitter.com/UMichBlockchain)
*This entity has >2.5M UNI and is therefore eligible for administering the onchain vote*
# **A Primer on Rootstock**
### **Bringing the EVM to Bitcoin**
Launched in 2018, RSK is the first Bitcoin sidechain. Generally speaking, a sidechain is an independent blockchain that’s fettered to a parent blockchain. In this case, Bitcoin is the parent chain, while RSK is the sidechain. The sidechain extension typically features aspects that the primary chain cannot support–Ethereum folk are very familiar with functionality separation nowadays due to the multichain and modular nature of EVM-based systems. Bitcoin is naturally more isolated, with a particular focus on sustaining the so-to-speak sanctity of its chain. However, the bare bones nature of Bitcoin means that it cannot support complex applications due to limitations around programmability. So how can this system be improved? Well, Bitcoin itself ideally stays untouched. Its usage as a ledger for an incorruptible store of value is therefore preserved, but it can be complemented with a sidechain like RSK.
**RSK is an EVM-compatible Bitcoin sidechain**, meaning that it is Turing complete and enables developers to construct a robust ecosystem with close proximity to the Bitcoin blockchain. Specifically, the chain uses the [<u>RSK Virtual Machine (RVM)</u>](https://dev.rootstock.io/rsk/architecture/), which is compatible with the EVM at the op-code level. This is precisely why Uniswap, and alike Ethereum dapps, have the ability to seamlessly deploy on RSK without significant smart contract modifications. Core Ethereum infrastructure, wallets, and tooling (Hardhat, Truffle, Ether.js, Web3.js, etc) also support RSK–so devs can easily migrate to and build on RSK while a user can simply [<u>add RSK</u>](https://chainlist.org/chain/30) to their already running list of chains on Metamask. But a shared execution environment is not enough of a value add. That’s where we must consider RSK’s true value proposition: shared security with Bitcoin.
### **Security Before All Else–Merged Mining**
Unlike most other blockchains, RSK employs a consensus mechanism known as merged mining, allowing miners to simultaneously secure both Bitcoin and RSK at no extra cost. This results in RSK benefiting from the formidable security and stability touted by Bitcoin. Approximately[<u> 50% of the current Bitcoin hashrate is involved in securing RSK</u>](https://stats.rsk.co/). In other words, many of the same miners that provide security to Bitcoin are also securing RSK using the same hardware and energy inputs. Some of the largest Bitcoin mining pools like Antpool, Luxor, Braiins, F2Pool, and Binance Pool, have all opted into the merged mining setup.
**What about previous failures surrounding merged mining like CoiledCoin?**
* Rootstock doesn’t implement the traditional merge-mining mechanism used by CoiledCoin–but a more modern protocol with additional security guarantees. This is explained by RSK’s Chief Scientist [<u>here. </u>](https://medium.com/iovlabs-innovation-stories/modern-merge-mining-f294e45101a0)An in-depth analysis can be found in the Consensus section [<u>here</u>](https://medium.com/iovlabs-innovation-stories/measuring-rsk-security-d169ac03b181). The infamous CoiledCoin attack was performed by a single individual (LukeJr) who could control more than 51% of the blockchain hashrate, which is impossible on Rootstock, and was ideologically motivated because CoiledCoin competed with Bitcoin, something Rootstock does not do. On the contrary, Rootstock provides additional value to Bitcoin. Rootstock talks have been given at Bitcon [<u>conferences</u>](https://baltichoneybadger.com/) without opposition of any kind. The same individual that attacked CoiledCoin has a positive opinion regarding Rootstock and a neutral opinion on the sidechain’s hashrate escrows.
### **Two-way Proof of Work Peg (PoWPeg)**
Rootstock does not have its own token nor inflation-based incentives. The way Bitcoin and RSK are connected is via a two-way peg using $BTC. A user deposits their $BTC in the RSK bridge, which, in turn, mints the rBTC on the RSK network. Both assets will always have a 1:1 ratio, and the max amount of mintable rBTC is the same as the max BTC supply of 21M. Hence, the main asset that the entire RSK ecosystem relies on is, at the end of the day, $BTC. RSK mining rewards are paid out to miners solely through transaction fees in the form of $rBTC.
Typically, if a PoW chain relies solely on rewarding its miners with txn fees, and if that chain has low volume, it would be subject to a 51% attack. This issue, however, is subverted under a shared security system like merged mining. No matter how low the volume falls, the network will remain steady because the reliance is entirely on the security of Bitcoin. Sure, one could argue Bitcoin itself could face fragility if txn fees and incentives simultaneously become too low–however, it is an unlikely case since the adoption of $BTC is so pervasive that many large parties are incentivized to secure the system even if it’s at a capital loss. Plus, innovations like [<u>inscriptions continue to sustain momentum for Bitcoin’s usage</u>](https://messari.io/report/bitcoin-brief-runes-grayscale-and-microstrategy?referrer=research-reports).
# **Bitcoin Ecosystem Catalysts**
If we analyze the previous points about the robust security and EVM compatibility of RSK, it’s clear how there may be an untapped market here for Uniswap to enter. Bitcoin, relative to the rest of the crypto market, is to a degree, isolated. The adoption of Bitcoin has been far more prominent around the world relative to other cryptocurrencies, even becoming [<u>legal tender in countries like El Salvador</u>](https://www.pwc.com/gx/en/financial-services/pdf/el-salvadors-law-a-meaningful-test-for-bitcoin.pdf). The US regulatory environment, though constrictive to most cryptocurrencies, [<u>has been significantly more amenable to Bitcoin</u>](https://watcher.guru/news/secs-gary-gensler-says-bitcoin-is-not-a-security).
In the past year alone, Bitcoin has taken tremendous mindshare among both investors and users. A series of BTC Spot ETF filings were released in July as [<u>Blackrock led the pack</u>](https://www.forbes.com/advisor/investing/cryptocurrency/spot-bitcoin-etf/). And August saw [<u>Grayscale secure a vital victory against the SEC</u>](https://cointelegraph.com/news/grayscale-wins-sec-lawsuit), as the appeals court denied the SEC’s attempt to deny GBTC’s conversion to an ETF. On the user side, inscriptions dominated the Bitcoin landscape, bringing another creative use case to the seemingly latent chain. Although ordinal (non-fungible) & BRC-20 (fungible) inscription volume peaked earlier in the year, they have since sustained a large degree of their momentum, with [<u>average daily inscription mints increasing by 48.1% in Q3</u>](https://messari.io/report/state-of-bitcoin-q3-2023). The large Bitcoin fee uptrend can also be attributed the inscriptions rush.
RSK is also taking advantage of these advancing narratives. Through [<u>RSKIP-387</u>](https://github.com/rsksmart/RSKIPs/blob/master/IPs/RSKIP387.md), Bitcoin ordinals and inscriptions are looking to become available on RSK using the Powpeg bridge. In terms of projects, IOV Labs is [<u>funding</u>](https://rootstock.io/grants/) more than 5 ordinals-based projects that came out of the HackerEarth Ideathon + Hackathon.
# **Liquidity Bootstrapping**
Rootstock will commit $3M Rootstock-based tokens in Uniswap-specific liquidity. The tokens will be deployed on Uniswap through the Rootstock integration with Oku, the funds will be provided by IOV Labs. They will work to deploy the funds as follows:
* 1st Phase - Deployment: up to $400k into four liquidity pools for the following:
* $100k in RIF/RBTC
* $100k in RIF/rUSDT
* $100k in RBTC/rUSDT
* $100k in RIF/wETH
<!---->
* 2nd Phase - Growth: up to $1M to be distributed in the previous four liquidity pools created in the 1st Phase.
* The amount to be added into the liquidity pools will be decided according to the trading volume growth in a period of 3 months for each pool.
* 3rd Phase - Expansion: up to $2M to be used in order to create new liquidity pools and token pairs.
* IOV labs will create new liquidity pools according to market demand. These new liquidity pools will be a minimum amount of $100k.
The goal is to deploy the $3M within 12 months in several phases. While the proposed limit is $3M, IOV Labs may increase this amount based on the outcome and success of this initiative.
Track active pools, TVL, volume, and fee metrics via [<u>Oku’s RSK analytics page</u>](https://oku.trade/info/rootstock/overview?utm_source=uniswap\&utm_medium=forum\&utm_campaign=rootstocktemp).
# **Success Criteria**
Overall, we propose the transparent measurement of this project’s success through the following success criteria and long-term goals:
* At least a 30% increase in TVL across all initial pools during 2024, excluding the liquidity provided by IOV Labs
* At least a 100% increase in average RSK DEX trading volume across all initial pools in the first six months after the onchain proposal
* Successful adoption of Uniswap by the Rootstock community, aiming for a >20% increase in the number of active users by end of Q1 2024
* Continuous and sustainable maintenance of the Uniswap-RSK integration contract, ensuring optimal operation and long-term security
# **Deployment Details**
The approval of this proposal by Uniswap governance will lead the below Uniswap v3 contracts to be deemed as the canonical deployment on RSK. As is the case with all canonical v3 deployments, this deployment will be subject to Ethereum Layer 1 Uniswap Protocol governance and control. The text record of the uniswap.eth ENS subdomain titled v3-deployments.uniswap.eth will be amended to include the reference to the stated v3 contracts on RSK.
**Below are the deployed contracts:**
| [v3CoreFactory](https://rootstock.blockscout.com/address/0xAf37Ec98A00fD63689cF3060Bf3b6784e00CaD82) | 0xaF37EC98A00FD63689CF3060BF3B6784E00caD82 |
| ------------------------------------------------------------------------------------------------------------------------------ | ----------------------------------------------- |
| [nftDescriptor](https://rootstock.blockscout.com/address/0xA231609cF5EE20B3Ff9BD8BbfD1928737e6e6264)
 | 0xA231609CF5ee20b3FF9bd8bBfD1928737E6e6264
 |
| [nonfungibleTokenPositionDescriptor](https://rootstock.blockscout.com/address/0x1519aB9C0bf7c8F261acA6c58d59A152c95B3eBc)
 | 0x1519ab9C0bF7C8f261aCa6c58d59A152C95B3Ebc
 |
| [nonfungibleTokenPositionManager](https://rootstock.blockscout.com/address/0x9d9386C042f194B460ec424a1e57ACde25F5c4B1)
 | 0x9d9386c042F194B460Ec424a1e57ACDE25f5C4b1
 |
| [v3Migrator](https://rootstock.blockscout.com/address/0x16678977cA4eC3dAD5Efc7b15780295fe5F56162)
 | 0x16678977CA4ec3DAD5efc7b15780295FE5f56162
 |
| [Multicall2](https://rootstock.blockscout.com/address/0x996a9858cdFa45aD68E47C9a30A7201E29c6A386)
 | 0x996a9858cDfa45Ad68E47c9A30a7201E29c6a386
 |
| [proxyAdmin](https://rootstock.blockscout.com/address/0xe6c623E32eD33f29b4D7c002c01Debda629E4604)
 | 0xE6c623e32eD33f29b4D7C002C01DebDA629e4604
 |
| [tickLens](https://rootstock.blockscout.com/address/0x55b9df5BF68ADE972191a91980459f48ECA16AFC)
 | 0x55B9dF5bF68ADe972191a91980459f48ecA16afC
 |
| [descriptorProxy](https://rootstock.blockscout.com/address/0x2aeCBEE0Dc58E3419a52eEAF6ea16c498bAeE24f)
 | 0x2AECbeE0dc58e3419A52EEaF6Ea16C498BAeE24F
 |
| [v3Staker](https://rootstock.blockscout.com/address/0x96481062bFAA29AdAAEBfc5fa6f46D9556F0150c)
 | 0x96481062BfAA29AdaaeBfC5FA6F46d9556F0150c
 |
| [quoterV2](https://rootstock.blockscout.com/address/0xb51727C996c68E60f598a923A5006853Cd2fEB31)
 | 0xb51727c996C68E60F598A923a5006853cd2fEB31
 |
| [swapRouter02](https://rootstock.blockscout.com/address/0x0B14ff67F0014046b4b99057Aec4509640b3947A)
 | 0x0B14ff67f0014046b4b99057Aec4509640b3947A
 |
| [Permit2](https://rootstock.blockscout.com/address/0xfcF5986450e4a014FFe7ad4aE24921b589D039b5)
 | 0xFcf5986450E4A014fFE7ad4Ae24921B589D039b5
 |
| [Universal Router](https://rootstock.blockscout.com/address/0x244f68E77357f86A8522323EbF80B5FC2f814d3E)
 | 0x244f68e77357f86a8522323eBF80b5FC2F814d3E
 |
| [Message Sender](https://rootstock.blockscout.com/address/0xf5F4496219F31CDCBA6130b5402873624585615a)
 | 0xf5F4496219F31CDCBa6130B5402873624585615a
 |
| [Message Receiver](https://rootstock.blockscout.com/address/0x38aE7de6f9C51e17f49cf5730dD5f2d29FA20758)
 | 0x38aE7De6f9c51e17f49cF5730DD5F2d29fa20758
 |
# Add rETH as Collateral to wETHv3 Mainnet
See proposal and parameter recommendations here: https://www.comp.xyz/t/add-reth-as-collateral-to-wethv3-on-mainnet/4498
# Deploy Uniswap V3 on Scroll
After a successful temperature check as well as deployments of Uniswap
V3 on both our Alpha and Sepolia testnets, Scroll looks to move towards a final
governance proposal to officially approve Scroll’s Uniswap V3 deployment on its newly
launched mainnet.
The [temperature check](https://snapshot.org/#/uniswap/proposal/0xc874c15656ac985df2f34d4438f8d074226f10408dd74f08295227974179b2c1) passed with 28M (100%) YES votes in August.
**Point of Contact:** \[Shahryar Hasnani, E-mail: shahryar@scroll.io]
## **Proposal Overview**
We propose that the Uniswap DAO recognizes Scroll’s mainnet deployment of Uniswap
V3 as the official - canonical deployment. Uniswap V3 has already been deployed and
highly utilized on Scroll’s Alpha and Sepolia testnets, with the router contract having
processed over 1.8M and 450K transactions on each testnet, respectively. A brief
overview of Scroll:
* Scroll is a bytecode-compatible zk-rollup, a native zkEVM scaling solution for Ethereum.
* Scroll is an open-source project developed in collaboration with the Ethereum Foundation Privacy and Scaling Explorations organization. It was built [with the community, for the community.](https://github.com/scroll-tech)
* [Our community ethos and vision](https://scroll.io/story) are aligned with Ethereum. We are committed to a secure, decentralized, censorship-resistant, and efficient future that Ethereum offers through our plans to decentralize Scroll sequencers and provers.
## **Motivation**
We believe that Uniswap being deployed on multiple Ethereum L2s is integral for encouraging competition and diversity of technical solutions to scale Ethereum. Furthermore, we believe that Uniswap’s community and the ecosystem that Scroll strives for are closely aligned. Both projects are building trustless, decentralized, and secure financial infrastructure that is accessible to anyone, regardless of merit or location. Deploying to Scroll offers many benefits, including significant user savings, an expanded user base, capturing the zkEVM market, and fostering L2 native innovation. The endgame of Ethereum and its L2s will be fundamentally underpinned by ZK— this deployment puts Uniswap in the best position to capitalize on the future of the EVM ecosystem by integrating with the most Ethereum-aligned and future-proof L2. Uniswap on Scroll will integrate closely with Scroll’s rapidly growing ecosystem. Dozens of projects have committed to deploying on our mainnet, and over 150 have deployed on our testnets, including AAVE, Lens, the Graph, Covalent, Safe, and Etherscan to name a few. Given the excitement around Scroll and current usage of our testnet, we expect hundreds of projects to deploy on our mainnet post-launch. Importantly, Uniswap on Scroll will propel L2 DEX innovation. We are on the brink of uncovering L2 native use cases that have not been feasible on Ethereum L1. Scroll will bring new developers and ecosystem integrations to Uniswap.
## **Partner Details**
**Scroll**
This proposal and the deployment of Uniswap contracts will be performed by the Scroll
Foundation, a foundation registered in the Republic of Seychelles.
**Delegate Sponsor**
In addition, Scroll is working with the [Michigan Blockchain](https://twitter.com/UMichBlockchain), which will act as the
delegate sponsor for this proposal.
* ***Proposers:*** Scroll Foundation
* ***Proposal Sponsor:*** Michigan Blockchain
* ***Deployer:*** Scroll Foundation
* ***Bridge Provider:*** Scroll Native Bridge
**Conflict of Interest Declaration**
There are no existing financial or contractual relationships between Scroll and any of Uniswap’s legal entities, including Uniswap Labs, UNI DAO & Foundation, nor investments of Uniswap Labs Ventures.
## **Additional information for cross-chain deployments**
Our focus has always been on providing the best possible experience for developers, and we have successfully delivered on this promise on our testnet, which we will continue to do on mainnet. We are proud to say that we are bytecode-compatible, meaning that migrating dapps from any EVM chain is easy and hassle-free.
**EVM-equivalent:** Scroll uses a forked version of Geth, enabling seamless infrastructure migration. Any application can be migrated to Scroll without code changes and additional audits.
**Developer friendly:** Scroll will support all existing development tools, including debuggers. Developers can work with a familiar development environment. No bytecode re-audits will be required minimizing the risk surface tremendously.
**Security:** Scroll inherits most of EVM’s features and security, which is by far the most battle-tested smart contract infrastructure in the entire space.
**Decentralization:** Scroll is leading the way in developing a decentralized prover network and has already committed to outsourcing proving. By decentralizing proof generation to the community, Scroll can achieve efficient proof generation and establish a more robust ecosystem.
We have always been committed to building in the open, starting from our collaboration with EF’s PSE team, and we remain closely connected to the Ethereum community—in fact, our team has contributed [~50% of the upstream PSE zkEVM codebase over the past two years](https://twitter.com/pseudotheos/status/1664249089998077960). Furthermore, we have been open source from day 1, have a strong in- house security team paired with rigorous audits, and are aiming to have third-party provers upon our mainnet genesis block and a gradual decentralization of our sequencer network.
The Scroll community has been testing the Uniswap V3 deployment on [Scroll’s testnets](https://sepolia-blockscout.scroll.io/) for months, often exceeding 200,000 transactions per day - more than many other L2s. In fact, our testnet community has successfully processed over 1.8M transactions through the Uniswap V3 router on our Alpha Testnet over 450k transactions on our Sepolia Testnet already.
## Protocol Security
ZK-Rollups are currently the most secure Layer 2 scaling solution. On the premise of inheriting the security of Ethereum, it relies exclusively on cryptography rather than unreliable crypto-economics.
Scroll has a trustless Layer 1 <> Layer 2 canonical bridge, which supports arbitrary message delivery. The bridge is part of the roll-up mechanism, verified by the smart contract and the zkEVM, which is much more secure than relayer-based bridges.
Security is the first priority for us. Scroll implements the EVM, which is well-specified and battle-tested, as well as the well-established and researched Halo2 cryptographic library. [Additionally, we have zkEVM circuit audits from Trail of Bits, Zellic, and KALOS; Bridge and rollup contracts audits from OpenZeppelin and Zellic; and Node implementation audits from Trail of Bits. We also have a bug bounty on ImmuneFi with a maximum reward of $1M.](https://scroll.io/blog/scrolls-security-measures) And finally, we have an in-house security team that continuously reviews our codebase.
We are launching with a timelock delay for contract and admin upgrades, and soon plan to establish a security council to control privileged functions and contract upgrades.
Finally, in a continuous process after mainnet launch, we will be working on developing decentralized sequencers and provers in an effort to secure and reduce the trust assumptions of using the network.
## **Success Criteria**
Deployment of Uniswap on Scroll will:
* Increase Uniswap TVL
* Grow Uniswap order volume
* Enable listing of new assets on Uniswap that are unique to Scroll
* Allow Uniswap to benefit from exposure to cutting-edge ZK technology and applications on Scroll (e.g., potential new functionality, projects to provide grants to, etc.)
The best way to measure success for Uniswap on Scroll is to focus on TVL and transaction volumes; however, there are a variety of other benefits Scroll will bring, such as onboarding its dedicated and expanding developer community to Uniswap, thereby boosting the growth of Uniswap’s developer community—this is also a critical success criteria.
## Deployment Details
The approval of this proposal by Uniswap governance will lead the stated Uniswap v3 contracts to be deemed as the canonical deployment on Scroll. As is the case with all canonical v3 deployments, this deployment will be subject to Ethereum Layer 1 Uniswap Protocol governance and control.
**Main Contracts**
* [Core Factory 2](https://scrollscan.com/address/0x70c62c8b8e801124a4aa81ce07b637a3e83cb919): `0x70C62C8b8e801124A4Aa81ce07b637A3e83cb919`
* [NFT Position Manager](https://scrollscan.com/address/0xb39002e4033b162fac607fc3471e205fa2ae5967): `0xB39002E4033b162fAc607fc3471E205FA2aE5967`
* [Router 2](https://scrollscan.com/address/0xfc30937f5cDe93Df8d48aCAF7e6f5D8D8A31F636): `0xfc30937f5cDe93Df8d48aCAF7e6f5D8D8A31F636`
**Additional Contracts**
* [multicall2Address](https://scrollscan.com/address/0xC1D2e074C38FdD5CA965000668420C80316F0915): `0xC1D2e074C38FdD5CA965000668420C80316F0915`
* [proxyAdminAddress](https://scrollscan.com/address/0x1E6dcAb806A42055098f23E2B3ac72D6E195F967): `0x1E6dcAb806A42055098f23E2B3ac72D6E195F967`
* [tickLensAddress](https://scrollscan.com/address/0x85780e12e90D2a684eB8E7404c985b5B5c8ce7E9): `0x85780e12e90D2a684eB8E7404c985b5B5c8ce7E9`
* [nftDescriptorLibraryAddressV1\_3\_0](https://scrollscan.com/address/0xAeE9c206ba89F3DA25EEe4636208519e0B86965B): `0xAeE9c206ba89F3DA25EEe4636208519e0B86965B`
* [nonfungibleTokenPositionDescriptorAddressV1\_3\_0 1](https://scrollscan.com/address/0xaccf12204b7591b2eccefe737440b0f53748b191): `0xACcf12204b7591B2ECCEFe737440B0f53748B191`
* [descriptorProxyAddress 1](https://scrollscan.com/address/0x675DD953225D296A44790dC1390a1E7eF378f464): `0x675DD953225D296A44790dC1390a1E7eF378f464`
* [v3MigratorAddress](https://scrollscan.com/address/0xF00577B5Dd0DA227298E954Ed11356F264Cf93d4): `0xF00577B5Dd0DA227298E954Ed11356F264Cf93d4`
* [v3StakerAddress 1](https://scrollscan.com/address/0xfdfbe973c9ecb036ecfb7af697fcace789d3f928): `0xFdFbE973c9ecB036Ecfb7af697FcACe789D3f928`
* [quoterV2Address 1](https://scrollscan.com/address/0x2566e082Cb1656d22BCbe5644F5b997D194b5299): `0x2566e082Cb1656d22BCbe5644F5b997D194b5299`
## Timeline
The temperature check has passed, and the relevant Uniswap v3 contracts have been deployed on Scroll. If the onchain vote passes, this deployment will be officially recognized as a canonical v3 deployment through an amendment to the v3deployments.uniswap.eth subdomain.
# CGP 2.0 Updates and Renewal
### **Summary**
After [successfully running CGP 2.0](https://compound.finance/governance/proposals/136) for two quarters and taking into consideration its impact, Questbook proposes to renew [Compound Grants Program 2.0](https://compound.finance/governance/proposals/136) with a budget of $970,000 = 20,847 COMP (calculated based on the most recent COMP price at the time of proposal submission, which was $46.53), spread across three domains. Questbook has received great feedback from the community, builders and domain allocators to renew the grants Compound Grants and are grateful for their valuable inputs.
For more details, see the full forum discussion here: <https://www.comp.xyz/t/cgp-2-0-updates-and-renewal/4518/44>.
### **Background and Progress**
CGP 2.0 went live on [Jan, 2023](https://twitter.com/compoundgrants/status/1614931948354535426?s=20) with a [grants budget of $800k](https://compound.finance/governance/proposals/136#:~:text=The%20grant%20budget%20is%20%24800K) spread across four domains. Over the past two quarters, CGP 2.0 domain allocators approved proposals requesting [$670,000 in grants](https://www.questbook.app/) and disbursed a total of ~$410,000 to accepted proposals from a pool of 100+ proposals. These domain allocators [**were elected from the community and by the community.**](https://compound.finance/governance/proposals/136) The specific information regarding the accepted proposals and the funded teams can be found [here](https://www.questbook.app/). Detailed information related to CGP 2.0’s funding breakdown, relevant metrics, insights, and proposed improvements going forward can be found [here](https://www.comp.xyz/t/cgp-2-0-updates-and-renewal/4518/44?u=harsha).
### **Proposal**
Based on the impact and insights derived from CGP 2.0, we propose renewing CGP 2.0 with a budget of $970k for two quarters. The domain allocators will utilize this budget to fund proposals that align with Compound's roadmap. After researching, gathering feedback from domain allocators, active community members, and builders, we propose supporting the following domains:
**RFPs, acceptance criteria and specifications for each domain**
1. Dapps and Protocol Ideas - [Link](https://docs.google.com/document/d/1Sre0LAkHEBQ1Rzhycbk3ALM3XBHF8NlXgl8tO5aVNWg/edit?usp=sharing)
2. Multi - Chain/Cross chain Strategy, Dev Tooling - [Link](https://docs.google.com/document/d/1QjT3UDNoTq4o0-xqYJVh-WB4X1EKS5eoVgOGZnw7k60/edit?usp=sharing)
3. Security Tooling - [Link](https://docs.google.com/document/d/1uEGIIK_eu_c008sJ_GY2nr9Bnjqq4p8dxnFKzvLLeYw/edit?usp=sharing)
* Given that [Dapps and New Protocol Ideas](https://www.questbook.app/dashboard/?grantId=0xeb047900b28a9f90f3c0e65768b23e7542a65163\&chainId=10\&role=community\&proposalId=0x36a) domain received more than twice the number of proposals compared to all the other domains combined, we propose merging Multi-chain and Cross-chain Strategy domain with the Dev Tooling domain.
* Additionally, we propose increasing the allocated grants budget for Dapps and New Protocol Ideas domain to $450,000 and reducing the grants budget of the [Security Tooling domain](https://www.questbook.app/dashboard/?grantId=0x291d6eb5de3b023ce9b760ef251b303c0c0fd11a\&chainId=10\&role=community\&proposalId=0x33b) to $150,000 taking into consideration the number of proposals and allocated grant amounts for both domains during [CGP 2.0](https://www.questbook.app/).
### Specifications and Implementation
Similar to the model implemented in CGP 2.0, the renewed grants program will be run using [**Delegated Domain Capital Allocation Model**](https://blog.questbook.xyz/posts/min-grants-dao-max-community-participation/). Each *domain allocator* will run their respective domain on-chain for full transparency using Questbook. Additional details related to specifications and implementation be found [here](https://www.comp.xyz/t/cgp-2-0-updates-and-renewal/4518/44?u=harsha).
### Compensation
Sourcing, reviewing, funding, marketing, tracking and nurturing proposals requires **significant expertise and time commitment** from the grants committee members and they should be fairly and competitively compensated for their efforts. Based on the learnings from CGP 2.0 specified above, we believe that a Program Manager is expected to dedicate approximately 25 hours per week, while the domain allocator is required to allocate an estimated 15 hours per week. However, these time commitments may vary depending on the number of proposals received for a domain and the domain allocators may exceed or work for less than 15 hours per week based on the proposal volumes. We propose keeping the hourly price the same for the Domain Allocators and the Program Manager as in the case of CGP 2.0.
* Questbook will provide the grants committee its grants orchestration tool free of cost. We suggest that the grants committee continue with [Synapse](https://www.synaps.io/) for KYC services and [Docusign](https://www.docusign.com/en-in) for all contractual agreements, as we have been using these services throughout CGP 2.0.
* However, for any specific asks from the grants team in order to run the process more smoothly, Questbook will charge for any additional feature requests based on the development overhead through a retrospective grant from Compound.
**All unallocated funds from the first iteration of CGP 2.0** [**have been returned back**](https://etherscan.io/tx/0x295fcc65d4704a09ea0146e127e29c869b67198d9ff87f4fee1d9a17733a1f39) **to the Compound treasury**
The **KPIs, CGP 2.0 funding overview, expectations** of the proposed renewal program along with the **responsibilities of the Domain Allocators and the Program Manager** can be found [here](https://www.comp.xyz/t/cgp-2-0-updates-and-renewal/4518/44?u=harsha).
### **About Questbook**
* Questbook (YC-W21) is a decentralized grant orchestration tool, currently being used by Polygon, AAVE, Celo & Solana.
* Considering the achievements of CGP 2.0, as well as the time commitment and operational expertise necessary for running an effective grants program, Questbook will continue in the role of the Program Manager. [Ruchil](https://twitter.com/roohchill) from Questbook will assume the responsibilities of the Program Manager in place of Sriharsha Karamchati due to bandwidth constraints. [Ruchil](https://twitter.com/roohchill) was the program manager for Polygon facilitating the disbursal of ~ $1M in grants. He works with Solana foundation and ecosystems within Solana on a daily basis to help them design their grants program. He has received a grant of $250K from the Solana foundation for the same. He also worked closely with CGP 2.0 Program Manager and Grants team.
### **Disclaimer**
Questbook has been collaborating with Michigan Blockchain to work through the details of this grant renewal proposal and communicate the merits to the broader Compound community. Michigan Blockchain was not provided consideration as a result of this collaboration as both proposers believe the passing of this proposal is in the best interest of the Compound protocol.
# Deploy Uniswap V3 on Filecoin Virtual Machine (FVM)
## Summary
We [Michigan Blockchain](https://twitter.com/UMichBlockchain) are submitting this proposal to deploy Uniswap v3 on the Filecoin Virtual Machine (FVM), a programmable EMV-compatible environment built over the Filecoin blockchain and its robust system of decentrally stored data. The [temperature check](https://snapshot.org/#/uniswap/proposal/0x36a17f6c311f3d910bc11cb4cd55891a7e6c71facd04e7bffcfb267fdd88c45b) for this proposal passed with **28M (~99.9%) YES** votes and **4.6k (~0.01%) NO votes**–the proposal stakeholders were agreed upon via the RFC.
## Proposal Motivation
Considering Filecoin is the de facto storage provider in the blockchain space, it is valuable for Uniswap to attain market share in its data economy early on. We therefore believe that an FVM deployment is an opportune manner by which Uniswap’s multichain vision is furthered.
### Uniswap’s Ability to Enhance the Decentralized Data Economy
One of the reasons that peer to peer storage systems like IPFS are difficult to maintain is because the parties involved in the network are not incentivized to expend resources to maintain the integrity of the stored data. Decentralization is not an inherent method for providing a superior storage product. That is why Filecoin was created. The Filecoin blockchain’s economic incentive structure between storage providers (SPs) and users creates a market for SPs to store and maintain data integrity over time. However, the robustness of that data economy must also be high for sustaining data storage in the long run. If SPs, for instance, do not have access to creatively expand their service provision business or efficiently put their capital to work, then their incentive to partake in the Filecoin/IPFS system is reduced.
The FVM’s launch on March 14, 2023 effectively made Filecoin programmable through the introduction of smart contracts. Programmability allows for the creation of dapps that work in tandem with the stored data. If an ecosystem of, say, DeFi applications can be built on the FVM to supplement the efforts of SPs, then the data economy is strengthened many fold. Invariably, DEXs are a rudimentary building block of a crypto economy, and just as they enable higher degrees of liquidity for numerous L1s, they will be able to provide a similar facility for Filecoin’s data economy. Uniswap would, for instance, grant SPs the ability to swap between $FIL tokens that they earn as a reward for providing their services. More DeFi use cases are mentioned in the “How the FVM is Enabling a Data Economy” section.
## Proposal Stakeholders
The following list of stakeholders is present to transparently communicate which entities and individuals are involved in proposal creation and implementation.
**Proposer:** [Michigan Blockchain](https://twitter.com/umichblockchain?lang=en)
* This entity is responsible for authoring the proposal & managing the governance process
**Deployer:** [Axelar](https://axelar.network/)
* This entity is responsible for the technical deployment of the contracts on the target chain
**Bridge Provider:** [Axelar](https://axelar.network/)
* This is the cross-chain messaging solution selected for this deployment
**Target Chain:** [Filecoin](https://fvm.filecoin.io/) (specifically, the FVM)
* This is the chain that v3 contracts have been deployed on
**Proposal Sponsor:** Michigan Blockchain
* This entity has >2.5M UNI and is therefore eligible for administering the onchain vote
## A Primer on Filecoin
### Filecoin, IPFS, and Storage Helpers
Filecoin is the premier decentralized storage protocol built on top of the Interplanetary File System (IPFS). The two entities are distinct but often incorrectly conflated as one. Although Protocol Labs founded–and continues to aid in the development of–both Filecoin and IPFS, the two systems serve distinct purposes. IPFS is not a blockchain but a set of modular data addressing and networking protocols. Using IPFS, files are fragmented, hashed, and distributed amongst numerous nodes. Data distribution in a network of SPs around the world makes the system more secure than a centralized cloud storage system. Centralized servers reduce the control an individual has over their data and increases the surface area for information exploits. The hashed nature of the data allows for a secure manner of locating files using a technique known as content-addressing, which differs from the traditional location-addressing method (HTTP) used by most of the Internet. Even though data on IPFS are stored off-chain (i.e. on hardware devices), they are secure due to the combination of content-addressing and a verifiable zk-proof system present on Filecoin.
IPFS’ system allows for enterprise data centers to pledge their idle network resources like bandwidth and disk drive to secure others’ data. Such a storage system, however, does not function effectively without an incentive structure in place. Monetarily rewarding the entities involved in the file storage and retrieval processes enables the creation of a micro economy, where storage providers (SPs) are paid by users to store their data. Filecoin is the blockchain-based economic layer built on top of IPFS that allows for the exchange of $FIL tokens between SPs and users. Without Filecoin’s incentive structure, the storage provision capabilities of IPFS would not function or scale. Filecoin also allows for the development of a competitive data storage market, where storage prices are more attractive than those issued by incumbent centralized SPs like AWS or Microsoft Azure. By tapping the long tail of data centers, costs for storage, compute, and retrieval can be brought dramatically below the cloud incumbents
Data storage and retrieval is also simplified through the help of third-party storage helpers. These entities aid in abstracting away much of the protocol’s dealmaking complexities between SPs and users. Instead of interacting directly with Filecoin and IPFS, developers can leverage storage helpers’ API services. Dapps can therefore receive decentralized storage benefits without much hassle. This is one of the reasons why the active number of deals, including those from [Filecoin Plus](https://docs.filecoin.io/basics/how-storage-works/filecoin-plus/), rose from [~16M to ~33M](https://observablehq.com/@starboard/chart-daily-active-deal-count-statistics) in 2023 alone. A notable storage helper called NFT.storage allows anybody using NFTs to decentrally store and retrieve their NFT metadata and images on IPFS and Filecoin. Used by platforms like OpenSea and Magic Eden, the helper has experienced over [122M total uploads, accounting for 304.13 TB of data on Filecoin](https://nft.storage/stats/).
### Proof of Storage
SPs are only paid when they submit two types of cryptographic proofs to the Filecoin protocol: Proof of Replication (PoRep) & Proof of Spacetime (PoSt). Collectively, these two proofs can be thought of as a means by which storage is proved. PoRep is initially conducted upon the SP receiving the users data, and it requires the SP to generate a public proof signifying that the hashed data is securely stored and replicated on a hardware device. It is a way to make sure that SP does not lie about the fact that they are storing the given data. PoSt is a process that occurs every 24 hours–it requires SPs to prove that a designated parcel of data is still stored (space) and able to be retrieved by the user whenever they desire (time). Daily spacetime proofs allow for the protocol to ensure data continuity. Currently, the network maintains [12.11 EiBs ](https://dashboard.starboard.ventures/capacity-services) of storage space, provided by [over 4,000 SPs](https://medium.com/tldrfilecoin/state-and-direction-of-filecoin-summarized-4b90c59e3cca).
Mere storage provision, however, is not a useful metric in and of itself because there must be demand present for the supplied storage. Although Q1 saw a decline in total storage provided, there was a 105% increase in the utilization rate, which is a more significant figure for displaying network activity.
Every SP has to collateralize a bond of $FIL tokens. Malicious and reckless SP behavior is thwarted by subjecting the bond to slashing; block rewards are also slashed in similar circumstances. Inability to generate a PoSt proof therefore has monetary consequences. The current stake that Filecoin SPs have put forth as collateral amounts to ~ 144M FIL tokens.
The other side of the Filecoin data economy is the retrieval system. Users must pay retrieval providers using $FIL to retrieve their data from the storage providers. Current systems like [Filecoin Saturn](https://saturn.tech/#contact) enable a decentralized Content Delivery Network (CDN) for data retrieval. This process is continually being iterated to be made more efficient.
## The Filecoin Virtual Machine
### How the FVM is Enabling a Data Economy
Due to the V18 Hygge Filecoin network upgrade in March 2023, smart contract programmability was introduced to the Filecoin blockchain. The FVM is a WASM-based execution environment that has the potential to enable programmable markets for storage, retrieval, compute, and Filecoin subnets, each catering to a new custom service. Foreign runtimes like the EVM are able to function on top of the FVM, allowing for developers to seamlessly program applications on Filecoin. Over time, multiple runtime environments will be introduced to the FVM, but the primary runtime that is currently available is the EVM. Solidity programmers can therefore utilize familiar tools like Hardhat, Foundry, Truffle, and Metamask to create EVM-based dapps on Filecoin, with the Filecoin complexities being abstracted from the developers’ purview. And so, with the incorporation of smart contracts, Filecoin is addressing the L1 market from the vantage point of actually being able to store users’ data; most other blockchains simply do not have the simultaneous storage capabilities and programmability.
Support for numerous VMs will enable FVM to better interact with alternative L1s and increase liquidity transmission between previously siloed chains. Programs deployed on the EVM, MoveVM, JS/SES, or any other VMs will be able to fork onto the FVM. This proposal seeks to create a fork of the Uniswap v3 code and deploy it on the FEVM.
**The FVM’s goal is to harbor a robust data economy, and this can be accomplished by launching various services, enabled by smart contract development. Below are some examples:**
***Perpetual Storage:*** Applications that allow for the automatic renewal of a deal between a client and the SPs, allowing for a continuous, long-term storage agreement that requires minimal manual intervention on behalf of the client.
***Data DAOs:*** The FVM does not have direct access to the underlying data, but it does allow for that data to be governed. DAOs can be created around a dataset, accessible by a consortium of individuals as opposed to a single entity. Token-gated structures can also allow for better dataset access controls, like determining which entities can read, write, or read+write to a dataset.
***Data Monetization:*** Data can also be tokenized, where certain tokens stand for a portion of a dataset, prescribing a market-determined value to the data underlying the respective tokens. This way, data itself can be collateralized and traded. Users of certain applications can also monetize their data by selling their profile NFTs, which give access to underlying consumer data, to marketing or analytics agencies.
***DeFi:*** A crypto economy is not complete without basic financial applications like DEXs and lending protocols. The “Proposal Motivation” section underscores why DEXs like Uniswap are important. Below are more examples of DeFi initiatives in the crypto data economy. Each of these has the ability to further enhance Uniswap’s position on Filecoin by routing liquidity between these various applications.
One example of a DeFi function is staking. Just like Lido and Rocket Pool allow ETH holders to secure the Ethereum blockchain without running a validator node with high computational and economic fixed costs, a similar model can be applied to Filecoin. A liquid staking protocol on FVM can therefore establish a profit-sharing system between SPs and $FIL holders. An alternative means for SPs to gather more $FIL for collateral purposes is by borrowing the $FIL from a lending protocol–of course, such dapps can also be built on the FVM. Token-gated features on lending dapps can also be enabled to allow for cost-effective $FIL borrowing. If an SP, for instance, has built a track record of reliable data storage with no slashing history, they can be issued an NFT by the lending protocol that gives the SP access to undercollateralized $FIL loans. Since larger amounts of data and longer storage periods require more $FIL, it is important to have seamless access to the token. This example illustrates the utilization of both DeFi and identity on the FVM.
Lending platforms and staking protocols are simply incomplete without a DEX like Uniswap. So, to provide actors in the Filecoin ecosystem with a place to easily swap between assets like $FIL and $stFIL (this asset doesn’t exist yet–just an example), there must be an AMM present. Other creative applications can also be built using Uniswap in the backend for automated asset swaps; the opportunities are very expansive.
### Ecosystem Development
Since storage is a vital part of every project, Filecoin has attracted clients of all colors from both the crypto native and web2 world. [Internet Archive](https://archive.org/), a public repository of data from documents and websites to movies and songs, utilizes Filecoin to safeguard its information. The [USC Shoah Foundation](https://sfi.usc.edu/about) also leverages Filecoin to store important historical accounts about genocides like the Holocaust. As for other blockchains, Filecoin is used by various L1s and L2s for data storage, largely through storage helpers like NFT.storage.
As of Q1 2023, the Filecoin ecosystem has [484 projects](https://messari.io/report/state-of-filecoin-q1-2023), with a trend of initiatives surpassing the initial project phase and into the accelerator stage and beyond. The Filecoin Foundation recently hosted a hackathon called [Space Warp](https://spacewarp.fvm.dev/#ie) containing over $400k of prizes and accelerator grants for promising projects building on the FVM. This was one of the initiatives to bootstrap the FVM ecosystem. Nearly two months after the FEVM’s launch, there have been [808 contracts deployed](https://dashboard.starboard.ventures/fvm) with over [130k transactions](https://dashboard.starboard.ventures/fvm) on the platform. Active contract users have also increased [184.5%](https://dashboard.starboard.ventures/fvm) since April 1st. Such activity is revitalizing the condition of Filecoin from a stance of developer interest. Over the next few months smart contract deployment is projected to increase heavily, a large shift from the past two years, during which the Filecoin [active developer count fell by 11%](http://developerreport.com/).
Overall, it is evident that the Filecoin Foundation, Protocols Labs, and their partners are aggregating resources to attract more users to the FVM. The growth thus far has been strong–but it is too early to call it a success. This Uniswap deployment, however, will certainly be another method to attract both developers and users to the FVM.
## Deployment Details
The approval of this proposal by Uniswap governance will lead the stated Uniswap v3 contracts to be deemed as the canonical deployment on the FVM. As is the case with all canonical v3 deployments, this deployment will be subject to Ethereum Layer 1 Uniswap Protocol governance and control. The text record of the uniswap.eth ENS subdomain titled v3-deployments.uniswap.eth will be amended to include the reference to the stated v3 contracts on the FVM.
**Uniswal V3 contracts have been deployed on Filecoin at the following addresses:**
[UniswapV3Factory](https://filfox.info/en/address/0xB4C47eD546Fc31E26470a186eC2C5F19eF09BA41) | `0xB4C47eD546Fc31E26470a186eC2C5F19eF09BA41`
[Multicall2](https://filfox.info/en/address/0xffd927d6F17495B28635DD49d24638e97BD8c8b8) | `0xffd927d6F17495B28635DD49d24638e97BD8c8b8`
[ProxyAdmin](https://filfox.info/en/address/0xe9901ae78efB4386B1132009E310d08bCB445Bf5) | `0xe9901ae78efB4386B1132009E310d08bCB445Bf5`
[TickLens](https://filfox.info/en/address/0x76c001ad9E527FEfA8Fa822a987Ad44ce720BAeD) | `0x76c001ad9E527FEfA8Fa822a987Ad44ce720BAeD`
[NFTDescriptor ](https://filfox.info/en/address/0xe909B0cAE57EE7EFF56A5Ca7fc4b66CF4F7C2D38) | `0xe909B0cAE57EE7EFF56A5Ca7fc4b66CF4F7C2D38`
[NonfungibleTokenPositionDescriptor](https://filfox.info/en/address/0x22850a17032F40778C0C0a3fDd96905950a39f89) | `0x22850a17032F40778C0C0a3fDd96905950a39f89`
[DescriptorProxy](https://filfox.info/en/address/0xf0198aAa4a8792e2a4a6e6Fb3039e4B1C71f15bB) | `0xf0198aAa4a8792e2a4a6e6Fb3039e4B1C71f15bB`
[NonfungibleTokenPositionManager](https://filfox.info/en/address/0x4cd986dD509fbB6A695aE971d5C56c8795f640ee) | `0x4cd986dD509fbB6A695aE971d5C56c8795f640ee`
[V3Migrator](https://filfox.info/en/address/0x409af45457D4779828BFBCbe7aA653C38Edb9Ed9) | `0x409af45457D4779828BFBCbe7aA653C38Edb9Ed9`
[V3Staker](https://filfox.info/en/address/0x915362b5450acbBc9F8044191aE7E35c86F2fE51) | `0x915362b5450acbBc9F8044191aE7E35c86F2fE51`
[QuoterV2](https://filfox.info/en/address/0xE45C06922228A33fFf1ED54638A0db78f69F9780) | `0xE45C06922228A33fFf1ED54638A0db78f69F9780`
[SwapRouter02](https://filfox.info/en/address/0xcAb04058e60020d65D18D4B3DFF2cA1445D7099f) | `0xcAb04058e60020d65D18D4B3DFF2cA1445D7099f`
**Axelar Interchain Governance Executor is deployed at the following address:**
[InterchainProposalSender (Mainnet)](https://etherscan.io/address/0x1f8A4d195B647647c7dD45650CBd553FD33cCAA6) | `0x1f8A4d195B647647c7dD45650CBd553FD33cCAA6`
[InterchainProposalExecutor (Filecoin)](https://filfox.info/en/address/0xFf3b2DA1379cc67cc2755194604713f10b820b0E) | `0xFf3b2DA1379cc67cc2755194604713f10b820b0E`
## Timeline
This proposal has passed the RFC and temperature check phases. The relevant Uniswap v3 contracts have also been deployed on the FVM. If this onchain vote passes, this deployment will be officially recognized as a canonical v3 deployment through an amendment to the v3deployments.uniswap.eth subdomain. The front-end integration for this deployment will most likely be handled by a third-party Uniswap interface like [Oku Trade](https://oku.trade/)--not by Uniswap Labs.
# Create a UNI-ARB Grant Program (UAGP) and Protocol Delegate Program
Thanks to everyone who has taken the time to read and help iterate our proposal for the UNI-ARB Grant Program (UAGP) and Protocol Delegate Program! Talking with you all has made us even more excited about how the Uniswap DAO can strengthen both the Uniswap / Arbitrum ecosystems.
As outlined in the[ temperature check](https://gov.uniswap.org/t/temp-check-create-a-uni-arb-working-group/21583/1), the proposal suggests the creation of the UAGP and Protocol Delegate Program, utilizing a significant allocation of 2.2m $ARB tokens to enhance the Uniswap ecosystem on the Arbitrum Protocol.
After an 8-week research sprint and iterations with delegates in our capacity as Working Group Zero (WG0), we've fine-tuned the structure for both the UAGP and Protocol Delegate Program.
Now it is time to vote on the funding of both of these programs with parts of the received $ARB airdrop. Following a successful onchain proposal, WG0 will lead a nomination and election process to fill the UAGP and Protocol Delegate Program with more members. As initiators of the programs, we have an ambition to be part of the mentioned programs and would feel privileged to help drive these forward.
**Working Group Zero (WG0) members:**
- web3 Studios (Crypto-native advisory) [@bernard](https://gov.uniswap.org/u/bernard)
- Alastor (Crypto-native advisory) [@Stastny](https://gov.uniswap.org/u/stastny)
- Doo Wan Nam (StableLab, Uniswap Deployment Accountability Committee) [@Doo\_Stablelab](https://gov.uniswap.org/u/doo_stablelab)
- Jun Sun (Uniswap Deployment Accountability Committee, Delegate) [@Juanbug](https://gov.uniswap.org/u/juanbug)
Helpful links for context: [Temp Check](https://gov.uniswap.org/t/temp-check-create-a-uni-arb-working-group/21583/1), [Snapshot vote](https://snapshot.org/#/uniswap/proposal/0x86ded24b11c4714e0f4f2b6e4ca489f60dc33e6f2f4ababa5575bf5ab973a005), [RFC](https://gov.uniswap.org/t/rfc-alastor-w3s-create-a-uni-arb-working-group/21376), [UAGP Research](https://drive.google.com/file/d/1nIi5ujPa_-7PtDFtR3QBqxL7nl861Ry1/view?usp=sharing), [Delegate Program Research](https://drive.google.com/file/d/1Idp35yZmHIPMDVg9OGpbWyTDtf7-ko1l/view?usp=sharing)
## Background
The ARB airdrop provides the Uniswap community with an opportunity to enhance its presence within the Arbitrum ecosystem, thus nurturing growth.
**The UNI-ARB Working Group Zero aims to unify various governance initiatives into a single, coherent system. This helps us align with Uniswap's vision and positions us to take advantage of future allocation opportunities.**
Therefore, we proposed the establishment of a Working Group 0 that had the task to structure the UNI-ARB Grant Program and Protocol Delegate Program and get to an on-chain vote:
1. **Grant Program: 1.1 million (25% of the total airdrop) ARB tokens for UNI-ARB Grants -** Supporting growth and development of projects exclusively within the Uniswap-Arbitrum ecosystem, with a focus on long-term benefits.
2. **Protocol Delegate Program: 1.1 million (25% of the total airdrop) ARB tokens for Governance -** Empowering the committee to actively participate in Arbitrum governance and influence strategic decisions.
# 1. UNI/ARB Grant Program (UAGP)
After an extensive 8-week research phase with the WG0–researching leading Grant Programs, expert interviews, and iterations with Uni delegates–we're excited to introduce a best-in-class Grant Program designed to become a pacesetter for future Uniswap grant initiatives.
## Summary
- This proposal outlines a **framework for funding Uniswap and Arbitrum ecosystem development with grants** from the Arbitrum Airdrop.
- Concentrating on **fewer but more impactful initiatives, the committee will focus on grants from 50 - 250k $ ARB** (vs. a large number of grants to smaller projects) and administer a budget capped at $1 million ARB for the initial 6 months.
- To manage the manual nature of grants administration, we propose a *committee of 5 members — one operating lead and five reviewers (incl. operating lead) — to efficiently allocate funds without necessitating community votes on each application.
- **Monthly reports will update the community** on decisions taken and each funded project's status.
## Mission
The UNI/ARB Grant Program (UAGP) aims to:
- **Fund High-Impact Projects:** The program allocates grants specifically to projects that demonstrate the potential for substantial positive impact on the Uniswap and Arbitrum ecosystems.
- **Strengthen the Uniswap and Arbitrum Ecosystems:** The UNI/ARB Grant Program (UAGP) aims to strengthen the ties and facilitate exchange between the Uniswap and Arbitrum ecosystems.
- **Ensure Transparency and Community Input:** The program mandates regular progress reports and seeks community feedback to influence the direction of funded projects.
## Grant Program Design & Approach
Setting up a best-in-class Grant Program is a multifaceted task. We broke it down into its key components, aligned with a grantee's journey, to effectively solve the typical challenges of grant programs.
With our WG0, we took 8 weeks to do research on the leading Grant programs from other protocols (UGP, Aave, Metamask, Synthetix), conduct expert interviews with Grant Program leads from multiple ecosystems, and iteration sessions with 8 larger Uni delegates (voting power of ≥2.5M UNI).
Find detailed research here: [UAGP Research](https://drive.google.com/file/d/1nIi5ujPa_-7PtDFtR3QBqxL7nl861Ry1/view?usp=sharing)
## Exec view
- **$1 million ARB allocated across impactful grants**, with allocation sizes between **$50-250k per project**.
- **5-member committee** responsible for selection and oversight, led by an operating lead.
- A **transparent nomination and election process for additional committee members**, emphasizing a blend of technical and investment expertise.
- Our objective is to **distribute the grant funds within the initial 6-month period**.
- We aim for **close alignment with Uniswap Foundation** to receive continuous feedback on priorities while generally operating independently to avoid overlaps..
## Key Pillars
### (A) **Grant Program Objectives and Criteria**
**Objectives**
For an extensive description of our objectives, please refer to the mission statement above. The program focuses on three key areas:
- **Fund High-Impact Projects**
- **Strengthen the Uniswap and Arbitrum Ecosystems**
- **Ensure Transparency and Community Input**
**RFP-based Program vs. Open**
Rather than solely relying on inbound applications for grant distribution, we decided for an RFP-based approach to align with high-impact themes that we defined and got feedback on by a range of delegates, the Uniswap Foundation, and active community members.
To gather these ideas, we carefully selected an initial list of RFPs for funding, with a priority on projects offering the highest potential value for Uniswap. These initial themes are designed to remain adaptable, allowing for continuous adjustments to meet the evolving needs of the ecosystem. This process merged what we identified as valuable contributions within Working Group 0 with valuable guidance and feedback from both delegates and UF.
1. **Liquidity Management and Derivative Protocols**:\
_The development of derivative and liquidity management protocols interacting with Uniswap can pave the way for more sophisticated instruments and strategies on Arbitrum, seeing new increases in transaction volumes and TVL._
2. **Arbitrum testnet with EIP-1153 enabled**:\
_Currently, developers aiming to test Uniswap v4 face a cumbersome and convoluted procedure. This process, which needs to be executed locally, is far from straightforward. The lack of a streamlined approach poses challenges and inefficiencies for these developers. There's a pressing need for a more intuitive and efficient testing environment or system to simplify this procedure for Uniswap v4._
3. **Uniswap v4 Infrastructure Dev Tools**:\
_The intricacies of Uniswap v4 are difficult for present-day development tools to manage, often resulting in less-than-smooth implementations. From this perspective, it underscores the necessity for a new or improved toolset that specifically adds value to the Uniswap-Arbitrum ecosystem. To prevent overlap with UF in the context of this particular RFC, which focuses on general Uniswap v4 development, we will closely coordinate our inbound with UF._
4. **Uniswap on Arbitrum Ecosystem tools or products**:\
_Tools or products for the ecosystem that aim to strengthen the protocol, elevate user engagement, and capture attention from new users and outside parties. This category is kept broad intentionally to allow for a broad range of contributions and targeting and tech tool or product fulfilling the aforementioned target._
5. **Open Contribution**:
_A variety of initiatives and applications, not necessarily aligning with the previous four categories, are welcomed by the Grant Program. This flexibility allows for the embrace of a wide range of contributions from our community, promoting growth and innovation within the Uniswap-Arbitrum ecosystem._
### (B) Application Process
To efficiently handle the anticipated surge in applications, we've implemented a streamlined process that initially screens applications using RFPs and team requirements. These applications will be submitted through Airtable and published in Notion. Following this, we will manually review all projects to identify those warranting further due diligence in a structured process:
- **Initial Screening & RFP/Open Submission:** Applicants complete an online form, choosing to either address a specific Request for Proposals (RFP) or opt for an open submission. This step serves as our first layer of manual screening.
- **In-Depth Review & Feedback:** Projects that pass the initial screening will undergo a review DD by our committee, including interviews and constructive feedback. This process is conducted on a rolling basis, ensuring ongoing evaluation and an even distribution of workload throughout the entire term.
- **Award & Monitoring:** Once approved, projects receive funding and kick off their work, with periodic check-ins and a concluding evaluation to measure impact and success.
### ( C) Due Diligence
Our due diligence process aims to be a robust evaluation system that combines the rigor of early-stage investing with strategic alignment to Uniswap's goals. After the initial screening, we will focus on the following elements:
- **Team Assessment:** We evaluate the project's team, considering qualifications, experience, and track record to gauge their ability to execute their vision effectively.
- **Impact Assessment:** We evaluate the potential impact of the project on the Uniswap and Arbitrum ecosystems, ensuring alignment with our grant program's values. Here we consider the technological potential of the project, as well as its potential application areas.
- **Risk Assessment:** We identify and assess various risks, including market, technology, and execution risks, to gauge the project's risk mitigation strategies effectively.
Following the evaluation using the aforementioned dimensions, projects proceed through the subsequent internal governance procedure:
- **Final Approval by Reviewer Committee:** The committee uses a form to give a 'yes' or 'no' to each grant application, requesting references as part of the assessment.
- **Strategic Funding Focus:** Our grants are aimed at projects that have a substantive impact on the protocol's growth and effectiveness (vs. wide range of small grants).
- **Ask for continuous feedback from UF:** To prevent breaking points in communication and objectives, we aim to get continuous feedback on our funding decisions from the Uniswap Foundation.
### (D) Selection Process & Reporting
Transparency and continuous dialogue form the backbone of our selection and reporting process, ensuring that each grantee remains aligned with program expectations.
- **Monthly Reports**: We will provide monthly updates on our selections and updates on funded projects. These updates will include general project trajectory and progress toward milestones. To create the reports we will set regular monthly check-in dates where grantees fill a template/slide in order to give the key info about the project’s status, such as:
- Summary of Achievements for the Month
- Funds Utilized
- Milestones Reached
- Challenges Faced
- Upcoming Goals
- **Output Metrics:** With the initial priorities in mind, some effective measures for meaningful output will look as follows:
- **Number of Grants Distributed:** Number of grants that were awarded during a defined time period (3m, 6m).
- **Total Funds Allocated:** Cumulative sum of funds distributed over a particular time frame, showcasing the program's financial impact.
- **Milestone Completion Rate:** Calculated as the number of successfully achieved project milestones divided by the total number of milestones, multiplied by 100, to evaluate the effectiveness of grant-supported initiatives.
- **Outcome Metrics:** Depending on the final portfolio of funded projects, we will gauge the success rate of grantees through specific outcome metrics. While these metrics can be influenced by a wide range of external factors, such as market conditions and individual decisions on project level, we are committed to supporting and funding the most promising projects to the best of our ability. Metrics include:
- **Community Satisfaction Score:** An average score ranging from 1 to 10, gathered from community feedback surveys.
- **Protocol Integrations:** The number of blockchain protocols or projects that successfully integrate with Uniswap on Arbitrum as a result of the grants program.
- **Usage of Tools funded:** Measuring the adoption and usage of tools and infrastructure funded by the grants program. This could include metrics such as the number of developers using these tools or the volume of transactions processed through them.
- **Net New Liquidity Providers (LPs):** Tracking the increase in the number of liquidity providers within the Uniswap on Arbitrum ecosystem. This metric reflects the program's impact on attracting new participants to contribute liquidity.
### (E) Project Allocation & Support
Our approach to grant allocation focuses on achieving high impact, which we believe comes from bigger, more substantial projects:
- **Focus on $50-250k High-Impact Projects:** Our grant allocation strategy prioritizes projects with the potential for significant impact. We concentrate our financial support in the $50,000 to $250,000 ARB range.
- **Providing Non-financial Support:** Offer more than just funding by assisting selected projects with selective strategic guidance, and other key areas that contribute to long-term success.
- **Discord Support Channel:** We aim to establish a dedicated Discord channel for project to project exchange and bi-monthly office hours for direct support interactions.
### (F) Team Set-up
Our committee aims to create an efficient and predictable grant application and decision process.
- **5 committee members:** 1 operational lead and 5 reviewers (incl. ops lead)
- **Terms and Renewal:** Committee members serve for 6-month terms, requiring a renewal process overseen by UNI governance.
- **Nomination and Election Process:** When this proposal has passed, the 2 week nomination and election process for the remaining members will be kicked off.
The **Grant Program’s initial team** will be made up of the following individuals:
- **Operational Lead -** [**@bernard**](https://gov.uniswap.org/u/bernard) **(web3 Studios - Crypto-native advisory)** \
Experience: Ex-McKinsey Consultant and Founder of w3s. Leading Strategy Work and Supporting Governance for [Gro DAO](https://community.gro.xyz/t/strategy-finance-and-risk-pod-pod-creation-proposal/441), Strategy Support for [Zerion](https://www.prnewswire.com/news-releases/zerion-closes-12m-series-b-fundraise-led-by-wintermute-ventures-301646731.html), conducted analytical and [research work](https://www.web3-studios.com/research) together with leading web3 firms such as Polygon, The Sandbox, and DappRadar.
- **Grant Reviewer -** [**@Doo\_Stablelab**](https://gov.uniswap.org/u/doo_stablelab) **- Doo Wan Nam (COO at StableLab, Uniswap Deployment Accountability Committee)**Experience: Professional delegate at StableLab across major DeFi protocols, including MakerDAO, Optimism, Aave, 1inch, Balancer, Element, InstaDapp, Hop. Previously spent 3.5 years at the Maker Foundation. Participation in an Accountability Working Group that shipped [Proposal Template 2.0 - Upgrade for Deployments & Agreements](https://gov.uniswap.org/t/proposal-template-2-0-upgrade-for-deployments-agreements/19936)
Once this proposal is approved, the 2-week voting period will be initiated to fill the remaining 3 spots, where individuals interested in becoming reviewers can nominate themselves by responding to the Election Forum post (will be created separately).
### (G) Governance
The UAGP governance aims for transparency, efficiency, and broad community involvement. It outlines mechanisms to ensure fair and balanced decision-making for all stakeholders.
- **Multi-sig:** Committee functions as a 4 of 5 multi-sig
- **Term Limits and Renewals:** Each committee member serves a term of two quarters (6 months). At the end of each term, the effectiveness and impact of the UAGP will be reviewed by UNI governance.
- **Grant Allocation:** Proposals to allocate Grants can be initiated by any committee member and will be shared internally to vote on.
## Budget and Compensation
**1.1 million (25% of the total airdrop) $ARB tokens are requested for UNI-ARB Grants.** While the vast majority of the funds will be allocated to grants, some operations costs need to be addressed.
After reviewing other best-known Grant Programs like [Aave](https://governance.aave.com/t/updated-proposal-aave-grants-dao-renewal/11289) and the [UGP](https://gov.uniswap.org/t/temperature-check-create-the-uniswap-foundation/17358), we decided to propose the following compensation package for core members:
- Operational Lead: 100 $ARB/hr, capped at 25 hrs/week
- Review committee: 100 $ARB/hr, capped at 10 hrs/week
Below, we put down a budget estimation for the next 6 months, considering 3 budget categories: grants itself, compensation and maintenance costs.
**Budget (6 months)**
| | |
| ------------------------------------------------------- | ---------------- |
| **Category** | **Amount (ARB)** |
| Expected Grants to Award | 924,000 |
| **Grants Total Budgeted Cost** | **924,000** |
| Max Compensation | 156,000 |
| Budget for tooling, subscriptions, and misc | 20,000 |
| **Operations Max Budgeted Cost** | **176,000** |
| **Total UAGP Budget** | **1,100,000** |
We recognize that workload varies across different phases of the cycle. For instance, the selection phase may require peak capacity, while other stages could be less demanding. As a result, we've estimated an average commitment of 25 hours per week for the operational lead and 10 hours per week for the review committee
## Case studies:
To better articulate the scope and focus of the UAGP, we've incorporated case studies in response to feedback received from Uni delegates during our iterative process. These case studies aim to make our target projects more tangible and offer insights into what we mean by projects that strengthen the Uniswap-Arbitrum ecosystem.
1. ### Li.Fi (Uni RFC [link](https://gov.uniswap.org/t/rfc-li-fi-mma-infrastructure-development-for-uniswap/21444))
1. <ins>Project description</ins>
1. Advancement of MMA. The Multi-Messaging Aggregation is a bridge-agnostic solution designed for Uniswap to securely relay governance messages from Ethereum to other chains.\
Instead of relying on a single bridge, MMA combines multiple selected bridges into a unified cross-chain framework. A governance message is sent from Ethereum to the destination chain via all these bridges and is deemed valid only if a quorum of these bridges relayed the same message;
2. [Three audits](https://docs.li.fi/smart-contracts/audits) and a Code4arena audit contest done so far.
2. <ins>Benefits for Uniswap</ins>
1. **Increased Safety**: By having a spectrum of bridges verifying governance messages, MMA offers improved security guarantees for Uniswa's cross-chain governance use case;
2. **Liveness and Censorship Resistance**: Redundancy through multiple bridges ensures the system remains live even if one bridge fails, thus improving liveness and censorship resistance;
3. **Flexibility and Extensibility:** MMA facilitates the integration of new bridges and allows for the phasing out of outdated ones without causing disruptions. This ensures Uniswap can access the best bridges available and avoid vendor lock-in;
4. **Immutability and Trustlessness**: MMA is designed to be fully immutable and operates completely on-chain, which means that once Uniswap's configuration is set, it cannot be altered.
3. <ins>Scope</ins>
Planned timeline for use of funds is 12 months (including 6 months for a v2 release of this project).
2. ### Flashstake (Uni RFC [Iink](https://gov.uniswap.org/t/rfc-flashstake-enabling-upfront-yield-for-uniswap-liquidity-v2-v3))
1. <ins>Project description</ins>
1. Flashstake offers a unique mechanism where users receive immediate upfront returns on their investments. Leveraging a blend of interest rate swaps and a market dedicated to the time value of money, Flashstake ensures a consistent yield rate, disbursing the returns to the investor right at the outset;
2. This protocol is currently live on Ethereum Mainnet, Arbitrum and Optimism;
3. Flashtake received a grant from [AAVE Grants DAO](https://aavegrants.mirror.xyz/gon0JE4BxQqzuKJ72jIcwcQQyq41sF9jNP_CkEJ-vq0);
4. [Two audits](https://docs.flashstake.io/security-and-risks/audits) and team’s commitment to release a bug bounty program soon.
2. <ins>Benefits for Uniswap</ins>
1. **New functionality for LPs:** current Uni V2-V3 LPs will be able to Flashstake to earn instant upfront yield;
2. **More TVL streamed:** upon yield LPs incentives, there could be larger amounts of liquidity locked for extended periods of time;
3. **Migration from V2 to V3**: Uniswap V2 tokens are supported, helping to migrate to Uniswap V3.
3. <ins>Scope</ins>
Planned timeline for use of funds is 1 to 3 months.
3. ### **Hal.xyz** (funded by AAVE Grant, successfully completed and acquired by Infura, [**link**](https://dev.hal.xyz/use-cases/uniswap))
*This is an example of a project that was beneficial to the Uniswap community as a tool, completing a building phase, accomplishing milestones, and delivering a product that is adopted by the industry.*
1. <ins>Project description</ins>
A platform that combs through blockchain entries, allowing users to craft alerts for activities such as trading, governance decisions, and tax compliance, all at an undefined cost. This tool can greatly refine user interactions and demystify the intricacies of working with blockchain.
2. <ins>Benefits for Uniswap ([link](https://dev.hal.xyz/use-cases/uniswap))</ins>
1. **Boost community engagement**
Notify helps DAO, DeFi, and NFT projects build community engagement by delivering important updates to Uni users;
2. **Price, liquidity, or gas alerts**
Configure alerts based on any blockchain activity that matters to your project and to your user's wallet. No code required;
3. **Get notified on any channel**
Major channels supported including email, Telegram, Discord, Slack, Twitter, and customizable Webhooks
# 2. Protocol Delegate Program
In our effort to create a well-defined delegate program, we at took a systematic approach. Our initial step involved breaking down the Delegate Program into basic components to better understand its core ideas. Subsequently, we closely examined other successful Delegate Programs like Arbitrum, Optimism, Synthetix Ambassador Council, Rari, and Stader to identify effective strategies.
To gain deeper insights, we engaged with 6 experts in delegate programs. This allowed us to learn more and incorporate the best industry practices. This collaborative and iterative research led us to develop a robust UNI-ARB Delegate Program.
## Summary
- **Remaining ~1.1 million (25% of the total airdrop) ARB tokens is requested for Governance -** Empowering the committee to actively participate in Arbitrum governance and influence strategic decisions.
- To ensure effective representation, a **committee of 2 members** will serve as dedicated representatives of the Uniswap community’s interests
- The **success of the program will be evaluated based on how satisfied the community is, how much the delegates participate in decision-making, and if their choices match Uniswap's values**.
## Program Format
To secure adequate representation, a committee comprising 2 members is instituted to act as committed proponents of the Uniswap community's interests. This committee's sole responsibility is to advocate for Uniswap, guaranteeing unbiased decision-making. The primary aim is to actively participate in Arbitrum governance, enabling the Uniswap community to play a pivotal role in shaping the future of the ecosystem.
## Delegate Program Design & Approach
As previously highlighted, a parallel methodology was employed to ascertain the optimal Program structure. Comprising five fundamental pillars, the primary framework encompasses the entirety of the core process. Find detailed research here [Delegate Program Research](https://drive.google.com/file/d/1Idp35yZmHIPMDVg9OGpbWyTDtf7-ko1l/view?usp=sharing)
These pillars are represented on the following image:
### (A) Objectives and Criteria
The Uni-Arb Delegate Working Group will transparently and accountability represent the Uniswap community’s interests in the Arbitrum DAO. Potential responsibilities will include:
- Participation in voting discussions
- Voting participation through multi-sig
- Attendance at bi-weekly community calls
### (B) Delegates Application Process
The program holds elections on a semiannual basis. During this time, the community members who participate in Uniswap governance vote to select the delegates who will represent them for the next 6 months.
One of the WG0 members has been selected based on the criteria listed below, but we invite community members to nominate themselves below to fill the rest of the total multi-sig spots. Self-nomination will happen on this forum post, and the UF will host a Snapshot vote to determine these 2 members.
Prospective delegates submit various information about themselves based on the following criteria:
- Strong familiarity and prior experience with DAO governance structures and processes.
- A demonstrated understanding of both the Uniswap protocol and the Arbitrum protocol, showcasing a comprehensive grasp of the technical aspects.
- A commitment to being an engaged and participatory delegate, aligned with the declared availability and bandwidth to fulfil the responsibilities effectively.
- Eligibility requires not currently having any existing delegations within the Arbitrum ecosystem. This ensures a diverse range of perspectives and prevents the concentration of influence.
Once the proposal is approved and a specific nomination process post is created, members will be asked to make use of the[ official Delegate Statement Template](https://forum.arbitrum.foundation/t/delegate-statement-template/31) to fill out the application and post their response on the forum.
**Current committee (part of WG0)**
- **Jun Sun (Uniswap Deployment Accountability Committee, Delegate)** [**@Juanbug**](https://gov.uniswap.org/u/juanbug) Experience: On current Uniswap Deployment Accountability Committee, Led Penn Blockchain governance for 2 years, Delegate at Uniswap, Compound, Optimism, etc; Helped draft, steward, and submit various cross-chain deployment proposals, Co-authored a research paper Deep Diving into Uniswap’s Governance with recommendations on reinvigorating governance activity.
### ( C) Election/Voting Process
Once this proposal is approved, the 2-week voting period will be initiated, where individuals interested in becoming delegates can nominate themselves by following the application process outlined above.
1. Community members then have the opportunity to select their preferred delegate through the Uniswap Governance platform.
2. Upon successful selection, candidates are obligated to fulfil KYC requirements to proceed with their delegate responsibilities.
### (D) Governance
- The commitment to Arbitrum governance spans six months.
- Full participation in voting discussions is a mandatory expectation for each participant.
- Maintaining 100% voting participation via multi-signature is a core requirement.
- The rationale behind the committee's voting decisions will be openly shared through communication threads for both Arbitrum and Uniswap delegates.
- Active engagement involves attendance at bi-weekly community calls, jointly organised by fellow Arbitrum delegates.
- Specific details outlining expectations will be communicated directly with committee members subsequent to the conclusion of the voting phase.
The UADP governance likewise aims for transparency, efficiency, and broad community involvement. It outlines mechanisms to ensure fair and balanced decision-making for all stakeholders.
- **Multi-sig:** Delegate Program functions as a 2 of 3 multi-sig. 2 of the signers will be the 2 delegates and the other will be the grants program operational lead. The operational lead will be there for operational and transition support, and the 2 delegates will be tasked with consistently submitting the votes.
- **Term Limits and Renewals:** Each committee member serves a term of two quarters (6 months) before being put up for reconsideration.
### (E) Voting Record Reflection
When it comes to tracking how delegates vote, the current approach, used by different DAOs, involves looking at their voting history during specific times linked to their election cycle. This helps the community decide if they should be re-elected based on how they've voted. However, it can be tough to figure out if their voting really matches the program's main goals, especially when things aren't clear-cut.
To address this, the UNI-ARB Delegate Program will hold elections twice a year to check if delegates are doing what's expected of them regularly. This way, we can prevent problems and give the community chances to set new expectations over time. The evaluation will be based on how satisfied the community is, how much the delegates participate in making decisions, and if their choices match Uniswap's values.
## Budget and Compensation
Like the UNI-ARB grants program, ~1.1 million (25% of the total airdrop) $ARB tokens are requested for the UNI-ARB Delegate program. Due to the nature of delegation technically, the remaining funds in the Arbitrum community wallet will be delegated in an all or nothing transaction. These funds will be delegated to the Delegate Program wallet and will stay in the community wallet; some operational costs will be addressed. Similar to the grant program, we have capped each delegate to a maximum of 10 hrs/week for a 6 month maximum total of $48k, which translates to just under ~50k $ARB. In reality, the final amount should be less. A small portion will also be earmarked as a reserve fund in case legal and similar expenses arise. Please note that until ARB is used as an expense, our goal is to have all of the ARB be self-delegated.
**Budget (6 months)**
Below, we put down a similar “budget” estimation for the next 6 months.
| | |
| --------------------------------------------------------------------------------------------------------------------------------------- | ---------------- |
| **Category** | **Amount (ARB)** |
| ARB left in community wallet for self-delegation (~1 million) | 0 |
| Max Compensation (Will be self-delegated whilst sitting idle) | 50,000 |
| Reserve: Legal expenses if applicable, gas reimbursements, delegation smart contract, etc. (Will be self-delegated whilst sitting idle) | 50,000 |
| **Total UADP Budget** | **100,000** |
## End of WG0 Phase 1 and compensation
As previously agreed upon in the Snapshot vote, our Working Group Zero (WG0) will receive a compensation of $20,000 ARB for their efforts over the last 8-week sprint that will be split equally by its 4 members. This amount will be subtracted from the program's overall budget and will serve as the compensation for the four WG0 members.
## Conclusion
Thanks to invaluable delegate feedback, our program is aligned to fund projects that strengthen the Uniswap-Arbitrum ecosystem.
Upon successful approval of this proposal, UAGP and the Protocol Delegate Program will initiate a 2-week nomination and election process.
We're excited to kick this off and sincerely believe that, with the involvement of our delegates, we can set a precedent for streamlined, effective grant programs that make a significant difference.
## Next Steps
- Upon approval of the on-chain vote, funds will be transferred to a multi-sig wallet, co-managed by the named parties and Erin from the UF, to cover contributor compensation.
- The fund allocation is 2.2 million $ARB, equally divided between Protocol Delegates and the Grants Program Sub-Working Groups.
- A sum of 20,000 ARB will be reserved for compensating the 8-week time commitment of the WG0 members.
- Two separate elections will launch after the vote to populate contributor roles in both the Protocol Delegates and Grants Program.
- The terms for each subgroup will kick off upon election conclusion.
# CGP 2.0 Updates and Renewal
### **Summary**
After [successfully running CGP 2.0](https://compound.finance/governance/proposals/136) for two quarters and taking into consideration its impact, Questbook proposes to renew [Compound Grants Program 2.0](https://compound.finance/governance/proposals/136) with a budget of $970,000 = 17,436.7 COMP (calculated as per the most recent COMP price at the time of proposal submission: $55.6) spread across 3 domains. Questbook has received great feedback from the community, builders and domain allocators to renew [CGP 2.0](https://www.comp.xyz/t/cgp-2-0-delegated-domain-allocation-by-questbook/3352) and are grateful for their valuable inputs.
For more details, see the full forum discussion here: https://www.comp.xyz/t/cgp-2-0-updates-and-renewal/4518
### **Background and Progress of CGP 2.0**
CGP 2.0 went live in [Jan, 2023](https://twitter.com/compoundgrants/status/1614931948354535426?s=20) with a [grants budget of $800k](https://compound.finance/governance/proposals/136) spread across four domains. Over the past two quarters, CGP 2.0 domain allocators approved proposals requesting ~ [$670,000 in grants](https://www.questbook.app/) and disbursed a total of ~$326,000 to accepted proposals from a pool of 100+ proposals. These domain allocators [were elected from the community and by the community.](https://compound.finance/governance/proposals/136) The specific information regarding the accepted and funded proposals can be found [here](https://www.questbook.app/) . Detailed information related to CGP 2.0’s funding breakdown, relevant metrics, insights, and proposed improvements going forward can be found [here](https://www.comp.xyz/t/cgp-2-0-updates-and-renewal/4518)
### Renewal **Proposal**
Based on the impact and insights derived from CGP 2.0, we propose renewing CGP 2.0 with a budget of $970k for two quarters. The domain allocators will utilize this budget to fund proposals that align with Compound’s roadmap. After researching, gathering feedback from domain allocators, active community members, and builders, we propose supporting the following domains:
- Given that [Dapps and New Protocol Ideas](https://www.questbook.app/dashboard/?grantId=0xeb047900b28a9f90f3c0e65768b23e7542a65163&chainId=10&role=community&proposalId=0x36a) domain received more than twice the number of proposals compared to all the other domains combined, we propose merging Multi-chain and Cross-chain Strategy domain with the Dev Tooling domain.
- Additionally, we propose increasing the allocated grants budget for Dapps and New Protocol Ideas domain to $450,000 and reducing the grants budget of the [Security Tooling domain](https://www.questbook.app/dashboard/?grantId=0x291d6eb5de3b023ce9b760ef251b303c0c0fd11a&chainId=10&role=community&proposalId=0x33b) to $150,000 taking into consideration the number of proposals and allocated grant amounts for both domains during [CGP 2.0](https://www.questbook.app/) .
### Specifications and Implementation
Similar to the model implemented in [CGP 2.0](https://www.comp.xyz/t/cgp-2-0-delegated-domain-allocation-by-questbook/3352/82), the renewed grants program will be run using **[Delegated Domain Capital Allocation Model](https://blog.questbook.xyz/posts/min-grants-dao-max-community-participation/)**. Each *domain allocator* will run their respective domain on-chain for full transparency using Questbook. The data and performance across key metrics will be visible to the community. Additional details related to specifications and implementation be found [here](https://www.comp.xyz/t/cgp-2-0-updates-and-renewal/4518).
### Compensation
Sourcing, reviewing, funding, marketing, tracking and nurturing proposals requires **significant expertise and time commitment** from the grants committee members and they should be fairly and competitively compensated for their efforts. Based on the learnings from CGP 2.0 specified above, we believe that a Program Manager is expected to dedicate approximately 25 hours per week, while the domain allocator is required to allocate an estimated 15 hours per week. However, these time commitments may vary depending on the number of proposals received for a domain and the domain allocators may exceed or work for less than 15 hours per week based on the proposal volumes. We propose keeping the hourly price the same for the Domain Allocators and the Program Manager as in the case of CGP 2.0
- Questbook will provide the grants committee its grants orchestration tool free of cost. We suggest that the grants committee continue with [Synapse](https://www.synaps.io/) for KYC services, [Docusign](https://www.docusign.com/en-in) for all contractual agreements, and [BLG](https://twitter.com/BlockchainLG) - Blockchain Lawyers Group for all contractual agreements as we have been using these services throughout CGP 2.0.
- However, for any specific asks from the grants team in order to run the process more smoothly, Questbook will charge for any additional feature requests based on the development overhead through a retrospective grant proposal from Compound at the end of two quarters.
[CGP 2.0 Funding Overview](https://www.notion.so/CGP-2-0-Funding-Overview-1455f8dfb7bc43e585161b7b06481284?pvs=21)
- Considering the funding breakdown and COMP’s price on August 10th, 2023, **~$400,000 will be reserved** from the CGP 2.0 budget’s available funds. This allocation will be utilised to fulfill the milestone payout obligations for accepted proposals and committee compensation for the month of August. Unallocated funds from the [Grants SAFE](https://www.comp.xyz/t/cgp-2-0-delegated-domain-allocation-by-questbook/3352/54?u=harsha) and all domain level SAFE will be returned back to the treasury.
- The unallocated funds from every domain will be returned to the treasury from the renewal budget at the end of 2 quarters
The **KPIs and expectations** of the proposed renewal program along with the **responsibilities of the Domain Allocators and the Program Manager** can be found [here.](https://www.comp.xyz/t/cgp-2-0-updates-and-renewal/4518)
### **About Questbook**
- Questbook (YC-W21) is a decentralized grant orchestration tool, currently being/previously used by Polygon, AAVE, Celo, Solana, TON, Aleph Zero etc.
- Considering the achievements of CGP 2.0, as well as the time commitment and operational expertise necessary for running an effective grants program, Questbook will continue in the role of the Program Manager. [Ruchil](https://twitter.com/roohchill) from Questbook will assume the responsibilities of the Program Manager in place of [@harsha](https://www.comp.xyz/u/harsha) due to bandwidth constraints. Ruchil was the program manager for Polygon facilitating the disbursal of ~ $1M in grants. He works with Solana foundation and ecosystems within Solana on a daily basis to help them design their grants program. He has received a grant of $250K from the Solana foundation for the same. He also worked closely with CGP 2.0 Program Manager and Grants team.
### **Disclaimer**
Questbook has been collaborating with Michigan Blockchain to work through the details of this grant renewal proposal and communicate the merits to the broader Compound community. Michigan Blockchain was not provided consideration as a result of this collaboration as both proposers believe the passing of this proposal is in the best interest of the Compound protocol.
# Deploy Uniswap V3 on Moonbeam (2023)
## Summary
We [Michigan Blockchain](https://twitter.com/UMichBlockchain) are submitting this proposal to reinstate the deployment of Uniswap v3 on Polkadot’s EVM-compatible parachain, Moonbeam. The temperature check for this proposal passed with **26M (~100%) YES** votes and **169 (~0%) NO** votes–the proposal stakeholders were agreed upon via the RFC.
## Proposal Motivation
Last spring, the Uniswap DAO voted on this exact topic. The proposal advanced through Uni’s governance rails, receiving positive [feedback from the community](https://gov.uniswap.org/t/governance-proposal-deploy-uniswap-v3-on-moonbeam/16759), progressing past the [temperate check](https://snapshot.org/#/uniswap/proposal/QmaG6nJYW3xLeQwAa6xxhpbuYS8h6PVQpbx1vfqpqxAtik), and eventually passing with a near unanimous YES decision during the [onchain vote](https://www.tally.xyz/gov/uniswap/proposal/19). Nomad was the designated contract deployer and the appointed cross-chain messaging solution for that proposal. Illusory Systems (Nomad) received the Additional Use Grant, which can be seen on the [v3-core-license-grants.uniswap.eth ENS subdomain](https://app.ens.domains/name/v3-core-license-grants.uniswap.eth/details). Although Nomad obtained the license exemption in May 2022, they never began v3 contract deployment on Moonbeam. This can generally be seen as fortuitous from Uniswap’s vantage point as the hiatus allowed Uniswap to avoid exposure to the [Nomad bridge exploit](https://twitter.com/samczsun/status/1554252024723546112?s=20) on August 1, 2022.
Recently, both the [Uniswap](https://gov.uniswap.org/t/governance-proposal-deploy-uniswap-v3-on-moonbeam/16759/12?u=abdullahumar) and [Moonbeam](https://gov.uniswap.org/t/continue-the-uniswap-v3-deployment-on-moonbeam-with-different-bridge-provider/20831) communities have voiced interest in reinstating the previous proposal. As a result, we have conversed with key members of the Moonbeam ecosystem to formulate a reformed proposal with modifications to the previous proposal. This new proposal will contain updates regarding the architecture and activity on both Polkadot and Moonbeam. The previous $2.5M commitment by the Moonbeam foundation to the Uniswap Grants Program (UGP) has been omitted due to difficult market conditions, but there are liquidity incentives available through [Moonbeam Foundation’s Level 3](https://forum.moonbeam.foundation/t/referendum-87-revised-grant-program/399) grant process. This has the potential to qualify for the mentioned grant over the course of the next few months, allowing for more seamless liquidity bootstrapping on Moonbeam.
## Proposal Stakeholders
The following list of stakeholders is present to transparently communicate which entities and individuals are involved in proposal creation and implementation.
**Proposer: [Michigan Blockchain](https://twitter.com/umichblockchain?lang=en)**
* This entity is responsible for authoring the proposal & managing the governance process
**Deployer: [GFX Labs](https://gfx.xyz/)**
* This entity is responsible for the technical deployment of the contracts on the target chain
**Bridge Provider: [Wormhole](https://wormhole.com/)**
* This is the cross-chain messaging solution selected for this deployment
**Target Chain: [Moonbeam](https://moonbeam.network/) (a Polkadot parachain)**
* This is the chain that v3 contracts have been deployed on
**Proposal Sponsor: Michigan Blockchain**
* This entity has >2.5M UNI and is therefore eligible for administering the onchain vote
## Moonbeam, Polkadot, and How Uniswap Benefits
One of the key selling points for Uniswap’s deployment onto Moonbeam is the potential for the DEX to attain market share in the broader Polkadot ecosystem.
### The Polkadot Relay Chain
At the heart of Polkadot lies the Relay Chain, a layer-0 blockchain with limited bells and whistles, lacking native support for smart contracts. The purpose of the Relay Chain is to serve as a simplistic centerpiece into which other blockchains integrate. Layer-1 blockchains that connect to the Relay Chain are called parachains. Each parachain has autonomy over its architecture with a native token, collator set (collators are just validators for a parachain), and governance system. The Polkadot Relay Chain uses Nominated Proof of Stake (NPoS) consensus, making it responsible for the crucial task of handling the ecosystem’s security. The chain’s [staking ratio currently sits at 47%](https://www.stakingrewards.com/earn/polkadot/metrics/) (~$4B DOT out of $7.6B DOT mcap) which indicates that nearly half of the token supply is involved in securing Polkadot. Parachain collators aren’t directly responsible for security but are vital for aggregating parachain txns into a block candidate, along with a respective state transition proof, for the Relay Chain to validate. Offloading consensus responsibilities to the Relay Chain liberates parachains and lets them divert their resources and efforts to designing and maintaining specialized L1s like Moonbeam.
### Moonbeam: Polkadot’s Go-to EVM-Compatible Parachain
Moonbeam was inaugurated as Polkadot’s second parachain after it [won a parachain slot auction](https://moonbeam.foundation/moonbeam-crowdloan/) in Q4 2021. Parachain slots are the limited number of seats present on the Relay Chain. Each slot is occupied by a particular project for a lease period of two years. Currently, [43](https://polkadot.subscan.io/parachain) out of the [100 maximum slots](https://wiki.polkadot.network/docs/learn-parachains-faq#is-100-a-hard-limit-on-the-number-of-parachains-that-can-be-supported) are filled. In order for a parachain slot to become occupied, a project must win a slot auction: a 7-day bidding process during which multiple projects compete to attain a seat on the Relay Chain. The project that bids the most DOT tokens bonds (locks up) the bidded tokens for the duration of slot lease. Bonded tokens are returned post lease expiration. To ease the financial burden of self-funding large bids, projects vie for DOT holders’ contributions to crowdfund their bid. Moonbeam received a total of [35,759,931 DOT from ~200k contributors](https://moonbeam.foundation/moonbeam-crowdloan/), the highest number of tokens committed for any parachain auction. As a reward, DOT contributors received Glimmer ($GLMR), the native Moonbeam token responsible for rewarding collators, network txn fees, and governance. The sheer number of contributors made GLMR’s distribution decentralized.
### XCM & Interoperability
Along with security, the second core function of the Relay Chain is providing trustless interoperability between parachains. The sharing of state and validation logic enables a trustless ecosystem. Individual parachains do not have a reliance on trusting other parachains and can instead depend on the Relay Chain. The specific railway for sending assets and messages to parachains via the Relay Chain is called XCMP, which utilizes a standardized communication format called XCM. This is Polkadot’s way of enabling a versatile cross-chain environment, as XCM is not only limited to parachains but can also be utilized by non-Substrate chains. XCM went live May 2022, the same month that the previous Moonbeam RFC was released. It has since [relayed ~235k messages](https://polkadot.subscan.io/xcm_dashboard). Parity Technologies is constantly iterating on XCM’s functionalities, with [XCM v3 launching soon](https://wiki.polkadot.network/docs/learn-xcm).
Moonbeam currently [leads all other parachains](https://polkadot.subscan.io/xcm_channel) in terms of cross-parachain txns via XCM channels. Over 2/3 of the top XCM channels involve transfers either to or from Moonbeam, illustrating the parachain’s high usage in the Polkadot ecosystem.
Moonbeam also leveraged XCM to create the XC-20 token standard. XC-20 tokens are essentially Substrate assets that conform to the ERC-20 interface. This is a game changer for Uniswap. Since Uni uses ERC-20 tokens, the DEX struggles to accommodate non-ERC-20 tokens like Substrate native tokens. If a user wants to create a DOT/ETH pool, for instance, this is not possible due to DOT’s incompatibility with Uniswap’s ERC-20 requirement. Utilizing xcDOT, the XC-20 version of DOT, fixes this issue.
This interoperability between parachains will expose Uniswap to the entire Polkadot ecosystem. Uniswap’s presence on Moonbeam will likely become a beacon for users and developers to access liquidity more seamlessly. The transfer of assets and data from Ethereum to Moonbeam to other parachains–and vice versa–would facilitate the overall growth of Polkadot and Uniswap.
### Developers and Ecosystem
As of Q4 2022, Polkadot saw its [full-time developer count](https://www.developerreport.com/) increase to 752, trailing only behind Ethereum. This is in part due to the ease of using the Substrate framework. The rate of growth was on par with Ethereum but lagged behind competing chains like Cosmos and Solana. A more holistic measure of growth would also include the activity present on Polkadot’s canary chain, Kusama, which saw a 21% increase in full-time developers. Prior to launching on Polkadot, projects tend to launch a version of their chain on Kusama–which is not a testnet but a fully sovereign chain–to battle test their product. Kusama hosts a very similar Relay Chain-Parachain architecture to mimic the conditions of Polkadot. Moonbeam’s sister chain on Kusama is called Moonriver. Moonbeam itself saw a full-time developer growth rate of 39%.
Moonbeam is only second to Acala in terms of parachain TVL, with $46.5M spread across 44 different protocols. Due to the ease with which Ethereum developers can launch their EVM dapps onto the parachain, Moonbeam boasts the largest quantity of applications in the Polkadot ecosystem.
The DEX market on Moonbeam is largely uncontested, with StellaSwap absorbing most of the parachain’s TVL. With capital efficient liquidity pools and strong brand recognition, Uniswap’s expansion into the Moonbeam ecosystem will very likely enable it to capture market share from StellaSwap and also attract new users–the goal is not for this to be a zero-sum game.
## Deployment Details
The approval of this proposal by Uniswap governance will lead the stated Uniswap v3 contracts to be deemed as the canonical deployment on Moonbeam. As is the case with all canonical v3 deployments, this deployment will be subject to Ethereum Layer 1 Uniswap Protocol governance and control. The text record of the uniswap.eth ENS subdomain titled v3deployments.uniswap.eth will be amended to include the reference to the stated v3 contracts on Moonbeam.
**Deployed Contracts Information (completed by GFX Labs):**
[Message Sender](https://etherscan.io/address/0xf5f4496219f31cdcba6130b5402873624585615a#code)
[Message Receiver](https://moonbeam.moonscan.io/address/0xB2af16D6c7074228fC487F17929De830303E6531#code)
[v3CoreFactoryAddress](https://moonbeam.moonscan.io/address/0x28f1158795A3585CaAA3cD6469CD65382b89BB70#code)
[multicall2Address](https://moonbeam.moonscan.io/address/0xcefe54c7a797199ab4e7e9ebb0885f1ece4aa544#code)
[proxyAdminAddress](https://moonbeam.moonscan.io/address/0x401908E5E38D2F285425bafc1795eA900D030dEa#code)
[tickLensAddress](https://moonbeam.moonscan.io/address/0x1f4F7b041895D9eB1A79be0896AF3E68e4160010#code)
[nftDescriptorLibraryAddressV1_3_0](https://moonbeam.moonscan.io/address/0x041b81cb4d223d8e70ac96c0d103f8a956ed4514#code)
[nonfungibleTokenPositionDescriptorAddressV1_3_0](https://moonbeam.moonscan.io/address/0x921c55AE486e63D16dbfbE216573A21aeB684c02#code)
[descriptorProxyAddress](https://moonbeam.moonscan.io/address/0x974841BD5aea2aac749Ff581d02E27B5D986c654#code)
[nonfungibleTokenPositionManagerAddress](https://moonbeam.moonscan.io/address/0x9036D0DcB5a059C9371B05D508f0072Df773854e#code)
[v3MigratorAddress](https://moonbeam.moonscan.io/address/0x76776b10d782a1d194fBFC92d4b01db1cE1eEB4B#code)
[v3StakerAddress](https://moonbeam.moonscan.io/address/0x74E9C28a9E62d8B559347f569d05e493EAd9703D#code)
[quoterV2Address](https://moonbeam.moonscan.io/address/0x48aF91cDcad8FfdD7a8d4CdF73c16CB0632D3D17#code)
[swapRouter02](https://moonbeam.moonscan.io/address/0xc507E22BA3140dc0A79fDF27e03c98aa20f3ee66#code)
## Bootstrapping Liquidity
Due to tumultuous market conditions, promises of liquidity bootstrapping have been temporarily excised. However, there are still alternative methods to help procure initial Uni v3 liquidity on Moonbeam post deployment. Michigan Blockchain is currently exploring writing a proposal on the Moonbeam forums via the [Moonbeam Foundation’s Level 3](https://forum.moonbeam.foundation/t/referendum-87-revised-grant-program/399) grant process. We are open to community feedback here, but the plan is for our team to apply for a Moonbeam grant on behalf of the DAO.
## Timeline
This proposal has passed the RFC and temperature check phases. The relevant Uniswap v3 contracts have also been deployed on the Moonbeam chain. If this onchain vote passes, this deployment will be officially recognized as a canonical v3 deployment through an amendment to the v3deployments.uniswap.eth subdomain. Thereafter, Uniswap Labs is left with the task of handling the front-end integration updates and including Moonbeam to the auto router–this final step is not subject to the DAO’s discretion and is handled entirely by Uniswap Labs, a separate entity from DAO.
# Deploy Uniswap V3 on Avalanche
## Summary
We [Blockchain at Michigan](https://twitter.com/UMichBlockchain) are submitting this [proposal](https://gov.uniswap.org/t/deploy-uniswap-v3-on-avalanche/20587) for initiating Uniswap v3 deployment on the Avalanche blockchain. With the BSL expiring on April 1st, the Uniswap Foundation has [stated](https://gov.uniswap.org/t/cross-chain-deployment-guide/19988?u=gfxlabs) the importance of Uniswap v3 expansion to popular EVM chains. Establishing Uniswap on alt L1s–and not just on Ethereum L2s–is vital for establishing a robust, multichain future. After consulting with the Ava Labs team, we believe that this is a crucial and opportune time for Uniswap to expand to Avalanche’s growing ecosystem.
The [temperature check passed](https://snapshot.org/#/uniswap/proposal/0xa47404722b9c8a6fb850cf5de79e8a95f073f06393290949644a627bfe85bced) with **26M (91.26%) YES** votes and **2.5M (8.74%) NO** votes.
## Proposal Motivation
The primary urgency behind this proposal is the upcoming BSL expiration on April 1st. As soon as the license expires, all entities will have the legal right to duplicate Uniswap v3 and utilize the forked code for commercial purposes. Invariably, large chains like Avalanche will see a rapid influx of v3 copycats, which will dilute the markets on those respective chains. It is therefore imperative for Uniswap v3 to get ahead of the competitors by launching on large chains before duplicates arise. Trader Joe v2, the current leading DEX on Avalanche, did [$92.45M](https://defillama.com/dexs/chains/avalanche) of volume in the past 24 hours (Feb 23)–indicative of the demand for a concentrated liquidity AMM. Due to the continual growth of the Avalanche ecosystem, along with the liquidity present on the platform, we believe that this proposal be enacted as soon as possible to ensure that Uniswap establishes a foothold in the Avalanche DEX market.
We realize that beyond the chain of deployment, the community must also consider the required cross-chain messaging protocol. Although the DAO previously coalesced to utilize [Wormhole for the BNB Chain deployment](https://snapshot.org/#/uniswap/proposal/0x6b8df360fdf73085b21fdf5eef9f85916fbde95621a3d454cb20fbe545ffc852), we believe that such a decision should not set a precedent for bridge selection. A vendor lock-in model would prevent the further testing of equally renowned messaging protocols like LayerZero. A handful of delegates and tokenholders have also pioneered a more novel approach to governance messaging, where cross-chain governance relies not on a single bridge but simultaneously on a handful of bridges. Although we see the merits of a [multi-bridge system](https://gov.uniswap.org/t/cross-chain-bridge-assessment-process/20148/1), it will take time for this approach to garner attention and be fully vetted. The DAO can decide to opt into a multi bridge system in the future–but for an agile deployment that can be implemented in the present, we believe that LayerZero is the best solution.
## Current State of Avalanche
Avalanche is a blockchain platform that utilizes three separate blockchains, the Platform Chain (P-Chain), Contract Chain (C-Chain), and Exchange Chain (X-Chain), to improve scalability and interoperability. These three chains compose a consortium of validators called the Primary Network, which is responsible for Avalanche’s security.
Avalanche operates with the Avalanche consensus algorithm, which is designed to be more efficient than alternative consensus mechanisms and enables EVM-compatibility. The consensus mechanism checks validators’ transaction confirmations randomly by allowing all nodes to work in parallel, increasing the probability that a transaction is valid. The C-Chain leverages the Snowman consensus protocol, which mimics Avalanche consensus but is optimized for smart contract integration. Therefore, most Avalanche dAPP activity currently transpires on the C-chain.
In comparison to other smart contract platforms, Avalanche touts 2-second time-to-finality, faster than any of its peers (ex. Ethereum finality is 10 minutes). Uniswap on Avalanche would thereby enhance the user experience for both application users and liquidity providers.
Avalanche also allows for an unbounded number of validators without sacrificing block time. This allows for an increasing degree of decentralization over time. In Q4 2022, the platform’s [Nakamoto coefficient increased from 30 to 32](https://nakaflow.io/)–surpassing most other L1s–and is poised to continue in an upward direction. Currently, there are [1,228 validators](https://www.avax.network/validators) and over [233M AVAX tokens staked](https://www.avax.network/validators). The expanding validator set and staked AVAX tokens exemplify a robust L1.
The Avalanche architecture permits a high degree of scalability through its ecosystem of subnets. Similar to Ethereum’s L2s, subnets allow for outsourcing blockspace from the Primary Network to alternative blockchains. Application-specific blockchains can be launched under customized subnets, granting builders control over their development stack (subnets specify their own execution logic, fee regime, state, networking, and security). Large protocols that initially relied on the C-Chain, like DFK and StepNetwork, are now migrating to their individualized subnets. The increase in subnets furthers the security of Avalanche since each subnet’s validators must simultaneously secure the Primary Network.
Increased application activity on the C-Chain and subnets presents Avalanche as an expanding ecosystem. At the time of writing, according to [DeFi Llama](https://defillama.com/chains), Avalanche holds over $950M of TVL across 281 different protocols.
Since launching in Q3 2020, Avalanche’s txn count has cumulatively increased to nearly [700M](https://avascan.info/). Messari reported that between Nov 2021 - Nov 2022 alone, the network experienced [YoY txn growth of 1,507%](https://research.nansen.ai/article/529/avalanche-scaling-with-subnets). Although [daily active users remained relatively steady since Summer 2022](https://tokenterminal.com/terminal/projects/avalanche), average daily transactions increased from ~1M to ~3M, indicating the emergence of power users. A reliable user base is imperative for a properly functioning Uniswap protocol. The presence of long-term liquidity provision would aid in bootstrapping individual subnets as well as making the C-Chain more robust.
Post deployment, the most fierce competitor for Uni v3 will be Trader Joe. Since Trader Joe recently released a Uni v3-like, [capital efficient AMM](https://docs.traderjoexyz.com/), Uniswap has an incentive to capture as much of Avalanche’s DEX market prior to Trader Joe v2 locking in a concrete user base. Plus, after the BSL expires in April, numerous Uni v3 forks will invariably launch on Avalanche. Therefore, to minimize Uniswap’s dilution in the Avalanche ecosystem, the DAO is incentivized to launch v3 as soon as possible.
Due to Uniswap’s strong brand, it has the ability to capture market share from existing DEXs and attract liquidity from new users. A notable historical anecdote is Polygon. Once Uni v3 launched on Polygon, it quickly acquired market share from both Quickswap and Sushiswap. Although this experiment is yet to be tested on an alt L1, it is likely that a similar pattern will surface on Avalanche–although Trader Joe may present a higher degree of friction. Nonetheless, it is not necessary that the DEX competition will result in a zero-sum game and can favor both Trader Joe and Uniswap simultaneously.
Apart from DeFi developments, Avalanche has also made strides in other sectors like gaming, NFTs, and user adoption. Further facilitation of each of these categories is enabled by a DEX like Uniswap. And in turn, Uniswap liquidity providers–and maybe token holders–will attain economic value from the protocol’s increased usage.
## Safety and Cross-Chain Governance
### LayerZero Overview
We propose using LayerZero, an omnichain bridging solution, to facilitate cross-chain message passing between Ethereum and Avalanche. LayerZero has pre-existing support for both Avalanche and Ethereum.
The [first use case of Omnichain Fungible Token (OFT) transfer](https://medium.com/avalancheavax/layerzero-aims-to-create-one-unified-experience-for-btc-b-339eb4d23672) has been active for nearly 4 months on Avalanche. LayerZero allows Avalanche BTC (BTC.b) bridging between all LayerZero-supported chains, creating a composable, unified liquidity system for BTC. From the 25+ supported chains, two, DFK and Swimmer, are run as their own subnets. Apart from cross-chain asset transferring, LayerZero also supports arbitrary message passing–which includes governance communication between Uniswap on Ethereum to Avalanche.
LayerZero is backed by the likes of a16z, Sequoia, Uniswap Labs, Coinbase, and numerous others–it is supported by thousands of cross-chain builders with over 2,000 contracts deployed on mainnet, ~700 unique applications, ~2M total messages, ~$5B transactional volume, and billions of dollars in TVL.
**Is the bridge secured by a trusted entity, by a multi sig, or a protocol/set of incentivized nodes?**
LayerZero endpoints rely on an architecture leveraging Ultra Light Nodes and two off-chain entities called oracles and relayers to securely relay messages between endpoints on a source and destination chain. The oracle is responsible for relaying block headers, and with the default LayerZero setup, will be handled by Chainlink. A transaction proof is sent using the relayer; the default relayer is operated by LayerZero. Hence, the security of the system relies on 2 entities. The primary assumption behind this setup is that the oracle and relayer remain independent at all times. Collusion between the entities would lead to a compromised system. Uniswap will have the option to operate one or both of these entities which would decrease the possibility of collusion.
**Is the bridge secured by a trusted entity, by a multi sig, or a protocol/set of incentivized nodes?**
LayerZero leverages direct MPT validation construction of the source transaction and verifies the merkle inclusion proof directly on the destination chain via the protocol’s novel Ultra Light Node (ULN).
**Is it possible for a fraudulent message to be passed to the destination chain? If so, are there any recall mechanisms?**
Malicious message transmission is a possibility if there is a compromise of both the oracle and relayer sets. Both entities would have to agree to approve a fraudulent message together and against the same application. For example, the decentralized Chainlink DON would have to actively collude with the LayerZero Labs relayer at the same time to enable passing of a malicious message. If the application selects multiple oracles and multiple relayers, thereby pricing its security higher, fraudulent message passing would require more independent parties to be simultaneously compromised.
**What are the ramifications of fraud to the malicious actor?**
Unlike some other bridges, LayerZero does not pose an economic stake or bond to punish malicious actors via a slashing mechanism. Instead, if the default oracle-relayer configuration is compromised, then there is a reputational backlash that would beset LayerZero and Chainlink–since they are the entities responsible for the relayer and oracle, respectively. However, if Uniswap decides to control the messaging stack by running either the oracle or relayer, then Uniswap itself will have to answer for its shortcomings if there happens to be malicious activity.
LayerZero is also designed to be censorship resistant. Oracles and Relayers cannot censor messages without censoring all messages due to the sequential nonce ordered enforcement on the receiving chain. As a result, if an attacker obtained control of the Uniswap-selected Oracles or Relayers, and succeeded in censoring a message, every subsequent message would also be censored and the vote would stop. Uniswap could then expediently resolve the issue by updating configurations and messaging would resume.
**Has the bridge code been audited? By a third party? What attack vectors and vulnerabilities were identified, if any? Have the identified vulnerabilities been remedied?**
Immutability is part and parcel to LayerZero’s infrastructure. Its smart contracts are not upgradable and therefore aren’t prone to bugs due to smart contract updates. Smart contract bugs is the predominant historical cause for bridge exploits, as was the case with Wormhole’s $300M and Nomad’s $190M hack in 2022. To ensure that the current LayerZero contracts are reliable enough to be set in stone and entirely independent from LayerZero Labs’ future involvements, the protocol has been [audited 35+ times](https://github.com/LayerZero-Labs/Audits) and reviewed at least 3+ times by the LayerZero Labs team.
LayerZero is the only major cross-chain messaging protocol to have secured significant transaction volume (~$5B) over time without any exploit, compromise of key infrastructure, or loss of user funds. Additionally, LayerZero has the [largest live bug bounty across the industry at up to $15M](https://medium.com/layerzero-official/layerzero-security-update-april-2022-4c27a22380b4).
### Future Bridge Alterations
Following deployment, if Uniswap governance would like to switch to a different bridge setup, the DAO can do so with a future proposal. There are current ruminations regarding a multi bridge messaging setup–but that is too early to implement for this proposal. Much like the recent BNB Chain deployment proposal, we recommend utilizing a single bridge for the time being and integrating a more novel system later on after the BSL expiration.
## License Exemption
We are requesting an exemption via an Additional Use Grant (license change enacted via the ENS domain uniswap.eth) that would allow LayerZero to use the Licensed Work to deploy it on Avalanche, provided that the deployment is subject to Ethereum layer 1 Uniswap Protocol governance and control. Uniswap v3 will be deployed on Avalanche by LayerZero Labs through the “[Deploy Uniswap V3 Script](https://github.com/Uniswap/deploy-v3#deploy-uniswap-v3-script)”. LayerZero Labs would be permitted to use subcontractors to do this work.
## Timeline
Once the on-chain governance proposal is completed, LayerZero Labs will deploy the Uniswap v3 smart contracts on the Avalanche C-Chain. Uniswap Labs will handle the front-end integration updates and include Avalanche to the auto router. Altogether, this deployment will take ~5 weeks to complete.
# Deploy Uniswap v3 on Celo
Dear Uniswap community,
A few weeks ago we (Blockchain at Michigan in partnership with the [Celo Foundation](https://celo.org/) and the [Celo Climate Collective](https://climatecollective.org/)) submitted a proposal to deploy Uniswap V3 on Celo to launch “Green Asset” Liquidity Pools and expand access to Uniswap to the 6B smartphone users around the world.
We initiated the [Temperature Check](https://snapshot.org/#/uniswap/proposal/0x4fdc5d5c87669d3c99072541e1c775f8dee9b906241b2ce22203737b608c8e55) and [Consensus Check](https://snapshot.org/#/uniswap/proposal/0xa5b0e54358d8a0bff4b90461873cd4bec83e57d7b87f2e18b9a4ff81539b21ca) on Snapshot, where the proposal received strong support from the Uniswap community (~100%) voted yes for the proposal. Before putting forth the formal on-chain governance proposal, we wanted to ensure we worked closely with Uniswap Labs and the Uniswap community to put forth clear documentation on the cross-chain governance bridging. We believe this proposal is a first step in a long and fruitful collaboration between the Celo and Uniswap communities—a journey we are particularly excited to embark on.
We’re excited to initiate the formal governance proposal. We’d love to receive your support in this proposal. The proposal discussion can be found [here](https://gov.uniswap.org/t/governance-proposal-deploy-uniswap-v3-on-celo/16686)
## Description
In partnership with the Celo Foundation and the Celo Climate Collective, we propose to authorize the deployment of the Uniswap protocol to Celo on behalf of the community.
Celo is a mobile-first, carbon-negative, EVM-compatible blockchain. Specifically, we propose launching Uniswap on the Celo platform to:
* Increase Uniswap’s presence through $10M in financial incentives to Uniswap users, as well as additional grant funding provided by the Celo Foundation to utilize Uniswap as a financial building block
* Bring Uniswap V3’s increased capital efficiency to the 6B smartphone users around the world
* Create green asset liquidity pools with natural capital backed assets such as tokenized carbon credits (e.g. MCO2, TCO2, and GNT) and future nature backed assets issued on Celo like land and forests
* Use Uniswap as a decentralized mechanism to rebalance the Celo Reserve with nature backed assets rather than relying on centralized exchanges
* Foster pathways for future green use cases on Uniswap
Overall, we believe the Uniswap community’s mission of creating a trustless and decentralized financial infrastructure accessible to anyone aligns with Celo’s vision of tackling climate change and achieving prosperity for all. The full proposal including information on incentives and governance bridging can be found [here](https://gov.uniswap.org/t/governance-proposal-deploy-uniswap-v3-on-celo/16686)