[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.
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.
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’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.
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.
[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.
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.
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’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.
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.
https://gov.uniswap.org/t/l2beat-delegate-platform/22449/12
https://gov.uniswap.org/t/l2beat-delegate-platform/22449/12
Thanks for you questions—
a) Subdomains won't expire/be abandoned. There's just a transition in tracking like Erin stated, but unlike with v3, we are implementing the tracking subdomain from the get go, before the license expires.
Thanks for you questions—
a) Subdomains won't expire/be abandoned. There's just a transition in tracking like Erin stated, but unlike with v3, we are implementing the tracking subdomain from the get go, before the license expires.
b) We try to bring deals to the DAO on an ad hoc basis, so we will of course be asking for additional capital. With v3 deals so far, we've helped chains put up RFCs on their end asking for capital, like is the case with the recent Saga and BOB proposals. It may be worthwhile to set aside a particular preset budget for these alternative chains if the community would be more comfortable with this approach.
c) There should be very clear justification regarding who gets an additional use grant. An RFP would just allow for a consolidated forum for entities to post their ask for an exemption. If someone can make a strong enough case for why they should have an exemption, they would be an ideal candidate here. Examples include a FE provider since if they do the deployment as opposed to the UF, it could make sense. But if you can't justify not having the UF deploy on your behalf, or if UF isn't willing to do so for some reason, then granting that given entity an exemption would make more sense. Of course, the final decision is made by governance, and exemptions should be minimal due to the need for an onchain vote to alter the exemption domain.
Thanks for you questions—
a) Subdomains won't expire/be abandoned. There's just a transition in tracking like Erin stated, but unlike with v3, we are implementing the tracking subdomain from the get go, before the license expires.
Thanks for you questions—
a) Subdomains won't expire/be abandoned. There's just a transition in tracking like Erin stated, but unlike with v3, we are implementing the tracking subdomain from the get go, before the license expires.
b) We try to bring deals to the DAO on an ad hoc basis, so we will of course be asking for additional capital. With v3 deals so far, we've helped chains put up RFCs on their end asking for capital, like is the case with the recent Saga and BOB proposals. It may be worthwhile to set aside a particular preset budget for these alternative chains if the community would be more comfortable with this approach.
c) There should be very clear justification regarding who gets an additional use grant. An RFP would just allow for a consolidated forum for entities to post their ask for an exemption. If someone can make a strong enough case for why they should have an exemption, they would be an ideal candidate here. Examples include a FE provider since if they do the deployment as opposed to the UF, it could make sense. But if you can't justify not having the UF deploy on your behalf, or if UF isn't willing to do so for some reason, then granting that given entity an exemption would make more sense. Of course, the final decision is made by governance, and exemptions should be minimal due to the need for an onchain vote to alter the exemption domain.
for a) we can look at v3 as an example - we had the license grant subdomain till bsl expired, then transitioned to v3deployments.uniswap.eth. Subdomains are here, the v3 license one is the wonky one because it's got ascii characters in it.
Thanks for the detailed proposal UAC. A few questions:
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.
Thanks for the detailed proposal UAC. A few questions:
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.
a. What happens to the chains registered under the subdomain v4-core-license-grants.uniswap.eth after the BSL license expires? Will the subdomain continue to live as it is or will it be abandoned?
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.
b. Based on your analysis is there need to reserve additional budget with the UAC for future (yet unlaunched) chains?
At the end of each quarter, the DAO can vote on which RFP candidates should be granted a license exemption via a Snapshot vote.
c. Will this be a competitive vote for limited number of licences or each vote that passes the regular governance parameters will get a license?
for a) we can look at v3 as an example - we had the license grant subdomain till bsl expired, then transitioned to v3deployments.uniswap.eth. Subdomains are here, the v3 license one is the wonky one because it's got ascii characters in it.
Thanks for the detailed proposal UAC. A few questions:
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.
Thanks for the detailed proposal UAC. A few questions:
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.
a. What happens to the chains registered under the subdomain v4-core-license-grants.uniswap.eth after the BSL license expires? Will the subdomain continue to live as it is or will it be abandoned?
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.
b. Based on your analysis is there need to reserve additional budget with the UAC for future (yet unlaunched) chains?
At the end of each quarter, the DAO can vote on which RFP candidates should be granted a license exemption via a Snapshot vote.
c. Will this be a competitive vote for limited number of licences or each vote that passes the regular governance parameters will get a license?
