Scaling V4 and Supporting Unichain

[GFXlabs]

Update - TEMP CHECK is live.

We have begun the 5 day temperature check proposal on Snapshot.

[Herees]

Concerns Regarding Proposal Transparency and Potential Conflicts of Interest

It is imperative to address several transparency concerns and potential conflicts of interest associated with this proposal.

Oku, a project operated by GFX Labs, generates revenue primarily through deployment and ongoing maintenance fees for entities seeking to integrate Uniswap v3. Oku positions itself as an expert in v3 code implementation and appears to derive the vast majority—if not the entirety—of its revenue from this model. This subscription-based structure has demonstrated significant value to Oku itself, while providing limited to no direct benefit to UNI token holders. This mirrors the value capture model historically observed with Uniswap Labs.

The proposed exclusive license exemption of Uniswap v4 for similar purposes would represent a substantial commercial advantage for Oku and GFX Labs. If this integration is indeed as valuable as it is positioned to be, then a compelling question arises: Why is the DAO being asked to fund this effort or subsidize it through grants or paying subscriptions and deployment costs, when the commercial value accrues disproportionately to Oku and GFX Labs?

Further, serious reputational concerns have been raised. Rune Christensen, a founder of MakerDAO and Sky, has publicly accused the GFX Labs delegation of participating in a coordinated governance attack on MKR token holders, allegedly with the objective of acquiring governance control through the forced liquidation of MKR holdings. Rune referred to the actors involved as “a crooked mercenary VC fund” with a track record of extracting value from DeFi protocols without equitable contribution.

In light of these allegations, several critical questions remain unanswered:

1. Who are the venture capital firms currently backing GFX Labs and Oku?

2. Is Phoenix Labs among those investors?

3. What is the source of the funding that has supported Oku beyond the $1.6 million grant provided by the Uniswap DAO?

4. Is there any ongoing or pending litigation involving GFX Labs, Oku, and MakerDAO or Sky?

Additionally, Oku’s intent to commercialize an “enterprise” version of its Uniswap v4 API, while keeping the free version closed-source, suggests further value extraction for private benefit at the expense of broader DAO alignment and open-source principles. @jengajojo

A further concern is an apparent violation of the Uniswap DAO’s stated governance principles. Specifically, the Uniswap Foundation’s published guidelines require that all conflicts of interest be disclosed and that delegates with such conflicts abstain from voting on related proposals. GFX Labs, despite having a direct financial interest in this proposal, has already voted in favor of its own Snapshot proposal. This action appears to be a clear breach of the DAO’s governance principles.

Given the above, I strongly urge all delegates to exercise heightened caution and critical judgment before casting votes in support of this proposal.

[GFXlabs]

We have been one of the longest-standing contributors to the Uniswap DAO. We have proposed and passed the most proposals, and some of the most influential proposals. Feel free to review our voting record on Tally or Snapshot. The Uniswap delegates we’ve worked with for four years know our character.

@Herees

• Who are the venture capital firms currently backing GFX Labs and Oku?
• Is Phoenix Labs among those investors?
• What is the source of the funding that has supported Oku beyond the $1.6 million grant provided by the Uniswap DAO?
• Is there any ongoing or pending litigation involving GFX Labs, Oku, and MakerDAO or Sky?

• GFX Labs has one venture capital firm investor, ChainVision, a local Chicago fund.
• No.
• GFX Labs has two primary sources of revenue today.
  1. Oku generally enters into service agreements with chains to deploy and maintain our infrastructure.
  2. GFX Labs has done software development and research work for various protocols and crypto organizations.
• No

For Uniswap delegates who want to read some context, Rekt wrote a good article summarizing the event. To not distract from the core thread, we will not answer further questions related to MakerDAO here.

[kfx]

Voted For, with rationale explained my delegate thread.

@kfx

I support this proposal primarily because I would support any proposal for an alternative frontend that has reasonable cost requirements and a competent, experienced team behind it. Having alternative frontends is important for Uniswap, as it reduces both regulatory and censorship risks. Uniswap is too important a protocol to rely on a single point of failure at the UI level. Additionally, it provides the DAO with some leverage over Labs—something sorely needed, as the DAO’s history demonstrates.

Side note on the conflict of interest involving @GFXlabs that someone mentioned (quote below). As one of the authors of the DAO Principles, I’d like to clarify how I interpret their application in this case.

@Herees

A further concern is an apparent violation of the Uniswap DAO’s stated governance principles. Specifically, the Uniswap Foundation’s published guidelines require that all conflicts of interest be disclosed and that delegates with such conflicts abstain from voting on related proposals. GFX Labs, despite having a direct financial interest in this proposal, has already voted in favor of its own Snapshot proposal. This action appears to be a clear breach of the DAO’s governance principles.

Let me be clear that this is a conflict of interest situation, and potentially falls under the guideline that “severe conflicts of interest […] must be avoided.” Ideally, GFX Labs should change their vote to “Abstain.” However, I don’t believe this alone is a reason to veto the proposal. The principles are non-binding and voluntary—a delegate may choose to disagree with them. (Though the vision is that violating the principles will make a delegate ineligible for DAO programs such as the Treasury Delegation Program.) Furthermore, to my knowledge, GFX Labs did not vote in favor of adopting the principles—perhaps anticipating situations like this—so at the very least, their position is internally consistent.

[Herees]

While competition with Uniswap Lab is needed, it must be noted that the UNI token’s only forward-looking utility lies in its role within the UVN on Unichain.

As @Doo_StableLab has highlighted, OKU intends to deploy V4 on competing L2s and charge fees—allowing GFX Labs to profit significantly. GFX was previously mandated to promote and integrate V3 due to its license expiration. V4’s license, however, remains in effect for some time.

Why should GFX be permitted to monetize early V4 access—funded by UNI holders—for private gain? A more appropriate approach would be to contract a V4-proficient developer, directing any resulting revenue above salary expenses to the treasury etc.

Moreover, GFX has selectively responded to key concerns. The current proposal values V4 blanket access at ZERO—a valuation that demands serious scrutiny.

[Gauntlet]

Gauntlet has voted against this proposal for the time being due to several outstanding concerns:

• Blanket License Designation: It’s unclear what “blanket” licensing entails in this context. The DAO has already granted license rights to the Uniswap Foundation, and it’s ambiguous whether this proposal allows Oku Trade to sub-license or enable forks of V4, including new brands, tokens, or frontends on other chains. Why can’t a one-off license for Oku’s use case be managed through the Foundation or proposed via a subcommittee process?
• Oku Trade Development Grant: We’d prefer clarification on why Oku was not supported in the latest grant cycle. This proposal seems to be downstream from the Foundation’s remit. If an application is rejected, we will still view Oku as a long-standing partner and would not necessarily rule out DAO-based funding as an alternative.
• Concerns with Expansion Strategy: As noted in previous discussions (including recent proposals from StableLab and AlphaGrowth), we remain skeptical of the efficacy of past Uniswap expansion efforts. Many expansion proposals have targeted low-quality chains, leading to administrative burden and poor capital efficiency. Without a clear shift in strategy, we currently do not support expanding blanket rights to Oku or continuing V3’s licensing precedent.

Oku Trade has proven to be a committed partner to Uniswap, but we believe some of this proposal’s high-level strategic implications for expansion require reassessment.

[GFXlabs]

@GFXlabs

Further, any deployment completed by GFX must be reviewed by the UAC to be considered official.

To expand on what we meant by this language, GFX would like the ability to deploy standard Uniswap V4 deployments, no forks, that the UAC must review before they are considered official. The DAO will have the ultimate ownership over all deployments. We have a long-standing policy of turning away chains and teams that have offered us lucrative opportunities to support forks to stay aligned with the Uniswap DAO.

[GFXlabs]

We drafted a proposal for the grant text based on past grants and the most recent proposal 85 for delegates to consider. We are happy to take feedback.

Proposed Grant Text:
GFX Labs (“GFX”) is granted an Additional Use Grant to allow GFX to use the Uniswap V4 Core software code (which is made available to GFX 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, GFX 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”); and deploy the AMM as smart contracts on public blockchain networks.

This grant does not confer rights to sublicense.

This grant does not confer rights to alter Uniswap V4 code, with the exception of adding peripheral smart contracts required to connect the new deployments to the Uniswap governance contract on Ethereum.

This grant does not confer rights to deploy Uniswap V4 without the brand name (forking).

This grant requires affirmative approval by the Uniswap Accountability Committee (UAC) prior to deployment in a production environment.

This grant requires Uniswap V4 deployments to be owned by the Uniswap DAO.

This license is conditional on GFX 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.

[Herees]

A critical condition must be added: OKU/GFX should only be permitted to launch Uniswap V4 for its own frontend on its target chains. Under no circumstances should they be allowed to charge deployment or maintenance fees to those chains. GFX is currently monetizing the distribution of the V3 license, and this proposal appears to formalize and entrench that position with the BUSL V4 license.

This proposal grants exclusive distribution rights to OKU/GFX, enabling them to profit significantly by monopolizing V4 deployments to miscellaneous L2s. It is imperative to emphasize that Uniswap should not bear deployment or maintenance costs—especially not to support a for-profit entity capitalizing on the V4 software code they did not contribute to developing.

The proposal stands in stark opposition to the principles of open-source software. It enshrines a single private actor with exclusive rights to distribute and profit from public infrastructure. If any such proposal is to be considered, it must include mechanisms to:

• Introduce competition in the monetization and distribution of the V4 license,

• Ensure a percentage of any revenue derived from such distribution is allocated back to the Uniswap DAO.

Additionally, serious questions must be raised:

• Was the Uniswap Accountability Committee (UAC) aware that GFX was profiting from the Uniswap V3 license exception, and V3 integration expertise to other chains? @AbdullahUmar

• Why did the Uniswap Foundation grant $1.6 million to a for-profit company that is generating revenue through exclusive license access/installation? @devinwalsh

If the DAO’s goal is to encourage competition with Uniswap Labs, then grants and license exceptions should be directed toward frontend teams actively building user acquisition and adoption—not companies focused on rent extraction with obscure L2s.

This proposal, if passed, risks diluting the Uniswap brand and raises serious concerns about the potential cartelization of protocol governance by private entities.

[GFXlabs]

@Herees

This proposal grants exclusive distribution rights to OKU/GFX

This proposal does not give us exclusive distribution rights.

[404DAO]

We have voted against the proposal in its current form. Specifically, we oppose the request for a blanket license exemption but we’re open to supporting funding Oku with $250k for V4 integration and $90k annually for Unichain maintenance.

The precedent set by granting a blanket “additional use” license to a private entity with independent business objectives is concerning. The original one-off license to the Uniswap Foundation made sense as it is a nonprofit entity that exists to serve the DAO and protocol’s interests. By contrast, granting Oku/GFX Labs the ability to deploy V4 to any chain introduces long-term governance and alignment risk.

While we believe Oku is a strong partner with a solid track record, this request crosses a line in terms of decentralization and control. We believe Oku/GFX should be able to work with the Foundation to utilize their blanket exemption as needed.

Development funding is reasonable but we would like to see Oku usage data

We support the funding request of $250k for V4 development and $90k annually for Unichain support. However, we echo the concerns raised by other delegates: Oku has not provided usage data for historical V3 integrations. The data available on their analytics page covers all uniswap v3 data, not Oku specific data.

Chain deployments alone don’t tell the full story. Before funding is released, we’d like to see the following metrics:

• Monthly active wallets and traders using Oku
• V3 swap volume via Oku frontend for all deployed chains
• LPs created or managed through Oku frontend
• TVL attributable to Oku’s interface

This data should be published quarterly moving forward.

Lastly, we have concerns around GFX’s decision to vote For on their own proposal. While not explicitly prohibited, proposers with a financial interest are expected to abstain. Considering the ask for a blanket v4 licensing exemption and the accompanying funding request, an Abstain vote would have signaled alignment with the Uniswap DAO.

[Herees]

The only entity competing with GFX/OKU in the distribution and deployment of the prior to license expiration V3—and potentially V4—contracts, contingent upon the approval of this proposal, is Uniswap Labs itself. No other organization has been authorized to undertake the activities currently being carried out by GFX/OKU.

That appears to be a rather exclusive position.

[AbdullahUmar]

• In order to deploy Uniswap v4 on any chain, the deploying entity must be granted a license exemption from the DAO through an onchain vote
• The DAO has the ability to grant any entity the ability to deploy v4
• A license exemption can be one-off or a blanket exemption
• One-off exemptions allow the entity requesting the license exemption the ability to deploy v4 on a new chain—but only on that given chain. This requires an RFC, snapshot, and onchain vote.
• A blanket exemption allows the entity requesting the license exemption the ability to deploy v4 on any new chain—BUT whenever that deploying entity launches v4 on a new chain, it must go through the formal governance process for declaring a new deployment “official”. This is why the final arbiter for deciding whether a deployment is official or not is the DAO.
• All v4 deployments must remain fully unaltered and owned by Uniswap governance, with no trading fees going to the deploying entity—all fees are controlled by Uni DAO (this is just the fee switch but for a new chain). The deployer is simply providing the service of deploying the v4 contracts in a secure manner—Oku so happens to provide a front-end trading venue that gives access to the backend v4 contracts. So they are effectively charging for the FE aspect, not necessarily v4 deployment aspect. Any FE can tap into the official v4 contracts once they are made official.

@AbdullahUmar

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.

Let’s break down the above quoted statement.

• Oku finds a chain that wants v4
• Oku creates a chat between the target chain, Oku, and the UAC
• The target chain posts an RFC on the forum requesting the canonicalization of their deployment
• The DAO has seven days to veto the canonicalization of the given v4 deployment on the forum by communicating any points of dissent
• If nobody has concerns about a given proposal, then the deployment is considered canonical/official—this has been the case with v3 deployments so far
• In case there is contention on the forum where delegates believe the given chain should not get the deployment, then the target chain must respond to the points of contention. If issues are still not resolved and contention about the deployment remains, the v4 deployment will not move forward without an official DAO vote as a means to resolve the dispute.

One aspect that I think is worth adding to this process is that Oku, or any deployer, isn’t able to publish any of the v4 contracts until the RFC from the chain is posted. Only after that 7-day RFC period passes can the deployment proceed. In this circumstance, Oku wouldn’t get paid for their services until the DAO approves a deployment.

@Herees

GFX is currently monetizing the distribution of the V3 license, and this proposal appears to formalize and entrench that position with the BUSL V4 license.

^Oku is not monetizing on the v3 BSL since it has expired. v3 is now under MIT, which makes it fully open source. Any entity can deploy v3. But if that entity wants their deployment to be “official” and owned by Uniswap governance, then they must consult an entity like Oku, Reservoir, or even Labs. These are trusted deployers who have shown their ability to properly execute deployments.

@Herees

Was the Uniswap Accountability Committee (UAC) aware that GFX was profiting from the Uniswap V3 license exception, and V3 integration expertise to other chains?

^Oku’s revenue comes from the front-end integration and maintenance costs associated with a deployment, not from the v3 exemption. Oku also didn’t get an exemption directly from the DAO while v3 was under the BSL. They simply provided the service of giving target chains a front-end to trade using official Uni v3 forks in the backend.

If Oku wasn’t providing these services for v3, then who would the DAO rely on for cross-chain expansion? Well, we could probably find another company providing similar services, but they would all charge for the integration and maintenance of the deployments. Some of the deployments that Oku has done have been subsidized by the DAO. Whether that’s good or bad isn’t for me to say. The DAO voted in favor of such decisions. But it doesn’t make any sense to not pay third parties for providing a trading venue for people to continue using v3. Otherwise, all these other chains would just resort to some alternative DEX. For example, if BOB didn’t work with Oku, then Uniswap would have zero presence on that chain.

@AbdullahUmar

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 difference with v4 is that not anyone can deploy it for commercial purposes. Yes, if an entity has a license exemption for v4 while it’s under the BSL umbrella, they will have a relative competitive advantage to other deployers. The thing is anyone can apply for a v4 license exemption. They just have to convince the DAO that it’s prudent for them to attain that exemption. For most companies, it’s not really a profitable endeavor to explore. Oku provides real value to users in the sense that their brand is highly conflated with Uniswap at this point. Target chains appreciate working with Oku since they’ve demonstrated competency in liaising the process between the DAO, UAC, and any other Uni-related entities.

@Herees

Why did the Uniswap Foundation grant $1.6 million to a for-profit company that is generating revenue through exclusive license access/installation?

That’s not their business model. As stated, anyone can deploy v3. For v4, yes, you need a license exemption. But a deployment only goes through if it follows the formal governance process. A blanket exemption just makes the operational overhead of cross-chain expansion less cumbersome.

Another point—companies adjacent to Uniswap should make money for the services that they’re providing. I’m not sure why Oku hasn’t been given a follow-up grant. Not my domain to comment on. Maybe it’s because they’ve figured out a revenue model where they’ve been promoted from a mere grantee to an actual business?

@Herees

• Introduce competition in the monetization and distribution of the V4 license,
• Ensure a percentage of any revenue derived from such distribution is allocated back to the Uniswap DAO.

^Anyone can apply for a v4 license exemption:

@AbdullahUmar

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.

An Alternative Path Forward

If delegates are not comfortable with granting GFX the blanket license exemption, then the alternative would be to rely more closely on UF for handling v4 deployments. In other words, UF can subcontract GFX for deploying v4 on a given chain if the RFC for deploying on that chain passes. In that case, the license exemption remains relegated to the Foundation. Or the UF can do the deployment of the v4 contracts themselves. However, this does not solve the issue of providing traders with a FE. The reason why giving Oku a blanket exemption would make sense is so that the v4 contract deployment and FE integration are bundled together operationally. But these don’t need to be combined tasks. They can be separate. Not giving Oku an exemption would simply require more coordination between UF and Oku. Again, functionally, this wouldn’t really make much difference since the DAO still has the ability to veto a deployment. In the case that UF only has the blanket exemption, Oku would still charge the target chain for integration and maintenance of the FE—unless the UF has plans of using an alternative FE provider.

[Herees]

The core issue is that the demand for the OKU front end is not driven by user interest in utilizing it across other chains. Rather, these chains are compensating OKU primarily for the access it provides to the enshrined Uniswap contracts. GFX can demonstrate its value to users and liquidity providers by providing actual analytics—something it has not addressed in its communications with other stakeholders.

You are correct that similar fees might be charged by other deployers or distributors. However, the fees associated with OKU are higher because it operates for profit. This raises the question: why shouldn’t these Layer 2 networks engage directly with the Uniswap Foundation and pay fees for deployment directly to them? At least in that case, the DAO would directly benefit from the associated revenue.

As always, if you want to understand the outcomes, look to the incentives that drive them.

[Avantgarde]

Thanks to GFX Labs for putting this proposal forward. We really appreciate the work your team has already done for Uniswap in successfully expanding our reach across many chains, and believe Oku has proven to be a valuable piece of infrastructure for the ecosystem.

We’re generally supportive of what this proposal aims to achieve. Getting Uniswap V4 scaled up quickly and making sure there are good tools available from the get-go is important for its success and for keeping Uniswap at the forefront. Likewise, we do see the benefits of allowing GFX lead V4 rollouts from a streamlining perspective, and the requested funding appears fair for the amount of work involved.

We do agree that it would be nice to see some additional activity data beyond mere deployments, and also think other delegates have raised valid points with regards to “excessive” profiteering. We very much appreciate the added context from @AbdullahUmar which does provide reassurances. For now, we’ll support this proposal in the temp check but want to emphasise that the details around these concerns need to be hashed out and necessary assurances included in writing to avoid having to rely on “trust me bro” before we can fully support this proposal at the onchain vote.

[ilia_0x]

Dear Uniswap Community and Delegates,

I’m writing as an active Uniswap user, liquidity provider, and perhaps most relevantly here, a developer actively building AI solutions and protocols leveraging the power of Uniswap V4. I want to express my strong support for the GFX Labs proposal and offer a perspective focused on the practical needs of builders within this ecosystem.

The Uniswap DAO’s core strategic objective, as I understand it, is to maximize the adoption, reach, and utility of the Uniswap protocol. With V4, this means aggressively expanding its presence across diverse EVM chains and fostering a vibrant ecosystem around its unique hook architecture. This goal cannot be achieved in a vacuum; it requires robust, accessible, and reliable infrastructure.

This is precisely where GFX Labs and Oku have proven invaluable. Their track record in expanding V3’s reach to over 30 chains, often facilitated by initial DAO support, is undeniable. They haven’t just deployed contracts; they’ve provided a functional, multi-chain interface and tooling that serves real users.

Now, as we look to V4, the infrastructural needs are even more critical. The success of V4 hinges not just on the core protocol, but on:

1. Advanced Analytics: Understanding pool performance, hook interactions, and LP strategies is vital.
2. Reliable Data APIs: These are the bedrock for third-party integrations, enabling everything from custom dashboards to sophisticated DeFi strategies.
3. Efficient Indexing: Fast, accurate, and publicly accessible indexed data is non-negotiable for building scalable retail and institutional products on top of V4.
4. Hook Discovery & Support: A thriving hook ecosystem requires platforms where developers can showcase their innovations and LPs/traders can easily discover and utilize them.

Frankly, no other entity has demonstrated a greater capacity or commitment to building this specific V4-focused infrastructure, in alignment with the DAO, than GFX Labs/Oku. Their proposal directly addresses these critical needs – V4 liquidity management tools, pool analytics, a dedicated V4 data API, and hook discovery mechanisms.

It’s also important to contextualize this within the broader ecosystem. While the official Uniswap front-end exists, it’s operated by a private, commercial entity (Uniswap Labs). Its priorities and value accrual mechanisms are naturally aligned with its shareholders, which may not always perfectly overlap with the broader, decentralized goals of the DAO and its token holders. Oku, particularly when operating with DAO mandates and funding, offers a crucial, complementary, and potentially more DAO-aligned pathway for protocol interaction and expansion, especially onto chains the primary interface may not prioritize.

For developers like myself and teams working on bringing V4’s power to a wider audience, the public availability of robust indexing and analytical APIs, as proposed by GFX, is absolutely critical. This infrastructure is the key that unlocks the next wave of innovation – enabling us to build user-friendly applications, integrate V4 into institutional workflows, and ultimately drive significant volume and value back to the Uniswap protocol.

Now, regarding the valid concerns raised by fellow delegates:

• Funding Source (DAO vs. UF): While procedural consistency is important, the urgency of building foundational V4 infrastructure cannot be overstated. Given that the license grant component requires a DAO vote regardless, consolidating the funding request here seems pragmatic. This should be viewed as a strategic investment by the DAO into enabling its own V4 ecosystem.
• Blanket License: This is understandably a point of caution. However, a purely one-off process risks significantly slowing down V4 adoption, which goes against our strategic goals. A conditional blanket license, as GFX seems amenable to (requiring UAC review, DAO ownership, no forking), strikes a good balance. To further strengthen DAO oversight and address concerns, we should mandate regular, public reporting of Oku-specific usage metrics (volume, users, TVL influence per chain) as a condition of the license. This provides efficiency while ensuring accountability and demonstrating ROI.
• Value Capture/Business Model: Oku charging chains for deployment and maintenance isn’t necessarily “rent-seeking” on the license itself (especially the clarified V4 terms). It’s compensation for the significant development, integration, and ongoing operational work required to provide a functional front-end and reliable infrastructure in new ecosystems – a service that directly benefits the DAO by expanding Uniswap’s footprint. This expansion might not happen otherwise. Ensuring Oku is sustainable allows them to continue providing this value. The mandated transparency via data reporting (mentioned above) is the mechanism to ensure the DAO receives commensurate value for its grants and permissions.
• Transparency/Data: I fully agree with calls for more granular, Oku-specific data. This should be a non-negotiable requirement tied to both the funding and the license grant. Let’s empower our partners, but verify the impact.

Proposed Path Forward:

1. Approve the funding ($250k + $90k/year) as a strategic investment in essential V4 infrastructure.
2. Grant the Additional Use Grant (License) but make it conditional on:
   • Adherence to the strict terms outlined by GFX (UAC review before official status, DAO ownership, standard V4 code, etc.).
   • Mandatory, regular (e.g., quarterly) public reporting of Oku-specific V4 usage metrics across all supported chains.

This approach empowers a proven partner to accelerate critical V4 adoption while embedding strong mechanisms for DAO oversight and accountability.

Finally, speaking as a builder, we need the infrastructure outlined in this proposal. The developer community is eager to build on V4, and we are ready to collaborate with Oku to help shape and utilize these tools, ensuring they drive real utility, liquidity, and innovative products for the entire Uniswap ecosystem. Let’s equip our key partners for success, with the right checks and balances in place.

Thank you for your consideration.

Best regards,
ilia.eth

[kaereste]

The following reflects the views of L2BEAT’s governance team, composed of @krst, @Sinkas, and @Manugotsuka, and it’s based on their combined research, fact-checking, and ideation.

We are voting FOR this proposal in the temperature check.

We appreciate the efforts of GFX Labs in spearheading the deployment of Uniswap on various chains. We believe that having third parties build businesses around official Uniswap deployments is a net positive for the Uniswap ecosystem in general. @AbdullahUmar detailed explanation of the process, along with GFX Labs’ clarification of the licensing terms, alleviated most of our concerns regarding the blanket license approval. However, we would like to support the request for more usage data regarding the Oku frontend.

[blockchainedu]

We’ve carefully reviewed the discussion on this forum and spoke with several fellow delegates and the Uniswap Foundation.

We want to be clear: we continue to support the strategic intent of this proposal. Integrating v4 into Oku and deploying v4 across more chains is directionally correct. Reducing friction for hook experimentation and liquidity deployment is essential for Uniswap’s long-term growth.

@AbdullahUmar

But it doesn’t make any sense to not pay third parties for providing a trading venue for people to continue using v3. Otherwise, all these other chains would just resort to some alternative DEX. For example, if BOB didn’t work with Oku, then Uniswap would have zero presence on that chain.

Some may assume the BSL license is sufficient to protect Uniswap’s v4 moat. But competitors are already building mechanics similar to v4 and hooks. The real solution lies in capturing market share through deployments vetted by the UAC on BD-aligned chains.

To that end, Oku should provide more data on the past v3 deployments and TVL accrued through its infrastructure. This is now more important than ever, given @alphagrowth’s role to coordinate deeper chain-side incentives.

However, like other delegates, we must flag the licensing ambiguity in the current Snapshot proposal. It has caused conflicting interpretations.

@GFXlabs

This grant does not confer rights to sublicense.

This grant does not confer rights to alter Uniswap V4 code, with the exception of adding peripheral smart contracts required to connect the new deployments to the Uniswap governance contract on Ethereum.

This grant does not confer rights to deploy Uniswap V4 without the brand name (forking).

This grant requires affirmative approval by the Uniswap Accountability Committee (UAC) prior to deployment in a production environment.

This grant requires Uniswap V4 deployments to be owned by the Uniswap DAO.

We appreciate GFX’s clarifications in the forum. However, if the future on-chain version doesn’t reflect these constraints, we will be voting “NO”. The ability to fork or misrepresent v4 deployments would be detrimental for Uniswap and the v4 growth strategy.

@kfx

However, I don’t believe this alone is a reason to veto the proposal. The principles are non-binding and voluntary—a delegate may choose to disagree with them. (Though the vision is that violating the principles will make a delegate ineligible for DAO programs such as the Treasury Delegation Program.)

Moreover, while the DAO principles are technically voluntary, adhering to them reflects the strength of our governance culture. We strongly encourage GFX Labs, as a long-standing delegate and contributor, to voluntarily abstain from voting on such a proposal that offers them a direct financial benefit.

[tid_research]

Hey folks, I’m gonna vote no on this one, even though I really like the idea of pushing Uniswap V4 further. The blanket license thing just feels off—it puts a lot of power in GFX Labs’ hands, and since they’re a for-profit company, I’m not sure they’ll prioritize theDIY: The proposal asks for $340,000 ($250,000 for V4 integration, $90,000 for Unichain maintenance), but doesn’t offer any direct financial return to the DAO. Maybe a revenue-sharing deal where some of Oku’s V4 profits go back to the treasury could make it fairer.

Having some kind of independent group, like a rotating delegate team, to keep an eye on things would make me feel better. Skipping the Uniswap Foundation also seems like a weird choice—they’re set up to handle this kind of coordination and could bring a neutral perspective, maybe even working with GFX Labs or other devs.

Plus, the proposal’s super focused on backend stuff like analytics and APIs, but I think it’s light on user-friendly features. Oku’s UI already gets some flak for being tricky to use, and without a clear plan to make V4’s hooks or interface more welcoming for regular traders, I worry we might lose ground to centralized exchanges or other DeFi platforms. I love the vision, but I think we need to tweak this to better fit the DAO’s long-term goals.

[GFXlabs]

Scaling V4 and Supporting Unichain

GFX Labs proposes that the Uniswap DAO allocate funding to support the integration of Uniswap V4 on Ethereum in Oku, grant GFX Labs a blanket license exemption for future V4 deployments, and to add support for Unichain on Oku. This initiative aims to enhance Uniswap’s reach, encourage liquidity migration to V4, and solidify the protocol’s position as the leading decentralized exchange.

EDITs/Updates

• We have updated the Additional Use Grant language. Scroll down to read more.
• We will be hosting office hours for delegates who would like to understand Oku’s current swap volume, users, and other internal metrics on Friday, the 9th, at 12:30 Central Time. If you would like to attend, send Getty a DM on Telegram, and he will send you a meeting invite. Anyone unable to attend at that time, we are happy to schedule a 1:1. In the meantime, feel free to browse Oku’s Uniswap V3 Analytics or to view the various Uniswap V3 deployments we have completed on DeFiLlama.
• The plan is to post the onchain proposal on Friday, so voting will begin on Monday.
• We will be on Tuesday’s community call to discuss the proposal further.

Background

In 2022, GFX Labs was granted $1.6M from the Uniswap DAO to scale the Uniswap ecosystem and expand the protocol’s presence across EVM chains. Today, Oku is live across 30+ chains, and we have expanded our services to offer best-in-class bridge and trade aggregation. With a dedicated interface for V3 pool analytics and a simplified LP management interface, Oku has served as a consistent and scalable growth channel for the wider Uniswap ecosystem.

We’ve deployed to a wide range of chains at our own expense – far exceeding the original scope of the grant – and have generated a high ROI by accelerating Uniswap adoption across new environments. Now, with the advent of Uniswap V4, it’s time to build the next generation of tooling for the next wave of liquidity.

Scale V4 and Add Unichain Support

Since the launch of Uniswap V4 in January 2025, we’ve seen a surge in interest from users, partners, and hook developers eager to experiment with the new protocol’s capabilities. As one of the most active contributors to the Uniswap ecosystem infrastructure, GFX Labs views this momentum as a timely opportunity to scale V4 usage, reduce friction for LP’ing, and host an environment for hook developers to showcase their innovative pool adaptations. As we have provided for V3, GFX Labs will develop a dedicated V4 analytics interface to support hooked pool discovery and performance tracking.

Who benefits?

The Uniswap DAO’s ability to expand V4’s reach heavily depends on ecosystem builders and infrastructure. That is why supporting the flywheel between hook builders, liquidity migrators/providers, and traders is crucial. With V4’s flexibility also comes complexity. It is key that each stakeholder’s user experience and needs are addressed and iterated upon so V4 can become the dominant DEX protocol. Oku will fill the gaps and support ecosystem players as a base layer user interface for developers, LPs, traders, and chains. EVM chains with V4 enabled will have separate interfaces to distinguish between hooked and vanilla pools.

Hook Devs: Hook developers thrive when LP’ing is made easy, unlocking exposure to their unique market architecture

LPs: Intuitive position management tools and highlighted yield farming opportunities for V4 pools

Traders: Option to include V4 “hooked” pools for unique trading strategies & best execution

DAO: Expand V4 footprint across all chains and highlight market opportunities for unique market structures

Proposed Plan

V4 Development Scope

• V4 Liquidity management
• Pool analytics with historical performance data
• Oku V4 data API for anyone building in the Uniswap ecosystem
• Hook pool discovery via V4 analytics dashboard
• Routing support for V4 traders

For the one-time integration and build-out of V4 on Ethereum Mainnet into Oku, we are requesting a total of $250K. The Uniswap DAO could expect delivery within two months of the proposal passing. Post launch, Oku will continue to improve the V4 interface and iterate based on feedback.

• Backend infrastructure: $150,000. This would primarily focus on indexing the V4 protocol, adding a routing setup for V4 markets, and updating our peripheral systems to support V4.
• Frontend development: $100,000. There are two phases here. The first would be designing new UI elements for pool creation, V4 LPing, V4 analytics, V4 trading, and any other UI updates necessary to support V3 and V4 in the same interface. The second phase is implementing the design improvements.

Unichain Deployment on Oku

• Within two weeks of this proposal passing, Unichain and the V3 deployment will be available in Oku. Unichain users will have access to a full suite of Oku features, including a smart routing system integrated into 10 trade routers and 11 bridges.
• As soon as we have the minimum viable backend and frontend support for V4, we will integrate the Unichain V4 deployment.

Given our long-standing relationship with the DAO and our concurrent request for the initial V4 integration, GFX Labs will waive the standard integration fee for integrating Unichain with Oku. Recognizing the benefit of a synergistic V3/V4 offering, instead we are requesting $90k - $7.5k per month - to cover operational and maintenance related costs. This cost structure is representative of preferential pricing for the Uniswap DAO.

Permissionless Licensing Agreement

GFX Labs is requesting an Additional Use Grant, which provides licensing permissions for V4 deployments to streamline the process of bringing V4 to new chains. As an established partner of the Uniswap ecosystem, this process maximizes the DAO’s ability to scale efficiently, support hook innovation, and increase V4 pool dominance across EVM.

Granting GFX a license is an operational improvement. Rather than requiring each chain to go through a four-week governance process, our team can work closely with the UAC to ensure new deployments can happen quickly without eroding the DAO’s priorities.

Delegates will likely notice that this process closely aligns with the current process for deploying Uniswap V3 on new chains.

Further, before our team deploys Uniswap V4, the UAC must have approved it. GFX will only deploy the standard V4 contracts, and all deployments must be owned by UNI token holders. GFX will have no right to deploy V4 independently without the UAC’s approval.

Below is the Additional Use Grant text proposed by the UF and their GC.

GFX Labs (“GFX”) is granted an Additional Limited Use Grant to allow GFX to use the Uniswap V4 Core software code (which is made available to GFX subject to the license available at https://github.com/Uniswap/v4-core/blob/main/licenses/BUSL_LICENSE (the “Uniswap Code”)) subject to the below limitations.

As part of this additional use grant, GFX 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”); and deploy the AMM as smart contracts on public blockchain networks.

This grant does not confer rights to sublicense, and GFX may not assign such rights (in whole or in part) to any third party, including in connection with any merger, consolidation, reorganization, change of control, spin out, or sale of all, or substantially all, of GFX’s assets or business.

This grant does not confer any rights to modify or alter the Uniswap Code.

This grant does not confer rights to deploy Uniswap V4 without the brand name (forking).

This grant requires affirmative approval by the Uniswap Accountability Committee (UAC) prior to deployment in a production environment.

This grant requires Uniswap V4 deployments to be owned by the Uniswap DAO.
This license is conditional on GFX 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.

With a new emphasis on V4 infrastructure, Oku further aligns itself as a standard bearer for the Uniswap ecosystem, with a focus on expanding utility and interoperability across EVM environments. By funding this proposal, the DAO positions itself to scale V4 usage, promote novel onchain markets, and support unique market innovation from the ground up.