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.