404 DAO Delegate Platform

[404DAO]

[TEMP CHECK] Scaling V4 and Supporting Unichain - Snapshot

Our voting rationale for the GFX/Oku Scaling V4 Proposal Snapshot can be found in the forum thread:

@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.

[404DAO]

Scaling v4 and Supporting Unichain - Tally

@404DAO

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

Scaled Version of Current Proposed Implementation

DAO-Owned Implementation

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

[404DAO]

Uniswap Accountability Committee S4 Elections

We ABSTAINED from the UAC vote by equally voting for all candidates. Since Cole was running for the UAC we felt an abstain vote was most appropriate.

[404DAO]

Scaling V4 and Supporting Unichain

We voted FOR the updated Oku proposal to scale Uniswap v4 and advance Unichain after the grant-licensing clause was removed. We appreciate GFX’s responsiveness in revising the proposal and remain committed to Oku’s continued development. To guide any future funding decisions, we would like to see regular metrics reports —or something comparable— so that the DAO can track impact and allocate resources based on clear data.

[404DAO]

Trial run a Technical Advisory Board (TAB)

We voted AGAINST the Trial Advisory Board proposal. While we support efforts to unpack complex technical topics and deepen delegates’ technical understanding of proposals, this proposal introduces an overly prescriptive and costly structure to address a problem that currently lacks urgency. Technical proposals represent a small share of governance activity today, and introducing a new board —specifically one that is preselected— feels premature. We’d prefer to see more organic demand for technical review emerge before committing to additional operational overhead.

[404DAO]

Uniswap Unichain - USDS and sUSDS Co-Incentives Growth Management Plan

@404DAO

404 voted FOR the USDS/sUSDS co-incentive Snapshot proposal. Given the need to accelerate adoption of Unichain and our belief that Sky is well-positioned to support that growth, we are generally supportive at this stage. However, we believe the proposal requires additional clarity before advancing to a Tally vote.

Specifically, the current incentive structure lacks detail around how rewards will be allocated, leaving too much uncertainty. For instance, if incentives are used to boost sUSDS yield, then net of operating costs, the structure guarantees a minimum 4% APR on the first $20M in TVL on top of sUSDS base yields. This yield declines to 3.2% for the first $50M and 2.4% for first $100M in TVL. We would like to see more explicit modeling and documentation on how these rewards would be distributed under various scenarios.

Additionally, we do not believe governance should be asked to vote on incentive allocations on a monthly basis. Delegates often lack the resources and bandwidth to oversee and manage dynamic incentive programs effectively. We would prefer this responsibility be delegated to existing incentive managers or committees.

To benchmark expectations, we reviewed Gauntlet’s reporting on the current Unichain incentive program, which has achieved approximately $59 in TVL per $1 spent. For the USDC/USDT0 pool, which is currently the only incentivized stablepair pool, TVL per $1 spent is $53. With $800K in incentives, this would result in $42.4M in TVL and if the full $3.2M proposed here were deployed at similar efficiency, it could drive ~$170M in TVL.

Based on these reference points, we suggest tying KPI unlocks to targets that reflect a 50% increase over the current proposed KPIs. Specifically, we recommend a performance-based structure of 37.5M / 75M / 150M TVL targets per $1M additional incentive unlock.

[404DAO]

Etherlink Co-Incentives Proposal

We voted AGAINST the Etherlink Co-Incentives proposal. We do not believe the $150K co-incentive request will drive sustainable growth. Historical data from Forse Analytics shows that most liquidity incentive programs result in short-term TVL spikes, with retention typically falling below 50% after 90 days. LP behavior remains largely mercenary, with rewards often sold immediately.

Since incentives are already being distributed through the Apple Farm Season, we see limited additional value from more incentives. Until we see clear organic demand with a clear strategy for achieving stickiness onchain beyond the campaign, we cannot support this proposal.

[GFXlabs]

Not to single out 404, but this sort of thinking isn’t constructive for a high-growth startup like Uniswap. Generally speaking, we’re going to need to allocate funds to many things, most will fail, but the few that succeed will succeed so massively that it will cover all the prior investments and produce a considerable return. It seems contradictory to vote against this well-structured request for $150K when 404 (and most of the DAO) voted in favor of the +7.5M UNI funding package for Unichain and Uniswap v4.