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.