Proposal #85
Proposal Authors: Uniswap Accountability Committee (@abdullahumar, @juanbug, @alicecorsini)
[Disclaimer - This proposal is powered by the Uniswap Accountability Committee. kpk did not receive compensation for posting this proposal.]
Uniswap DAO successfully expanded v3 to an aggregate 40 chains. It streamlined the deployment process with help from partners like Oku and Reservoir, who have set up v3 instances and user interfaces for LPs and traders. These deployments have been supplemented with incentive programs and growth initiatives, all of which have been initiated by the DAO and its target chain partners.
With Uniswap v4 having launched in February and the Business Source License (BSL) in place, the DAO has an opportunity to maximize v4’s impact using the lessons it has learned from v3 expansion. As the BSL represents a competitive advantage for Uniswap, the DAO needs to prioritize driving adoption of v4 pools and hooks over the coming months, in supplement with the programs that the UF is actively pursuing. The first step in growing Uniswap v4 across multiple chains begins with laying the operational groundwork around the BSL.
Uniswap v4’s potential is tied to its flexible hook-driven architecture, which can reshape the DEX landscape and further strengthen Uniswap’s dominance. If v4 reaches a critical mass of hooks and liquidity, it could outcompete standalone applications by integrating their features into Uniswap’s ecosystem, acting as a sink for liquidity and talent.
This also means that, as opposed to previous versions, v4’s success depends not just on the core AMM design but also on external developers building useful hooks. In this context, strong incentives for developers and liquidity providers are key to success.
Uniswap v4 presents two main challenges:
While it is less apparent with v3, v4’s success depends heavily on timing. For Uniswap to dominate across chains, adoption needs to happen quickly and broadly. For this reason, we propose to deploy v4 on as many chains as early as possible. This allows us to tackle a broader audience and enables hook developers to compete and innovate across different ecosystems rather than being limited to just one.
Hooks that gain traction on Ethereum or Arbitrum might look different from those that succeed on chains like Ink, Sonic, or Celo. Smaller or newer chains provide a testing ground for developers to experiment without directly competing with established hooks on larger networks. On the other hand, larger ecosystems provide access to a broader and more varied audience. Over time, similar hooks may emerge in different environments but appeal to their users in unique ways.
For example, Uniswap v3 often struggles to compete with native DEXs on new chains. But v4 is different—it can work as a behind-the-scenes platform, allowing native projects to build their own branded hooks on top of it. By partnering with new chains early and encouraging developers to build on v4 from the start, Uniswap has a much better chance of becoming the dominant DEX across multiple ecosystems.
To accelerate v4 adoption across as many chains as possible, we need to act promptly. DAO-affiliated groups like the Foundation, UAC, and external teams like Oku and Reservoir—if they choose to partake in v4 growth—have the opportunity to drive this initiative.
The v4 license is effectively a strategic advantage. With v3, cross-chain growth only took off after the BSL expired. This time, we should use the license to maintain a competitive edge before it eventually transitions to an open-source MIT license.
The first step is setting up a clear process for managing deployments, including a system for granting license exemptions to launch official v4 instances. Details follow.
Uniswap v4 is governed by the Business Source License (BSL) 1.1, which is a temporary source-available license that allows users to view, modify, and experiment with the code but restricts commercial use unless explicitly permitted by the licensor. Over time, BSL-covered software transitions into an open-source license, in this case, MIT, meaning that after a predetermined period, the software will be freely usable by anyone.
We see no reason to enact an early transition to MIT, but if the DAO were to decide this to be the best route, we’d have to create an onchain proposal to deploy a subdomain titled “v4-core-license-date.uniswap.eth” detailing the early conversion date. This present proposal will not be deploying the change date subdomain.
Uniswap v4’s BSL provides an essential competitive advantage by limiting unauthorized commercial use of the protocol. This creates a temporary moat in several key ways:
The BSL offers a temporary advantage, and its effectiveness will diminish over time due to the following factors:
In this proposal, we put forward:
Adopting parlance from the v3 process, we propose using the following text for v4 license exemptions:
[Entity Name] is granted an Additional Use Grant to use the Uniswap V4 Core software code (which is made available to [Entity Name] subject to the license available at** https://github.com/Uniswap/v4-core/blob/main/licenses/BUSL_LICENSE (the “Uniswap Code”)). As part of this additional use grant, [Entity Name] receives a license to use the Uniswap Code for the purposes of a full deployment of the Uniswap Protocol v4 onto the [Blockchain Name] blockchain. [Entity Name] is permitted to use subcontractors to execute this deployment. This license is conditional on [Entity Name] complying with the terms of the Business Source License 1.1, made available at** https://github.com/Uniswap/v4-core/blob/main/licenses/BUSL_LICENSE.
The above text will be utilized for one-off license exemptions. In other words, this given verbiage for the purpose of granting a deployer the permission to launch the v4 contract on a SINGULAR target chain. We expect this to be used in rare circumstances.
Additionally, we propose that the DAO reserve the ability to grant blanket exemptions to select entities in charge of deploying v4 across ANY DAO-approved EVM ecosystem.
Below is the text to be used for blanket exemptions:
[Entity Name] is granted an Additional Use Grant to allow [Entity Name] to use the Uniswap V4 Core software code (which is made available to [Entity Name] subject to the license available at <u>https://github.com/Uniswap/v4-core/blob/main/licenses/BUSL_LICENSE</u> (the “Uniswap Code”)).
As part of this additional use grant, [Entity Name] receives a limited worldwide license to use the Uniswap Code for the purposes of creating, deploying and making available aspects of the Uniswap Protocol v4 (the “AMM”); to modify and update the AMM over time; and deploy the AMM as smart contracts on blockchain-based applications and protocols.
The [Entity Name] is permitted to use subcontractors to do this work. This license is conditional on the [Entity Name] complying with the terms of the Business Source License 1.1, made available at <u>https://github.com/Uniswap/v4-core/blob/main/licenses/BUSL_LICENSE</u>.
For certain entities, blanket exemptions would optimise the process by reducing governance overhead. The selection of target chains will follow the optimistic approval process currently present with v3 deployments, thereby reducing the need for a vote. The assumption is that v4 deployments will largely be conducted by a select few entities, like the UF and potential front-end providers, not by individual organizations, so a blanket exemption is prudent.
This proposal calls for the DAO to grant its first blanket license exemption to the Uniswap Foundation so that they may be able to assist target chains with contract deployments as soon as possible.
We would also like to help teams that have worked closely with the DAO to assist with v3 deployments, in particular those who are also able to provide front-end compatibility for v4, receive license exemptions. At a later date, the UAC will create a rolling RFP forum post where front-end providers and deployers can post their proposition for attaining a license exemption from the DAO.
At the end of each quarter, the DAO can vote on which RFP candidates should be granted a license exemption via a Snapshot vote. Winners of this election process will proceed to an onchain vote, which will formally alter the text record, granting the given entity an Additional Use Grant. These onchain proposals will also bundle together any funding request that the given applicants may have posited. A future RFC will be posted outlining this process further.
The v4-core-license-grants.uniswap.eth subdomain will be owned and managed solely by the timelock address, so it may only be altered through a governance vote. The Accountability Committee will not have the authority to write to this subdomain due to the delicate legal underpinnings regarding the BSL.
In this proposal, we ask the DAO to grant the Accountability Committee management rights over the v4deployments.uniswap.eth domain, allowing for the team to update the text record once a deployment has been approved by the DAO.
To ensure transparency and consistency in the deployment of Uniswap v4, we propose to establish a dedicated ENS subdomain at v4deployments.uniswap.eth. This subdomain will serve as a canonical registry for all official v4 deployments that have been approved by the DAO. While the BSL is in effect, only deployments conducted by an entity with a license exemption—or Uniswap Labs—will be added to this registry.
By maintaining an authoritative list of official v4 deployments, this registry will provide the community, developers, and liquidity providers with a trusted source of information regarding which v4 instances are recognized and aligned with Uniswap governance. This subdomain will effectively mimic the existing v3deployments.uniswap.eth. Accordingly, as this present proposal will create the v4deployments.uniswap.eth domain, it will also grant the Accountability Committee management rights over it, allowing for the team to update the text record once a deployment has been approved by the DAO.
The text records for this domain will be formatted such that the key is the network number of the chain in question and the value is a string with the address of the bridge sender contract on mainnet associated with the deployment followed by the PoolManager address on the destination chain, and finally the owner contract of the PoolManager, each separated by a space and a comma. PoolManager.sol, the Singleton contract, will act as the replacement for the v3Factory address used for v3 text records.
For example, the v4 deployment details on Base are as follows:
Chain ID: 8453
PoolManager: 0x498581ff718922c3f8e6a244956af099b2652b2b
Sender Contract for Base: 0x866E82a600A1414e583f7F13623F1aC5d58b0Afa
Base PoolManager Owner: 0x31FAfd4889FA1269F7a13A66eE0fB458f27D72A9
ENS Subdomain Text: 0x866E82a600A1414e583f7F13623F1aC5d58b0Afa, 0x498581ff718922c3f8e6a244956af099b2652b2b, 0x31FAfd4889FA1269F7a13A66eE0fB458f27D72A9
The Event Horizon Community voted FOR on this Proposal (ehUNI-51): EventHorizon.vote/vote/uniswap/ehUNI-51
The Uniswap Foundation (“UF”) is granted an Additional Use Grant to allow the UF to use the Uniswap V4 Core software code (which is made available to the UF subject to the license available at https://github.com/Uniswap/v4-core/blob/main/licenses/BUSL_LICENSE (the “Uniswap Code”)). As part of this additional use grant, the UF receives a limited worldwide license to use the Uniswap Code for the purposes of creating, deploying and making available aspects of the Uniswap Protocol v4 (the “AMM”); to modify and update the AMM over time; and deploy the AMM as smart contracts on blockchain-based applications and protocols. The UF is permitted to use subcontractors to do this work. This license is conditional on the UF complying with the terms of the Business Source License 1.1, made available at https://github.com/Uniswap/v4-core/blob/main/licenses/BUSL_LICENSE.