Uniswap Governance

This is a ranked choice vote to update the Incentivized Pools in Phase 2 of the Optimism-Uniswap Liquidity Mining Program. The top 3 choices will be selected in addition to the existing pools: WETH-DAI 0.3% USDC-DAI 0.01% For more information, check out the Uniswap governance forum post:

Post: https://gov.uniswap.org/t/rfc-update-community-governance-process-changes/19718 ~~~ On November 21st, we posted a Request for Comment 5 on a series of proposed changes to the Uniswap community governance process. Thank you to everyone who has provided their comments! Based on community feedback and discussion, we are making some adjustments to our proposal. We will keep this proposal outstanding until next Wednesday December 14th, at which point we will post a Snapshot poll on the changes. The changes to the RFC based on feedback are as follows: Revisions and updates to RFC Increase the new “Request for Comment” process to be a minimum of 7 days rather than our originally proposed 3 days. We agree with Alana Levin 2, GFX Labs 1, and others that a minimum of 1 week ensures that the community will have adequate time to digest each proposal, ask questions, and provide feedback. Increase the quorum for the new Temperature Check, the remaining off-chain Snapshot poll, to 10M UNI rather than the originally proposed 5M UNI. As pointed out by Deven Matthews 1 from Blockchain at Berkeley, 37 delegates meet the 2.5mm threshold – proposers would only need to garner support from 2 of these delegates to move to the last governance vote with a 5M quorum. Increasing quorum to 10M UNI increases the effectiveness of this phase as a signal of community support. We highlight two suggestion from Toby from Other Internet to 1) standardize Snapshot language, particularly by formalizing the use of “No change” rather than other more biased language in Snapshot polls, and 2) reach out to popular governance platforms where the governance process is listed to update it, if the vote passes. We are now planning to post a Snapshot Poll to vote on Wednesday, December 14th. The voting parameters will be 7 days and a 40M UNI quorum. In addition to the above changes, we also pose the following question to the community. We originally proposed that changes to the off-chain components of the community governance process be votes on through an off-chain vote on Snapshot. GFX Labs 1 brought up the point that custodians do not allow voting off-chain - which means many voters may not be able to participate in those votes. Should these changes be voted on on- or off-chain? Particularly if you keep your UNI at a custodian, please opine! Below, we provide an updated version of our original post. TL;DR One of the goals of the Uniswap Foundation 1 is to reduce the amount of friction in the community governance process. In that spirit, today we are proposing changes to that process to improve its efficiency and efficacy. We propose the following changes to the community governance process: Remove the first off-chain Snapshot poll, and replace it with a “Request for Comment” post. The first phase of the governance process should allow the community to digest a proposal, comment, and ask questions. We also believe two off-chain votes introduces unnecessary friction. Increase quorum for the remaining off-chain Snapshot poll in the second phase to 10M UNI. The purpose of this off-chain vote is to gauge community sentiment prior to the governance vote. We believe the 10 million UNI quorum will act as a better signal than the lower quorum requirements in the current process. We also propose to formalize a process for future changes to the off-chain components of the community governance process, like the changes discussed in this proposal. As mentioned above, we are now welcoming feedback from the community on whether these changes should be voted on through an on- or off-chain vote. If you keep your UNI at a custodian, opine below! Summary Uniswap’s governance process is a core input to the community’s ability to steward its ongoing maintenance and growth in a fair and transparent manner. The design of the process should optimize for the dissemination of information throughout the community, for thoughtful iterations on proposals, and for signaling from the community prior to on-chain votes. While the governance process put in place today has, for the most part, been successful in achieving those goals, we believe improvements can be made to reduce overhead and to enhance off-chain signaling prior to the final governance vote. These process enhancements were previously discussed in the forum here, but the simplifications were never implemented. We have decided to bring them back with minor changes. Below we lay out the suggested changes, alongside our rationale. We are excited to hear and incorporate your feedback into this process change. 1297×842 65.2 KB Current Process A detailed outline of the current process can be found here 1. Temperature Check: A temperature check is accompanied by a 3-day snapshot poll that requires a majority vote of 25K UNI yes-vote threshold. Consensus Check: A consensus check is accompanied by a 5-day snapshot poll that requires a majority vote of 50K UNI yes-vote threshold. Governance Proposal: The on-chain proposal and vote is the final phase of the governance process. The proposer must have a minimum of 2.5M UNI delegated to their address. Proposed changes to community governance process Phase 1: Request for Comment Rename: Temperature Check → Request for Comment Removal of Snapshot off-chain vote requirement A minimum of 7 days before moving forward We believe the first phase of the governance process should allow the community to digest a proposal, comment, and ask questions – and not require going through the friction of one of two off-chain votes. The RFC Phase should last for at least 7 days to give the community ample time to formulate opinions on the proposal and provide feedback. Phase 2: Temperature Check Increase the required quorum from 50K to 10M UNI For this phase to better serve as a signaling tool, we suggest increasing the Snapshot poll yes-vote threshold to 10 million UNI. This threshold should be high enough to prevent lower quality proposals from moving to the final phase, while being low enough for higher quality proposals to garner enough support and move on to the final phase. As suggested by Toby, we also strongly suggest the standard usage of a “No change” option in these Snapshot polls. Phase 3: On-chain Governance Vote No changes Proposed formalization of process changes to off-chain components of governance process As mentioned above, we are looking for more community feedback on this topic In her original post on the community governance process, Ashleigh states “On-chain voting is not necessary to make updates to off-chain processes.” An on-chain vote is unnecessary and requires users to pay gas, so should not be required for off-chain process changes. However, we do believe that community support and acceptance is important for process changes to have legitimacy. We thus originally proposed that changes to off-chain processes be voted on through off-chain votes on Snapshot with a 7-day voting period and 40M UNI quorum (original RFC here 5). However, GFX Labs 1 made the point that custodians do not allow UNI holders to vote off-chain, which may mean some UNI is precluded from voting on those changes. We would like more community feedback on whether these kinds of changes should be voted on on- or off-chain. Particularly if you keep your UNI at a custodian, please opine! Conclusion and Next Steps If no new serious changes to the proposal are required, we plan to post a Snapshot Poll on Wednesday, December 14th for the community to vote on these changes. If the Snapshot receives a quorum of 40M UNI votes, the community is indicating they are in favor of these changes. The UF will update relevant documentation on the forum and work with other platforms where the Uniswap governance process is defined to make updates as well.

Summary This proposal is created to further support the mission of a Multichain Uniswap. We propose to the Uniswap community to authorize the deployment of Uniswap V3 on Scroll testnet. Scroll is an EVM equivalent zk-Rollup, a native zkEVM scaling solution for Ethereum. Similarly to Uniswap, Scroll started out working closely with the Ethereum Foundation - built with the community, for the community! Deploying to Scroll bears many benefits, such as significant savings for users, user base growth, capturing the zkEVM market in advance, and fostering L2 native innovation. We are aligned with Ethereum in our community ethos and vision. We are committed to Ethereum’s decentralized, censorship-resistant and efficient future. Generally, we believe that Uniswap’s community and the ecosystem Scroll is striving for are closely aligned: both projects are building towards trustless and decentralized (financial) infrastructure that is accessible to anyone regardless of merit and location. In the following we detail Scroll’s architecture and mission. We look forward to receiving feedback and are happy to answer the community’s questions. About Scroll Scroll is a native zkEVM Layer 2 solution for Ethereum. We are committed to building an EVM equivalent ZK-rollup to help Ethereum become more scalable without sacrificing security. We have been building in the open from day one, and collaborating on the zkEVM with the PSE (Privacy and Scaling Explorations) group at the Ethereum Foundation. Scroll is aiming at building the best possible solution to scale Ethereum Layer 1. Scroll is compatible with Ethereum at the bytecode level, which is a major breakthrough in Layer 2 technology and brings huge benefits to the entire Ethereum community: EVM equivalent: Scroll reuses Geth, enabling seamless migration of infrastructure. 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 all the features and security of EVM which is by far the most battle-tested smart contract infrastructure in the entire space. Decentralization: Scroll is pioneering a decentralized prover network and is the only L2 that has committed to outsource proving before launching on mainnet. By decentralizing proof generation to the community, Scroll will also have efficient proof generation and a more robust ecosystem. Advance Ethereum’s ultimate goal: zkEVM will not only be limited to Layer 2, it will also be used to scale Layer 1. Construction and testing of Scroll will further advance Ethereum’s ultimate goal of “zkSNARK Everything”. Contribute to building a decentralized and efficient future for Ethereum! ZK-Rollups are widely considered to be the Holy Grail of Ethereum scaling - a best-in-class Layer 2 scaling solution that is very cheap and secure. Scroll’s vision is to build a fully EVM-compatible zk-Rollup that any existing Ethereum application can easily migrate to, thereby helping Ethereum scale without affecting the developer experience. We are live on testnet and will be launching on mainnet once our rapidly growing community of users, developers and auditors battle test the network. Proposal By launching on testnet, Uniswap has the opportunity to be part of this battle testing process and get a head start in the zk-Rollup ecosystem. In addition, many protocols (dapps) who are looking to launch on Scroll have asked for integration with an AMM. This is an opportunity for Uniswap to be a strong consideration for these applications. Uniswap’s multi-chain mission can be facilitated and accelerated by deploying on Scroll in the most seamless way currently possible on Ethereum. Uniswap is a uniquely important DEX in the Ethereum ecosystem and pioneers how the ecosystem and user behavior evolves and can continue to do so by benefiting from the explosion of potential use cases that an L2 affords. Uniswap on Scroll will: Be able to offer high throughput, tps and low gas fees to cater to financial applications which are latency-sensitive such as Uniswap. Consolidate the project’s position as an early mover and capture a rapidly growing market in advance as the Ethereum ecosystem gradually shifts to a zkEVM focus. Integrate closely with Scroll’s rapidly growing ecosystem. Dozens of projects have committed to begin deployment within weeks of our initial testnet launch. Projects include Lens, theGraph, Covalent, Empiric, Blockwallet, Ledger, Safe, Orbiter and many more. Based on the excitement around Scroll and zkRollups broadly, we expect over a hundred projects to deploy on our permissionless testnet. Propel L2 DEX innovation. We are only at the brink of uncovering L2 native use cases that have not been feasible on Ethereum Layer 1 as of now. Scroll is incentivizing developers globally to break frontiers by funding research grants, hosting educational workshops and continuously making cutting edge research publicly available. Help foster an ecosystem fueled by creativity. Applications (Games, DeFi and more) that have not been seen till now will be deploying on Scroll and having Uniswap on Scroll is mutually beneficial as novel use-cases will use swaps and liquidity pools. Everything from in-game economies to zk-dapps with swap features will have the opportunity to integrate with Uniswap, leading to a new era for application-layer innovation. Bridge Security ZK-Rollup is 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. Currently, Scroll has a trustless Layer 1 <> Layer 2 bridge, which supports arbitrary message delivery. The bridge is part of the rollup mechanism, verified by the smart contract and the zkEVM, which is much more secure than classical relayer-based bridges. Security is the first priority for us. Scroll implements the EVM which is well-specified and battle-tested. Additionally, we have an in-house security team working with 10+ external auditors who keep a close eye on the security of our codebase. Last but not least, Scroll is built on a completely open source basis. This includes the ZK circuits, the proving system, and the verifier smart contract. Its code security is closely monitored by community developers from projects such as Zcash, 0xPARC, Ethereum Foundation and Filecoin. We firmly believe that using such community standards is the most solid way to maintain the security of the codebase and the security of the entire system. Timeline After passing the Temperature Check we will move forward with deploying Uniswap V3 on our Scroll testnet. The current testnet already supports the deployment of contracts. Since we are fully compatible with EVM, it is very easy to deploy on Scroll. We expect the full deployment will take 2-3 weeks. It is important to us to be closely in touch with the Uniswap community from the start and want to ensure that everything runs smoothly before starting the full governance process for the mainnet deployment.

Background: On Ethereum, Uniswap Labs governance consists of a suite of smart contracts. However, in addition to its original deployment on Ethereum L1 mainnet, Uniswap contracts are also deployed on four additional domains - Polygon, Optimism, Celo, and Arbitrum. Uniswap deployments on these domains do not have native access to the on-chain governance system, nor the UNI tokens which grant voting power in this system on Ethereum mainnet; in order for the existing Uniswap governance system to execute proposals governing these deployments, there must be some method of passing governance decisions from Ethereum mainnet to other domains. Presently, this method has been implemented differently for each of the four chains. The system governing Optimism and Polygon follow similar design principles, and should be functional for passing proposals. The system governing the Arbitrum deployment was mis-configured due to a mis-communication between developers, and will require more involved intervention to repair. Problem: Arbitrum was initially going to allow L1 addresses to pass calls directly to L2 with msg.sender preserved. After realizing security issues with this approach, Arbitrum team instead shifted their approach to use aliasing (this method transforms L1 addresses to be a different address when represented on an L2): Uniswap Labs was not made aware of this change in approach before deploying on Arbitrum. The Uniswap Factory was deployed with the owner set to the same, unaliased address of the L1 Uniswap Timelock contract. To verify, see: owner address Address 0x1a9c8182c09f50c8318d769245bea52c32be35bc | Arbiscan set at UniswapV3Factory | Address 0x1F98431c8aD98523631AE4a59f267346ea31F984 | Arbiscan This address on Arbitrum is an EOA (not a contract) which nobody has the private key to control The governance deployer key on Arbitrum has burned the nonce that could deploy a contract to this address, verifiable here: Address 0x41653c7d61609d856f29355e404f310ec4142cfb | Arbiscan Therefore, nobody can execute governance proposals on Arbitrum in the current state Solution: To fix the cross chain messaging bridge, Arbitrum proposes the following: 1. Final governance vote kicks off (after Temperature and Consensus checks pass). 2. Before the vote passes, Arbitrum will add a temporary exception to disable address-aliasing for messages from the L1 TimeLock contract, 0x1a9c8182c09f50c8318d769245bea52c32be35bc. Arbitrum will notify the Uniswap community via the Uniswap governance forum once this is done. 3. Once the final on-chain governance vote passes, the Uniswap governance contract will send a cross-chain message from the L1 Timelock contract to call setOwner on the L2 Uniswap factory, setting the owner to the L1 Timelock’s address alias, 0x2BAD8182C09F50c8318d769245beA52C32Be46CD. <em>This is the L1 Timelock address + the alias offset: 0x1a9c8182c09f50c8318d769245bea52c32be35bc + 0x111 1000000000000000000000000000000001111 as described further at L1 To L2 Messaging | Arbitrum Documentation Center </em> 4. We will be able to see when this is completed on-chain. Arbitrum will re-enable aliasing for the L1 Timelock contract address. Once this is complete, cross-chain governance between Uniswap and Arbitrum will be fully functional. Conclusion Uniswap is currently the leading decentralized exchange by TVL on Arbitrum, and if this proposal passes the temperature check and continues along the governance process, it will strengthen the current relationship between the two projects.

Background: On Ethereum, Uniswap Labs governance consists of a suite of smart contracts. However, in addition to its original deployment on Ethereum L1 mainnet, Uniswap contracts are also deployed on four additional domains - Polygon, Optimism, Celo, and Arbitrum. Uniswap deployments on these domains do not have native access to the on-chain governance system, nor the UNI tokens which grant voting power in this system on Ethereum mainnet; in order for the existing Uniswap governance system to execute proposals governing these deployments, there must be some method of passing governance decisions from Ethereum mainnet to other domains. Presently, this method has been implemented differently for each of the four chains. The system governing Optimism and Polygon follow similar design principles, and should be functional for passing proposals. The system governing the Arbitrum deployment was mis-configured due to a mis-communication between developers, and will require more involved intervention to repair. Problem: Arbitrum was initially going to allow L1 addresses to pass calls directly to L2 with msg.sender preserved. After realizing security issues with this approach, Arbitrum team instead shifted their approach to use aliasing (this method transforms L1 addresses to be a different address when represented on an L2): Uniswap Labs was not made aware of this change in approach before deploying on Arbitrum. The Uniswap Factory was deployed with the owner set to the same, unaliased address of the L1 Uniswap Timelock contract. To verify, see: owner address https://arbiscan.io/address/0x1a9c8182c09f50c8318d769245bea52c32be35bc set at https://arbiscan.io/address/0x1F98431c8aD98523631AE4a59f267346ea31F984#readContract This address on Arbitrum is an EOA (not a contract) which nobody has the private key to control The governance deployer key on Arbitrum has burned the nonce that could deploy a contract to this address, verifiable here: https://arbiscan.io/address/0x41653c7d61609d856f29355e404f310ec4142cfb Therefore, nobody can execute governance proposals on Arbitrum in the current state Solution: To fix the cross chain messaging bridge, Arbitrum proposes the following: 1. Final governance vote kicks off (after Temperature and Consensus checks pass). 2. Before the vote passes, Arbitrum will add a temporary exception to disable address-aliasing for messages from the L1 TimeLock contract, 0x1a9c8182c09f50c8318d769245bea52c32be35bc. Arbitrum will notify the Uniswap community via the Uniswap governance forum once this is done. 3. Once the final on-chain governance vote passes, the Uniswap governance contract will send a cross-chain message from the L1 Timelock contract to call setOwner on the L2 Uniswap factory, setting the owner to the L1 Timelock’s address alias, 0x2BAD8182C09F50c8318d769245beA52C32Be46CD. *This is the L1 Timelock address + the alias offset: 0x1a9c8182c09f50c8318d769245bea52c32be35bc + 0x111 1000000000000000000000000000000001111 as described further at https://developer.offchainlabs.com/arbos/l1-to-l2-messaging#address-aliasing* 4. We will be able to see when this is completed on-chain. Arbitrum will re-enable aliasing for the L1 Timelock contract address. Once this is complete, cross-chain governance between Uniswap and Arbitrum will be fully functional. Conclusion Uniswap is currently the leading decentralized exchange by TVL on Arbitrum, and if this proposal passes the temperature check and continues along the governance process, it will strengthen the current relationship between the two projects.

Boba Network and Franklin DAO (Prev. Penn Blockchain) are submitting this proposal to Deploy Uniswap v3 on Boba Network. Summary In cooperation with DMA Labs (a major contributor to ICHI’s Uniswap v3 management protocols (https://www.ichi.org/)) and support of furthering the vision of Multichain Uniswap 15, we propose that the Uniswap community vote to authorize the deployment of Uniswap v3 to Boba Network. Boba Network is a blockchain Layer 2 scaling solution and Hybrid Compute (https://cryptodaily.co.uk/2022/07/boba-networks-hybrid-compute-why-it-will-unlock-blockchains-true-potential) platform offering lightning fast transactions and fees anywhere from 40-100x less than the respective Layer 1. Boba’s Hybrid Compute brings the power of Web2 on-chain, with smarter smart contracts that allow developers and creators to leverage off-chain compute and real-world data to offer an enriched experience unlike anything else on the market today. In addition, Boba Network is the first and only multichain (https://www.theblock.co/post/149837/ethereum-layer-2-boba-network-integrates-with-fantom-and-moonbeam) Layer 2, deploying on leading Layer 1 chains such as Ethereum, Avalanche, BNB and Moonbeam. Deploying on Boba will expand the Uniswap community to include users of the Boba multichain ecosystem, helping Uniswap on its journey to become a leading product in the multichain world. The timeline for deployment will be approximately 3-4 weeks following the Governance Proposal, with contract deployment being handled by the Boba Network team. Proposal We believe there are many benefits for the Uniswap Protocol, some of which include: Ethereum equivalence. Developer tools, resources, projects, and protocols supported by Ethereum are already supported on Boba Network. A trustless bridge architecture to bridge assets from Ethereum to the Boba Network L2 has been in place since mainnet launch, with many bridging partners extending our bridge capabilities, such as Across.to, Synapse, Multichain and Layerswap. Low cost transactions with high security. As an Ethereum L2, Boba Network relies on Ethereum’s strong base layer security while providing very low cost transactions, with fees anywhere from 40-100x less than Ethereum. Details for incentivized Adoption of Uniswap v3 Boba Network will provide $1M $BOBA tokens to foster the usage of Uniswap v3 on Boba Network. The tokens will be sent to a multisig wallet co-owned by the Uniswap Grants Program (UGP) and Boba Network, who will work to deploy the funds as follows: The incentives should be designed together with other projects which are operating on top of Uniswap v3 such as ICHI, Perpetual Protocol, Paraswap, or 1inch. The $BOBA can be used to incentivize liquidity but should not be limited to this use case. Anything increasing the usage of Uniswap v3 on Boba Network, including building new applications on top of Uniswap v3, should be supported. The goal is to deploy the $1M in the time period of one year. Funds not used after two years would go back to Boba. The spending is limited to $1M - the transferred amount of $BOBA as part of the proposal. Boba Network can decide to increase this amount based on the outcome of this initiative. In addition to this, Boba Network has already contributed more than $4M of liquidity on Uniswap v3 to bootstrap the initial success of Uniswap v3 on the Boba Network. Security Boba Network is designed so that users can send arbitrary messages between smart contracts on L2 and L1. Users can relay messages themselves. The security of the messages passed is secured within the rollup protocol. Bridging and sequencing transactions is based on Optimism’s Optimistic Rollup codebase. From L1 to L2, users need to trigger the CanonicalTransactionChain contract on L1 to create a new block on Boba Network. Our Sequencer is then forced to include the transaction on L2. From L2 to L1: Making provable statements about the state of Boba requires a cryptographic commitment in the form of the root of the Boba's state trie to a smart contract on L1 called the StateCommitmentChain. We regularly publish updates of the state trie. With Merkle tree proofs of the commitments, users can use these proofs to make verifiable statements about the data within the storage of any contract on Boba at a specific block height. This can then be used to enable contracts on Boba L2 to send messages to contracts on L1. The bridge uses the security of the source chain (L1). In an Optimistic Rollup design, state commitments are published to L1 without any direct proof of the validity of these commitments. Instead, these commitments are considered pending for a period of time (called the “challenge window”). In the challenge window the commitment could be invalidated through a fraud proof. Fraud proof challenges are not enabled and there’s a single sequencer design currently in production. In the event of fraud, the malicious actor and the prover of fraud will (in the future) play out an interactive challenge game and the malicious actor will be slashed. The Boba Network codebase and Optimism’s codebase have undergone multiple audits, with no outstanding vulnerabilities. More details about Boba Network can be found on our engineering roadmap. License Exemption We are requesting an exemption that will allow Boba Network to use the Licensed Work to deploy it on Boba Network, a Layer 2 blockchain on Ethereum, provided that the deployment is subject to Ethereum Layer 1 Uniswap Protocol governance and control. Timeline After passing the Temperature Check with 25k UNI voting yes to deploy to Boba Network, we are excited to move forward to the Consensus Check phase to collect further feedback in advance of an on-chain vote. Following the Consensus Check phase, we will submit this proposal shortly after to an on-chain vote. Provided that the proposal passes both steps, and all governance systems have been built and audited, we will be ready to move forward with the Uniswap v3 deployment on Boba Network. Yes - Deploy Uniswap v3 to Boba No - Make no Change Conclusion Boba Network is primed for substantial growth in the coming year. We have implemented an aggressive developer acquisition program for projects building on not just our Ethereum L2, but also on top of Boba L2s for other chains like Avalanche, BNB, and Moonbeam. Our approach will bring in many new projects, and we feel Uniswap v3 is an essential component that will serve as a foundational layer for this growth. We welcome any questions and comments and are happy to provide any clarifications as needed. We are excited to submit this proposal to the Uniswap community and look forward to your feedback! Thank you.

Boba Network and Franklin DAO (Prev. Penn Blockchain) are submitting this proposal to Deploy Uniswap v3 on Boba Network. Summary In cooperation with DMA Labs (a major contributor to ICHI’s Uniswap v3 management protocols (https://www.ichi.org/)) and support of furthering the vision of Multichain Uniswap 15, we propose that the Uniswap community vote to authorize the deployment of Uniswap v3 to Boba Network. Boba Network is a blockchain Layer 2 scaling solution and Hybrid Compute (https://cryptodaily.co.uk/2022/07/boba-networks-hybrid-compute-why-it-will-unlock-blockchains-true-potential) platform offering lightning fast transactions and fees anywhere from 40-100x less than the respective Layer 1. Boba’s Hybrid Compute brings the power of Web2 on-chain, with smarter smart contracts that allow developers and creators to leverage off-chain compute and real-world data to offer an enriched experience unlike anything else on the market today. In addition, Boba Network is the first and only multichain (https://www.theblock.co/post/149837/ethereum-layer-2-boba-network-integrates-with-fantom-and-moonbeam) Layer 2, deploying on leading Layer 1 chains such as Ethereum, Avalanche, BNB and Moonbeam. Deploying on Boba will expand the Uniswap community to include users of the Boba multichain ecosystem, helping Uniswap on its journey to become a leading product in the multichain world. The timeline for deployment will be approximately 3-4 weeks following the Governance Proposal, with contract deployment being handled by the Boba Network team. Proposal We believe there are many benefits for the Uniswap Protocol, some of which include: Ethereum equivalence. Developer tools, resources, projects, and protocols supported by Ethereum are already supported on Boba Network. A trustless bridge architecture to bridge assets from Ethereum to the Boba Network L2 has been in place since mainnet launch, with many bridging partners extending our bridge capabilities, such as Across.to, Synapse, Multichain and Layerswap. Low cost transactions with high security. As an Ethereum L2, Boba Network relies on Ethereum’s strong base layer security while providing very low cost transactions, with fees anywhere from 40-100x less than Ethereum. Details for incentivized Adoption of Uniswap v3 Boba Network will provide $1M $BOBA tokens to foster the usage of Uniswap v3 on Boba Network. The tokens will be sent to a multisig wallet co-owned by the Uniswap Grants Program (UGP) and Boba Network, who will work to deploy the funds as follows: The incentives should be designed together with other projects which are operating on top of Uniswap v3 such as ICHI, Perpetual Protocol, Paraswap, or 1inch. The $BOBA can be used to incentivize liquidity but should not be limited to this use case. Anything increasing the usage of Uniswap v3 on Boba Network, including building new applications on top of Uniswap v3, should be supported. The goal is to deploy the $1M in the time period of one year. Funds not used after two years would go back to Boba. The spending is limited to $1M - the transferred amount of $BOBA as part of the proposal. Boba Network can decide to increase this amount based on the outcome of this initiative. In addition to this, Boba Network has already contributed more than $4M of liquidity on Uniswap v3 to bootstrap the initial success of Uniswap v3 on the Boba Network. Security Boba Network is designed so that users can send arbitrary messages between smart contracts on L2 and L1. Users can relay messages themselves. The security of the messages passed is secured within the rollup protocol. Bridging and sequencing transactions is based on Optimism’s Optimistic Rollup codebase. From L1 to L2, users need to trigger the CanonicalTransactionChain contract on L1 to create a new block on Boba Network. Our Sequencer is then forced to include the transaction on L2. From L2 to L1: Making provable statements about the state of Boba requires a cryptographic commitment in the form of the root of the Boba's state trie to a smart contract on L1 called the StateCommitmentChain. We regularly publish updates of the state trie. With Merkle tree proofs of the commitments, users can use these proofs to make verifiable statements about the data within the storage of any contract on Boba at a specific block height. This can then be used to enable contracts on Boba L2 to send messages to contracts on L1. The bridge uses the security of the source chain (L1). In an Optimistic Rollup design, state commitments are published to L1 without any direct proof of the validity of these commitments. Instead, these commitments are considered pending for a period of time (called the “challenge window”). In the challenge window the commitment could be invalidated through a fraud proof. Fraud proof challenges are not enabled and there’s a single sequencer design currently in production. In the event of fraud, the malicious actor and the prover of fraud will (in the future) play out an interactive challenge game and the malicious actor will be slashed. The Boba Network codebase and Optimism’s codebase have undergone multiple audits, with no outstanding vulnerabilities. More details about Boba Network can be found on our engineering roadmap. License Exemption We are requesting an exemption that will allow Boba Network to use the Licensed Work to deploy it on Boba Network, a Layer 2 blockchain on Ethereum, provided that the deployment is subject to Ethereum Layer 1 Uniswap Protocol governance and control. Timeline After passing the Temperature Check with 25k UNI voting yes to deploy to Boba Network, we are excited to move forward to the Consensus Check phase to collect further feedback in advance of an on-chain vote. Following the Consensus Check phase, we will submit this proposal shortly after to an on-chain vote. Provided that the proposal passes both steps, and all governance systems have been built and audited, we will be ready to move forward with the Uniswap v3 deployment on Boba Network. Yes - Deploy Uniswap v3 to Boba No - Make no Change Conclusion Boba Network is primed for substantial growth in the coming year. We have implemented an aggressive developer acquisition program for projects building on not just our Ethereum L2, but also on top of Boba L2s for other chains like Avalanche, BNB, and Moonbeam. Our approach will bring in many new projects, and we feel Uniswap v3 is an essential component that will serve as a foundational layer for this growth. We welcome any questions and comments and are happy to provide any clarifications as needed. We are excited to submit this proposal to the Uniswap community and look forward to your feedback! Thank you.

Which pools should be selected? 1. WETH/USDC, WETH/DAI, WETH/OP 2. WETH/USDC, WETH/DAI, USDC/DAI 3. WETH/USDC, WETH/DAI

How should the program be structured? 1. 2 Phase Deployment, Option 1 [200 OP/ 2 weeks, 600 OP] 2. 2 Phase Deployment, Option 2 [200 OP/ 4 weeks, 600 OP] 3. 3 Phase Deployment [50k OP/ 2 weeks, 100k OP/ 3 weeks, 650k OP until funds are all used]

Penn Blockchain (FranklinDAO) is creating this proposal in partnership with Matter Labs to Deploy Uniswap V3 on zkSync. Deploy Uniswap V3 to zkSync Summary To support Uniswap’s multichain mission and expand cross-chain experiences, we propose the deployment of Uniswap V3 to zkSync 2.0 on behalf of the community. zkSync ecosystem has over 100 projects committed to launching on mainnet, including top DeFi protocols, infrastructure, on/off ramps, etc. Deploying on zkSync will onboard new users & increase user activity on Uniswap by decreasing costs compared to Ethereum without security degradation zkSync shares Ethereum’s ethos as a free open-source project with a commitment to personal sovereignty, decentralization and community ownership We welcome feedback from the community on the proposal, including suggestions on how it can be improved. About zkSync zkSync 2.0 is a ZK rollup (https://ethereum.org/en/developers/docs/scaling/zk-rollups) that supports generalized EVM compatibility for the Ethereum blockchain. The primary benefit of zkSync 2.0 is that developers who have created EVM dApps can port to zkSync 2.0 effortlessly and realize significantly lower gas fees and more transactions per second without compromising on security. zkSync 2.0 is a significant leap forward in Layer 2 technologies with long awaited improvements and benefits for Ethereum developers: EVM Compatible - supporting generalized EVM smart contracts on a ZK rollup making it easy to deploy existing dApps ToolChain Compatible - able to port smart contracts with existing tools Ethos Compatible - aligned with the ethos of decentralization and open-source Certainty - using zero knowledge proofs offering certainty of security not probability Future Proof - ecosystem partners that adopt zkSync 2.0 now will enjoy all future improvements without the need to change their code There is broad consensus that ZK rollups are the endgame for scaling Ethereum. zkSync’s EVM compatibility, ease of use, and composability will accelerate developer and retail adoption. Top researchers including Vitalik Buterin recognize ZK rollups as the long term scaling solution. Security & Bridges ZK rollups are the most secure scalability solution available today as they rely purely on math to fully inherit the security of Ethereum. There is a general L1<>L2 communication bridge which will support arbitrary message passing and secured by validity proof and Ethereum consensus. Bridge validators can’t pass an incorrect message or change the content, the worst case would be to censor everyone. Importantly, we’ll be building out additional safety functionality and monitoring off & on-chain activity. Security is top of mind for zkSync. We are currently working with tier-1 auditors for zkSync 2.0 and specifically in the review process for the bridge code. Audits will be conducted before each major upgrade. Besides audits, we offer a substantial bug bounty program. Proposal There’s significant value in Uniswap being available on an EVM compatible ZK rollup. Deploying early on zkSync helps solidify Uniswap’s place as the number one DEX and a thought leader. Importantly, it will help grow a large list of projects that can be built on Uniswap V3. Established projects like Argent, Curve, and Yearn have committed to launch along with over 100 more projects and big infrastructure players like Chainlink, The Graph, Gnosis are supporting the ecosystem. Growing the public smart contract libraries interfacing and using Uniswap v3 codebase will solidify Uniswap’s influence in the Ethereum ecosystem which is moving on to ZK rollups. While the zkSync ecosystem is already experiencing very fast growth, the team is planning programs to attract and fund innovative projects and research partners to accelerate the network’s adoption and in turn, Uniswap’s usage. License Exemption We are requesting an exemption via an Additional Use Grant (license change enacted via the ENS domain uniswap.eth) that would allow Matter Labs to use the Licensed Work to deploy it on zkSync provided that the deployment is subject to Ethereum layer 1 Uniswap Protocol governance and control. Uniswap V3 will be deployed on zkSync by Matter Labs through the “Deploy Uniswap V3 Script” albeit we may need to modify the compilation step with approval from the Uniswap Labs team. Timeline Following the Consensus Check and Governance Proposal we will be ready to move forward with the Uniswap V3 deployment on zkSync. zkSync has been on testnet since February 2022 and plans to launch mainnet early October. A timely assessment of the deployment of Uniswap v3 code to zkSync is important: while deploying on zkSync is fast and easy because it’s fully EVM compatible, we estimate the full effort will take 4-6 weeks given Uniswap’s relevance. This allows for proper testing, communication to the community and engagement with the broader zkSync ecosystem.

Penn Blockchain (FranklinDAO) is creating this proposal in partnership with Matter Labs to Deploy Uniswap V3 on zkSync. Deploy Uniswap V3 to zkSync Summary To support Uniswap’s multichain mission and expand cross-chain experiences, we propose the deployment of Uniswap V3 to zkSync 2.0 on behalf of the community. zkSync ecosystem has over 100 projects committed to launching on mainnet, including top DeFi protocols, infrastructure, on/off ramps, etc. Deploying on zkSync will onboard new users & increase user activity on Uniswap by decreasing costs compared to Ethereum without security degradation zkSync shares Ethereum’s ethos as a free open-source project with a commitment to personal sovereignty, decentralization and community ownership We welcome feedback from the community on the proposal, including suggestions on how it can be improved. About zkSync zkSync 2.0 is a ZK rollup (https://ethereum.org/en/developers/docs/scaling/zk-rollups) that supports generalized EVM compatibility for the Ethereum blockchain. The primary benefit of zkSync 2.0 is that developers who have created EVM dApps can port to zkSync 2.0 effortlessly and realize significantly lower gas fees and more transactions per second without compromising on security. zkSync 2.0 is a significant leap forward in Layer 2 technologies with long awaited improvements and benefits for Ethereum developers: EVM Compatible - supporting generalized EVM smart contracts on a ZK rollup making it easy to deploy existing dApps ToolChain Compatible - able to port smart contracts with existing tools Ethos Compatible - aligned with the ethos of decentralization and open-source Certainty - using zero knowledge proofs offering certainty of security not probability Future Proof - ecosystem partners that adopt zkSync 2.0 now will enjoy all future improvements without the need to change their code There is broad consensus that ZK rollups are the endgame for scaling Ethereum. zkSync’s EVM compatibility, ease of use, and composability will accelerate developer and retail adoption. Top researchers including Vitalik Buterin recognize ZK rollups as the long term scaling solution. Security & Bridges ZK rollups are the most secure scalability solution available today as they rely purely on math to fully inherit the security of Ethereum. While developers are free to build their own bridge for any token, zkSync 2.0 has two default trustless bridges (one for ETH and one for ERC20 tokens). The bridges support arbitrary message passing and are secured by validity proof and Ethereum consensus. Fraudulent messages are not possible. The only actions a malicious actor could take is to censor messages, confirm inclusion in a block and then discard the state change. Security is top of mind for zkSync (https://docs.zksync.io/dev/security/approach/#_1-security-by-correctness). We are currently working with tier-1 auditors for zkSync 2.0 and specifically in the review process for the bridge code. Audits will be conducted before each major upgrade. Besides audits, we offer a substantial bug bounty program (https://docs.zksync.io/dev/security/bug-bounty). Proposal There’s significant value in Uniswap being available on an EVM compatible ZK rollup. Deploying early on zkSync helps solidify Uniswap’s place as the number one DEX and a thought leader. Importantly, it will help grow a large list of projects that can be built on Uniswap V3. Established projects like Argent, Curve, and Yearn have committed to launch along with over 100 more projects and big infrastructure players like Chainlink, The Graph, Gnosis are supporting the ecosystem (https://ecosystem.zksync.io/). Growing the public smart contract libraries interfacing and using Uniswap v3 codebase will solidify Uniswap’s influence in the Ethereum ecosystem which is moving on to ZK rollups. While the zkSync ecosystem is already experiencing very fast growth, the team is planning programs to attract and fund innovative projects and research partners to accelerate the network’s adoption and in turn, Uniswap’s usage. License Exemption Uniswap V3 will be deployed on zkSync by Matter Labs contingent upon approval by the Uniswap community for a license exemption. Governance at deployment will be subject to Ethereum layer 1 Uniswap Protocol governance and control facilitated by the messaging bridge (https://v2-docs.zksync.io/dev/guide/cross-chain-tutorial.html#reading-the-counter-value). Timeline Following the Temperature Check, Consensus Check, and Governance Proposal we will be ready to move forward with the Uniswap V3 deployment on zkSync. zkSync has been on testnet since February 2022 and plans to launch mainnet early October (https://blog.matter-labs.io/100-days-to-mainnet-6f230893bd73). A timely assessment of the deployment of Uniswap v3 code to zkSync is important: while deploying on zkSync is fast and easy because it’s fully EVM compatible, we estimate the full effort will take 4-6 weeks given Uniswap’s relevance. This allows for proper testing, communication to the community and engagement with the broader zkSync ecosystem.

Summary This proposal is created on behalf of Blockchain at Michigan, and in partnership with Proximity Labs. We propose to deploy Uniswap v3 on Aurora through an additional grant license and ask the Uniswap community to consider and discuss this proposal. Uniswap will expand access to decentralized and permissionless trading of tokens on Aurora, and aligns with the community’s multichain vision to bring trustless liquidity to all chains and position itself as a de facto DeFi hub in the space. Our proposal will include a $5m amount allocated for financial incentives to Uniswap users on Aurora and a commitment to actively engage with the Uniswap community to further support its growth through grant programs and funding for protocol-related development. Proximity Labs will coordinate with the community and governance participants to distribute these funds and will support future developments and allocations to projects leveraging Uniswap and DeFi’s ecosystem participants on Aurora. About Aurora Aurora is an EVM-compatible execution environment running on top of NEAR, a proof-of-stake layer 1 chain, and takes advantage of its unique features, including sharding and developer gas fee remuneration. Our long-term vision is to provide a user-friendly platform for developers and users to build fast and highly-scalable decentralized applications offering seamless integrations with NEAR’s native chain as well as different L1s and L2 networks. Transaction costs on Aurora are among the lowest while ensuring a high throughput, scalability, and security. Aurora's SputnikVM is a highly optimized EVM that can execute transactions at high speeds while maintaining full compatibility with Ethereum's VM. This makes Aurora the perfect platform for applications that require high transaction throughput without incurring high costs. There are a total of 100 active NEAR nodes acting as Aurora Relayers. The transaction finality happens on NEAR when a new block is minted, right after it’s wrapped in a NEAR transaction and broadcasted to the nodes through one of the relayers. Since the launch of Aurora in May 2021, the average block time has hovered around 1 second, the chain boosts almost instant transaction finality at ~2 secs and a near-zero transaction cost of ~$0.02 on average per tx. Proposal The Aurora ecosystem has been growing tremendously with very talented builders and founders joining our sides and leveraging Aurora’s exceptional low fees and fast-finality transactions. New integrations and exciting announcements from major protocols and DeFi players such as Curve, Lido,.. have made Aurora one of the fastest growing chains out in the space with an ever-growing number of new people joining and interacting with our dApps. Our network consists of a wide array of platforms, from decentralized exchanges, lending protocols and cross-chain bridges. Our flagship protocols include Bastion Protocol, a lending protocol with more than $340M worth of assets deposited; Trisolaris, a decentralized exchange which secures more than $230M in liquidity; and the Rainbow Bridge, with over $900M in volume bridged across NEAR, Aurora, and Ethereum. Aurora’s TVL sits at $500M, with highs at around $2.64B, demonstrating an overall increasing engagement with our ecosystem and a tremendously growing base of native supporters. There are more than 2.5 mil unique addresses with around 200k new unique addresses per day and we count around 200k transactions daily. Uniswap on Aurora Aurora has a long history of supporting cross-chain protocol deployment and has been eagerly assisting developers and founders all across various chains and spaces to expand and reach new communities and tap into new ecosystems... Major DeFi protocols such as The Graph, Flux Protocol, and Gnosis have already deployed on Aurora, and other blue chips such as Chainlink and Curve have committed to launching soon. We’re aware Uniswap has deployed on major chains such as Polygon, Arbitrum, Optimism, and Celo, with successful proposals to deploy on Moonbeam and Gnosis Chain. Deploying Uniswap would be the next big step to take to add to the already-growing DeFi hub on Aurora and will undoubtedly position itself as a premier AMM, and a major liquidity hub for Near, offering a seamless trading experience and allowing defi users to take advantage of its concentrated liquidity mechanism. This opportunity will allow Uniswap to gain more exposure within the NEAR community as it positions itself as a primary decentralized exchange hub as we’re headed towards a multi-chain economy, and will undoubtedly bring a massive stream of revenue for Liquidity Providers. Incentives Our proposal comes with financial and non-financial incentives to promote long-term protocol development, developer activity and innovation We plan on offering $5m from our ecosystem growth fund to the Uniswap community in the form of Liquidity Mining incentives and Developer Grants to support DeFi applications leveraging Uniswap on Aurora and building on top of it: Commit up to $2.5M for a liquidity mining campaign targeting the top liquid pairs to support the overall adoption of Uniswap V3 Allocate a $2.5M fund to support long-term protocol development by funding developers, designers, and community members building on top of Uniswap and driving Aurora’s growth. Promote and increase Uniswap’s visibility within our ecosystem and to new projects, as well as showcase in Aurora’s marketing campaigns and Near/Aurora hacker houses and hackathons. Rainbow Bridge Rainbow Bridge is the official decentralized bridge for transferring tokens between Ethereum, NEAR and the Aurora networks. At a high level, Rainbow Bridge works through: 1. LiteNodes (a lightweight node implemented as a smart contract that stores block headers. One deployed on the Ethereum network, which stores NEAR block headers, and one deployed on NEAR which stores Ethereum block headers.) 2. Relayers (scripts running on virtual servers, that periodically read blocks from one blockchain, and communicate them to the LiteNode running on the other.) 3. Connectors (smart contracts responsible for all of the logic associated with the cross-chain management of a given asset type). Proximity Labs and Aurora will build a connector following the community vote to make the bridge compatible with general messaging functionality. This connector will be deployed on both Ethereum and Near and will be responsible for transferring governance votes/messages between both chains. One of the advantages of Rainbow Bridge is its malleability. Any asset or data can be transferred across the Rainbow Bridge if relevant Connectors exist. Bridge Security Does the bridge support arbitrary message passing? * Yes, once the relevant connector will be deployed Is the bridge secured by a trusted entity, by a multi-sig, or a protocol/set of incentivized nodes? * The bridge is secured by multi-sig. Security is provided by implementing light-clients of both networks on the counterpart network: Ethereum light client on NEAR and NEAR light client on Ethereum. Does the bridge leverage the security of the source chain (e.g. Ethereum L1) or destination chain, or is the security provided by another third-party entity? * Rainbow bridge leverages both chains’ security (Ethereum and Near) through the use of Provers on both chains: EthOnNearProver NEAR contract in Rust and NearOnEthProver Ethereum contract in Solidity to verify Ethereum events and Near contract execution results. On Near, trust relies that at no time, 2/3 of the validators stake are honest. Not only the bridge, but also all other applications on NEAR operate under this assumption. Is it possible for a fraudulent message to be passed to the destination chain? If so, are there any recall mechanisms? * The rainbow bridge is based on trustless assumptions with no selected middleman to transfer messages or assets between chains. Because of this, anyone can interact with its smart contracts. When players with bad intentions submit bad information, it would be challenged by independent Watchdogs watching the Near blockchain. Similar attacks on the Rainbow Bridge have been dismissed resulting in the loss of the hacker’s funds What are the ramifications of fraud to the malicious actor? * The bridge requires having a watchdog service that monitors submitted NEAR headers and challenges any headers with invalid signatures. For added security, independent users can run several watchdog services. In the event one entity runs a majority of the watchdogs, fraudulent messages can be processed 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? * The code has been audited by ConsenSys and SigmaPrime. No critical vector attacks were identified. * View Audit Report License Exemption We are requesting an exemption via an Additional Use Grant (license change enacted via the ENS domain uniswap.eth) that would allow Proximity Labs and Aurora to use the Licensed Work to deploy it on Aurora, a Layer2 EVM compatible blockchain, provided that the deployment is subject to Ethereum layer 1 Uniswap Protocol governance and control. Uniswap V3 will be deployed on Aurora by Proximity Labs or Aurora through the “Deploy Uniswap V3 Script 15.” Proximity Labs or Aurora would be permitted to use subcontractors to do this work. Timeline Following the vote on the proposal by the Uniswap community, our team will be ready to start working on the deployment of Uniswap V3 on Aurora. We anticipate a few extra steps that will prelude the full deployment such as: Developing the general message connector on top of Rainbow Bridge Deploying Uniswap V3 smart contracts on Aurora We expected the full deployment to take anywhere around 4-5 weeks.

Read the full proposal here: https://gov.uniswap.org/t/consensus-check-create-the-uniswap-foundation/17457

[Read the full proposal here: https://gov.uniswap.org/t/temperature-check-create-the-uniswap-foundation/17358] Uniswap Foundation: Preamble Uniswap has already changed the world. In only 3 years, the world’s first automated market maker has pioneered DeFi primitives, supported more than $1T 7 in cumulative volume, and served millions of users 4 worldwide. Its daily volume today is on par with Coinbase 10. Ownership of the protocol was transferred to the community 12 in 2020 and since then the Uniswap Grants Program (UGP) has demonstrated the potential for community-funded initiatives to make a positive impact. Over 1.5 years, UGP has funded 120+ grantees 22 improving governance, and developing new interfaces and developer tooling. However, there is still work to do to help Uniswap reach its full potential. The governance process has too much friction, the ecosystem is too difficult to navigate, and UGP in its current form is not able to fund the most ambitious and impactful projects. We want to change that. Today, we are excited to propose the creation of the Uniswap Foundation, which has the mission to support the decentralized growth and sustainability of the Uniswap Protocol and its supporting ecosystem and community. In other words, the goal of the Uniswap Foundation is to support you. Uniswap’s community is expansive, encompassing the universe of individuals and organizations which build on and benefit from decentralized protocols. Your contributions have already made Uniswap a success, but we want to help you accomplish much more. The Uniswap Foundation (UF) will provide grants to builders, researchers, organizers, academics, analysts, and more to grow the Protocol and plan for its future. It will make it easier to govern the protocol and community treasury, and to navigate the broader ecosystem. It will help you make an impact – to reduce friction, and amplify your efforts. We believe that Uniswap will be the value exchange layer of the Internet. It brought the automated market maker to the masses. It has led the way in the evolution and growth of DeFi and web3. It is censorship resistant, permissionless, decentralized, and secure – constituting a set of properties which we believe should define our world’s financial infrastructure. But there is still a long way to go for Uniswap to reach its full potential. We’re excited to work with all of you to make that happen. If you’re excited too, please read our proposal, comment, reach out to chat (our DMs - @devinawalsh and @nkennethk are open!), and spread the word. Uniswap Foundation Proposal This proposal is being put forth by the Uniswap Foundation, a Delaware corporation formed by Uniswap community members Devin Walsh and Ken Ng to facilitate the steps outlined in this proposal. TL;DR Today, we are thrilled to propose the creation of the Uniswap Foundation (UF). Scope: The UF, the first Foundation of a major protocol to go through the community governance process, will support the Protocol’s decentralized growth, reinvigorate governance, and serve as a Protocol advocate. Team: Devin Walsh will serve as the Executive Director, Ken Ng will serve as Head of Operations, and they will build out a team of 12. Budget: To fund these efforts, we are requesting: A $14M Operating budget to cover a full team for 3 years A $60M expanded Uniswap Grants Program (UGP) budget to cover 3+ years We are requesting $74M total, which will be broken into two disbursements, with a first disbursement of $20M. Governance Participation: We are also requesting 2.5M UNI to participate in governance, primarily through delegation. Through usage of a new smart contract primitive The Franchiser 40, this UNI will be revocable by the DAO at any time, and cannot be used for any purpose outside of governance. Uniswap Foundation Mission In pursuit of a more open and fair financial system, the Uniswap Foundation supports the decentralized growth and sustainability of the Uniswap Protocol and its supporting ecosystem. Key Activities and OKRs We have listed our starting OKRs below. It’s possible these OKRs will have to change in the future. If they do change in a meaningful way, we will communicate that to the community. Growth: Promoting Decentralization & Growth of the Protocol and Ecosystem !OKR 1.png Governance: Reinvigorating the Uniswap Community Governance Process !OKR 2.png Advocacy: Advocating for the Protocol and amplifying its positive social impact !OKR 3.png Optimism Phase 0 token distribution link here 6 Year 1 Roadmap Our roadmap for the first year of operations includes but is not limited to the following activities: !Year 1.png Optimism Collective community Constitution link here Team Devin Walsh 108, Executive Director (ED) As ED, Devin will be responsible for setting UF’s strategic vision alongside the Board and driving execution to achieve that vision. Devin has been in crypto since 2016. She has conducted independent research for MIT’s Digital Currency Initiative, worked on decentralized identity at uPort (ConsenSys), and led protocol and venture investments at CoinFund. She has consulted with Edge & Node and cLabs, and led MIRA, a seed stage startup at the intersection of fine art and NFTs. She recently resigned as Chief of Staff at Uniswap Labs in order to propose the creation of the UF. Ken Ng 69, Head of Operations As Head of Operations, Ken will build and scale processes to maximize the UF’s impact. Ken has served the Uniswap ecosystem as Lead of the Uniswap Grants Program 1 for the past 1.5 years. He has helped run the Ethereum Foundation Ecosystem Support Program, which gave Hayden his initial grant 7 to build Uniswap. He served as COO of Slingshot Finance and cofounder of his nonprofit eduDAO, which helps raise funds for students and teachers in the Bronx. The needs, and thus the makeup, of our team may change over time. However, today we aim to hire for following roles, with a focus on filling the Grants and Governance roles first: !Team.png Applications are open today! Check out job descriptions here. As noted by Other Internet 4, there is also a need for new structures to “facilitate coordination across the complex web of stakeholders” within the Uniswap ecosystem. To provide this much needed coordination, the UF will be committed to working with a variety of independent parties (freelancers, development teams, research fellows, analysts, and more) to achieve many of its objectives. Advisors The Foundation’s initial advisory team will be made up of the following individuals: Jesse Walden, Founder and GP, Variant Julia Rosenberg, Co-Founder, Orca Protocol Alexis Gauba, Co-Founder, Opyn; Co-Founder, she256 Hart Lambur, Co-Founder of UMA In addition to advising UF on strategy and roadmap, this group will, alongside the Executive Director (ED) and Head of Operations, Provide input on UF’s initial hiring decisions. This may include interviewing potential candidates and sharing feedback with the Committee as it determines its first hires, including its third Board member and at least next three team members. Become temporary signers of the UF multi-sig, which will hold UF funds if and when the proposal is passed, for the sole purpose of executing approved proposals as instructed. This responsibility will be transitioned to UF team members once they are hired. Board Devin Walsh and Ken Ng will serve as the first two Board members of the UF. Alongside the UF’s Advisors, they will interview and target to hire a third Board member in the first 3 months of operations. Budget We are requesting $74M in UNI. This funding would be broken down into the following buckets: $60M for Uniswap Grants Program Grants spending will be broken down into the below categories. We will revisit and readjust these categories as needed to ensure we continue to deploy resources where they are most impactful. We are proud of the work done by UGP thus far (memorialized in this retrospective 22), and are incredibly excited to expand the scope of its work. !Grants.png We are already in the process of assessing several high impact grant proposals which UGP would be excited to fund, if and when this proposal is passed. Two examples are: A version of Uniswap v3 written in Cairo, to be deployed on Starknet A prototype of an MEV estimation tool leveraging machine learning techniques built by respected academics in the space We are also excited to continue funding ongoing work by existing grantees funded by UGP v0.1, including governance experiments and analyses from Other Internet, customer support from Serv.eth, and ETHGlobal hackathons. To ensure community alignment with larger grants disbursements, the UF will put forth an off-chain Snapshot to the community for proposed grants larger than $2M. We believe that this Grants budget will last approximately 3 years but this is subject to change depending upon the number and quality of applicants. We plan to approach the Treasury for additional Grants funds when there are ~6 months of funds remaining. $14M operating budget to build out a full team of 12 over the next two years. In order to provide stability to our employees and to sustain the Foundation, we may make a request to the community for additional funding for further out than 3 years when we return to the Treasury at 6-12 months of operations (read more below). Budget estimate looking forward three years is below. !Budget.png *Inclusive of UNI vesting. In order to incentivize a highly qualified team, the UF will offer competitive compensation packages including both fiat and long-term vesting UNI. To provide full transparency, we will disclose UF financials later this year. The UF will allocate an additional $2M in funds to cover legal fees in the case of unexpected future litigation. Fund Disbursements An approval of this proposal is an approval for the full $74M budget requested. We are requesting the funds in two disbursements: $20M now to cover operating expenses for the next 2 years and grants for 1 year. Assuming a UNI price of $7.04*, this initial request totals to 2,840,909 UNI. $54M, to be disbursed by the Uniswap Treasury in 6-12 months once the UF has completed the establishment of its legal entity. The UF will publish a post on the forum notifying the community a week prior to putting forth a formal governance proposal for the remaining funds. In other words, because this proposal approves the full amount of funding, we will not go through an additional the Temperature Check and Consensus Check steps to receive this second disbursement. *To calculate our final UNI request we will use the 30 day TWAP on the day we put forth our Governance Proposal. $7.04 is approximately the 30 day TWAP as of 8/3/2022. Governance Participation The UF is also requesting 2.5M UNI to participate in governance. These tokens will be delegated to the UF by the Uniswap DAO through a new smart contract design, The Franchiser, which ensures the tokens are only used for delegation, and allows the DAO to claw back the tokens at any time. The UF plans to use these tokens primarily for delegation to community members without the requisite 2.5M UNI to submit a governance proposal, however the UF may also self-delegate the UNI to vote, and to put up its own proposals. The Franchiser was developed by Noah Zinsmeister and was audited by Trail of Bits. Next Steps We are excited to discuss this proposal with the broader community as it passes through the Request for Comment phase. Should sentiment be positive, a Temperature Check Snapshot poll will be set up on Mon., August 8. If the Temperature Check poll passes, additional feedback will be incorporated before moving forward to the Consensus Check. Additionally, to discuss the proposal and answer your questions, we plan to attend the Uniswap Community call at 4 PM EST on Wed., August 10, and to host a Twitter Spaces on @uniswapgrants at 11 AM EST on Mon., August 15. [Read the full Proposal and Addendum here: https://gov.uniswap.org/t/temperature-check-create-the-uniswap-foundation/17358]

See governance forum for details: https://gov.uniswap.org/t/consensus-check-fee-switch-pilot/17384

See governance forum for details: https://gov.uniswap.org/t/fee-switch-design-space-next-steps/17132

Authors: Noodles + Crema + Vertex Related Discussion: Our proposal is similar to Voltz Additional Use Grant What is Rage Trade? Rage Trade is a new perpetual swap protocol built using Uniswap v3. Many on-chain perpetuals currently use Uniswap v2 style vAMMs. However, traders and LPs benefit from v3’s concentrated liquidity so we opted to build on v3 to design the most capital efficient perp. Why do we need an additional use grant? Our proposal is most similar to the proposal by Voltz Protocol. Unlike Voltz we have not forked UNI v3’s code but instead we have built on top of it. Think of Uniswap as our matching engine, and on top we have built a risk engine to enable leverage trading. We have wrapped the following on top of Uniswap’s core: leverage trading, leverage LPing, cross-margin, liquidations, and real time funding rates. What changes have we made that require additional use? We have built libraries to enable leverage trading, leverage LPing, and real-time funding rates. Each of the libraries below makes use of Uniswap’s BUSL protect code (that we require an additional grants use for): SimulateSwap: This library is used to simulate a swap on Rage. It makes use of Uniswap’s TickBitMap and SwapMath libraries. TickBitmapExtended: This library is a slightly modified version of Uniswap's TickBitmap, required in SimulateSwap for using tick data from UniswapV3Pool contract. TickExtended: This library is used to enable realtime funding payments on Rage Trade. They borrow from Tick libraries of Uniswap v3. LiquidityPosition: This library enables leverage liquidity providing (and the accompanying margin logic). It utilises the Uniswap SqrtPriceMath library to do so. ### How will approving this proposal benefit Uniswap? 1. Onchain Perps bring new liquidity to UNI v3: Since we are strictly built on top of UNI v3 (not a fork) all additional TVL + trading volume is strictly additive to UNI v3. 2. Rage Trade will spend significant R&D resources on designing efficient v3 LP strategie: Rage has already designed a new LP strategy known as the 80-20 strategy that composes with Curve’s tricrypto. 3. Liquid & composable on-chain perpetuals enable a whole new world of Uniswap spot strategies: Using perps, Uniswap v3 users can mitigate impermanent loss on Uni v3 via delta hedging. Additionally multi-collateral perps open new avenues and payoffs that are currently not possible on the spot market. Conclusion Rage Trade stands to benefit Uniswap in many ways and strictly adds to Uniswap’s value as a protocol. We look forward to discussing our proposal with the Uniswap community and answering questions in the comments below.

Summary: Enable a 1bp, 1tick fee tier on optimism (L2). The rationale and initial temperature check for this proposal can be found here: https://gov.uniswap.org/t/deploy-a-1bp-fee-tier-to-uniswapv3-on-optimism/16930 Process: The complete process is described in Uniswap’s Governance Reference here 4 and can be summarized as: • A proposal is posted in GovernorBravo on Mainnet (GovernorAlpha for Kovan) • The proposal is voted, queued and executed via Timelock. • When all the conditions are meet and is executed, Timelock contract, which is authorized to execute administrative actions on the protected contracts, will execute the requested actions in the proposal. Since this proposal needs to be executed on a different network, in this case L2 Optimism, the executing action needs to be forwarded to the proper target. In order to do that, Timelock will send the transaction to OVM_L1CrossDomainMessenger (Optimism mechanism to forward transactions from L1 to L2). The transaction will then be sent via Optimism contracts to Uniswap’s CrossChainAccount, that is the privileged contract that can execute administrative tasks on protected contracts on L2 Optimism, and CrossChainAccount will forward the transaction, if it has the right origin, to the target Contract, in this case to UniswapV3Factory. The sequence of contract interactions is the following: • GovernorBravo.propose(targets, values, signatures, calldatas, description) ◦ where targets are the address of the contracts to interact with, ◦ calldatas the calldatas to execute on those contracts, and ◦ description, the description of the proposal (or name) • OVM_L1CrossDomainMessenger.sendMessage(target, calldata, gas) ◦ where target is the address of the contracts to interact with on L2, ◦ calldata the calldata to execute on that contract, and ◦ gas, the gas to be used on that transaction • CrossChainAccount.forward(target, calldata) ◦ where target is the address of the Uniswap contracts to interact with on L2, and ◦ calldata the calldata to execute on that contract • UniswapV3Factory.enableFeeAmount(fee,tickSpacing) ◦ where fee is the fee to enable (in hundredths of a bip), and ◦ tickSpacing the spacing between ticks Compiling all the calls together it can be seen as: GovernorBravo.propose( [OVM_L1CrossDomainMessenger address], [ 0 ], [ “” ], [ encodedCalldata( OVM_L1CrossDomainMessenger.sendMessage( CrossChainAccount address, encodedCalldata(CrossChainAccount.forward( UniswapV3Factory address, encodedCalldata( UniswapV3Factory.enableFeeAmount( 100, 1 ) ) ) ), 8000000 ) ], “Enable 1bp fee tier on Optimism” ) Test network execution (Kovan) Proposer Address: 0xF526Eb7D2d4445FA8d258959A000400cca4A93f4 Addresses • GovernorAlpha (No GovernorBravo in kovan): ◦ 0x5e4be8Bc9637f0EAA1A755019e06A68ce081D58F ◦ https://kovan.etherscan.io/address/0x5e4be8bc9637f0eaa1a755019e06a68ce081d58f • OVM_L1CrossDomainMessenger: ◦ 0x4361d0F75A0186C05f971c566dC6bEa5957483fD ◦ https://kovan.etherscan.io/address/0x4361d0F75A0186C05f971c566dC6bEa5957483fD • CrossChainAccount: ◦ 0x3D7E0d4BD24F556767ccFC9c54092447BA88e926 ◦ https://kovan-optimistic.etherscan.io/address/0x3D7E0d4BD24F556767ccFC9c54092447BA88e926 • UniswapV3Factory: ◦ 0x1F98431c8aD98523631AE4a59f267346ea31F984 ◦ https://kovan-optimistic.etherscan.io/address/0x1F98431c8aD98523631AE4a59f267346ea31F984 Proposal Proposal: { targets: [ ‘0x4361d0F75A0186C05f971c566dC6bEa5957483fD’ ], values: [ ‘0’ ], signatures: [ ‘’ ], calldatas: [ ‘0x3dbb202b0000000000000000000000003d7e0d4bd24f556767ccfc9c54092447ba88e926000000000000000000000000000000000000000000000000000000000000006000000000000000000000000000000000000000000000000000000000002dc6c000000000000000000000000000000000000000000000000000000000000000c46fadcf720000000000000000000000001f98431c8ad98523631ae4a59f267346ea31f984000000000000000000000000000000000000000000000000000000000000004000000000000000000000000000000000000000000000000000000000000000448a7c195f000000000000000000000000000000000000000000000000000000000000006400000000000000000000000000000000000000000000000000000000000000010000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000’ ] } Proposal’s calldata dissection • 1st layer (OVM_L1CrossDomainMessenger) ◦ sendMessage(address,bytes,uint32) ◦ https://rimeissner.dev/transaction-decoder/#/?data=0x3dbb202b0000000000000000000000003d7e0d4bd24f556767ccfc9c54092447ba88e926000000000000000000000000000000000000000000000000000000000000006000000000000000000000000000000000000000000000000000000000002dc6c000000000000000000000000000000000000000000000000000000000000000c46fadcf720000000000000000000000001f98431c8ad98523631ae4a59f267346ea31f984000000000000000000000000000000000000000000000000000000000000004000000000000000000000000000000000000000000000000000000000000000448a7c195f000000000000000000000000000000000000000000000000000000000000006400000000000000000000000000000000000000000000000000000000000000010000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 • 2nd layer (CrossChainAccount) ◦ forward(address,bytes) ◦ https://rimeissner.dev/transaction-decoder/#/?data=0x6fadcf720000000000000000000000001f98431c8ad98523631ae4a59f267346ea31f984000000000000000000000000000000000000000000000000000000000000004000000000000000000000000000000000000000000000000000000000000000448a7c195f0000000000000000000000000000000000000000000000000000000000000064000000000000000000000000000000000000000000000000000000000000000100000000000000000000000000000000000000000000000000000000 • 3rd layer (UniswapV3Factory) ◦ enableFeeAmount(uint24,int24) ◦ https://rimeissner.dev/transaction-decoder/#/?data=0x8a7c195f00000000000000000000000000000000000000000000000000000000000000640000000000000000000000000000000000000000000000000000000000000001 Transactions • [x] Post Proposal ◦ Transaction: https://kovan.etherscan.io/tx/0x18013fbc91c6d7beff8b7d5eb576e2fb2c03d266fdaa83e47c34ec6e09fa3644 ◦ Proposal ID: 2 • [x] CastVote ◦ Transaction: https://kovan.etherscan.io/tx/0xb7f485094d778a967b61d64e78439ee6dd8d6f4704f8d3de7de7db54994e57ff • [x] Queue: ◦ Transaction: https://kovan.etherscan.io/tx/0xf24bc0902bcea7e16adfe61419177b66fb074b47497c60bf7e4dfb65c490fe17 • [x] Execute: ◦ Available since: 1655765068 (GMT: Monday, June 20, 2022 10:44:28 PM) ◦ Kovan Transaction: https://kovan.etherscan.io/tx/0xece5b14c411777a5d17c8eb0fda582785033a7ec4676af786ec2e9dfa83b76a1 ◦ Kovan-Optimism Transaction: https://kovan-optimistic.etherscan.io/tx/0x21e372a4b907461e002f38f8da59d3e2e221a50f717a2852df743a8b283c91e4 Mainnet execution Proposer Address: 0x7B3ee5816a61Fe182Fd7f89844a2BAFdD84AE5b2 Addresses • GovernorBravo: ◦ 0x408ED6354d4973f66138C91495F2f2FCbd8724C3 ◦ https://etherscan.io/address/0x408ED6354d4973f66138C91495F2f2FCbd8724C3 • OVM_L1CrossDomainMessenger: ◦ 0x25ace71c97B33Cc4729CF772ae268934F7ab5fA1 ◦ https://etherscan.io/address/0x25ace71c97B33Cc4729CF772ae268934F7ab5fA1 • CrossChainAccount: ◦ 0xa1dD330d602c32622AA270Ea73d078B803Cb3518 ◦ https://optimistic.etherscan.io/address/0xa1dd330d602c32622aa270ea73d078b803cb3518 • UniswapV3Factory: ◦ 0x1F98431c8aD98523631AE4a59f267346ea31F984 ◦ https://optimistic.etherscan.io/address/0x1F98431c8aD98523631AE4a59f267346ea31F984 Proposal Proposal: { targets: [ ‘0x25ace71c97B33Cc4729CF772ae268934F7ab5fA1’ ], values: [ ‘0’ ], signatures: [ ‘’ ], calldatas: [ ‘0x3dbb202b000000000000000000000000a1dd330d602c32622aa270ea73d078b803cb3518000000000000000000000000000000000000000000000000000000000000006000000000000000000000000000000000000000000000000000000000002dc6c000000000000000000000000000000000000000000000000000000000000000c46fadcf720000000000000000000000001f98431c8ad98523631ae4a59f267346ea31f984000000000000000000000000000000000000000000000000000000000000004000000000000000000000000000000000000000000000000000000000000000448a7c195f000000000000000000000000000000000000000000000000000000000000006400000000000000000000000000000000000000000000000000000000000000010000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000’ ] } Proposal’s calldata dissection • 1st layer (OVM_L1CrossDomainMessenger) ◦ sendMessage(address,bytes,uint32) ◦ https://rimeissner.dev/transaction-decoder/#/?data=0x3dbb202b000000000000000000000000a1dd330d602c32622aa270ea73d078b803cb3518000000000000000000000000000000000000000000000000000000000000006000000000000000000000000000000000000000000000000000000000002dc6c000000000000000000000000000000000000000000000000000000000000000c46fadcf720000000000000000000000001f98431c8ad98523631ae4a59f267346ea31f984000000000000000000000000000000000000000000000000000000000000004000000000000000000000000000000000000000000000000000000000000000448a7c195f000000000000000000000000000000000000000000000000000000000000006400000000000000000000000000000000000000000000000000000000000000010000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 • 2nd layer (CrossChainAccount) ◦ forward(address,bytes) ◦ https://rimeissner.dev/transaction-decoder/#/?data=0x6fadcf720000000000000000000000001f98431c8ad98523631ae4a59f267346ea31f984000000000000000000000000000000000000000000000000000000000000004000000000000000000000000000000000000000000000000000000000000000448a7c195f0000000000000000000000000000000000000000000000000000000000000064000000000000000000000000000000000000000000000000000000000000000100000000000000000000000000000000000000000000000000000000 • 3rd layer (UniswapV3Factory) ◦ enableFeeAmount(uint24,int24) ◦ https://rimeissner.dev/transaction-decoder/#/?data=0x8a7c195f00000000000000000000000000000000000000000000000000000000000000640000000000000000000000000000000000000000000000000000000000000001

Authors: Trent (PG Member), Tim (PG Member) Abstract This is a proposal for the Uniswap community to support important Ethereum Public Goods through the Protocol Guild: a vested split contract which goes to 110 core protocol contributors. We propose that 500k UNI (~$2.5mm @ $5.19 UNI) be allocated to support the ongoing work of these core contributors in the initial Protocol Guild Pilot. Participating in the 1 year Pilot allows guild members to engage with Uniswap in a way that is values- and incentive-aligned. Simultaneously, it will allow them to continue the important work of scaling our shared infrastructure and making it as resilient as possible for the applications on top of it. Useful links Protocol Guild Docs 1 Year Vesting Contract Initial Announcement - Dec 2021 List of Members PG twitter account Context 1. As a credibly neutral, maximally uncapturable infrastructure with no block reward, the Ethereum base protocol doesn’t offer the same token incentives to contributors as applications or L2s can. However, the protocol still needs to attract and retain talent to continue to evolve. As the broader ecosystem continues to grow, competition for talented individuals will only increase. This isn’t to fault individuals for rationally weighting financial incentives, or protocols for leveraging the power of tokens - this is just the reality of the current context. We also acknowledge that financial motivations aren’t the only or best motivator for people, it’s just one tool in our toolset that is currently underleveraged. 2. Existing public goods funding solutions tend to be either too narrow or broad in scope, fail to exclusively target core protocol contributors, or depend on an intermediating institution, which often leads to organizations, and not individuals, being recipients of funds. 3. The Protocol benefits from contributor continuity. Transferring institutional knowledge between cohorts is more likely to happen successfully the more overlap there is. Here’s a longer exploration of the project rationale. If we believe what we are building is important, then we should structure the incentives to attract more smart people to work on it. After all - “Ethereum is an unprecedented arena for playing cooperative games”; we should try to manifest the novel possibilities made possible by this arena. (Griffith, 2019) What is the Protocol Guild? The Protocol Guild aims to address the challenges mentioned above with a simple tool: a weighted split contract that includes vesting. Members will solicit sponsorships in the form of tokens from applications & protocols that build on Ethereum, which gives core contributors exposure to success at the application layer: current contributors are rewarded for past work through time-based weighting current contributors contribute for longer periods, resulting in less contributor churn, better institutional knowledge transfer, and more stable core infrastructure new contributors are incentivized to join core protocol work, protocol evolution and maintenance is more robust To date, the membership includes over 110 Ethereum protocol contributors, including researchers, client maintainers, upgrade coordinators, and more, all self-curated (member list here). This is a broad-based ecosystem effort: members come from 22 different teams and 9 organizations. Only 30% of members are directly employed by the EF. The membership is continuously curated and there are quarterly updates to the split contract. The Guild contracts will act as an autonomous value routing mechanism, operated independently from any existing institution, purpose-built for incentivizing long-term core protocol work. At no point does PG take custody of funds on behalf of members, it is all handled trustlessly. The diagram below and the docs have more information. !0xsplits horizontal.png PG Pilot Since starting the project in Nov 2021, we’ve built norms around member onboarding, refined the splitting and vesting mechanisms, and have created extensive documentation on how PG operates. At this point, we’re ready to test the mechanism’s efficacy with a 1 year / $10-20mm Pilot. We want to make sure the mechanism operates smoothly before graduating to a larger round with longer vesting periods. We are currently outreaching to 5-10 prominent Ethereum-based projects to get commitments for this important first milestone. We want to ensure there is a healthy diversity of contributing protocols both in terms of USD value as well as domain (eg. DeFi, staking, etc). The first commitment is from Lido to contribute 2,000,000 LDO, and the vote (forum post) to contribute 200k ENS will conclude in the next few days. The funds for the Pilot would be vested directly to Guild members over one year: see the Pilot vesting contract here. Note that funds would not replace salaries for core contributors, and each recipient would be making an independent decision about how to use their tokens once vested. Proposal We are inviting the Uniswap community to be part of this inaugural Pilot in the form of a 500k UNI transfer to the Protocol Guild’s vesting contract. We think this is an appropriate amount which balances between the current size of the treasury ($1.2b as of May 16, 2022), the number of beneficiaries, and the scope and intent of the Pilot. There are a few reasons why supporting the Protocol Guild benefits the Uniswap community: Uniswap’s long-term success is tightly coupled with the continued evolution and maintenance of the Ethereum protocol. These are projects that often have multi-year timelines. Contributing to the Pilot meaningfully increases the incentive to contribute to the core protocol, including: * The Merge: moving from PoW to PoS, increasing security and sustainability * EVM improvements: new functionality for developers like EOF * Statelessness: sustainable management for state growth * Supporting L2 scaling: EIP-4844, EIP-4488 * Proposer Builder Separation: reducing centralizing incentives for consensus participants * Continuous client maintenance: improving sync, exploring new database types, researching modular clients * Coordinating network upgrades: making sure the community helps to shape and is aware of network upgrades Having exposure to UNI allows protocol contributors to engage more with Uniswap governance. Members will be encouraged (but not obligated) to use the vested tokens in their respective governance framework. Uniswap should be among the protocols maximally aligned with the Public Goods of the largest ecosystem it operates in. Pilot participation maintains and expands the Uniswap community’s existing reputation for funding Public Goods. Diverse funding sources from the community further decentralizes protocol governance and prevents influence from pooling with any single entity. Next Steps If this Temp Check Snapshot vote has a positive outcome, we will move to a consensus check, and then an onchain vote.

Context After passing the Temperature Check vote with 7M UNI voting in favor of deploying Uniswap v3 on Gnosis Chain (GC), we are creating this post to move forward into the Consensus Check stage. Comments on the previous post expressed support for v3 deployment on GC, but also suggested more clarity on the following topics: The team that will be deploying Uniswap v3 on GC The bridge used to facilitate cross-chain governance for Uniswap v3 on GC The details of liquidity incentives provided, including timelines and logistics for transferring funds We have updated this post accordingly and provided more details on each of these items. About Gnosis Chain In production since 2018 (as the xDai Chain), the rebranded Gnosis Chain is rapidly evolving with a new focus and mission. Gnosis Chain (GC) provides a real-world value chain that closely mirrors the Ethereum 2.0 ecosystem. This includes a beacon chain framework, rollups, and other vital functionality. GC will serve in a front-running capacity for important Ethereum 2.0 updates. Tuned parameters on Gnosis Chain enable faster blocks and epochs, low-cost stable transactions, and the opportunity to construct trustless bridges and conduct seamless transfers between GC and the Ethereum 2.0 mainnet. Proposal The Gnosis Chain team is committed to ecosystem development, adoption, and growth as the Eth2.0 landscape comes into focus. With a mission to “accelerate Ethereum,” Gnosis Chain is poised for expansion. With this in mind, we propose a Uniswap v3 deployment to Gnosis Chain. We believe there are many benefits for both Uniswap Labs and Uniswap users, some of which include: 1. A DeFi ecosystem primed for growth. Once deployed, Uniswap would become a cornerstone DeFi engine for protocols using and interacting within the ecosystem. Perpetual Protocol is a flagship protocol on GC that relies on Uniswap v3. This deployment will enable Perpetual to continue to flourish on the Gnosis Chain. Additional bluechip app deployments with growing TVL include Curve, Sushiswap, and Tornado Cash, with many new and promising DeFi projects choosing Gnosis Chain as their home base. A list of current projects is available at https://gnosischain.world/ 2. An iterative environment. Uniswap Labs can experiment with new functionality and alpha test new features in a real-value environment (which differs from a test environment in that users behave differently with value on the line, token supply is limited, real adversaries exist, etc). Uniswap can spot and remediate any final potential issues stemming from important Ethereum updates prior to mainnet activation and take advantage of optimized slot and epoch times for faster iteration. 3. Tight Ethereum compatibility. Tools, resources, projects, and protocols supported by Ethereum are already supported on Gnosis Chain, with more onboarding regularly. Gnosis Safe is facilitating daily operations for many existing projects. A trustless bridge architecture designed to connect Ethereum and Gnosis Chain is in the works. The Gnosis Beacon Chain validator set is expanding rapidly bringing massive decentralization to the chain. The primary differences separating the GBC from the Ethereum Beacon chain include 5-second blocks and < 2-minute epochs, stable transactions with a max target of $.01 per 100K gas, and an economically and geographically diverse validator set, and a lower-stakes, lower-TVL environment. 4. Unique chain characteristics. Stable, low-cost transactions provide unique opportunities for Uniswap users. When gas costs are known and have a low impact on trade decisions, new strategies and approaches emerge which are currently untenable on the Ethereum mainnet or other chains with wide-ranging fee variability. 5. User incentives. A large directive for the Gnosis Chain is to increase the user base and on-chain activity by strategically allocating funds from the GnosisDAO treasury to promote adoption. An ecosystem fund has been created for this purpose, and we propose to use a portion of these funds to promote Uniswap v3 on Gnosis Chain. We propose providing up to $10M to incentivize the adoption of Uniswap v3 on Gnosis Chain. Details for incentivized Adoption of Uniswap v3 The $10M will be provided in GNO to foster the usage of Uniswap v3 on Gnosis Chain. The incentives should be designed together with other projects, which are operating on top of Uniswap v3 such as Perpetual Protocol, Gelato, or Stakewise. This should allow for more sustainable utilization of Uniswap as Gnosis Chain doesn’t have a team dedicated to Uniswap v3. The GNO can be used to incentivize liquidity but should not be limited to this use case. Anything increasing usage of Uniswap v3, including building new applications on top of Uniswap v3 should be supported. The goal is to spend the $10M in the time period of 2 years. Funds not used after two years would go back to GnosisDAO. The spending is limited to $10M and the transferred amount of GNO as part of the proposal. GnosisDAO can decide to top up this amount based on the outcome of this initiative. Cross-Chain Governance with Nomad Since the Temperature Check, we have discussed with stakeholders within the Uniswap ecosystem, who have expressed a desire to see trust-minimized bridges used for governance for new Uniswap v3 deployments. In addition, we’ve also seen the Nomad team’s proposal to deploy v3 on Moonbeam, which includes a section addressing this, as well as documenting the current fragmented approach to governance across various v3 deployments. In the interest of taking a standardized approach to cross-chain governance of v3 deployments moving forward, we’ve partnered with the Nomad team to leverage the Nomad generalized message passing channels to manage the governance of the Uniswap v3 deployment on Gnosis Chain. We believe that Nomad is the best solution for cross-chain governance, as it: Supports generalized messages between chains Does not rely on a multi-sig or validator set, but rather leverages an optimistic mechanism that allows bad messages to be challenged via fraud proofs Nomad will be deployed on Gnosis Chain shortly and will leverage Gnosis Zodiac Modules as part of its governance stack. We are excited about partnering with Nomad to create a trust-minimized governance stack that can offer a standard for the Uniswap ecosystem. License Exemption We are requesting an exemption that will allow Gnosis Ltd. to use the Licensed Work to deploy it on Gnosis Chain, a layer 1 blockchain with deep connections to Ethereum, provided that the deployment is subject to Ethereum layer 1 Uniswap Protocol governance and control. Timeline Following the Consensus Check phase, we will submit this proposal shortly after to an on-chain vote. Provided that the proposal passes both steps, and all governance systems have been built and audited, we will be ready to move forward with the Uniswap v3 deployment on Gnosis Chain. Proposal Acceptance and Execution As the proposal funding has to come from GnosisDAO, this proposal has to be accepted by both: UNI and GNO token holders. The execution of this proposal is dependent also on the acceptance of the proposal by GnosisDAO. The GnosisDAO proposal has to include the setup of the multi-sig and the allocation of GNO and would be executed once it is accepted by GNO token holders. Two singers from the Uniswap community and two singers from the GnosisDAO community should be selected to participate in the multisig wallet. Conclusion The Gnosis Chain is preparing for substantial growth in the coming year. We have implemented an aggressive infrastructure grants program including large grants to Nethermind, Lighthouse and Erigon client teams to support base-layer functionality and security. The ecosystem fund will bring in many new projects, and we feel Uniswap v3 is an essential component that will serve as a foundational layer for this growth. We welcome any questions and comments and are happy to provide any clarifications as needed. We are excited to submit this proposal to the Uniswap community and look forward to your feedback! Thank you.

Proposal Topic Blockchain at Berkeley is creating this proposal in partnership with Nomad to Deploy Uniswap V3 on Moonbeam. Process Update The Temperature Check for this proposal passed with 8.3M UNI voting Yes on the Snapshot. We now move to the Consensus Check phase to collect further feedback in advance of an on-chain vote. Summary In support of furthering the vision of Multichain Uniswap, we propose that the Uniswap community vote to authorize the deployment of Uniswap V3 to Moonbeam. We hope this proposal will serve as an example to create a generalizable, trust-minimized approach to cross-chain deployments, with the goal of supporting a multichain Uniswap ecosystem. Moonbeam is a Polkadot parachain which features EVM-compatibility, allowing it to serve as a port-of-entry for Ethereum-native apps to participate in the greater Polkadot ecosystem. Deploying on Moonbeam will expand the Uniswap community to include users of the Polkadot ecosystem, helping Uniswap on its journey to become a leading product in the multichain world. Moonbeam is a reputable chain which has enjoyed high stability and considerable activity since its launch in January, making it a great fit for Uniswap’s trusted brand. About Moonbeam Moonbeam is an EVM-compatible smart contract parachain of the Polkadot network; it is optimized for cross-chain use cases and natively interoperable applications. EVM compatibility and a comprehensive tool suite of integrations like Etherscan, The Graph, Chainlink, and more, allow developers to deploy existing Solidity smart contracts and apps to Moonbeam with minimal changes. Moonbeam also extends the EVM with native cross-chain integrations powered by Polkadot’s XCM, allowing Moonbeam apps to interact with assets and services from other chains in the Polkadot ecosystem in a trust-minimized way. Moonbeam was the first parachain to go live on the Polkadot network, launching on January 11 this year. Like Moonriver, its sister parachain on Kusama, Moonbeam is expected to accumulate developer and user activity from the 100+ projects building DApps and protocols on the network. Expanding Uniswap to Moonbeam We believe that the timing is perfect for Uniswap V3 to deploy on Moonbeam. Uniswap has been deployed on Ethereum, Polygon, Arbitrum, and Optimism, giving it great coverage within Ethereum and its most popular L2s. However, Uniswap has not yet expanded beyond the greater Ethereum ecosystem. Unlike the other deployment targets, Moonbeam represents a much larger target market — Polkadot users. The growth potential of the Polkadot ecosystem is reflected in part by the fact that Polkadot consistently ranks in the top ecosystems for developer activity, despite having just enabled parachains auctions in December 2021. The Polkadot community has grown in parallel with the Ethereum community, and shares many of the same values — decentralization, censorship resistance, open access to finance, to name a few. However, the two communities have largely been discrete, and deploying Uniswap on Moonbeam brings them together in a meaningful way. Moonbeam is the de facto DeFi hub for Polkadot. Blue chip DeFi projects have deployed or committed to deploying to Moonbeam, including Sushiswap, Lido, Curve, Chainlink and Covalent. As the ecosystem develops, we believe that deploying Uniswap V3 will position it to become a premier AMM on Moonbeam, and, more broadly, a large liquidity hub for the entire Polkadot ecosystem. This represents a massive opportunity to capture this untapped market, which could mean significant fee revenue for LPs and UNI token holders. The Nomad team has worked on this proposal because Nomad and Connext have already been deployed as Moonbeam’s main bridging solutions, and have begun to drive cross-chain liquidity from Ethereum into Moonbeam. By deploying Uniswap V3 on Moonbeam, Nomad would be able to route even more liquidity into Uniswap pools and additionally facilitate cross-chain communication for Uniswap governance. Trust-Minimized Bridging and Cross-Chain Governance Decentralized cross-chain governance is a topic we are excited about working on within the Uniswap ecosystem. As Uniswap Labs highlighted in their post about Multichain Uniswap, it is important that new chains have a trust-minimized arbitrary message passing solution to facilitate secure, decentralized governance of a deployment of Uniswap. The Moonbeam community already uses Nomad and Connext to bridge ERC-20 tokens from Ethereum; despite Moonbeam having only been live for two months, $35M TVL is currently bridged to Moonbeam via Nomad, with over $250M in total volume since deployment. However, Nomad is more than just a protocol for token bridging; at its core, Nomad is a protocol for trust-minimized arbitrary message passing, and Uniswap V3 deployed on Moonbeam can leverage Nomad for governance. We have worked with developers at Uniswap Labs to research, understand, and document the current state of cross-chain governance for Uniswap deployments. It became clear that, currently, cross-chain governance solutions have been patched together differently for all three of the chains that Uniswap is deployed on, leading to significant complexity and overhead for governance participants who wish to execute proposals governing deployments on other chains. This problem will multiply as Uniswap is deployed to more chains. Nomad can provide an out-of-the-box solution for this problem. Nomad’s own contracts are governed by a decentralized cross-chain governance app built on its arbitrary message passing rails. This application can be tailored for the purpose of governing Uniswap deployments on chains other than Ethereum mainnet. Rather than attempting to introduce this change on all chains at once, however, we can demonstrate the value of this solution in a de-risked manner by leveraging it first for a new deployment, Moonbeam. Rewards and Grants As part of this proposal, Nomad, via a grant from the Moonbeam Foundation, will commit $2,500,000 to the Uniswap Grants Program to help grow the Multichain Uniswap ecosystem. Through collaborative discussions with members of the Uniswap community, we learned that there were likely higher-leverage ways to enrich the Uniswap community than just providing liquidity mining rewards. As Uniswap develops into a multi-chain ecosystem, we want to support developers working to create high-quality multichain apps building on-top of Uniswap, and better multichain experiences for Uniswap users. These grants will promote long-term protocol development, developer activity and innovation towards this goal. To borrow language from the Uniswap Grants + Gitcoin announcement, we hope for this initiative to fund “bounties, hackathons, and grants” for “developers, designers, community organizers and other web3 builders” working on multi-chain projects which improve, extend, promote or build upon Unsiwap in a cross-chain manner. Examples of projects that could be funded with this grant include: Building a cross-chain application which allows Uniswap LPs to close a position on Ethereum and open one atomically on Moonbeam Improving open-source wallet softwares to create better multi-chain user experiences for Uniswap users Building a frontend application which allows governance participants to more easily construct cross-chain governance proposals for Uniswap Leveraging Substrate’s native interoperability protocol, XCM, to build an application which composes Uniswap on Moonbeam with another substrate chain Funding office hours to educate new users about multichain crypto experiences We are so excited to see what members of the Uniswap community come up with to leverage this grant! Conclusion We are excited about the possibility of the Uniswap community entering the Polkadot ecosystem via a V3 deployment on Moonbeam. To reiterate, we feel that this is a fantastic opportunity for the following reasons: Expansion into Polkadot: Uniswap will be able to tap into a brand new market and all the community members in the Polkadot ecosystem. Moonbeam’s EVM-compatibility makes it simple to deploy existing Solidity code, while simultaneously providing access to other parachains using XCM. By leveraging XCM and Moonbeam’s position as the DeFi hub for Polkadot, Uniswap has the opportunity to become the premier AMM across Polkadot. Trust-minimized Governance: Per Uniswap’s goal of becoming a multi-chain protocol while remaining trust-minimized, we propose using Nomad’s trust-minimized channels to deploy Uniswap V3 on Moonbeam. This can serve as an opportunity to test this improved decentralized governance application within a safe container, with the potential of rolling it out to other V3 deployments in the future. Rewards for Uniswap Grants Program: Instead of simply offering liquidity mining incentives, we want to fund community members working to develop and enrich multichain experiences built with Uniswap. We will commit $2.5M to the Uniswap Grants Program to fund cross-chain development deployed within the Uniswap ecosystem, in order to further expand Uniswap’s multi-chain presence. We are excited to engage with the Uniswap community and governance process to discuss more around bringing Uniswap V3 to Moonbeam. Please let us know any and all feedback and criticism, so that we can improve this proposal and expand Uniswap into Moonbeam and Polkadot!

Proposal Discussion Topic Blockchain at Berkeley is creating this proposal in partnership with Nomad to Deploy Uniswap V3 on Moonbeam. Summary In support of furthering the vision of Multichain Uniswap, we propose that the Uniswap community vote to authorize the deployment of Uniswap V3 to Moonbeam. We hope this proposal will serve as an example to create a generalizable, trust-minimized approach to cross-chain deployments, with the goal of supporting a multichain Uniswap ecosystem. Moonbeam is a Polkadot parachain which features EVM-compatibility, allowing it to serve as a port-of-entry for Ethereum-native apps to participate in the greater Polkadot ecosystem. Deploying on Moonbeam will expand the Uniswap community to include users of the Polkadot ecosystem, helping Uniswap on its journey to become a leading product in the multichain world. Moonbeam is a reputable chain which has enjoyed high stability and considerable activity since its launch in January, making it a great fit for Uniswap’s trusted brand. About Moonbeam Moonbeam is an EVM-compatible smart contract parachain of the Polkadot network; it is optimized for cross-chain use cases and natively interoperable applications. EVM compatibility and a comprehensive tool suite of integrations like Etherscan, The Graph, Chainlink, and more, allow developers to deploy existing Solidity smart contracts and apps to Moonbeam with minimal changes. Moonbeam also extends the EVM with native cross-chain integrations powered by Polkadot’s XCM, allowing Moonbeam apps to interact with assets and services from other chains in the Polkadot ecosystem in a trust-minimized way. Moonbeam was the first parachain to go live on the Polkadot network, launching on January 11 this year. Like Moonriver, its sister parachain on Kusama, Moonbeam is expected to accumulate developer and user activity from the 100+ projects building DApps and protocols on the network. Expanding Uniswap to Moonbeam We believe that the timing is perfect for Uniswap V3 to deploy on Moonbeam. Uniswap has been deployed on Ethereum, Polygon, Arbitrum, and Optimism, giving it great coverage within Ethereum and its most popular L2s. However, Uniswap has not yet expanded beyond the greater Ethereum ecosystem. Unlike the other deployment targets, Moonbeam represents a much larger target market — Polkadot users. The growth potential of the Polkadot ecosystem is reflected in part by the fact that Polkadot consistently ranks in the top ecosystems for developer activity, despite having just enabled parachains auctions in December 2021. The Polkadot community has grown in parallel with the Ethereum community, and shares many of the same values — decentralization, censorship resistance, open access to finance, to name a few. However, the two communities have largely been discrete, and deploying Uniswap on Moonbeam brings them together in a meaningful way. Moonbeam is the de facto DeFi hub for Polkadot. Blue chip DeFi projects have deployed or committed to deploying to Moonbeam, including Sushiswap, Lido, Curve, Chainlink and Covalent. As the ecosystem develops, we believe that deploying Uniswap V3 will position it to become a premier AMM on Moonbeam, and, more broadly, a large liquidity hub for the entire Polkadot ecosystem. This represents a massive opportunity to capture this untapped market, which could mean significant fee revenue for LPs and UNI token holders. The Nomad team has worked on this proposal because Nomad and Connext have already been deployed as Moonbeam’s main bridging solutions, and have begun to drive cross-chain liquidity from Ethereum into Moonbeam. By deploying Uniswap V3 on Moonbeam, Nomad would be able to route even more liquidity into Uniswap pools and additionally facilitate cross-chain communication for Uniswap governance. Trust-Minimized Bridging and Cross-Chain Governance Decentralized cross-chain governance is a topic we are excited about working on within the Uniswap ecosystem. As Uniswap Labs highlighted in their post about Multichain Uniswap, it is important that new chains have a trust-minimized arbitrary message passing solution to facilitate secure, decentralized governance of a deployment of Uniswap. The Moonbeam community already uses Nomad and Connext to bridge ERC-20 tokens from Ethereum; despite Moonbeam having only been live for two months, $35M TVL is currently bridged to Moonbeam via Nomad, with over $250M in total volume since deployment. However, Nomad is more than just a protocol for token bridging; at its core, Nomad is a protocol for trust-minimized arbitrary message passing, and Uniswap V3 deployed on Moonbeam can leverage Nomad for governance. We have worked with developers at Uniswap Labs to research, understand, and document the current state of cross-chain governance for Uniswap deployments. It became clear that, currently, cross-chain governance solutions have been patched together differently for all three of the chains that Uniswap is deployed on, leading to significant complexity and overhead for governance participants who wish to execute proposals governing deployments on other chains. This problem will multiply as Uniswap is deployed to more chains. Nomad can provide an out-of-the-box solution for this problem. Nomad’s own contracts are governed by a decentralized cross-chain governance app built on its arbitrary message passing rails. This application can be tailored for the purpose of governing Uniswap deployments on chains other than Ethereum mainnet. Rather than attempting to introduce this change on all chains at once, however, we can demonstrate the value of this solution in a de-risked manner by leveraging it first for a new deployment, Moonbeam. Rewards and Grants As part of this proposal, Nomad, via a grant from the Moonbeam Foundation, will commit $2,500,000 to the Uniswap Grants Program to help grow the Multichain Uniswap ecosystem. Through collaborative discussions with members of the Uniswap community, we learned that there were likely higher-leverage ways to enrich the Uniswap community than just providing liquidity mining rewards. As Uniswap develops into a multi-chain ecosystem, we want to support developers working to create high-quality multichain apps building on-top of Uniswap, and better multichain experiences for Uniswap users. These grants will promote long-term protocol development, developer activity and innovation towards this goal. To borrow language from the Uniswap Grants + Gitcoin announcement, we hope for this initiative to fund “bounties, hackathons, and grants” for “developers, designers, community organizers and other web3 builders” working on multi-chain projects which improve, extend, promote or build upon Unsiwap in a cross-chain manner. Examples of projects that could be funded with this grant include: Building a cross-chain application which allows Uniswap LPs to close a position on Ethereum and open one atomically on Moonbeam Improving open-source wallet softwares to create better multi-chain user experiences for Uniswap users Building a frontend application which allows governance participants to more easily construct cross-chain governance proposals for Uniswap Leveraging Substrate’s native interoperability protocol, XCM, to build an application which composes Uniswap on Moonbeam with another substrate chain Funding office hours to educate new users about multichain crypto experiences We are so excited to see what members of the Uniswap community come up with to leverage this grant! Conclusion We are excited about the possibility of the Uniswap community entering the Polkadot ecosystem via a V3 deployment on Moonbeam. To reiterate, we feel that this is a fantastic opportunity for the following reasons: Expansion into Polkadot: Uniswap will be able to tap into a brand new market and all the community members in the Polkadot ecosystem. Moonbeam’s EVM-compatibility makes it simple to deploy existing Solidity code, while simultaneously providing access to other parachains using XCM. By leveraging XCM and Moonbeam’s position as the DeFi hub for Polkadot, Uniswap has the opportunity to become the premier AMM across Polkadot. Trust-minimized Governance: Per Uniswap’s goal of becoming a multi-chain protocol while remaining trust-minimized, we propose using Nomad’s trust-minimized channels to deploy Uniswap V3 on Moonbeam. This can serve as an opportunity to test this improved decentralized governance application within a safe container, with the potential of rolling it out to other V3 deployments in the future. Rewards for Uniswap Grants Program: Instead of simply offering liquidity mining incentives, we want to fund community members working to develop and enrich multichain experiences built with Uniswap. We will commit $2.5M to the Uniswap Grants Program to fund cross-chain development deployed within the Uniswap ecosystem, in order to further expand Uniswap’s multi-chain presence. We are excited to engage with the Uniswap community and governance process to discuss more around bringing Uniswap V3 to Moonbeam. Please let us know any and all feedback and criticism, so that we can improve this proposal and expand Uniswap into Moonbeam and Polkadot!

Deploy Uni V3 to Gnosis Chain In production since 2018 (as the xDai Chain), the rebranded Gnosis Chain is rapidly evolving with a new focus and mission. Gnosis Chain (GC) provides a real-world value chain that closely mirrors the Ethereum 2.0 ecosystem. This includes a beacon chain framework, rollups, and other vital functionality. GC will serve in a front-running capacity for important Ethereum 2.0 updates, Tuned parameters on the Gnosis Chain enable faster blocks and epochs, low-cost stable transactions, and the opportunity to construct trustless bridges and conduct seamless transfers between GC and the Ethereum 2.0 mainnet. The Gnosis Chain team is committed to ecosystem development, adoption, and growth as the Eth2.0 landscape comes into focus. With a mission to “accelerate Ethereum,” Gnosis Chain is poised for expansion. With this in mind, we propose a Uniswap v3 deployment to the Gnosis Chain. We believe there are many benefits for both Uniswap Labs and Uniswap users, some of which include: 1. A DeFi ecosystem primed for growth. Once deployed, Uniswap would become a cornerstone DeFi engine for protocols using and interacting within the ecosystem. Perpetual Protocol is a flagship protocol on GC that relies on Uniswap v3. This deployment will enable Perpetual to continue to flourish on the Gnosis Chain. Additional bluechip deployments with growing TVL include Curve, Sushiswap, and Tornado, with many new and promising DeFi projects choosing Gnosis Chain as their homebase. A list of current projects is available at https://gnosischain.world/ 2. An iterative environment. Uniswap Labs can experiment with new functionality and front-run new features in a real-value environment (which differs from a test environment in that users behave differently with value on the line, token supply is limited, real adversaries exist, etc). Uniswap can spot and remediate any final potential issues stemming from important Ethereum updates prior to mainnet activation and take advantage of optimized slot and epoch times for faster iteration. 3. Tight Ethereum compatibility. Tools, resources, projects, and protocols supported by Ethereum are already supported by the Gnosis Chain, with more onboarding regularly. Gnosis Safe is facilitating daily operations for many existing projects. A trustless bridge architecture designed to connect Ethereum and Gnosis Chain is in the works. The Gnosis Beacon Chain validator set is expanding rapidly bringing massive decentralization to the chain. The primary differences separating the GBC from the Ethereum Beacon chain include 5-second blocks and < 2-minute epochs, stable transactions with a max target of $.01 per 100K gas, an economically and geographically diverse validator set, and a lower-stakes, lower-TVL environment. Unique chain characteristics. Stable, low-cost transactions provide unique opportunities for Uniswap users. When gas costs are known and have a low impact on trade decisions, new strategies and approaches emerge which are currently untenable on the Ethereum mainnet or other chains with wide-ranging fee variability. User incentives. A large directive for the Gnosis Chain is to increase the user base and on-chain activity by strategically allocating funds from the GnosisDAO treasury to promote adoption. An ecosystem fund has been created for this purpose, and we propose to use a portion of these funds to promote Uniswap v3 on Gnosis Chain. We propose providing up to $10M for a tailored liquidity mining program. The Gnosis Chain is preparing for substantial growth in the coming year. We have implemented an aggressive infrastructure grants program including large grants to Nethermind, Lighthouse and Erigon client teams to support base-layer functionality and security. The ecosystem fund will bring in many new projects, and we feel Uniswap v3 is an essential component that will serve as a foundational layer for this growth. We welcome any questions and comments and are happy to provide any clarifications as needed. We are excited to submit this proposal to the Uniswap community and look forward to your feedback! Thank you.

Summary To date, Uniswap has four deployments: Ethereum, Abritrum, Optimism, and Polygon. In addition to these deployments, there are proposals to deploy Uniswap on Harmony, Celo, and more chains expected soon. The protocol should continue to deploy to new markets, but as the protocol continues to grow, it is vital the protocol learns to manage each of the deployments. With each new chain, there is new infrastructure that needs to be adapted to so that UNI on Ethereum can govern all of these deployments. GFX Labs has been researching the various deployments and has prepared the first Uniswap cross-chain proposal to demonstrate how mainnet UNI can manage deployments on other chains. Polygon has a messaging mechanism between Ethereum and Polygon called the Fx-Portal. The portal functions via three contracts: FxRoot, State Sender, & FxChild. Messages can be sent from Ethereum to Polygon by calling the sendMessageToChild(address, bytes) at the FxRoot contract on Ethereum, which calls the State Sender contract. The validators monitor the State Sender contract and relay messages to the FxChild on Polygon. Upon successful relay to the FxChild, the message is executed on Polygon by the validators. The owner of the Uniswap v3 contracts on Polygon is the Ethereum Proxy contract. The proxy contract will only process transactions that originate from the Timelock contract on Ethereum and are delivered by the FxChild. Every governance proposal targeting a change on Polygon should set the FxRoot on Ethereum as the target and send the message (parameter change) via the contract. The message passed through the FxRoot must contain the target(s) contract on Polygon, the function(s) to call, the call data(s), similar to the proposal system. For the pilot of cross-chain governance, we are implementing the 1 basis point/1 tick fee tier on Polygon. The 1bp pools on Ethereum have been incredibly successful and increased Uniswap’s market share significantly since GFX Labs’ successful proposal in November 2021.  Because governance has already approved it on Ethereum, the content of this proposal should not be controversial and puts the focus on the research and implementation. Proposal GFX Labs has already tested the governance proposal on Goerli & Mumbai. To build the proposal–Uniswap Governor Alpha: propose() 1. Targets: [FxRoot Contract] 2. Values: [0] 3. Signatures: [“”] 4. Call data: [Call data to be processed by the FxRoot]. The data is from the sendMessageToChild(receiver (address), data (bytes)) `` _receiver (address) is the EthereumProxy contract which is the owner of the Uniswap Factory contract on Polyon. _data (bytes) is an encoded message where the abi is address[] targets, bytes[] datas, uint256[] values 1. Targets: [Uniswap Factory contract on Polygon] 2. Datas: [Uniswap Factory contract–enableFeeAmount(100,1)] 3. Values: [0] `` 5. Description: “1bp polygon test” Successful test 1. Proposal 2. Vote 3. Queue 4. Execute (Mainnet) 5. Executed (Polyon) Temperature Check Snapshot: 3/18/2022-3/21/2022 Consensus Check Snapshot: 3/21/2022-3/26/2022 Governance Proposal ETA: 3/28/2022

Summary To date, Uniswap has four deployments: Ethereum, Abritrum, Optimism, and Polygon. In addition to these deployments, there are proposals to deploy Uniswap on Harmony, Celo, and more chains expected soon. The protocol should continue to deploy to new markets, but as the protocol continues to grow, it is vital the protocol learns to manage each of the deployments. With each new chain, there is new infrastructure that needs to be adapted to so that UNI on Ethereum can govern all of these deployments. GFX Labs has been researching the various deployments and has prepared the first Uniswap cross-chain proposal to demonstrate how mainnet UNI can manage deployments on other chains. Polygon has a messaging mechanism between Ethereum and Polygon called the Fx-Portal. The portal functions via three contracts: FxRoot, State Sender, & FxChild. Messages can be sent from Ethereum to Polygon by calling the sendMessageToChild(address, bytes) at the FxRoot contract on Ethereum, which calls the State Sender contract. The validators monitor the State Sender contract and relay messages to the FxChild on Polygon. Upon successful relay to the FxChild, the message is executed on Polygon by the validators. The owner of the Uniswap v3 contracts on Polygon is the Ethereum Proxy contract. The proxy contract will only process transactions that originate from the Timelock contract on Ethereum and are delivered by the FxChild. Every governance proposal targeting a change on Polygon should set the FxRoot on Ethereum as the target and send the message (parameter change) via the contract. The message passed through the FxRoot must contain the target(s) contract on Polygon, the function(s) to call, the call data(s), similar to the proposal system. For the pilot of cross-chain governance, we are implementing the 1 basis point/1 tick fee tier on Polygon. The 1bp pools on Ethereum have been incredibly successful and increased Uniswap’s market share significantly since GFX Labs’ successful proposal in November 2021.  Because governance has already approved it on Ethereum, the content of this proposal should not be controversial and puts the focus on the research and implementation. Proposal GFX Labs has already tested the governance proposal on Goerli & Mumbai. To build the proposal–Uniswap Governor Alpha: propose() 1. Targets: [FxRoot Contract] 2. Values: [0] 3. Signatures: [“”] 4. Call data: [Call data to be processed by the FxRoot] 1. Data is from the sendMessageToChild(receiver (address), data (bytes)) _receiver (address) is the EthereumProxy contract which is the owner of the Uniswap Factory contract on Polyon. _data (bytes) is an encoded message where the abi is address[] targets, bytes[] datas, uint256[] values 1. Targets: [Uniswap Factory contract on Polygon] 2. Datas: [Uniswap Factory contract–enableFeeAmount(100,1)] 3. Values: [0] 5. Description: “1bp polygon test” Successful test 1. Proposal 2. Vote 3. Queue 4. Execute (Mainnet) 5. Executed (Polyon) Temperature Check Snapshot: 3/18/2022-3/20/2022 Consensus Check Snapshot: 3/20/2022-3/25/2022 Governance Proposal ETA: 3/28/2022