Scaling V4 and Supporting Unichain

[AbdullahUmar]

Addressing @Herees’ and @404DAO’s Concerns

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:

• Avalanche C Chain
• Base
• Rootstock

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

• 1. teams prefer to outsource the onboarding of dapps so they can focus on other core operations associated with the chain
• 2. 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)
• 3. 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
• 4. 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.

@AbdullahUmar

Negotiations with chains around v4 adoption, which will likely affect a chain’s spot in line for receiving a v4 deployment, will be conducted as a collaborative effort between the UAC and UF. We are coordinating with partners like Merkl and other incentive distributors to ensure their infrastructure is ready to handle v4’s complexities.

Next topic is whether or not we need another entity in all of this for chain approvals—

@404DAO

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.

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.

@404DAO

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.

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:

@AbdullahUmar

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.

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.