Scaling V4 and Supporting Unichain

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