# Scaling V4 and Supporting Unichain

**URL:** https://gov.uniswap.org/t/scaling-v4-and-supporting-unichain/25484
**Category:** Requests for Comment
**Created:** [April 22, 2025, 2:11pm UTC](https://gov.uniswap.org/t/scaling-v4-and-supporting-unichain/25484 "2025-04-22T14:11:52Z")
**Posts on this page:** 1
**Showing post:** 39

<div class="post-metadata">

### Author: ![blockchainedu](https://sea2.discourse-cdn.com/flex016/user_avatar/gov.uniswap.org/blockchainedu/32/9068_2.png) [@blockchainedu](https://gov.uniswap.org/u/blockchainedu)
#### Post date: [May 4, 2025, 5:57pm UTC](https://gov.uniswap.org/t/scaling-v4-and-supporting-unichain/25484/39 "2025-05-04T17:57:21Z")

</div>

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.

> [@Atiselsts.eth Delegate Platform](https://gov.uniswap.org/t/atiselsts-eth-delegate-platform/22270/22):
>
> 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.

---

_[View the full topic](https://gov.uniswap.org/t/scaling-v4-and-supporting-unichain/25484)._
