[RFC] Post-BSL Cross-chain Deployment Process & New Uniswap.eth Subdomain

Requests for Comment
1

TL;DR

  • Uniswap v3’s BSL expires this Saturday, April 1, 2023.
  • Post BSL-expiry, it will be beneficial to identify one official Uniswap v3 deployment per chain in order to provide safety & security for users, focused support to ecosystem participants, and clarity to Uniswap governance. This deployment would be recognized in future Uniswap governance actions, by the UF for hackathons, by the ecosystem for liquidity mining campaigns, etc.
  • In the post below we recommend the following in order to determine and track official Uniswap v3 deployments:
    • A recommended approach to Uniswap governance, with guidance to stakeholders on how they might go through the governance process. This approach allows for the fact that deployments can now be recognized as official after they have been deployed.
    • Creation of a new subdomain v3-deployments.uniswap.eth that will be used to track official deployments.
  • The creation of the new v3-deployments.uniswap.eth subdomain requires a governance vote. We are kicking that off here with an RFC, and we will gather feedback on this proposal as a whole as we go through the governance process.

As many of you know, the BSL is set to expire later this week on Saturday, April 1. Once it expires, it will be possible for any person or team to deploy the Uniswap v3 code for production or commercial use (more on the BSL here). We assume that there will be multiple deployments of Uniswap v3 across other chains.

However, after the BSL expires, it will still be important for the Uniswap DAO to determine which deployment, of many potential deployments, on another chain should be recognized as the Uniswap DAO’s official deployment.

It will be important, and beneficial to both the DAO and Uniswap users, to identify one official deployment per chain for many reasons:

  • Code Verification: this official deployment will have been verified as equivalent to the source code by the DAO. In other words, the DAO will have verified that no one has altered the deployment code in a malicious or unintentionally harmful manner. If for some reason the code has been altered, for instance to be deployed on StarkNet in Cairo or in another language on another chain, those changes would be vetted by the DAO prior to an on-chain vote.
  • Ecosystem Clarity & Support: Some Uniswap ecosystem developers may want to focus their efforts on integrating with one designated Uniswap deployment per L1 or L2. Ecosystem or Foundation funded liquidity mining campaigns and hackathons will similarly look to support the official deployment.
  • Uniswap Governance Control: Only the official deployment will be updated and maintained by Uniswap governance (ie., to add fee tiers or turn on fees).

Below we lay out the approach we recommend that Uniswap governance adopts to identify these official deployments. Some of the thinking around these steps were inspired by a post written by @devenmatthews a few days ago, which you might also want to read here.

The governance process will remain the same, with some specific recommendations in approach to:

  • Take into account the fact that deployments may now be done prior to the Uniswap governance process being completed to identify it an official deployment.
  • Allow the proposer to change the deployer team if they are unable to fulfill their responsibilities in a timely manner, or to change a bridge if the chosen bridge is hacked, prior to the final on-chain vote.
  • Still allow for the Uniswap DAO to review and approve specific details, such as the deployment team and bridge, prior to voting a deployment to be official.
  • Allow for the governance process to track official deployments in a newly created Uniswap.eth subdomain, v3-deployments.uniswap.eth. The on-chain vote will update this subdomain with the relevant deployment information

An on-chain vote is itself required to create the new subdomain we propose, v3-deployments.uniswap.eth, to track official deployments of Uniswap v3 on other chains. This RFC is kicking off the governance process to do that.

List of Actors in a Deployment

First we want to review and clarify the types of stakeholders who participate in a cross-chain deployment. This review may be helpful in understanding not only the recommendation below but the mechanics of these types of proposals as a whole. It’s possible for one entity or person to serve as multiple stakeholders at once – for instance, a proposer can also be a deployer, and a deployer can be a bridge provider.

Proposer: entity or individual that creates the proposal on forum, and manages the governance process

Deployer: entity that handles the deployment of Uniswap v3 contracts on other chains or L2s

Bridge Provider: cross-chain messaging solution selected from the Bridge Assessment Committee’s recommendations

L1 or L2 team: target chain for deployment

Proposal Sponsor: entity that has enough UNI to sponsor the final on-chain vote. The Uniswap Foundation is typically able to serve as the sponsor for these proposals.

Recommended Process

The governance process (defined here) will remain the same in terms of time frame, platform (forum, Snapshot, on-chain vote), and quorum requirements, with specific recommendations being made to the stakeholders on how they approach the process for ascribing a Uniswap v3 deployment as “official”.

Prior to an on-chain vote, Uniswap v3 should be deployed. During the vote, delegates should assess all components of the proposal and deployment including but not limited to a deployment’s equivalency to source code (potentially leveraging the help of more technical network stakeholders), and whether a bridge or bridging solution is included in the Bridge Assessment Committee’s set of recommendations.

Deployments which pass this governance process will receive support as the official Uniswap deployment on the L1 or L2 from the Uniswap Foundation, DAO, and ecosystem.

RFC:

  • Minimum 7 days. Post your proposal on the governance forum to allow the community to review and ask questions. Keep the proposal in the forum, responding to questions and iterating upon the proposal based on feedback for at least 7 days prior to moving to the next phase.
  • Proposal is for an official deployment on the L1 or L2, with the rationale for deploying Uni v3 on that chain.
  • At this point, the deployment may already be completed. If so, include links to relevant contracts, and include a description of the deployment team and bridge used.
  • If the deployment has not already been completed, the proposal might reference the deployer and bridge which are intended to be used, but this is neither binding nor required.
  • If the deployment has not been completed already, the proposer should converse with teams interested in aiding with contract deployment. Deployers can also comment on the RFC, communicating their willingness and technical capabilities to handle deployment.

Temperature Check:

  • 5 days. Create an off-chain Snapshot Poll to ensure community sentiment is in favor of your proposal. A majority of votes in favor, with a quorum of 10M UNI votes, is required to move forward to the last phase.

  • A Temperature Check is done, assessing Uniswap DAO’s desire to have the deployment done on the L1 or L2. Again, at this point, a deployer and bridge might be determined already, but it’s neither binding nor required.

  • If and when the Temp Check passes, the deployers will have confidence in Uniswap governance interest in supporting a deployment on the L1 or L2.

Deployment is completed

If a deployment has not already been completed, it should be done following a successful Temperature Check. The proposing team can work with the deployer to execute the contract deployments. Details of the deployment, including contract addresses and messaging infrastructure, should be added to the forum in the proposal for the on-chain vote.

Governance Vote:

  • 11 days (7 day voting period). An on-chain vote is proposed and executed. If successful, the vote would add the new deployment information to the newly created v3-deployments.uniswap.eth subdomain.
  • The benefits of this approach are as follows:
    • The proposer is not bound to a specific deployment team, if for some reason the original deployment team is unable to deploy in a timely manner prior to the on-chain vote.
    • The proposer is not bound to a specific bridge if a bridge is hacked between the RFC and deployment. A bridge or agnostic solution should ideally be chosen based on the recommendations from the Bridge Assessment Committee.
    • Uniswap governance still has final approval of the deployer and bridge used through the final on-chain vote.

Creation of v3-deployments.uniswap.eth subdomain

As we note above, and in alignment with the governance process we recommend after the BSL expires, the UF proposes to create a new ENS subdomain v3-deployments.uniswap.eth to track official deployments of Uniswap v3 on L1s and L2s. This RFC is kicking off that process, as the new subdomain can only be created through an on-chain governance vote.

If and when the on-chain vote passes to create this new subdomain, we will pre-populate deployment information for all deployments which have already been “approved” by the DAO (i.e., on Polygon, Optimism, Arbitrum, etc.).

Next Steps

Over the next week, we are excited to hear your feedback and integrate it into this proposal. After a week, if there is no strong disagreement from the community, we will move to a Temperature Check.

If and when the proposal successfully passes:

  • V3-deployments.uniswap.eth will have been created, and it will have been populated with information on deployments which have already been approved by the DAO
  • The UF will update its cross-chain deployment guide to incorporate these recommendations
  • The UF will direct all interested in launching Uniswap v3 on new chains after the BSL expiry to this process
10 Likes
2

Kydo from Stanford Blockchain Club here.

I want to draw more attention to this topic as it relates to the core of Uniswap governance for the foreseeable future. Firstly, I would like to express my gratitude to @devenmatthews and @devinwalsh for bringing attention to this topic. You can find @devenmatthews’s post here.

In my opinion, there are a few layers to the Post-BSL deployment question:

  • How many “recognized” deployment(s) per chain?
  • How is/are “recognized” deployment(s) selected?
  • How is/are “recognized” deployment(s) deployed?
  • Can “recognized” deployment(s) on a chain be changed?
  • How is/are “recognized” deployment(s) changed?

A “recognized” deployment is a deployment that is recognized by the DAO.

  • It MUST be controlled by the Uniswap DAO on Ethereum mainnet based on cross-chain governance standard (in progress by the bridge committee).
  • The Uniswap DAO MUST technically review its deployment.
  • The Uniswap DAO MUST on-chain approve its deployment.
  • It SHOULD be used by Uniswap liquidity providers and users.
  • Uniswap developers SHOULD use it as the base infrastructure.

How many “recognized” deployment(s) per chain?

Answer: ONE

I agree with @devenmatthews and @devinwalsh that there should be one “recognized” deployment on every chain (L1/L2/L3…). This lowers the coordination cost between different stakeholders within the Uniswap ecosystem.

How is “recognized” deployment(s) selected?

Answer: Devin-proposed process.

The current selection process can be summarized as the following:

  1. RFC: Post the proposal on the governance forum for at least 7 days prior to moving to the next phase. The proposal should include the rationale for deploying Uni v3 on that chain, and details of the deployment team and bridge used.
  2. Temperature Check: Create an off-chain Snapshot Poll for 5 days to ensure community sentiment is in favor of the proposal. A majority of votes in favor, with a quorum of 10M UNI votes, is required to move forward to the last phase.
  3. Deployment: If the Temperature Check passes, complete the deployment with the chosen deployment team and bridge, and add details of the deployment, including contract addresses and messaging infrastructure, to the forum in the proposal for the on-chain vote.
  4. Governance Vote: Propose and execute an on-chain vote for 11 days. If successful, the new deployment information will be added to the newly created v3-deployments.uniswap.eth subdomain, and the deployment will receive support as the official Uniswap deployment on the L1 or L2 from the Uniswap Foundation, DAO, and ecosystem.

I believe this flow (FCFS) is sufficient for EVM deployments. However, deployment on non-EVM chains could be problematic as different providers may want to transpile/rewrite Uniswap V3. An application-based selection process may be more appropriate for those deployments.

How is/are “recognized” deployment(s) deployed?

For EVM chains:

  1. The proposer deploys and publishes testing.
  2. Accountability mandatory check is conducted, and testing is published.
  3. The community is invited to audit the deployment.

Check out these resources for EVM deployments:

Regarding non-EVM chains, I would defer this discussion to another thread due to the complexity of the issues involved.

Can “recognized” deployment(s) on a chain be changed?

Answer: Yes

Allowing changes provides the DAO with flexibility to fix mistakes.

How is/are “recognized” deployment(s) changed?

Answer: Follows the selection process

While changing the “recognized” deployment may not occur frequently, I believe the process should be similar to the selection process described above. It is important to follow a clear and transparent process for making changes to the deployment.

In summary, the Uniswap governance community should focus on identifying how many “recognized” deployments are needed per chain and how to select, deploy, and potentially change those deployments. By following a clear process and involving the community, we can ensure that Uniswap remains a trusted and valuable participant in the decentralized finance ecosystem.

3 Likes
3

Thanks @devinwalsh for formalizing this post into an [RFC] and @Kydo for furthering the conversation.

New subdomain

I would like to throw my support behind creating a new subdomain to track ‘official/recongnized deployments’ (we should likely settle on a term here).
I think the formality of an on-chain vote and registry is important, as well as could be a useful tool for integrators.

Proposer-Deployer Separation

One rational in my original post for not making any binding decisions until a deployment has been made was to remove any contingencies that might harm a deployment process.

I’d like to underline that the initial Temperature Check should purely be an analysis of Uniswap’s interest in deploying on a specified L1/L2/L3. The proposer should only serve the informal role as being a coordinator, overseeing that the deployment is made and governance process is completed.

The original temperature check should not have any formal ties to the proposing team. The proposing team should not have any technical ownership of the governance process for a deployment on a specific chain. Informally, it should be assumed they will work cordially with a deployment team and help bring the final vote on-chain once a viable deployment has been made.

The Uniswap DAO should have no problem continuing the governance process with a deployer who was not recognized by the original proposer. Situations like this may arise if a proposing team/chosen deployer become unfit to make the deployment. There should be no issue with independent actors making a deployment and continuing the governance process with an official on-chain vote, when the original temperature check was proposed by a different party.

Recognition of Subjectivity

In my post, I try to generalize the ‘subjectivity’ of a Uniswap v3 deployment.

In summary, the current process recognizes the only nuance of v3 deployments being the bridge they use. Minor changes to the codebase which accomodate different features on EVM chains, as well as the vast subjectivity prevalent in non-EVM deployments are not accounted for (see Starknet proposal).

This was a majority of my reasoning for saying official deployments should be chosen after they have been made, to give the UniswapDAO a full overview of the deployed code they will be recognizing.

Testing Required

This framework would greatly benefit from a sister-framework for analyzing the security of a deployment.

  • For EVM-equivalent deployments, there should be a standard set of tests run and published before going to on-chain vote
  • any deployments which utilize a level of EVM byte-code interpretation should publish relevant audits about this process
  • any deployments which adapt code on a language level should undergo audits which adhere to a set of standards set by the DAO

This updated deployment proposal process does not require this sister-framework explicitly, so I’ll defer this conversation for now. The Nethermind team is hoping to assist in defining these standards and security practices through the Starknet deployment process (which hopes to utilize this new framework).

Changing an official/recognized deployment

As mentioned in my previous post, I think it is important that the UniswapDAO reserves the right to change the official deployment on a specific chain. We can reasonably assume this will not be commonplace (as the coordination cost of integrators and movement of capital would be expensive). Though, this has the irreplaceable affect of allowing the DAO to address security concerns later found in a deployment. This also addresses the idea of subjectivity where a new deployment may capture some features specific to the deployed chain which the DAO wants to capture (and justifies switching cost).

This should be done by making an edit to the new v3-deployments subdomain via an on-chain vote. This change should also require a temperature check (as it has a large switching cost associated), perhaps this needs to be detailed in the updated Cross-chain deployment guide.

Summary

I think the post made by @devinwalsh is a fantastic framework, I only wanted to make some things more explicit. Really excited the DAO is preparing for a new world where the v3 codebase is available for use by all.

3 Likes
4

Thank you for initiating this discussion around the post-BSL proposal standard, @devinwalsh. Appreciate your helpful input @Kydo & @devenmatthews.

Establishing a coherent deployment structure is imperative for signaling to the Uni community and all external stakeholders in the space that Uniswap has a systematic process behind multi-chain expansion.

We want to make sure that post-BSL standards are decided on as soon as possible to begin expanding to more alt-L1s and L2s. Ideally, a more rigorous expansion initiative should have taken place months ago when Uniswap still had the BSL as a competitive advantage. Unfortunately, we did not see as many deployments as we likely should have, partially due to organization/coordination problems that have been quelled after the establishment of the Uniswap Foundation in Fall 2022, voted in by the Uni DAO. The tumultuous market conditions further complicated matters, causing numerous chains to delay ecosystem expansions–not to mention exploits that prevented certain deployments from commencing, namely the Nomad debacle which has delayed both a Uni v3 deployment onto Moonbeam and Gnosis Chain.

Deploy Uni v3 Sooner Rather Than Later

Although the argument of deploying Uni v3 on X chain due to license expiration urgency is now moot, I still believe that going to market sooner rather than later could save Uniswap some headaches in the future. Here are a few reasons why:

A Bad Consumer Experience Hurts Uni’s Reputation:

The more time that passes, the more v3 forks will arise. A major issue with numerous, unruly deployments is that deciding between various forks will be cause for an unsatisfactory consumer experience. Where does a user go for the “real” Uniswap?

Numerous users are also not privy to the license ordeal at all. So when they see an unofficial Uni fork on their chain, they may subject themselves to unforeseen risks, especially if the deployers have altered contracts, deployed recklessly, or even employed malicious contract modifications. The mistakes of forks could incorrectly be attributed to Uniswap itself thereby damaging the protocol’s reputation.

Liquidity Segregation Among Forks & Battling for Market Share with Modified Forks:

Ideally, we get to market first on X chain with an “official” deployment that prevents segregated liquidity amongst unofficial forks. A fork of Uni with slight contract alterations may achieve higher TVL and activity on a chain–but that fork cannot be considered official since its code has been tampered, regardless of how much activity it has. So, instead of allowing a modified version of Uni present on X chain to dominate an L1 market–one that has garnered a ton of attraction and is not able to be considered an “official” fork due to its alterations–it’s best if we deploy untampered v3 contracts soon, making sure those deployments attain the most traction on X chains.

However, the above arguments are primarily for EVM chains. Non-EVM chains that alter v3 code out of necessity is a topic for later. It’s a good thing most large L1s have some way to support EVM-equivalent dapp deployments. For example, Avalanche has the C-Chain, Polkadot has Moonbeam parachain, Near has Aurora, Cosmos has app chains like Evmos & Kava…and a bunch of L1s just use EVM like BNB Chain.

Deciding From a Pool of Good Uni Forks:

Correspondingly deciding which fork we want to deem “official” by taking it through Uni governance rails could also become more complicated as more forks arise. What if multiple forks on X chain want to become official? And what if they’re all properly deployed? Who do we say yes to and who do we deny, especially if none of the forks happen to dominate the market on X chain? Although we will likely run into this issue, we can mitigate it as much as possible via conducting deployments in the near future.

Selecting a Deployer

Even though ramping up deployments has its benefits, we should not sacrifice safety for speed. Delineating some of the tasks for deployments will help in this arena. A tangible step the community has recently taken is creating the Bridge Assessment Committee.

Now that bridge assessment has been delegated to a committee, the stakeholder that requires the most scrutiny from the DAO is the deployer. The DAO must make sure that the deployment team is capable of proper contract implementation on the desired chain. So who will be assessing if the deployment is done correctly? If a proposer has yet to coordinate with a deployer, we may see an influx of forks wanting to have their deployment be used. And the process of vetting which forks are proper is necessary. A heuristics approach to this is simply coordinating with a well-known team with deployment history & technical capability, like Plasma Labs, LayerZero Labs, Wormhole, etc. It may also be the case that one or more of these entities begins deployments on multiple chains right as the BSL expires. This may be cause for concern–but would also alleviate issues regarding deployment reliability.

Furthermore, the deployer will likely be coordinating with Uni Labs after the onchain vote passes to complete front end integration. This process is most seamless if the deployer is a known, reliable entity.

The Stakeholder List

In reference to @devinwalsh’s post, I also suggest that the initial RFC requires have a section called “stakeholders”, where the tentative deployer is mentioned. It just makes it more clear for everyone assessing the deployment in general. I concur with @devenmatthews that the temp check should ONLY be a vote on the DAO’s desire to deploy on X chain, so the temp check must omit any mention of deployer, bridge, or any other stakeholder, BUT those stakeholders must be in the RFC. And later, the onchain vote should include the final full list of stakeholders.

Note that the bridge and deployer sections may be denoted as “unassigned” for an RFC. It’s up to the proposer to decide this–but if they have already selected a deployer and/or bridge, they should mention it for transparency.

In short:

  • Proposer should include a list of all stakeholders in the RFC, but this is just for clarity and transparency purposes
  • To make sure that the temp check is ONLY voting on the DAO’s interest of deploying on X chain, the temp check should NOT include the list of stakeholders
  • The onchain vote should include a full list of involved stakeholders
1 Like
5

Kydo from Stanford Blockchain Here.

We are in full agreement with the points @devenmatthews raised around

  • PDS (Proposer-Deployer Separation)
  • Recognition happens post-deployment
  • Testing requirements for all deployments.
  • Audits for non-EVM-compatible deployments
  • Ability to change deployments

With regard to @AbdullahUmar 's point, we agree that

  • Deployment speed can be improved.
  • Clearly laid out stakeholder list is helpful.
  • Deployer expertise is important
  • DAO should independently check deployment.

However, there are a few things we disagree on:

  • Deploy Uni v3 Sooner Rather Than Later
  • Users would confuse about which one is Uniswap.
  • Selecting outside parties to do deployment vesting on behalf of the DAO.

As we have mentioned before in the Boba vote, we do not believe more numbers of deployments would benefit Uniswap. Quality of deployment is a lot more important than quantity.

In our view, we have deployed on the major chains from a growth perspective. Now, it is our time to focus on long-term visions around zkEVM transpiling or rewriting V3 in different languages. Therefore, governance around post-BSL should focus more on these topics instead of GTM to more chains.

Moreover, we should be careful of the Uniswap brand being associated with other chains during this deployment process. Most chains only sound great on paper.

I think this is a valid question. However, this question is less about code-licensing, but more about brand asset control. The “real” Uniswap is the one that can use Uniswap branded assets. Eg, Sushiswap uses Uniswap’s code but not Uniswap’s brand.

Therefore, the user would not be confused post-BSL to find the “real” Uniswap even if there are many forks.

Currently, the DAO is in the process of forming the accountability committee (which I am a part of). The committee would essentially handle deployment verification with the open-source CLI tools I have listed here:

The committee could also work with the foundation in the future to develop easier testing tools for the community. The current testing toolkit is already intuitive enough for the technical members to use by themselves.

2 Likes
6

Thank you for the feedback, @Kydo.

I would agree that quality is a paramount concern for selecting where we decide to deploy. We at Blockchain at Michigan have turned down a handful of proposal sponsorships and proposal drafting requests because we don’t believe that it’s in the best interest of Uniswap. I do think that there are chains, however, meeting the quality criteria–like Polkadot, Cosmos, Near–that Uni should aim to attain a foothold in. Even if there is a lesser degree of activity on those chains, a lot of these deployments are meant to be a way for Uniswap to not miss out on promising markets. Expansion during a less active time is one way to position the protocol early on prior to a future market resurgence. Plus, such relationships are often a two way street. The presence of Uniswap on X chain can help incentivize builders and users to partake more actively on X chains. Uniswap is a liquidity facilitator for protocols and its presence helps prop up ecosystems. There is also a question of the extent of expanse Uni has on a chain. Like does Uni go to Kava or Evmos for access to Cosmos?

And at the end of the day, it’s ultimately the DAO’s decision to decide if certain deployments should go through. If we look empirically at stakeholders’ voting decisions and a general outlook on sentiment, most stakeholders are generally in favor of more deployments. But, yes, we will soon reach a plateau where we exhaust expanding into promising chains–just don’t think we’re there yet.

Another concern is how willing Uniswap Labs will be regarding expending its resources on certain front end integrations. To your point about Boba, Uni Labs would side with you, Kydo, on this topic. They do not presently see Boba as a chain that needs to be integrated into the front end to make Uni more robust. This leads to questions about how much say does the DAO really have over deployment decisions due to Labs’ gatekeeping.

In full agreement with the above.

100%. New DEXs will be rebranded versions of Uniswap, with copied underlying code. I suppose “real” Uniswap would not be a large cause for concern due to distinctive branding. Probably a larger concern exists about unbranded deployments on Uni v3 contracts made by multiple reliable deployers who want their deployment to be used as the “official” Uniswap. Even this may not turn out to be a prominent concern.

This is of course the preferred method for assessment, although I am not entirely against attaining help from third parties who’ve established a track record and are known for quality work. Nonetheless, if this process can be handled by the committee effectively, sounds good to me.

Summary:
We’re on the same page regarding the concerns you pointed out. The only slight separation is regarding the desire to deploy on more chains. While considering quality of chains is important, we’re still of the opinion that there are beneficial deployments to be completed for the sake of positioning Uniswap advantageously. But yes, the list of ecosystems that we hope to expand to, upon further due diligence, may turn out to be less in quantity than we expect. We also recognize that there is certainly a trade-off in the topics the DAO focuses on, and an over saturation of deployment conversations could take away attention from more prudent efforts.

2 Likes
7

I would heed against centering this redesign opportunity around a sense of urgency to deploy across EVM chains as quickly as possible. This process should be left as general as possible to be future-proof.

There is no necessity to formalize notion of ‘unaltered’ contracts within’ the requirements of being an official v3 deployment. While the DAO will always have the final say, formalizing statements like these will apply arbitrary limitations for Uniswap’s design space.

I disagree that Uniswap should push off this conversation. There are greatly interesting projects which offer Uniswap better scalability without targeting EVM, which are ready to begin a deployment process.

Altering code out of requirement is also not a fully encompassing description; Starknet specifically supports EVM byte-code interpretation, but it would be far more efficient to do a native rewrite in Cairo. There are also other major chains which are not EVM-equivalent per say. We may see EVM-compatible chains adopt new precompiles which could offer a Uniswap deployment better efficiencies (this is simply an example scenario). If a team is willing to support proper audits and security measures, and the DAO finds the changes fitting, I see no reason to prevent these activities.

Again, I think the process itself should not limit design space, the DAO should have the freedom to chose its philosophy.

Proposer-Deployer Separation

I’m somewhat confused how this fits into the suggested framework. If the UniswapDAO is recognizing deployments AFTER they have been deployed, the community has full clarity over the deployed code. I believe this is the function of the accountability committee to do technical reviews of the deployment process.

Using a ‘trusted deployment team’ as a heuristic is unnecessary and I would greatly contest any efforts to formalize this. Let anyone deploy, the DAO choses if they want to adopt a deployment.

Creating some pseudo-reliance on specific teams would greatly screw Uniswap deployments onto chains which the mentioned bridge teams support.

I see no reason to include these in the governance process.

I don’t ethically agree with this. The process would be simpler if Uniswap Labs handled all deployments. It’s not about ease, but accessibility imo.

2 Likes
8

Kydo from Stanford Blockchain Club here.

Thank you for the thoughtful response @AbdullahUmar . Wrt to “Quality vs Quantity” claim, I will say we might hold different views around individual chain quality and growth potentials. I think that is perfectly fine and we can agree to disagree. I am no expert in growth strategy and will defer this decision, like you have said, to the community, which has welcomed new chains with open arms. I can (and probably is) very much be wrong here.

Can you elaborate on what exactly is the problem here? A, B, and C all deployed UniV3 to a chain. What’re their incentives to compete for this deployment role? If you are talking about changing things within V3, then I think that’s a separate conversation and I think the DAO should have the power to deem a deployment official/recognized even if changes were made to contract logics, agreement with @devenmatthews here.

I think if we want to hire someone to do this, in addition to the community member / committee doing it, I am all for it. However, I am not seeing why WH or LZ would want to dedicate engineering resources to this contract work. And if the incentive is not clear from the contractor side, it is better to not have it.

All in all, I think we are mostly in agreement here in the forum.