Scaling V4 and Supporting Unichain

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.

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.

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.

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.

2 Likes