[Temperature Check] Create the Uniswap Foundation 
  Uniswap Foundation: Preamble 
  Uniswap has already changed the world

[Temperature Check] Create the Uniswap Foundation

The tentative deadline to provide feedback on the process below is Friday, February 17th. This date may be pushed back further, if required for further feedback and iteration. (Date updated from a previous version of this proposal)
Hi all, as I mentioned in the <a href="https://gov.uniswap.org/t/rfc-update-deploy-uniswap-v3-1-0-3-0-05-0-01-on-bnb-chain-binance/19734/44">BSC Deployment Proposal 103</a> comments, it is clear that cross-chain proposals, and specifically the choice of which bridge to use, can be improved for all governance stakeholders.
We also note that the BSC Deployment process will continue to move forward with the steps stated in that comment. There is a <a href="https://snapshot.org/#/uniswap/proposal/0x6b8df360fdf73085b21fdf5eef9f85916fbde95621a3d454cb20fbe545ffc852">Snapshot Poll 82</a> to select a bridge going on now that will end on Tuesday Jan. 31. The final BSC Governance vote will kick off after that, with the selected bridge.
As for the Assessment Process and Team, our proposal is as follows. Note we are seeking feedback on the process, as well as nominations for team members, and applications from bridge providers.
The outputs and process below aim to:
<ul>
<li>Support delegates and community members in making informed decisions related to cross-chain deployments.</li>
<li>Provide process clarity to bridge providers.</li>
<li>Remove inefficiency in the governance process moving forward for all governance stakeholders.</li>
</ul>
<h1>
<a name="deliverables-1" href="#deliverables-1"></a>Deliverables</h1>
We believe the deliverables below would be beneficial to the Uniswap community as a whole. The UF will support a process that will generate the following:
<ol>
<li>An extensive review of bridge providers which: 
a. Verifies key information about the bridge (template below) 
b. Identifies risk vectors to Uniswap governance, assigning them a risk level (Green, Yellow, Red)</li>
<li>Recommendation of one or multiple approaches in which to select bridge providers (and/or agnostic solution(s)) per deployment moving forward. This approach, or approaches, should be actionable in the short term in order to cater to cross-chain proposals put forth prior to the BSL expiry on April 1st, or shortly thereafter. This could take a number of forms, including for example diversifying deployments across a set of trusted bridges (on a 1/n basis, or otherwise).</li>
<li>Recommendation of one or multiple ways in which this team, or others, may continue to monitor bridge risk and support the community in the governance process on an ongoing basis.</li>
<li>Recommendation of one or multiple ways in Uniswap governance may approach bridging over a longer-term timeframe.</li>
</ol>
<h1>
<a name="process-2" href="#process-2"></a>Process</h1>
To create the deliverables above, we propose the following process:
Selection of a team of 4 engineers and 1 project manager
<ol>
<li>These individuals should be available for 10-15 hours per week over the next few weeks to participate in the assessment process, and to write up their findings in a report to share with the community.</li>
<li>Each engineer will be compensated $300/hour. The PM will be compensated $200/hour.</li>
<li>These individuals should not be on a bridge team or have a vested interest in any bridge. If there are any remaining conflicts of interest, outside of being on a bridge team or having a vested interest in a bridge team, those should be disclosed. The UF will do the best it can to select a team with no conflicts of interest whatsoever. However, we note that it is likely that those who are most adept at inspecting bridges and similar solutions may now or in the past have worked with a bridge or related team in some fashion in the past (I.e., bridge aggregator teams). If an otherwise fantastic candidate has some conflict, that will be disclosed upon the announcement of the team.
</li>
<li>The UF plans to select the engineers who will be participating in the group. Selection criteria for the engineers will include the following: relevant technical experience, understanding of bridge architectures and potential risk vectors, and alignment with Uniswap’s interests. For the PM role, selection criteria will include organizational skills, experience with technical writing, context into bridge architectures and potential risk vectors, and alignment with Uniswap’s interests.</li>
<li>The UF has a shortlist of candidates already, and we would love for additional candidates to be proposed in the forum below. For those who wish to nominate themselves, please post the following information in the forum below: 
a. Name, affiliation, Twitter handle 
b. Qualifications as they relate to the criteria stated above, stated briefly 
c. Explanation of why you are interested in becoming a member of this team</li>
<li>We will wait to finalize the team selection process until community feedback has been provided and incorporated through at least February 17th. In the interim we are excited for candidates to raise their hands and introduce themselves.</li>
</ol>
Selection of a set of bridges to review. This list should include, to start, deBridge, Celer, Wormhole, LayerZero, and the bridge-agnostic solutions which have been proposed thus far (for example, Kydo’s MMA design and Celer’s Multi bridge implementation) To be included in the assessment, a bridge must:
<ol>
<li>Be launched on mainnet, and have audits completed by at least two audit firms</li>
<li>Answer the questions listed below in the forum. Please post responses to the question directly, do not alter the format of your response from Q&amp;A. (We ask deBridge, Celer, Wormhole, LayerZero, and the developers of agnostic solutions to provide answers below to consolidate information for the assessment team - previous responses from BSC forum post may be used if relevant.)
</li>
<li>Pay $5,000 in USDC to the Uniswap Foundation, to cover part of the payment to the assessment team, prior to the assessment beginning. The intention of this fee is to test a compensation model for this team to provide governance support on an ongoing basis.</li>
<li>Alternative solutions such as the agnostic solutions cited above will be included in the assessment.</li>
</ol>
An assessment process: engineers should review the answers to the questions on the bridges in the comments below, then take steps to verify that information through a review of developer documentation, audits, smart contracts directly, and discussions with the bridge team. Further diligence into other risk vectors which may not be directly addressed in the questions below should be conducted by the team as well. Previous discussions in the forum (for instance, the chain on Other Internet’s <a href="https://gov.uniswap.org/t/rfc-uniswap-universal-governance-module/16829">UGM 7</a> process) may also be reviewed for added context.
A report, published to the community. This report should include the 3 deliverables listed above.
<h1>
<a name="timeframe-3" href="#timeframe-3"></a>Timeframe</h1>
We propose the following timeframe for the process described above:
Through Friday, Feb. 17 (or further into the future, as mentioned above)
<ul>
<li>
Community provides feedback on the proposal suggested above.</li>
<li>
Bridges submit their interest in being considered by answering the questions below in the forum.</li>
<li>
Assessment team candidates respond in the forum below with the information required (Name, affiliation, Twitter handle, fulfillment of criteria, interest). We have proposed steps below by which applicants will be chosen for the final team, though we may receive community feedback to adjust this process prior to February 17th.</li>
</ul>
Wednesday, Feb. 23
<ul>
<li>Announce the final process to be used, incorporating community feedback (this may include adjustments to the team selection process)</li>
<li>Announce the list of bridges to be considered</li>
<li>Announce the list of assessment team members</li>
</ul>
Monday, March 20
Initial reviews of all bridges conducted.
Monday, March 27
Final report published with community recommendations.
<h2>
<a name="team-member-application-4" href="#team-member-application-4"></a>Team Member Application</h2>
<h3>
<a name="phase-1-5" href="#phase-1-5"></a>Phase 1</h3>
Please provide the following information in the comments below. 
a. Name, affiliation, Twitter handle 
b. Qualifications as they relate to the criteria stated above, stated briefly 
c. Explanation of why you are interested in becoming a member of this team
<h3>
<a name="phase-2-6" href="#phase-2-6"></a>Phase 2</h3>
We propose that final team members should be chosen in the following manner. We are open to receiving feedback on this approach, and welcome that feedback in the comments below.
<ol>
<li>Each applicant (without any disqualifying characteristics, for instance close association to a bridge team) has a 30 minute interview with the Uniswap Foundation team.</li>
<li>Each applicant provides a referral to vouch to the applicant’s ability to effectively fulfill this role.</li>
<li>UF confirms applicant’s independence, to the extent possible.</li>
<li>UF selects final team members. UF provides an explanation as to why each team member was chosen.</li>
</ol>
<h2>
<a name="bridge-questions-7" href="#bridge-questions-7"></a>Bridge Questions</h2>
Please answer all these questions for the current deployed version of your bridge in a comment below. Your response should directly answer these questions in Q&amp;A format - please do not alter the format of your response.
<ol>
<li>List 3 succinct reasons why you believe your bridge/solution would best serve Uniswap governance.</li>
<li>How long has the system been running on mainnet?</li>
<li>How much value has the system secured? (Current TVL, total transaction volume)</li>
<li>Provide a background on your team.</li>
<li>Please link your developer documentation.</li>
<li>Does the bridge support arbitrary message passing?</li>
<li>Has the current deployed bridge code been audited? By a third party? What attack vectors and vulnerabilities were identified, if any? Have the identified vulnerabilities been remedied?</li>
<li>Is there a bug bounty program?</li>
<li>List ANY portion of the functional bridge that is upgradeable and explain how the upgrade process works.</li>
<li>Do any contracts have an owner or owner-like entity? If so, what can the owner do?</li>
<li>What is the security model of the bridge? Please describe the security model for the current implementation of the bridge. What trust assumptions are you making?</li>
<li>How can an adversary pass a fraudulent message from Ethereum to the destination chain? Please give specific and concrete examples.</li>
<li>How can an adversary withhold a valid governance message from Ethereum to the destination chain? Please give specific and concrete examples.</li>
<li>What are the ramifications of fraud to the malicious actor(s)? If it is legal ramification, please share the suite of legal action you can provide. If it is slashing, please point us to the codebase of the slashing behavior and describe in words how slashing works in your system.</li>
<li>Provide any additional information you would like here.</li>
</ol>

Cross-Chain Bridge Assessment Process   The tentative deadline to provide feedback on the process below

Cross-Chain Bridge Assessment Process

<h2>
<a name="tldr-1" href="#tldr-1"></a>TL;DR
</h2>
<ul>
<li>
One of the goals of the <a href="https://gov.uniswap.org/t/governance-proposal-create-the-uniswap-foundation/17499">Uniswap Foundation 6</a> is to reduce the amount of friction in the community governance process. In that spirit, today we are proposing changes to that process to improve its efficiency and efficacy.
</li>
<li>
We propose the following changes to the community governance process:
</li>
</ul>
<ol>
<li>
Remove the first off-chain Snapshot poll, and replace it with a “Request for Comment” post. The first phase of the governance process should allow the community to digest a proposal, comment, and ask questions – and for the proposer to respond and make updates. We also believe two off-chain votes introduces unnecessary friction, so we propose removing this first one.
</li>
<li>
Increase quorum for the remaining off-chain Snapshot poll in the second phase to 5M UNI. The purpose of this off-chain vote is to gauge community sentiment prior to the governance vote. We believe the 5M UNI quorum will act as a better signal than the lower quorum requirements in the current process.
</li>
</ol>
<ul>
<li>
We also propose to formalize a process for future changes to off-chain components of the governance process (like the changes discussed in this proposal): specifically, an off-chain Snapshot poll with the same parameters of the on-chain governance vote. Today, this would require a 7-day voting period with a 40M UNI quorum. All changes that entail changes to on-chain parameters should continue to go through the normal community governance process.
</li>
<li>
In 3 weeks, on Monday, December 12, we will post a Snapshot poll for the community to vote on these changes. As described above, the vote will last for 7-days and have a 40M UNI quorum.
</li>
</ul>
<h2>
<a name="summary-2" href="#summary-2"></a>Summary
</h2>
Uniswap’s governance process is a core input to the community’s ability to steward its ongoing maintenance and growth in a fair and transparent manner. The design of the process should optimize for the dissemination of information throughout the community, for thoughtful iterations on proposals, and for signaling from the community prior to on-chain votes. While the governance process put in place today has, for the most part, been successful in achieving those goals, we believe improvements can be made to reduce overhead and to enhance off-chain signaling prior to the final governance vote.
These process enhancements were previously discussed in the forum <a href="https://gov.uniswap.org/t/proposed-simplifications-to-the-uniswap-governance-process/15906">here 5</a>, but the simplifications were never implemented. We have decided to bring them back with minor changes.
Below we lay out the suggested changes, alongside our rationale. We are excited to hear and incorporate your feedback into this process change.
<div><a href="https://global.discourse-cdn.com/business6/uploads/uniswap1/original/2X/7/75520158aa8467d236ea8ab76a816174497405cf.png"><div>
Group 1 (1)1729×1138 87.1 KB
</div></a></div>
<h2>
<a name="current-process-3" href="#current-process-3"></a>Current Process
</h2>
A detailed outline of the current process can be found <a href="https://docs.uniswap.org/concepts/governance/process">here 6</a>.
<ol>
<li>
Temperature Check: A temperature check is accompanied by a 3-day snapshot poll with a 25k UNI quorum.
</li>
<li>
Consensus Check: A consensus check is accompanied by a 5-day snapshot poll with a 50k UNI quorum.
</li>
<li>
Governance Proposal: The on-chain proposal and vote, tied to on-chain executable code, is the final phase of the governance process. The proposer must have a minimum of 2.5M UNI delegated to their address, and there is a 40M UNI quorum requirement.
</li>
</ol>
<h2>
<a name="proposed-changes-to-community-governance-process-4" href="#proposed-changes-to-community-governance-process-4"></a>Proposed changes to community governance process
</h2>
Phase 1: Request for Comment
<ul>
<li>Rename: Temperature Check → Request for Comment</li>
<li>Removal of Snapshot off-chain vote</li>
<li>A minimum of 3 days before moving forward</li>
</ul>
We believe the first phase of the governance process should allow the community to digest a proposal, comment, and ask questions. The RFC Phase should last for at least 3 days so the proposers can gather adequate feedback to take into account for the next iteration of the proposal.
We are also removing the friction of two off-chain votes.
Phase 2: Temperature Check
<ul>
<li>Rename: Consensus Check → Temperature Check</li>
<li>Increase the required quorum from 50k to 5M UNI</li>
</ul>
For this phase to better serve as a signaling tool, we suggest increasing quorum to 5M UNI. This threshold should be high enough to prevent lower quality proposals from moving to the final on-chain vote, while not creating additional friction.
Phase 3: On-chain Governance Vote
<ul>
<li>No changes</li>
</ul>
<h2>
<a name="proposed-formalization-of-process-changes-to-off-chain-components-of-governance-process-5" href="#proposed-formalization-of-process-changes-to-off-chain-components-of-governance-process-5"></a>Proposed formalization of process changes to off-chain components of governance process
</h2>
In her original <a href="https://gov.uniswap.org/t/community-governance-process/7732">post 4</a> on the community governance process, Ashleigh states “On-chain voting is not necessary to make updates to off-chain processes.” We agree with this. However, we do believe that community support and acceptance is important for off-chain process changes to have legitimacy.
Thus, we propose a formalized process – intended to signal community support and acceptance – to change these off-chain components in the future. Specifically, we propose an off-chain vote with the same parameters of the final governance vote. Right now, that is a 7 day vote period and 40M UNI quorum.
These are the parameters we plan to use to pass all of the proposed changes in this proposal.
<h2>
<a name="conclusion-and-next-steps-6" href="#conclusion-and-next-steps-6"></a>Conclusion and Next Steps
</h2>
We welcome all feedback from the community on these proposed changes, and will incorporate feedback into the proposal where sentiment is strong.
If no serious changes to the proposal are required, we plan to post a Snapshot Poll in 3 weeks, on Monday, December 12th for the community to vote on these changes. This vote will last for 7 days and require a quorum of 40M UNI votes.
If the vote passes, the UF will update relevant documentation on the forum and elsewhere.

[Temperature Check] Create the Uniswap Foundation

Cross-Chain Bridge Assessment Process

[RFC] Community Governance Process Changes

[RFC] Community Governance Process Changes

Got something to add?