Establish Uniswap v4 Licensing Process
Proposal Authors: Uniswap Accountability Committee (@abdullahumar, @juanbug, @alicecorsini)
Summary
- Create the v4-core-license-grants.uniswap.eth subdomain to track BSL license exemptions
- Grant Uniswap Foundation a blanket license exemption to deploy v4 on target chains
- Create v4deployments.uniswap.eth subdomain to create an onchain registry of official v4 deployments
- Grant the UAC permission to write to the v4deployments.uniswap.eth subdomain
- Populate the text records of v4deployments.uniswap.eth with the 13 existing v4 deployments done by Uniswap Labs
Background
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.
Growing Uniswap v4
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:
- Attracting enough liquidity. Traders will only use v4 if its pools offer the best prices, which requires deep liquidity. This means convincing LPs to migrate funds from v3 and other DEXs.
- Offering compelling hooks. Without compelling hooks, users have little reason to switch to v4. As more developers build innovative hooks, v4 becomes increasingly attractive, creating a cycle of growth that solidifies Uniswap’s dominance. As per the below figure, the current trend in hook launches largely favors vanilla pools as opposed to “hooked” pools. It will take a concerted growth effort from the DAO and associated entities to help facilitate creative hook deployments and growth.
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.
Accelerating v4 Adoption
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.
On the Business Source License
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.
- Commercial Use Restriction: Uniswap v4 cannot be used for commercial deployments unless a special exemption (called an Additional Use Grant) is granted.
- Change Date: The license is set to expire by June 15, 2027, or earlier if the Uniswap DAO decides to transition it sooner.
- Automatic Transition to MIT: After the expiration date, the Uniswap v4 Core will become fully open-source under an MIT License, meaning anyone can freely use, modify, and deploy it.
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.
How the BSL Strengthens Uniswap’s Moat
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:
-
Prevention of Immediate Forks: The BSL prevents competitors from launching unauthorized forks of v4, ensuring that Uniswap maintains exclusivity over its novel hook architecture for a defined period of time.
-
Ecosystem Incentive Opportunities: The licensing framework allows Uniswap to selectively grant exemptions to chains that align with its strategic goals, potentially in exchange for incentives. The UF was granted an incentive budget for v4 deployments in proposal 82. That budget will not cover incentives on all chains where v4 will be deployed. There will be opportunities to negotiate with chains to contribute to incentive budgets for a v4 deployment. The UAC and UF will work together to negotiate those opportunities. Negotiations are more likely to be fruitful during the first year of v4 going live.
-
Encouraging Ecosystem Buy-in: Since third-party deployers need a license exemption, chains and DeFi projects are incentivized to engage with Uniswap governance rather than creating unauthorized alternatives. Granting license exemptions to a variety of deployers requires an onchain vote for each individual Additional Use Grant, so we recommend using a smaller group of authorized entities that will deploy on a given chain, starting with the UF.
Erosion of the Moat Over Time
The BSL offers a temporary advantage, and its effectiveness will diminish over time due to the following factors:
-
Expiration of the BSL: The BSL is set to expire by June 15, 2027. This means that competitors will be able to freely fork and deploy v4 without restrictions in just a few years.
-
Replication by Competitors: Even before expiration, competitors may develop alternative DEX architectures with similar capabilities, reducing Uniswap’s technical lead. This happened very quickly with the concentrated liquidity benefits ushered by v3.
-
Gradual Loss of Novelty: As hooks become more widely understood and replicated, their competitive differentiation will weaken, and the perceptual novelty will wane. Other protocols may introduce comparable or even improved features to rival v4’s architecture, and developers may not hold v4’s customizability as unique as it may have initially seemed.
Granting License Exemptions
In this proposal, we put forward:
1. The creation of the v4-core-license-grants.uniswap.eth subdomain.
2. A request to provide the Uniswap Foundation with a blanket Additional Use Grant to deploy v4 across any DAO-selected chains.
Single Chain Exemptions
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.
Blanket Exemptions
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
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 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 https://github.com/Uniswap/v4-core/blob/main/licenses/BUSL_LICENSE.
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 associated with respective target chains, so a blanket exemption is prudent.
Above is a list of entities that were granted v3 exemptions. This list will likely be much smaller for v4.
Initial Set of Exemptions
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.
Management of License Exemption Subdomain
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.
Tracking Official v4 Deployments
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:
| Contract Name | Contract Address |
|---|---|
| PoolManager | 0x498581ff718922c3f8e6a244956af099b2652b2b |
| PositionDescriptor | 0x25d093633990dc94bedeed76c8f3cdaa75f3e7d5 |
| PositionManager | 0x7c5f5a4bbd8fd63184577525326123b519429bdc |
| Quoter | 0x0d5e0f971ed27fbff6c2837bf31316121532048d |
| StateView | 0xa3c0c9b65bad0b08107aa264b0f3db444b867a71 |
| Universal Router | 0x6ff5693b99212da76ad316178a184ab56d299b43 |
ChainID:
8453
Base Sender Contract:
0x866E82a600A1414e583f7F13623F1aC5d58b0Afa
Base PoolManager Owner:
0x31FAfd4889FA1269F7a13A66eE0fB458f27D72A9
ENS Subdomain Text:
0x866E82a600A1414e583f7F13623F1aC5d58b0Afa,
0x498581ff718922c3f8e6a244956af099b2652b2b,
0x31FAfd4889FA1269F7a13A66eE0fB458f27D72A9
Coming Soon: Uni v4 Expansion Process
This proposal is part one in driving v4 growth. A second proposal will be posted on the forum in the coming months detailing the process behind onboarding new chains. We are collaborating with the Uniswap Foundation to ensure that enough of the railways are first set for ensuring the seamless and effective launch of v4 on various chains. If the launch of v4 on a chain is conducted nonchalantly, the target chain will quickly lose interest in collaborating with Uniswap in ensuring sustenance of the v4 ecosystem. As mentioned before, versus v3, there is much more buy-in required from chains for v4 to succeed.
Complexities around going to market with v4 include
- having a library of initial hooks for users to interact with on day one
- onboarding hook developers to go beyond the mere deployment of vanilla pools
- employing the proper front ends to accommodate for various hooks or an “official” page for users to interact with vanilla pools right away
- incorporating routing algorithms because hooks and aspects like dynamic fees create diverse, customizable pools with unpredictable behaviors, requiring routers to evaluate many more paths and conditions
Negotiations with chains around v4 adoption, which will likely affect a chain’s spot in line for receiving a v4 deployment, will be conducted as a collaborative effort between the UAC and UF. We are coordinating with partners like Merkl and other incentive distributors to ensure their infrastructure is ready to handle v4’s complexities.