I’m very excited to hear that Uniswap may sponsor new tools for Uniswap v4 via this proposal. Based on my personal experience, I think the Uniswap ecosystem benefits greatly from having more tooling options, and Oku is the best I’ve found. I use Oku’s Uniswap v3 tools multiple times per day to monitor pools, trading activity, and orderbook depth. In contrast, I feel blind on Uniswap v4: in my experience Uniswap’s official UI often errors out for me and I can hardly ever persuade it to show me correct data. That alone is enough reason for me to urge support for this proposal.
In addition, I find Oku’s bridge aggregator frequently useful, and Unichain is one of the most common chains I have been bridging to and from in recent weeks. Oku is always the first place I check when I’m bridging, so if an L2 isn’t supported by Oku yet, I have to resort to other annoying means to find a bridge to get my assets moved. Adding Unichain to Oku would be a huge plus and I’m happy to see that’s part of this proposal too.
The way I see it, Oku is a key part of what makes Uniswap so great, and has been so for years, and I encourage voters to continue to support Oku with reasonable grants such as this one.
Given that this onchain vote didn’t manage to achieve the required 40M UNI quorum threshold, despite very little opposition, maybe we should consider bringing back the functionality of email notifications for delegates to stay more informed about each proposal that goes up for an offchain or onchain vote here in Uniswap.
Something like this, that was proposed and implemented a while back, here in the Uniswap forum by Senate Labs (which shut down some time ago), and could now be done through proposals.app, which is the non-profit, open-source, and transparently run organization that was created by 2 of the co-founders of Senate Labs, @andreiv and me.
We have voted ABSTAIN on the Scaling v4 and Supporting Unichain Tally Vote. We would like to start by reiterating that we believe Oku has been a longstanding partner of the DAO, and are supportive of the strategic value they bring. This vote is incredibly important not only because it revolves around v4 tech but it is the first time a for-profit front-end has requested licensing approval from the DAO. The design of how the DAO grants, manages and approves v4 licensing sets an important precedent for any other front end providers, not just Oku, who request licensing exemptions in the future.
The current design grants Oku the ability to deploy v4 to any chain, provided they have received approval from the UAC. We are questioning whether this is the right approach long-term. In a future where multiple front ends will request and receive license exemptions, are there any long-tail risks that will be unaccounted for? Does the UAC have standing to approve/deny a license under its current structure? What happens if the UAC is dissolved in the future?
How should the DAO establish a licensing structure that prioritizes long-term alignment, growth/scaling, and risk mitigation? In our opinion, the DAO should own, manage and ultimately approve exemptions under an entity or structure that retains accountability to the DAO, whether through the UAC (if possible) or another DAO-owned entity. This entity could still contract a service provider for deployment support but would keep deployments and DAO accountability under an operational entity owned/aligned with the DAO.
Here is the design flow as we understand it under the proposed structure vs a potential revised structure
While approval flow remains similar with approvals moving through the UAC or a similar entity, there is a key difference in where the ownership of the exemption lies.
We believe this is an important discussion that should be had amongst delegates and would appreciate any thoughts/feedback from the legal specialists in the DAO.
cc: @Nistler@drllau_LexDAO
Concerns Around Proposal Structure, Transparency, and Governance
I completely agree with the concerns that have been raised by @404DAO a seperate entity is needed.
To add to this, the way the proposal is structured—and the model GFX/UAC is using—is a key reason why GFX and UAC are involved in nearly all current deployments. They are basically acting as an unofficial entity. However, while GFX benefits financially, UAC does not appear to bring any monetary value back to the DAO.
I agree; a new, independent entity that can also focus on transparency, value alignment and due diligence for any chain applying for a license. Right now, GFX is bringing license proposals to UAC with little discussion around user metrics from OKU or the true user demand on the licensed L2 chain. This process lacks clarity and accountability.
I also want to highlight a few governance issues that I find troubling:
Conflict of Interest: GFX continued to vote on its own proposal, even after concerns were raised about the clear conflict of intrest. @kfx
Lack of Public Data: GFX hasn’t made user metric data publicly available. Instead, delegates are expected to schedule one-on-one meetings just to get basic information.
Blaming Governance Apathy: When the on-chain vote failed due to low turnout, GFX publicly blamed “governance apathy” rather than acknowledging real issues with the proposal—like its lack of transparency and missing public user metrics.
Private Influence: There are concerns that some delegates who are personally close to GFX are not voting against or at all. This reluctance to vote against or challenge proposals may stem more from fear of harming relationships than from genuine support.
Lastly, I reached out to Redbelly Network, which is looking for canonical approval, but they’ve not yet answered basic questions about user data metrics and their financial arrangement with GFX. Blockchain = transparency lets not forget.
@AbdullahUmar, can you clarify what your due diligence process looks like for these canonical approvals? Also, how do these decisions align with your mission to protect the DAO’s value and the Uniswap brand—especially when so much value is going to one private company, and there are growing reputational risks tied to lesser-known chain deployments?
There are two very different worlds in which cross-chain expansions have occurred for v3: pre and post BSL.
If you look at the proposals that the DAO passed while the BSL was active, and shortly after it expired, there’s a much deeper level of critique associated with the due diligence behind them. Here are some examples:
Rootstock is a good one to explore. I recall spending a handful of months speaking with their team about their traction, tech, and thesis, eventually culminating in the above RFC. We worked with the Oku and Wormhole teams to effectively coordinate the deployment. Oku made headway during that process around deploying read-only versions of the Wormhole contracts on the target chain that made cross-chain expansion to non-L2s easier. The address 0xf5F4496219F31CDCBa6130B5402873624585615a on Ethereum Mainnet is a Wormhole message sender contract controlled by Uniswap’s V3 Timelock, used to send cross-chain messages to chains like Rootstock. The Rootstock chain has a Wormhole message receiver, configured to accept messages from this sender. This setup enables Uniswap to perform cross-chain operations securely via Wormhole. This is an example of an intricacy that Oku was able to address, ensuring that they abide by the DAO’s mandate to only use approved cross-chain messaging solutions like Wormhole and Axelar. Now, chains like Sonic, Rootstock, Saga, etc don’t want to deal with that overhead. They would much rather have a third party take care of this aspect and make sure it’s done right.
There was never an instance that the DAO voted to not go forward with a v3 deployment. That begged the question—why not just expand to as many chains as possible? This proposal around optimistic approvals for v3 expansion was approved by delegates since folks didn’t see much issue with deploying Uniswap practically everywhere. The downside of expanding to chains is far less significant than the potential upside. The downside risk is mainly around operational integrity around the deployment. The upside is going to as many chains as we can so that Uniswap has the potential to gather as much market share as it can, even if a handful of them do not succeed—a good recent example is BOB. A chain’s individual failure to gain long-term traction, imo, is not reflective of Uniswap’s ability to deliver the ability to trade assets.
So, the status quo that most all delegates have been content with is the deployment of v3 on most all chains, as long as the operational component is done properly. The key aspect here is that all of the deployed v3 contracts are done safely AND are owned by Uniswap L1 governance (via the ownership of each respective deployment’s v3 factory contract, or in the case of v4, the PoolManager).
Can other teams do this work? Yes. The main other entity that has executed on v3 expansion on L2s has been Reservoir/Protofire. They have not yet articulated a significant interest in v4 deployments.
dapdap came to the DAO a few quarters ago with a proposal to also begin hosting v3 on its front-end, but they didn’t go forward with the proposal because it wasn’t cost-effective enough. Teams have the ability to deploy the contracts and host their own FE, but practically nobody decides to because
teams prefer to outsource the onboarding of dapps so they can focus on other core operations associated with the chain
if they hire a different team to deploy a v3 fork, that v3 fork almost never wants to give up governance control of the v3 contract to UNI DAO and instead whitelabels the fork and launches a token around it (leads to competition with native DEXs)
distribution is often better for chains when a brand like Oku supports them on their FE—which for any sophisticated LP at this point is their go-to UI and is therefore conflated with the Uniswap brand
brand dilution concerns around supporting too many chains is filtered by Labs because chains on the Labs FE are more saliently associated with “Uniswap”, but that’s not necessarily the case with Oku. Most LPs and traders understand that Oku is acting as the gateway to almost any chain, thereby making their value proposition accessibility over exclusivity. This is the direction that the DAO has collectively been satisfied with
The selection of chains for v4 should be a bit different, namely, the chains with the most buy-in and explicated co-incentive amount would ideally be at the front of the line for receiving a v4 deployment. Deploying v4 is comparatively easy, especially for OP Stack chains. Making sure it does well is difficult. A team needs to bring capital and interest to the table for them to get a deployment. The UAC is currently thinking about the exact nature of this pipeline, and we will disclose the structure soon. It requires outreach to a handful of chains to see who can offer the best deals. Those who offer the most resources would ideally get pushed to the front of the line.
Next topic is whether or not we need another entity in all of this for chain approvals—
Is this not what the UAC currently does? Licensing exemptions are ONLY allowed to be granted by the DAO via an onchain vote. The approval of individual deployments conducted by an entity with a license exemptions is where the UAC comes into play, around making sure the contracts are verified, owned by the DAO, and that the target chains is connected to the right parties around incentives, etc. Is the fear here that Oku gets full authority over what gets deployed? Or whether the UAC alone has jurisdiction over what gets deployed? The real answer is that the DAO has the ability to voice what should or should not go forward—the UAC just gives a final stamp of approval on behalf of the DAO, stating that the proper checkboxes around a deployment are set. Again, we’re simply following the status quo that the DAO selected for v3 post BSL expiration. And for v4, in the licensing proposal, we outlined the intention to follow a model to prioritize chains that bring the most capital and buy-in to their v4 deployment.
I understand the sentiment behind this concern but do not think it would add a functional benefit. If we are to introduce another entity in the mix that remains in the middle of the DAO and FEs/hooks/chains, that creates unneeded redundancy. We might as well just use the UF to facilitate this process. License exemptions are primarily meant to be given to an entity that is conducting the deployments of the contracts. The UF has the ability to do that based on the v4 License exemption proposal passed last month. They can also hire subcontractors to do the work (Oku can’t based on their license verbiage; see above).
So, to reach a middle ground, I’d honestly just propose the following setup mentioned earlier in the forum thread:
In the above case, only the UF has the exemption. I’d like for the UAC to write up a clear post around v4 deployment operations soon (like this). We just haven’t done this yet since it’s been unclear where the responsibilities lie around who does the deployment, along with auxiliary concerns like a standardized package for chains requesting v4. UF is working on this, and this present grant would give Oku to also work on this.
If the main issue with this proposal failing is the license, I’d say just keep it with the Foundation.
One significant issue is the current license distribution model. However, an equally important concern is that the Uniswap Foundation (UF) allocated $1.6 million to OKU to develop a no-fee frontend intended to serve as a competitor to the Uniswap Labs frontend.
In practice, this initiative resulted in the creation of yet another privatized, for-profit frontend. Oku appears to be engaging in opaque agreements with various Layer 2 networks; arrangements that benefit OKU while excluding the DAO. Despite this, additional funding requests have been made to the DAO, even though OKU appears to be self-sustaining at this point.
Why is there no revenue-sharing model in place? If the goal of UF was truly to support a public goods frontend, why didn’t it directly launch one itself? A no-fee frontend is already available through GitHub without the need for a for-profit intermediary. Am I missing something fundamental here? Should the DAO be expected to operate as a funding source for private companies without any accountability or revenue return?
Granting UF control over licensing would at least provide them with negotiating power when engaging with entities that intend to build business models around frontend access and licensing.
Hello delegates, since proposal 88 failed to reach quorum, it will be reproposed in the coming days on our behalf by PGov. Since the abstaining voters voiced concerns around the licensing language, we will be removing that from the next proposal.
That means GFX Labs will only be able to deploy if the Uniswap Foundation gives us permission or if a future proposal introduces an amendment that allows us to do so.
Below is the text that will be used in the reproposal.
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, 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.
Updates
We have removed the Additional Use Grant language. The rest of the proposal remains the same.
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.
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.
Thank you for tagging me. Firstly let me make 2-3 points.
A party to contract require legal standing, the recognition of courts to sue and be sued. At the moment this is ambiguous because only the foundation and future treasury will have a legal tether. At best the rest is an unincorp assoc, or worse, a quasi-business partnership having benefits (though may not be monetary). It lacks the traditional ownership/governance/management boundaries and the law has a had time pinning down blame (see Ooki case). The legal risk of fault in case of tort (harm) doesn’t change, only. shuffles around. Elsewhere I’ve posted several structure that the UK consider usable in terms of digitals assets under control of a treasury but I’m awaiting outcome of a foundation grant to see what are other thoughts
Uniswap DAO doesn’t own the software, if it eventually becomes MIT license then at best it is a waiver. So without express grant from labs to … something … it would be hard to enforce any sub/re-license. As such if someone goes ahead and flouts the business delay, what can the DAO do? If you look at say Curve they’ve cunningly built the use of governance token into the protocol … but the way hooks implements it, it may be just an option.
Upon failure of clear contractual exchange of obligations, courts fall back on customary business practices. However, this is so new that arguable there has been no final concurrence on what is usual. For example if there was no express (re)license but a list of DEXs in good standing (ranked according to good practices and willing to tithe something back into a common-pool for R&D,this might be considered a co-op or trade alliance (since individual members are legal entities in own right).
So given that the entity is ambiguous, no standing (unless there’s some secret deal) to sue, and practices are still emerging, what can be done?
Decide what should be in the light (doxed) and what should preferably remain in the legal grey zone. So long as not doing anything obviously illegal, immoral or fiscally improper most regulators have bigger fish to hunt
Stand up the treasury ASAP … once there is a legal tether for the digital asset UNI token, a lot of options get reduced … so long as can relocate (xref Nexxus Mutual) then making a tentative commit is not irreversal, possibly expensive but not fatal.
Deciding on the license require unbiasedly considering the relationship with the labs … as in the case of Bankless, once the IP is yanked or impaired, entropy acelerates. Should the relationship be tighter (eg exclusive right to re/sublicense) with all the risks attached, or looser in the IP foundation is broader than a single firm.
FranklinDAO has voted against the updated proposal. We’re open to supporting the proposal with updated accountability measures that address the concerns raised by other delegates.
While there is reason to believe that additional funding would generate a positive return for the Uniswap community, GFX Labs has delivered on their previous commitments (expanding Uniswap’s chain footprint and building a front-end that a noticeable number of people actually use). The V4 ecosystem might benefit from expansion to other chains and if the Foundation isn’t prioritizing this work, DAO funding may make sense. Worth noting that the Foundation itself wasn’t interested in funding this, which validates the DAO route but also raises questions about strategic priority.
Our main reasons for voting against are that GFX has emphasized the ‘deliverables’ over measurable impact and is unwilling to share metrics that would demonstrate ROI for Uniswap. The current “Proposed Plan” shows development tasks, not market impact metrics that would demonstrate meaningful value creation for Uniswap. The transparency issues, voting on their own proposal, and lack of public usage data are problems. The number of new chains tells us little about how much value Uniswap is getting from these integrations, and while Uniswap is dominant, the real question is whether this specific funding unlocks incremental activity that wouldn’t occur through other means. Accountability and appropriate evaluation of use of previous funds requires meaningful KPIs and more granular usage and volume data.
FranklinDAO’s conditions for support: Quarterly public usage metrics: If public funds are being used, provide public accountability. We need DAUs, trading volume through Oku, TVL attributable to their interface, and adoption data by chain. Multiple delegates rightfully called out this transparency gap. One-on-one conversations with delegates behind closed doors isn’t the best way to go about things. Public metrics enable community oversight and informed decision-making on future proposals.
Governance abstention requirement: No voting on your own funding proposals. It’s common-sense. This is a clear conflict of interest violation that undermines community trust.
Clear outcome-based deliverables with deadlines: We need measurable milestones focused on incremental trading activity and user adoption that wouldn’t have occurred otherwise, to track progress and assess whether the claims of ROI in the proposal match up with what’s delivered.
(Ideally the Foundation should also provide a formal assessment of GFX Labs’ performance on their original $1.6M grant as well.)
The modified proposal (funding only, no blanket licensing) already addresses the most serious governance concerns. With proper accountability mechanisms this represents a potentially reasonable investment in needed infrastructure and new-chain expansion while establishing better standards for future DAO funding.
We’re voting in favor of this proposal because it offers a well-scoped and impactful approach to scaling Uniswap V4 while enhancing user experience across multiple chains.
Oku has already established itself as a valuable platform for liquidity providers, traders, and developers, and this upgrade will bring much-needed V4-specific tools, including analytics, routing, and liquidity management features.
The integration of Unichain, combined with the permissionless licensing framework, demonstrates a balance between flexibility and DAO oversight. The proposal outlines a reasonable budget, a clear development plan, and a rapid deployment timeline—with no upfront integration fee, which we view as a strong signal of long-term alignment.
As ITU Blockchain, we support this initiative and believe it will contribute meaningfully to the growth and accessibility of V4.
Thank you to all of the delegates who supported our proposal. The proposal was officially executed on June 8th. Unichain was quietly integrated into Oku on June 20th and formally announced on the 25th.
