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 BSC Deployment Proposal 103 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 Snapshot Poll 82 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:

Support delegates and community members in making informed decisions related to cross-chain deployments.
Provide process clarity to bridge providers.
Remove inefficiency in the governance process moving forward for all governance stakeholders.

Deliverables

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:

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)
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).
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.
Recommendation of one or multiple ways in Uniswap governance may approach bridging over a longer-term timeframe.

Process

To create the deliverables above, we propose the following process:

Selection of a team of 4 engineers and 1 project manager

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.
Each engineer will be compensated $300/hour. The PM will be compensated $200/hour.
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.
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.
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
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.

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:

Be launched on mainnet, and have audits completed by at least two audit firms
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&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.)
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.
Alternative solutions such as the agnostic solutions cited above will be included in the assessment.

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 UGM 7 process) may also be reviewed for added context.

A report, published to the community. This report should include the 3 deliverables listed above.

Timeframe

We propose the following timeframe for the process described above:

Through Friday, Feb. 17 (or further into the future, as mentioned above)

Community provides feedback on the proposal suggested above.
Bridges submit their interest in being considered by answering the questions below in the forum.
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.

Wednesday, Feb. 23

Announce the final process to be used, incorporating community feedback (this may include adjustments to the team selection process)
Announce the list of bridges to be considered
Announce the list of assessment team members

Monday, March 20

Initial reviews of all bridges conducted.

Monday, March 27

Final report published with community recommendations.

Team Member Application

Phase 1

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

Phase 2

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.

Each applicant (without any disqualifying characteristics, for instance close association to a bridge team) has a 30 minute interview with the Uniswap Foundation team.
Each applicant provides a referral to vouch to the applicant’s ability to effectively fulfill this role.
UF confirms applicant’s independence, to the extent possible.
UF selects final team members. UF provides an explanation as to why each team member was chosen.

Bridge Questions

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&A format - please do not alter the format of your response.

List 3 succinct reasons why you believe your bridge/solution would best serve Uniswap governance.
How long has the system been running on mainnet?
How much value has the system secured? (Current TVL, total transaction volume)
Provide a background on your team.
Please link your developer documentation.
Does the bridge support arbitrary message passing?
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?
Is there a bug bounty program?
List ANY portion of the functional bridge that is upgradeable and explain how the upgrade process works.
Do any contracts have an owner or owner-like entity? If so, what can the owner do?
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?
How can an adversary pass a fraudulent message from Ethereum to the destination chain? Please give specific and concrete examples.
How can an adversary withhold a valid governance message from Ethereum to the destination chain? Please give specific and concrete examples.
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.
Provide any additional information you would like here.