[RFC] Deploy Friendly Fork of Uniswap V3; ZERO Protocol on Polygon zkEVM

In line with the official v3 deployment process, it would be good to develop a similar one for v3 friendly forks since the protocol will see more friendly fork opportunities in the future. A v3friendlyforks.uniswap.eth domain will contain a record of all the friendly forks. Each record in the subdomain will stored by the friendly fork’s name and the details of the fork, such as the chain ID, factory address, and an IPFS link to the terms of the friendly fork.

Once the Zero protocol team has deployed their fork, they can post the deployment info here and then craft the initial proposal, creating the subdomain and adding Zero as the first friendly fork.

1 Like

I did not vote in the snapshot but plan to vote against the proposal, as it stands now, if there’s on-chain vote.


  1. My delegate statement says that “Uniswap should be kept credibly neutral; I’d only support funding initiatives that clearly benefit the protocol itself”. Supporting specific emerging protocols violates this principle and may cost the DAO in the long term.

  2. The operational questions related to the voting using veTokens is not clear (my previous post). Moreover, even if they were clear, voting for specific pools is once again picking sides and risks. If the proposal passes, I’d still like to see the Uniswap DAO abstain from voting, in order to avoid getting involved in protocol politics.

  3. The stakes are low. For one, there’s no urgent need to have an officially approved Uni v3 instance on zkEVM, as it’s a fledgling chain. For another, as the v3 BSL has expired, protocols don’t need ab explicit permission to friendly fork Uniswap v3.

  4. It’s worth looking at history of proposed similar forks, like Hermes on Harmony. I agree with @monet-supply here: “I’d prefer to see Uniswap pursue the highest value L2s/L1s with a direct launch that preserves Uniswap’s autonomy and branding and lets us own the user relationship.”

We respect the decentralized aspect of the Uniswap DAO and are more than willing to cooperate on all fronts. In terms of accountability and transparency, we are a totally open book and are happy to dive into any and all discussions in regards to ZERO or any of our protocols, now or in the future.

In response to the screenshots you inserted above - I think there is no denying that getting a cosign from Uniswap would be a huge opportunity not only for Zero protocol, but any protocol who has the courage to go through the governance process and follow the procedure to move to an on-chain vote.

In terms of the proposal being a “benefit to zero”, we could not agree more. There is a unique opportunity for zero protocol and that is why we have committed 10% of our initial supply to Uniswap DAO as a token of our appreciation for their innovation and support.

I definitely agree with others stating how “as the v3 BSL has expired, protocols don’t need an explicit permission to friendly fork Uniswap v3”, this is part of the reason why we decided to go through with this process and ask permission to get the “blessing” of the DAO. We could in fact fork the code with the benefit belonging exclusively with ZERO, but instead we decided to pay respect to Uniswap DAO by formulating what we feel to be an equitable proposition - while at the same time introducing a new, collaborative, and mutually beneficial path forward for UniSwap to engage with protocols that seek to fork its code anyway.

To clarify, when I mentioned that I felt Uniswap wouldn’t vote, what does that mean?
I don’t personally expect or demand the responsibility for Uniswap Governance to vote on the many proposals, but the DAO is free to do so as they see fit.

What would be the topics that the Uniswap community would be able to vote on?
Directing incentives is the core functionality of veNFT power on a ve(3,3) dex

Will the Uniswap community get the revenue from the fee for receiving such tokens?
Uniswap has a right to revenue like any other ve token holder.

In response to my statements that I felt “Uniswap would not deploy on Polygon zkEVM” and my view being “known internally” means nothing short of what I stated.

The proposal for Uniswap v3 to deploy on Polygon zkEVM was first published in March (Uniswap V3 Launch on zkEVM). Now we are 6 months past that approved proposal and we have come to the internal conclusion that we do not feel Uniswap was likely to follow through with deploying on zkEVM. With this in mind, we decided that it would be a great opportunity to do exactly what we are proposing. Going through the proper channels, getting a sponsor, providing all necessary information, reaching out to delegates and offering 10% of our initial supply in pursuit of this unique opportunity to set a new precedent for Uniswap and protocols that aspire to follow suit.


I appreciate your commitment to maintaining Uniswap’s credibility and neutrality. However, it is important to note that the proposal doesn’t necessarily violate this principle. The intention behind endorsing Zero Protocol as a friendly fork is to foster collaboration and shared growth within the broader DeFi ecosystem, rather than favoring a specific project. This endorsement sets a precedent for future partnerships and demonstrates Uniswap DAO’s willingness to engage with emerging protocols for mutual benefit. By actively participating, Uniswap DAO can have a say in shaping the DeFi landscape and ensuring it remains open and competitive. I would like to emphasize that not supporting emerging protocols may cost the DAO in the long term also. This is evidenced from Uniswap v2 forks taking more from the DAO than they gave back (if anything at all was given).

We understand that voting on pairs to get bribes and fees might be difficult for the DAO. However, the proposal emphasizes that Uniswap DAO has the freedom to vote or abstain from voting as they see fit to pursue the best interest of the DAO and maintain neutrality.

If you regard zkEVM a fledgling chain and one that is not in the category of “highest value L2s” then this proposal won’t step on the toes of those that want to preserve Uniswaps autonomy and branding for the “high value” chains. As you already mentioned, since the BSL has expired, we do not need to request permission for the fork. However, we feel like creating a system that both protocols can benefit from would be the more logical route to proceed.

Uniswaps multi-chain expansion is becoming massive and we extremely support this movement in terms of user experience, ease of reaching numerous chains on one protocol. The concept of “friendly fork” can able both Uniswap and Zero Chain to innovative consequences. We have couple questions and rewies about this temparature check. The answers will lead us to vote on the on-chain proposal.

  • Since there’s a big TVL difference between Uniswap and Retro Protocol, will there be anything except the participation of Zero Protocol’s governance? How will the revenue be distributed?

“Zero Protocol will utilize Uniswap’s established backend infrastructure as its foundational engine and be granted access to ecosystem-funded tooling.”

“Zero is a direct fork of the existing Retro project on Polygon POS, which already relies on Uniswap V3 for trading.”

  • Zero Protocol is described as a direct fork of Retro, but it’ll take Uniswap’s backend infrastructure as its foundational engine. How is it possible for a fork (Zero) to use some other backend (Uniswap) instead of the protocol it originally forked (Retro)?

  • Can you also briefly explain how will the Zero Protocol be the liquidity layer for Polygon zkEVM?

We voted “for” on this temperature check, and we’ll consider those answers for our future voting. We wish you good luck as ITU Blockchain delegation team

Although the mentioned concerns by the DAO about this proposal are fair, we believe that the benefits outweigh the costs. The main aspect to highlight is how the DAO is perceiving this proposal. It seems that, so far, the main concerns seem to be hesitation around 1) extending Uniswap’s name to a small, lesser-known team and 2) operationally setting up the structure behind how the DAO will vote on Zero protocol proposals.

As far as endorsing well-known protocols goes, this proposal isn’t necessarily meant to focus on that pursuit. Partnering with an established protocol is more of a growth play, where Uniswap attains a certain amount of tokens to vote on the decision making of that protocol, utilize those tokens for treasury diversification, and/or create incentives out of those tokens. This description would match what is occurring with the ARB token distribution. The goal here is to enable collaboration between larger protocols to aid the overall ecosystem’s health. Aligning incentives for big players is important.

However, this frame should be altered slightly when analyzing “friendly forks”, which, by definition, are going to be smaller, less established protocols who don’t yet have a stand-alone brand and would like to leverage Uniswap’s endorsement to help attract users+liquidity. Uniswap’s incentive here is not the governance part, meaning the operational part of involving itself in the protocol’s governance should not be the Uni DAO’s priority. The DAO can be involved as much or as little as it likes, and the 10% Zero token allocation still holds. We can limit the overhead–or we can decide to create a committee to manage the voting. Either way, this should not be the deal breaker for rejecting the proposal. Here, the idea follows more of a venture model, where the Uni DAO makes bets on a couple of its forks by recognizing them as partners and receiving ownership stake in those protocols. If the friendly fork ends up doing well, then there’s large upside for the treasury. This model won’t work as well for larger protocols since it’s never going to be the case that an established protocol will hand out 10% of their token balance.

But yes, we can’t just endorse every other protocol. The friendly fork must meet certain criteria, and this initiative is a good experiment, which would also help establish an ENS subdomain for recognizing these friendly forks all in one place. We believe that an initial round of due diligence on the merits of Zero protocol has already been conducted, implied by Polygon’s grant to aid in Zero’s development and liquidity-seeking initiatives:

Future friendly fork applications likely won’t have much more of a compelling pitch. And it seems Polygon zkEVM is also willing to advertise Zero as a predominant liquidity layer on their platform. All of this is only further pronounced if the following is true:

We (Michigan Blockchain) are therefore voting FOR this proposal.

1 Like