Cross-Chain Bridge Assessment Process

[devinwalsh]

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 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 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:

1. 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)
2. 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).
3. 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.
4. 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

1. 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.
2. Each engineer will be compensated $300/hour. The PM will be compensated $200/hour.
3. 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.
4. 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.
5. 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
6. 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:

1. Be launched on mainnet, and have audits completed by at least two audit firms
2. 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.)
3. 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.
4. 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 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.

1. Each applicant (without any disqualifying characteristics, for instance close association to a bridge team) has a 30 minute interview with the Uniswap Foundation team.
2. Each applicant provides a referral to vouch to the applicant’s ability to effectively fulfill this role.
3. UF confirms applicant’s independence, to the extent possible.
4. 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.

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

[Kydo]

Multi-Message-Aggregation (MMA)

A General Design for Multi-Bridge Governance.

Abstract

Multi-Message-Aggregation (MMA) is a message aggregation method for Uniswap to securely relay governance instructions from Ethereum to another chain. Instead of making one bridge provider the default message relayer, MMA relies on multiple bridge providers and a group of signers. This design offers more security than any one bridge and is designed for governance-related tasks. Moreover, this design is relatively engineering-lite and can be implemented in a reasonable time.

Compared to the existing design

Compared to the Universal Governance Model by @AlexSmirnov @modong , this design does not rely on an algorithmically onchain selecting function. We believe this mechanism should be reserved for future implementation due to 1) its potentially long engineering time, 2) new attack surface/bugs due to increased code complexity, and 3) the difficulty to standardize messaging formats across bridge providers. Instead, we delegate this algorithmic function to a 11/15 multisig. The multisig will select the message which will be executed. This way, we believe while keeping the contract complexity and engineering time low, we can still achieve high-security guarantees.

MMA Design

The MMA design can be split into three parts. Ethereum, the destination chain, and the off-chain world. On Ethereum, it is made up of the Uniswap Governance Complex (refers to the smart contracts that Uniswap relies on to issue governance actions) and individual bridge endpoints. In the off-chain world, there are bridge providers and multisig signers. On the destination chain, there are bridge endpoints, a message selection contract, and Uniswap contracts.

On Ethereum, once a governance proposal is approved and is related to deployments on other chains, the governance complex will send messages to each individual bridge endpoints for relaying to the destination chain(s). For simplicity, we will assume we are only sending governance message to one destination chain, but the concept is the same when sending to multiple chains. This design will not change the current voting process but would require the governance payload to be modified if cross-chain governance is involved.

Once the message reached the endpoint on the Ethereum side, each bridge provider will handle relaying the message to the destination chain independently.

Once the bridge provider relayed the message to the destination chain’s endpoint, the endpoint will send the message into the Message Selection Contract. The multisig will then select which message to execute and submit a transaction executing the message on the destination chain. We are recommending an 11/15 Safe multisig.

The rough implementation of the Message Selection Contract can be found here.

Security

Two kinds of malicious activities could surface: 1) fradulent governance message and 2) withholding attack.

A fradulent governance message is a governance message that got executed on the destination chain but was not approved by the Ethereum Uniswap Governance Complex. This can happen if and only if an adversary took control of one or more of the bridge providers AND more than 11 of the multisig signers. The adversary would first need to use the bridge provider to pass in a fradulent governance message into the Message Selection Contract and then use the 11 of the signers to approve the transaction to be executed. We believe this is unlikely to happen because hacking 11 independent signers and a bridge provider is not economically profitable to attack the governance bridge.

A withholding attack is when more than 4 of the multisig signers or all of the bridge providers refuse to sign or relay the message. Bridge’s withholding attack would be a concern if Uniswap has only one bridge provider; however, given we have three in this example, simultaneous withholding attacks from the bridge providers would be extremely unlikely. Multisig signers’ withholding attack could be more likely given the small subset of the participants involved. To address this problem, we should have a governance process to elect only the reputable governance delegate for this multisig role; alternatively, we could increase the total multisig size to make a withholding attack harder to coordinate.

Summary

We proposed a cross-chain governance mechanism, Multi-Message-Aggregation (MMA). This design aggregates messages relayed by bridge providers and a group of multisig signers select which message from the set to execute. MMA aims to be an intermediary solution for cross-chain governance between relying on one bridge provider and algorithmically aggregating multiple bridge providers. The security guarantee of MMA is also higher when compared to a single bridge provider.

We would love to hear thoughts from other technical members within the Uniswap ecosystem on MMA and the potential security vulnerability or engineering difficulties involved.

[Kydo]

After discussion with some members of the community, we also realized that the Safe multisig module and its corresponding front-end might not be available on some chains and could seriously limit the security assumption of this model. Therefore, we would love to see if there is an alternative approach to address this vulnerability.

[modong]

A Multi-bridge Implementation for Uniswap Governance is Now Available

This post includes the implementation of a multi-bridge Uniswap governance solution that is vendor-lock-in-free for Uniswap community to consider.

This solution is strictly better than choosing a single bridge in terms of security and availability. In addition, it also retains the strongest bargaining power in the hands of Uniswap community to always receive the best services. See this for more context.

The implementation combines both Celer and Wormhole and is open-sourced here

sgn-v2-contracts/contracts/message/apps/multibridge at multibridge ·...

All other bridges/cross-chain solutions such as LayerZero can be added easily via adapters.

A testnet deployment is done.

Setup:

• Source Chain: Avalanche Fuji testnet
• Destination Chain: BSC testnet

The reason we did not use Ethereum Goeril is that there is no available generic relayer from @Wormhole on Goeril and Wormhole team has not responded to us in assisting things.

• Cross-chain solutions used: Celer, Wormhole
• Contract addresses:
  – MultiBridgeSender Fuji 0x5a5F095183241f4B23a7Aa7f8949fd02D06CaeCf
  – CelerSenderAdapter fuji 0x243b40e96c6bF21511E53d85c86F6Ec982f9a879
  – WormholeSenderAdapter fuji
  0x0cb93b5c42437FE78b3697740D15b46707f97361
  – MultiBridgeReceiver bsctest 0x207fF5290Bb518D963CF0a62B371B5B2dB6943A2
  – CelerReceiverAdapter bsctest 0x37D2F4DCb5986ce2639bd66B022dcb9e3879156c
  – WormholeReceiverAdapter bsctest
  0xa5711D74780527484Be167bA3052eD3700d52B1D
  – UniswapV3Factory bsctest
  0x0bEC2a9E08658eAA15935C25cfF953caB2934C85

Test results:

• Source chain transaction: Avalanche Transaction Hash (Txhash) Details | SnowTrace
• Destination Chain tx1: message from wormhole:
  Binance Transaction Hash (Txhash) Details | BscScan
• Destination Chain tx2: message from celer and execute the governance call:
  Binance Transaction Hash (Txhash) Details | BscScan

Now let’s get to the solution specification.

Send Cross-Chain Messages through Multiple Bridges

This is a solution for cross-chain message passing without vendor lock-in and with enhanced security beyond any single bridge. A message with multiple copies are sent through different bridges to the destination chains, and will only be executed at the destination chain when the same message has been delivered by a quorum of different bridges.

The current solution are designed for messages being sent from one source chain to multiple destination chains. It also requires that there is only one permitted sender on the source chain. This would be the use case for Uniswap governance contract on Ethereum
calling remote functions of contracts on other EVM chains.

Workflow

Send message on source chain

To send a message to execute a remote call on the destintion chain, sender on the source chain should call remoteCall() of MultiBridgeSender, which invokes sendMessage() of every bridge sender apdater to send messages via different message bridges.

┌─────────────────────────────────────────────────────────────────────────────────────────────────────────┐
│ Source chain                                                                                            │
│                                                                                                         │
│                                                             ┌─────────────────┐   ┌───────────────────┐ │
│                                                         ┌──►│ Bridge1 Adapter ├──►│ Bridge1 Contracts │ │
│                                                         │   └─────────────────┘   └───────────────────┘ │
│                                                         │                                               │
│ ┌────────┐remoteCall()┌───────────────────┐sendMessage()│   ┌─────────────────┐   ┌───────────────────┐ │
│ │ Caller ├───────────►│ MultiBridgeSender ├─────────────┼──►│ Bridge2 Adapter ├──►│ Bridge2 Contracts │ │
│ └────────┘            └───────────────────┘             │   └─────────────────┘   └───────────────────┘ │
│                                                         │                                               │
│                                                         │   ┌─────────────────┐   ┌───────────────────┐ │
│                                                         └──►│ Bridge3 Adapter ├──►│ Bridge3 Contracts │ │
│                                                             └─────────────────┘   └───────────────────┘ │
│                                                                                                         │
└─────────────────────────────────────────────────────────────────────────────────────────────────────────┘

Receive message on destination chain

On the destination chain, MultiBridgeReceiver receives messages from every bridge receiver adapter. Each receiver adapter gets encoded message data from its bridge contracts, and then decode the message and call receiveMessage() of MultiBrideReceiver.

MultiBridgeReceiver maintains a map from bridge adapter address to its power. Only adapter with non-zero power has access to receiveMessage() function. If the accumulated power of a message has reached the a threshold, which means enough number of different bridges have delivered a same message, the message will be executed by the MultiBrideReceiver contract.

The message execution will invoke a function call according to the message content, which will either call functions of other contracts, or call the param adjustment functions of the MultiBridgeReceiver itself. Note that the only legit message sender is the trusted dApp contract on the source chain, which means only that single dApp contract has the ability to execute functions calls through the MultiBridgeReceiver contracts on different other chains.

┌────────────────────────────────────────────────────────────────────────────────────────────────────────────┐
│ Destination chain                                                                                          │
│                                                                                                            │
│ ┌───────────────────┐   ┌─────────────────┐                                                                │
│ │ Bridge1 Contracts ├──►│ Bridge1 Adapter ├──┐                                                             │
│ └───────────────────┘   └─────────────────┘  │                                                             │
│                                              │                                                             │
│ ┌───────────────────┐   ┌─────────────────┐  │receiveMessage()┌─────────────────────┐ call()  ┌──────────┐ │
│ │ Bridge1 Contracts ├──►│ Bridge2 Adapter ├──┼───────────────►│ MultiBridgeReceiver ├────────►│ Receiver │ │
│ └───────────────────┘   └─────────────────┘  │                └─────────────────────┘         └──────────┘ │
│                                              │                                                             │
│ ┌───────────────────┐   ┌─────────────────┐  │                                                             │
│ │ Bridge2 Contracts ├──►│ Bridge3 Adapter ├──┘                                                             │
│ └───────────────────┘   └─────────────────┘                                                                │
│                                                                                                            │
└────────────────────────────────────────────────────────────────────────────────────────────────────────────┘

Add new bridge and update threshold

Below are steps to add a new bridge (e.g. Bridge4) by the dApp community.

1. Bridge4 provider should implement and deploy Bridge4 adapters on source chain and all destination chains. The adapter contracts should meet the following requirements.
   • On the source chain, the sender adapter should only accept sendMessage() call from MultiBridgeSender.
   • On the destination chain, the receiver adapter should only accept messages sent from the Bridge4 sender adapter on the source chain, and then call receiveMessage() of MultiBridgeReceiver for each valid message.
   • Renounce any ownership or special roles of the adapter contracts after inital parameter setup.
2. Bridge4 provider deploy and open source the adapter contracts. dApp community should review the code and check if the requirements above are met.
3. dApp contract (Caller) on the source chain adds the new Bridge4 sender adapter to MultiBridgeSender on the source chain by calling the addSenderAdapters() function of MultiBridgeSender.
4. dApp contract (Caller) on the source chain adds the new Bridge4 receiver adapter to MultiBridgeReceiver on the destination chain by calling the remoteCall() function of MultiBridgeSender, with arguments to call updateReceiverAdapter() of the MultiBridgeReceiver on the destination chain.

Updating quorum threshold is similar to configure a new bridge receiver adapter on destination chain. It requires a remoteCall() from the source chain Caller with calldata calling updateQuorumThreshold() of the MultiBridgeReceiver on the destination chain.

Example

Use case: contract A on Goerli send message to contract B on BSC Testnet in order to call enableFeeAmount() for state change. Apply a 2-of-3 messages governance model with message bridge C, D and E.

Deployment and initialization

• Deploy MultiBridgeSender on Goerli, set address of A as allowed caller.
• Deploy MultiBridgeReceiver on BSC Testnet.
• Each message bridge provider prepare their own SenderAdapter and ReceiverAdapter, named with a prefix of their bridge name. Take preparation of CSenderAdapter and CReceiverAdapter as an example.
  • Deploy CSenderAdapter on Goerli, set address of MultiBridgeSender as multiBridgeSender.
  • Deploy CReceiverAdapter on BSC Testnet, set address of MultiBridgeReceiver as multiBridgeReceiver.
  • Call updateReceiverAdapter() of CSenderAdapter, set address of CReceiverAdapter on BSC Testnet(chain id 97) as a valid ReceiverAdapter.
  • Call updateSenderAdapter() of CReceiverAdapter, set address of CSenderAdapter on Goerli(chain id 5) as a valid SenderAdapter.
  • Transfer ownership of CSenderAdapter and CReceiverAdapter to address(0).
• Once all message bridges are ready, somehow let contract A call addSenderAdapters() of MultiBridgeSender with an address array of CSenderAdapter, DSenderAdapter and ESenderAdapter.
• Call initialize() of MultiBridgeReceiver, with an address array of CReceiverAdapter, DReceiverAdapter and EReceiverAdapter, and power threshold 2.

Sending your message

Prepare a calldata for contract B for calling enableFeeAmount(), then somehow let contract A call remoteCall() of MultiBridgeSender with _dstChainId = 97, _target = <address of contract B> and _callData = <calldata you prepared>.

Result

Imagine that the messages sent via C, D and E received by MultiBridgeReceiver on BSC Testnet in an order of 1.C 2.D 3.E. During receiving message sent via D, accumulated power reaches power threshold 2, which result in message execution(the calldata will be sent to contract B).

Notes to the community

We are more than happy to answer any questions, help with tests, collaborate with similar-minded builders like @AlexSmirnov, iterate based on feedbacks and provide audits from community selected firms.

Although Celer, being a 2018-vintage project, does not have the backing of large UNI-holding investors at this moment, we do trust the integrity and intelligence of all the Uniswap delegates to choose this positive-sum path that ensures the highest level of security and service quality for Uniswap’s multi-blockchain expansion.

[modong]

A testnet deployment is done.

Setup:

• Source Chain: Avalanche Fuji testnet
• Destination Chain: BSC testnet

The reason we did not use Ethereum Goeril is that there is no available generic relayer from @Wormhole on Goeril and Wormhole team has not responded to us in assisting things.

• Cross-chain solutions used: Celer, Wormhole
• Contract addresses:
  – MultiBridgeSender Fuji 0x5a5F095183241f4B23a7Aa7f8949fd02D06CaeCf
  – CelerSenderAdapter fuji 0x243b40e96c6bF21511E53d85c86F6Ec982f9a879
  – WormholeSenderAdapter fuji
  0x0cb93b5c42437FE78b3697740D15b46707f97361
  – MultiBridgeReceiver bsctest 0x207fF5290Bb518D963CF0a62B371B5B2dB6943A2
  – CelerReceiverAdapter bsctest 0x37D2F4DCb5986ce2639bd66B022dcb9e3879156c
  – WormholeReceiverAdapter bsctest
  0xa5711D74780527484Be167bA3052eD3700d52B1D
  – UniswapV3Factory bsctest
  0x0bEC2a9E08658eAA15935C25cfF953caB2934C85

Test results:

• Source chain transaction: Avalanche Transaction Hash (Txhash) Details | SnowTrace
• Destination Chain tx1: message from wormhole:
  Binance Transaction Hash (Txhash) Details | BscScan
• Destination Chain tx2: message from celer and execute the governance call:
  Binance Transaction Hash (Txhash) Details | BscScan

Happy to answer any questions!

[AlexSmirnov]

Hi Mo, great job by the Celer team on developing the implementation! In deBridge, we reviewed the developed code, and it looks good and fits the design that we proposed earlier.

We will prepare a PR with an adapter for the deBridge infrastructure by tomorrow and will ask our security audit partner Halborn to perform a security audit of the developed code

[asselstine]

Hi all! I’m Brendan from PoolTogether. We also had a need for a chain-agnostic bridging standard. We didn’t want to write bespoke code for every single bridge, so we worked with others to design an ERC to standardize the call structure.

ERC-5164: Cross-Chain Execution was developed in partnership with Hop Protocol and others. This ERC is designed to be a bridge-agnostic standard for communicating with smart contracts across bridges.

PoolTogether has written ERC-5164 wrappers for:

• Optimism
• Arbitrum
• Polygon

The implementation was audited by C4. Check out pooltogether/ERC5164 on Github.

Hop Protocol V2 will be launching soon and will include ERC-5164 messaging. I believe V2 will support messaging between 15 different chains. Binance Smart Chain may be one of them; but I don’t know. Edit: I’ll ping the team

No matter what cross-chain execution solution Uniswap opts for, it would be great for us to rally around ERC-5164 so that we can leverage each other’s efforts and avoid vendor lock-in. Ideally the Uniswap engineers or bridges can build ERC-5164 adapters.

[cwhinfrey]

Hi all, we’d love to see ERC-5164 used here and it’s been a pleasure working with Brendan, Pierrick, and the rest of the PoolTogether folks on this. We hope ERC-5164 facilitates greater composability and competition amongst bridges and prevents bridge lock-in. Ultimately, this is healthy for the space and we think Hop can succeed on its own merits.

We’re really excited about Hop v2 and the Hop Core Messenger. We believe it’s currently the only bridge that provides users and LPs with the full economic security of the network they’re on.

As much as we’d love to see Hop used by Uniswap for Ethereum <> BSC messaging, it’s likely not a good fit right now. Hop currently has the same dependency as Uniswap and relies on an existing message bridge with Ethereum for a network to be supported. If Hop were to add BSC support, we’d have the same discussion and analyze the same solutions discussed above. The chosen solution would act as a replacement for the native message bridge typically seen in rollup designs which Hop was built for. I do think the solutions discussed above are good enough for Uniswap’s use case given Uniswap’s tightly-scoped governance controls but likely have not achieved the level of trustlessness needed for Hop’s use case which involves the full custody of Hop-controlled assets on the spoke network.

Down the road, if Uniswap has a need for sending trustless spoke-to-spoke messages, spoke-to-Ethereum messages, or synchronizing state across all networks, this is where the Hop Core Messenger and various messaging systems built on top can add the most value. In the meantime, we’ll be releasing some open-source contract libraries that may be useful, will continue to support the ERC-5164 initiative, and are eager to help here where we can.

[AlexSmirnov]

Integration of deBridge Adapter into Multi-Bridge Implementation

In deBridge, we’d like to express our support for a multi-bridge Implementation developed by Celer team. We made a pull request (PR) where developed an adapter that adds support for deBridge infrastructure into the proposed multi-bridge framework.

To test out integration, we performed a mainnet deployment of all smart contracts in BNB and Polygon Chains and made a test updateQuorumThreshold() operation initiated in the MultiBridgeSender contract in BNB Chain and successfully settled in the MultiBridgeReceiver Polygon.

Transaction details can be found in deBridge explorer.

The source code and additional details are available here:
https://github.com/celer-network/sgn-v2-contracts/pull/232

We would like to encourage all bridge teams that support multi-bridge Implementation to make similar pull requests, adding their bridge adapter to the framework

Advantages of multi-bridge implementation

Beyond what was previously mentioned by @modong, there are a few more benefits to the multi-bridge approach:

1. In order to add an adapter, every bridge team will have to perform a code review of the developed implementation. This helps to improve security by having more pairs of eyes on the code.
2. Each bridge team should perform the integration and develop the adapter before the start of the assessment process, that allows the assessment team to use the source code and deployed implementation of the adapter to better understand the design of the bridge and review how integration will work in practice.
3. The multi-bridge solution is versatile and can increase security, even for blockchain ecosystems with a canonical bridge, which is just one of the bridges participating in the framework. In the event of a problem or vulnerability in the canonical bridge, malicious messages or proposals can be prevented as confirmations from non-canonical bridges are still required.

Community feedback

I also wanted to comment on the following points which @Kydo raised above:

@Kydo

1. its potentially long engineering time, 2) new attack surface/bugs due to increased code complexity, and 3) the difficulty to standardize messaging formats across bridge providers

1. The multi-bridge solution turned out to be relatively simple and not much different from vendor-locked integration. Complexities of each specific bridge integration are abstracted into adapters that are developed by each bridge team who wants to join the framework.
2. Like with a single bridge integration, the code should undergo thorough testing by the community and pass security audits.
3. The advantage of the proposed solution is that standardization is achieved through adapters developed by each bridge team, providing a standardized approach across all bridges.

We’d love to hear feedback from @kydo and other community members on potential risks and problems of proposed implementation as well as ideas of what can be improved.

Request for Code Reviews and Security Audits

Code reviews and security audits for the solution would help to assess security risks of the developed implementation.

If no significant issues or requests for improvements are identified within next 7 days, we will be ready to initiate and cover the cost of a security audit by Halborn.

[jkol]

Hey all, Asa and Jon from Hyperlane here.

We believe that Uniswap’s governance bridge selection criteria should prioritize safety and lack of vendor lock-in. Since this is a governance based use-case, the clear parameter to optimize for in this case is safety, while others such as speed or cost are irrelevant. Given this we are in clear support for the Multi Message Aggregator (MMA) design proposed by @Kydo , and previously by others such as @blockchaincolumbia and several bridge providers.

Below, we make the case for support for the MMA, and how the MMA design can be implemented with Hyperlane.

Safety via defense-in-depth

With respect to safety, believe the most important principle is defense-in-depth, a principle championed by the proposals from Kydo, Blockchain@Columbia, and others. In our opinion, the best approach to defense-in-depth is to aggregate the security models of multiple bridge providers as proposed by the MMA, as well as to optionally include security provided by elected members of the Uniswap community (e.g. via a Gnosis Safe).

As far as we can tell (and we are very biased), Hyperlane is the only platform that is able to provide this aggregation natively.

Bridge aggregation with Hyperlane Interchain Security Modules

With Hyperlane, users such as Uniswap can specify custom Interchain Security Modules (ISMs), smart contracts which contain the logic to verify their interchain messages.

This allows Uniswap to, for example, specify an ISM that requires the following:

• Verification of the message by Wormhole
• Verification of the message by Axelar
• 4/6 signatures from Hyperlane validators unaffiliated with Uniswap (including well known entities such as Staked, Blockdaemon, Everstake, ZeePrime, and ZK Validator)
• n/m signatures from Hyperlane validators run by designated members of the Uniswap community*

It’s worth noting that Hyperlane is the only interoperability provider that currently has this type of modular security architecture already in production. The Multisig ISM can be used today, without any additional development required. Additionally the required infrastructure has been open-sourced and there are comprehensive guides and documentation for its operation. Work on the Aggregation ISM has already begun irrespective of Uniswap’s assessment process, as the system was designed to allow for the simple and fast implementation of new security modules.

An example for the interface can be seen here:

/**
 * @notice Manages an ownable set of ISMs that must all verify an interchain
 * message before it is accepted.
 */
contract AggregationISM is IInterchainSecurityModule, Ownable {
  using AggregationIsmMetadata for bytes;
  using EnumerableSet for EnumerableSet.AddressSet;
  
  EnumerableSet.AddressSet private _isms;

  function addIsm(address _ism) public onlyOwner {
    require(_isms.add(_ism));
  }

  function removeIsm(address _ism) public onlyOwner {
    require(_isms.remove(_ism));
  }

  function verify(bytes calldata _metadata, bytes calldata _message)
    public
    view
    returns (bool)
  {
    for (uint256 i = 0; i < _isms.length(); i++) {
      IInterchainSecurityModule _ism = IInterchainSecurityModule(_isms.at(i));
      require(_ism.verify(_metadata.at(i), _message);
    }
    return true;
  }
}

Uniswap governance would be able to modify this ISM’s configuration over time (or change ISMs entirely). Potential changes to the ISM config include but are not limited to:

• Require a message to pass through an optimistic security model
• Add additional bridge providers to the aggregation
• Require particular messages to also be approved by a Gnosis safe**
• Modify the unaffiliated-with-Uniswap and/or affiliated-with-Uniswap validator sets

*Running a Hyperlane validator simply requires an AWS account, and RPC connection, and a machine to run on, and can be set up in ~30 minutes without any capital expenditures.

**This is, in-effect, similar to adding an additional Hyperlane validator set, but with fully offline keys

Vendor lock-in

If Uniswap were to use Hyperlane for interchain governance, our recommendation would be to use the Interchain Accounts API, an interchain application built on top of Hyperlane’s core messaging layer.

Interchain Accounts extend the control of an account on a local chain (e.g. Ethereum), allowing it to make arbitrary function calls on remote chains.

Because Interchain Accounts allow for arbitrary function calls, choosing Hyperlane today to implement the MMA would not prevent Uniswap from migrating to a different solution tomorrow, and it provides the easiest way for Uniswap to incorporate new security options as they materialize, as they each can be expressed as a new ISM.

To avoid confusion, we will make a separate post answering the 13 questions submitted by the Foundation.

[drinkcoffee]

Ermyas Abebe, Arjun Chand, and I (Peter Robinson) think that the assessment process should use the Crosschain Risk Framework.

For me, when I try to put a link in I get an error saying “links aren’t allowed”. The Crosschain Risk Framework is available at this website: crosschainriskframework dot github dot io

Anyone can contribute to the website by submitting a pull request to the associated github repo. Using github means that the discussions about issues with the framework are open and transparent.

[ermyas]

Hi all,

Adding to Peter’s post above:
The Crosschain Risk Framework is a document that aims to provide a high-level systematic overview of the security risks in crosschain protocols by identifying, classifying, and analyzing risks inherent in their design, implementation, and operation. In addition, it offers a set of risk controls and best practices to mitigate the likelihood and severity of such risks.

The document doesn’t directly analyze individual protocols but offers a general toolkit for reasoning about crosschain protocols. Hence, we think it could be very helpful to the efforts of the working group that will be tasked with assessing and recommending paths forward for Uniswap.

The document builds on a lot of excellent prior work by numerous folks and is still a work in progress. We’d highly value community contribution and feedback.

[Zellic]

Dear Uniswap community,

I’d like to put forth Zellic as a strong candidate as a technical expert in the selection of a cross-chain solution for Uniswap governance. Our experience with two of the largest bridges, LayerZero and Wormhole makes us a valuable asset to the team. Beyond just that, we have a deep understanding of cross-chain technology in general.

Introducing Zellic

Zellic is a smart contract auditing firm with extensive experience in the blockchain security industry. We have consulted and audited both Wormhole and LayerZero, two of the largest bridge contenders. We’ve worked with them in-depth, from war rooms to pull requests. In February 2022, we reverse-engineered a large cross-chain security incident with samczsun.

Apart from Wormhole and LayerZero, Zellic has worked with a range of clients, including Aptos Labs, Mysten Labs, SushiSwap, and the Solana Foundation, among others. Our commitment to security is reflected in our wide range of clients, who trust us to secure their code.

Our Team

Jasraj “Jazzy” Bedi, Zellic’s CTO, will be the engineer representing Zellic. Jazzy is a renowned blockchain security expert and the founder of the world’s former #1 CTF (competitive hacking) team Perfect Blue. Jazzy has expertise in general bridge architecture. As he led the audits for both Wormhole and LayerZero, Jazzy already has a deep understanding of both codebases. If selected, Jazzy will also immediately ramp up on the rest of the contenders.

Jazzy’s socials:

• Twitter: ret2jazzy
• GitHub: ret2jazzy

Zellic socials:

• Twitter: zellic_io
• GitHub: zellic
• Website

We are happy to work pro bono, as our mission at Zellic is to protect as much TVL as possible. The choice of bridge provider by Uniswap is significant for the entire crypto industry.

Conflicts of Interest

Ethics are our pillar. As previously mentioned, we work with both Wormhole and LayerZero. Nonetheless, we are committed to impartiality, objectivity, and fairness. Before all else, we are a security audit provider. Our job is to provide objective assessments. We will work to ensure the best solution for Uniswap governance is selected, regardless of individual bridge(s).

We believe that Zellic is the right choice for this job, and we’re excited to participate in the assessment process. We look forward to hearing back from the community and contributing to the best of our abilities.

[modong]

@AlexSmirnov

In deBridge, we’d like to express our support for a multi-bridge Implementation developed by Celer team. We made a pull request (PR) where developed an adapter that adds support for deBridge infrastructure into the proposed multi-bridge framework.

PR from @AlexSmirnov at deBridge is now merged. This is yet another proof that a multi-bridge solution is simple to integrate and extend. Given the current discussion and voting on the proposal, we think it is an optimal time to revisit this multi-bridge solution.

[philippzentner]

Proposed Implementation of a Multi-Bridge, Agnostic Solution

Over the past few months, LI.FI (a bridge aggregator supporting 13 bridges) has been closely monitoring the development in Uniswap’s Forum related to the BNB Chain Deployment Proposal, its subsequent Snapshot Poll which ended on Jan 31, and the current on-chain vote in favor of implementing Wormhole.

While we applaud the interest shown by key stakeholders of the crypto ecosystem in finding a suitable bridging solution for Uniswap’s Cross-Chain Governance, we strongly recommend that Uniswap not select one bridge provider for its BNB Chain Deployment Proposal. Specifically, we do not believe the BNB Chain Deployment Proposal should move forward before more research can be done, even if this may come as a letdown to many community members – be it bridge builders or other individuals.

Instead, we urge the Uniswap Foundation and the Uniswap community to fully immerse themselves in the Cross-Chain Assessment Process outlined by @devinwalsh. While the sprint to move to BNB Chain before the business license expires is important, we believe finding a long-term solution for cross-chain governance to be far more important than the short-term win of deploying V3 code first. There will be new chains, new versions of Uniswap, but there will never be another chance to expand governance safely and securely on the first try. Uniswap is a market leader in design (AMMs), token structure (airdrops), and overall competency, and LI.FI believes that the model Uniswap chooses for cross-chain governance has a high chance of becoming industry standard. We – as members of the crypto industry – want to see this done the correct way, and from the start.

Bridges, specifically arbitrary messaging bridges (AMBs), are in the nascent stages of development. Short-term, Wormhole, LayerZero, Celer, Axelar and deBridge are certainly viable solutions for cross-chain governance and have received substantial traction in terms of volume at the liquidity layer and development by dApps at the messaging layer.

That being said, we at LI.FI have done the research on AMBs (Navigating Arbitrary Messaging Bridges) and have delved deeply into the pros and cons of eight different AMB solutions. Our conclusion is simple: no single AMB is tested enough to be considered a robust and secure solution that a project of Uniswap’s size can solely rely on at this point. If there was a single, obvious AMB solution that could be trusted by Uniswap, then this forum post would not be necessary. Lest it be forgotten, two major AMBs were exploited in the past twelve months (Nomad and Wormhole), while LayerZero has also come under fire recently for its security model (Prestwich, L2Beat). We do not say this as condemnation, rather, we point this out to highlight just how difficult it is to build secure AMBs and the subsequent risks a dApp is exposed to by choosing a single bridging solution. In addition to this sentiment, we believe AMBs like Axelar, Synapse, Hyperlane, Multichain, Connext Amarok, and Hop deserve to be considered by Uniswap and the deadline of two and half weeks is too short for them to be formally introduced, debated, and voted upon again.

To summarize, LI.FI stands staunchly behind the concerns previously raised by @Kydo, @AlexSmirnov, and @modong. LI.FI believes that a multi-bridge, agnostic approach is best suited for Uniswap cross-chain governance because of the following reasons:

• By picking one bridging solution, Uniswap will be selecting a winner in a niche that is perhaps yet to find the most optimal solution, resulting in a lack of innovation going forward and a dominance by the AMB that will not help the space move forward in the right direction.
• With bridges, trust is a spectrum, and all the AMBs make different trade-offs resulting in unique strengths and weaknesses. However, when it comes to Uniswap’s use case of cross-chain governance, security can never be a trade-off. This is where a multi-bridge solution comes in to overcome these trust trade-offs, offering better security than any one bridging solution.
• Aggregating the best, most trusted AMBs will be in the best interest of the Uniswap community as, irrespective of shortcomings in any individual bridge, Uniswap will always receive the best services required for cross-chain governance.

So, where do we go from here?

More research is in order, which we believe should be two-pronged.

1. Cross-Chain Bridge Assessment Framework

We would like to add our own feedback to Devin’s framework and add an additional step to the process.

The MMA solution or any other multi-bridge solution is built on the idea of Uniswap choosing multiple bridges as “adapters.” The first thing to do, therefore, is to determine which bridges meet Uniswap standards, as outlined by @devinwalsh.

We believe that Uniswap should first build a unique framework to both quantitatively and qualitatively measure and allow for the ranking of different bridge solutions by the engineering team. This would decrease the workload of the engineering team by letting them focus on stress-testing bridge solutions without having to create the parameters of such a test themselves.

As one of the largest players in DeFi, Uniswap has the chance to create the de facto bridge assessment criterion.

By our estimation, there are four bridge framework solutions currently in the ether.

• Crosschain Risk Framework – created by ConsenSys & LI.FI
• L2 Beat Bridge Risk Framework – created by L2Beat
• Assessing Blockchain Bridges – created by Joel John
• With Bridges, Trust Is a Spectrum: A Quantified Framework – created by LI.FI and CryptoStats

Uniswap has the chance to build upon, combine, and quantify the works of four major research pieces without having to start from scratch.

With that in mind, we recommend that Devin’s initial Cross Chain Bridge Assessment make room for four researchers, who can help build this framework to assist the engineering team, who can then test out different bridging solutions based on the criteria mentioned in the framework and select which bridges make the cut to become a part of the multi-bridge solution.

The researchers will then explain the decision of the team through easy to digest articles, which can be used by other builders to assess bridges for their own dApps and by users to expand their knowledge of bridges and make more informed decisions when it comes to choosing a bridging solution for their needs. To this end, collaborations with other public good infrastructure projects like L2BEAT, Ethereum.org, among others, should also be considered to spread awareness and educate the public about bridges.

As Devin laid out, 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.

To this end, we recommend Peter Robinson, Arjun Chand, Ermyas Abebe, and Bartek Kiepuszewski (though we believe Uniswap should have the final call here).

We believe the current timeframe is aggressive but doable. However, if the list of bridges were to expand, we would recommend pushing back the March 27th date.

2. Consideration of Making the Universal Governance Model an EIP

Uniswap pushing for a cross-chain governance EIP would be net positive for the industry, in our opinion, specifically in the context of a multi-bridge solution. Such an EIP would give dApps a shared template for creating safe, secure governance modules, while also giving flexibility for dApps to choose different bridging solutions based on their security, time, and cost preferences.

To that end, we believe that Uniswap should create and propose a new cross-chain EIP based on the design outlined by Mo Dong from Celer and Alex from deBridge (with, of course, any tweaks recommended by the engineering and research team).

Additionally, there are two EIPs and one forum post that Uniswap should consider learning from and building upon in addition to the framework above.

• EIP 5164, as explained by Brendan Asseltine, is a PoolTogether and Hop-backed EIP looking to standardize governance message passing. While EIP 5164 is not a perfect fit for Uniswap – it proposes that all bridges provide the same interface to apps so that apps can just build against this interface and choose one bridge later – it does provide insight into the difficulties that EIP writers will have in coming up with a single design.
• EIP 6170, is a common smart contract interface for interacting with messaging protocols.
• Principled approach to bridges, proposes block header based bridges.

In our estimation, none of these solutions have captured enough mindshare to become industry standard. However, they have all pushed the envelope in what can be done in standardizing messaging, and Uniswap could learn much from it.

We recommend that Uniswap employ the same four-engineering team to standardize the MMA solution as an EVM-compatible EIP.

Given Uniswap’s position and influence in the ecosystem, it has the power to push an EIP that can potentially become the de-facto solution for any project indulging in cross-chain governance.

Conclusion

A multi-bridge, agnostic solution that the community invests resources into is a win-win-win for all the parties involved (Uniswap, bridging solutions, and the dApps that will implement this solution for cross-chain governance in the future).

As Devin said, the developments as a result of the proposed deployment on BNB Chain are net-positive for the ecosystem. Open discussions about bridge designs and frameworks for assessing security risks associated with them are exactly what we need to fast-forward the maturity of the bridging solutions and enable development of secure bridges.

We look forward to the feedback of the UF and the community on our proposal.

[Multichain]

Hi everyone, Multichain here. Multichain is an infrastructure developed for arbitrary cross-chain interactions. We are secured by MPC and ZKP, and we are envisioned to be the ultimate router for Web3.

We sincerely hope that we can help and contribute to the Uniswap community by working together with you.

And here are the answers to the 15 questions from us:

1. List 3 succinct reasons why you believe your bridge/solution would best serve Uniswap governance.
a. The most significant reason for Multichain’s superior security is its foundation in Secure Multi-Party Computation (SMPC), a theory developed and validated by some of the world’s most renowned cryptographers. The key algorithm implemented at the heart of Multichain’s cross-chain bridge and router is the Threshold Signature Scheme (TSS). These nodes are independent entities that can collectively sign transactions. Using a Distributed Key Generation algorithm, each node independently owns part of the private key shards. The complete set of private keys will never appear, let alone the possibility of being revealed. This can avoid single points of failure, and enhance decentralization and security. The underlying MPC structure design, combined with a wealth of experience in building cross-chain bridges and an abundant supply of liquidity, allows us to offer the cheapest cross-chain fees as well.

b. We are proud to have created the largest cross-chain infrastructure ecosystem, with over 3000 bridges built for our partners and support for more than 80 networks, including both well-known EVM chains and non-EVM chains. Our platform has an excellent number of daily active users, especially on BNB chain. We believe that our strong presence in the BNB community will greatly benefit Uniswap users who are looking to expand their network reach.

c. Innovation is at the core of Multichain’s mission, and we are proud to be the pioneers in cross-chain technology. We were the first to establish a bridge in the crypto space, and we continue to innovate with the launch of RouterV3, which enables native asset bridging. We also led the way in NFT bridging and developed the cross-chain message protocol, anyCall. Most recently, we launched zkRouter, which offers users the option to utilize ZK technology, in addition to our MPC option. Our commitment to innovation and exploration means that the Uniswap community can expect even more exciting developments from Multichain in the future.

2. How long has the system been running on mainnet?
Multichain was born on July 20th, 2020, under the name Anyswap. We have been running on the mainnet for 2 years, 6 months. Our focus has always been on addressing the need for distinct and diverse blockchains to communicate with each other seamlessly.

From the outset, our main product has been the asset cross-chain bridge, which has undergone several iterations and was later upgraded to become the core cross-chain solution, Router. We also developed an NFT cross-chain solution, which further expanded the capabilities of our platform.

At Multichain, we are committed to building and improving our cross-chain infrastructure to provide the best possible experience for our users.

In addition to promoting interoperability across different networks and facilitating smooth asset and value transfers, Multichain also enables seamless data and message transmission across chains. In April 2022, Multichain launched anyCall, a general cross-chain messaging protocol that allows for arbitrary cross-chain messaging.

Multichain has been running successfully for almost three years now. Earlier this year, we released the zkRouter whitepaper, which is an important component of Multichain’s inter-chain trust layer public infrastructure. In the near future, applications (such as cross-chain bridges) built on zkRouter will be available to the public.

3. How much value has the system secured? (Current TVL, total transaction volume)
a. Bridge & Router TVL：$1.78 B
b. Total transaction volume: $ 97.73 B

4. Provide a background on your team.
As an exceptional international team, the members of Multichain share a common vision and contribute their unique skills to the project. Established in 2020, Multichain comprises experts from diverse backgrounds in engineering, cryptography, economics, and mathematics. The team is united in their pursuit of becoming the ultimate Web3 router.

The technical members have extensive experience in the blockchain industry and have collaborated for over a decade. Notably, Andre Cronje serves as the architecture advisor of Multichain and is widely recognized as a pioneer in the field of decentralized finance (DeFi). In 2020, Cronje created yearn.finance and Keep3rV1, in addition to contributing to other notable DeFi projects. Moreover, he has played a critical role in shaping Multichain’s technical architecture designs.

Multichain has also garnered numerous contributors from MultiDAO. The DAO is dedicated to achieving the Multichainverse and supporting Multichain in its mission.

5. Please link your developer documentation.
a. https://docs.multichain.org/getting-started/introduction
b. https://multidao.gitbook.io/anycall/the-latest-version/v7/how-to-integrate-anycall-v7

6. Does the bridge support arbitrary message passing?
Yes. We do offer a cross-chain messaging protocol called anyCall, which has been operating reliably for over a year. Our esteemed partners, such as Curve, have leveraged anyCall to enhance their cross-chain LP rewards distribution governance. Under the hood, anyCall is powered by the MPC network, and its security is fortified by MPC cryptography. In addition, we have recently introduced zkRouter testnet, which allows messages to be transmitted in a trustless and decentralized manner. By incorporating ZK technology with advanced cryptography and mathematics, zkRouter has eliminated the dependence on trust in the cross-chain process. Compared to other cross-chain bridges in the space, zkRouter provides a new level of security that’s unparalleled.

7. 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?
Multichain has completed comprehensive audits on all of our products, and we are pleased to make the audit reports available to the public. Audit reports can be seen here: GitHub - anyswap/Anyswap-Audit. Our audit report repository contains a total of 13 third-party audits, including those conducted by esteemed companies in web3 such as TrailOfBits, CertiK, SlowMist, and BlockSec. The audits identified primarily contract issues, though their severity was generally low. We encourage you to review the aforementioned audit report repository for further details. Any vulnerabilities identified during the audit process have been remedied and reviewed by the auditing companies.

Security is one of the highest priorities at Multichain. Multichain has built long-term partnerships with world-leading third-party code auditing companies to conduct code auditing of every version or important update of codes. Multichain also has dedicated 10% of its revenues to a security insurance fund and has two bug bounty programs — one with Immunefi and the other internal.

Multichain has established an academic alliance with leading international cryptography experts who specialize in threshold signature algorithms and MPC in order to keep up with recent advancements in related technologies and drive technological progress.

8. Is there a bug bounty program?
Yes. We have partnered with Immunefi to establish a bug bounty program of up to $2 million. In addition, we have set up a dedicated security mailbox to receive bug disclosures that do not meet the requirements of the Immunefi plan. Furthermore, we have established security partnerships with other industry partners, such as Binance & Multichain’s War Room, to share information about vulnerabilities and security experiences and to create stronger security measures for the industry.

To date, we have issued bug rewards totalling more than $2 million, which has effectively raised the security level of Multichain products. We have also created a security fund to alleviate users’ concerns about security during cross-chain transactions.

9. List ANY portion of the functional bridge that is upgradeable and explain how the upgrade process works.
We do not have upgradeable portions for security reasons. This is to prevent contracts from being accidentally or maliciously upgraded by attackers, potentially leading to asset loss or abnormal functions. By disabling the upgrade feature, we ensure that the contracts remain secure and stable.

10. Do any contracts have an owner or owner-like entity? If so, what can the owner do?
One of the fundamental design principles of Multichain cross-chain contracts is to minimize single-point risks and reduce the attack surface. Unlike traditional contracts, cross-chain contracts have no owner, which adds an extra layer of security. In fact, all Multichain addresses are generated and managed by the MPC network, eliminating the need for an individual or entity to hold ownership. Furthermore, these MPC addresses do not possess a private key, and as a result, there is no single point of failure or vulnerability.

11. 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?
At present, our Bridge, Router, and AnyCall products are based on a distributed MPC network security model. Additionally, our latest development, zkRouter, is based on zero-knowledge proof technology.

A distributed MPC network is a distributed asset control network implemented with cryptography. It aligns with the decentralized philosophy of blockchain, where nodes hold private key shards. When the number of nodes that agree to sign reaches a predefined threshold, multiple nodes collaborate to generate a signature, completing cross-chain asset or message transfers. It is important to note that the process of distributed key generation and signature generation ensures that the private key never appears in its complete form, and the security of the process is guaranteed by cryptographic algorithms. Furthermore, Multichain’s MPC network uses a trusted execution environment (TEE) that offers dedicated security isolation hardware, further enhancing security.

zkRouter, on the other hand, is based on zero-knowledge proof technology. It generates zero-knowledge proofs based on the source chain’s consensus results, which are then passed on to the target chain for verification, thereby completing cross-chain transfers. The rigorous mathematical derivation and secure cryptography in the zero-knowledge proofs ensure that no one or entity can act maliciously, and as long as at least one honest participant is present in the system, cross-chain transfers can occur securely. Even in extreme case where all participants are malicious, the system cannot be compromised.

In summary, a distributed MPC network is based on cryptography, while zkRouter is based on zero-knowledge proof technology, which combines cryptography and mathematics.

12. How can an adversary pass a fraudulent message from Ethereum to the destination chain? Please give specific and concrete examples.
Currently, Multichain’s asset cross-chain bridge and router rely on the SMPC-based MPC Network to process cross-chain messages. The MPC Network is composed of independent nodes that verify the message status of the source chain and participate in the subsequent TSS execution based on their own verification results. TSS is a strong consensus determined by cryptography, which can only be completed when a threshold number of MPC nodes participate at the same time, otherwise, there is no result.

Therefore, in order for an adversary to transmit incorrect messages from Ethereum to the target chain while Ethereum is running normally, he must first control an MPC node to initiate a TSS request and inject the incorrect information into the MPC network, thus forging the incorrect information. The execution of TSS then requires the adversary to simultaneously control more than 2/3 of the nodes in the MPC network to complete the action.

Multichain has recently released a solution based on ZKP technology to solve the problem of trust in cross-chain communication called zkRouter. zkRouter relies on ZKP technology to generate proof of Ethereum’s consensus result, and proof of any result not agreed upon by Ethereum’s consensus cannot be generated and verified. The proof supports independent verification and can be completed by on-chain contracts after being passed to the target chain.

In this case, an adversary cannot achieve his goal of tampering with information by attacking either the proof generator or the transmitter. The only path is to challenge the security strength of Ethereum’s consensus mechanism and write incorrect information into Ethereum’s consensus result by attacking Ethereum.

13. How can an adversary withhold a valid governance message from Ethereum to the destination chain? Please give specific and concrete examples.
Regarding the trust mechanism of MPC, under the normal operation of Ethereum, there are three ways to try to withhold governance information on Ethereum.

The first way is to withhold the message from being transmitted to the MPC network, which will not trigger the execution of subsequent TSS. Since all MPC nodes can act as initiators of TSS requests, the adversary needs to disable the network of all nodes simultaneously, or attack or control all nodes simultaneously and make them refuse service or become paralyzed.

The second way is to block the node’s access to governance messages on Ethereum by disabling the node’s network, attacking or controlling the node. If more than 1/3 of the nodes are blocked, the MPC Network cannot complete the TSS execution normally, thus achieving the adversary’s goal of withholding governance messages on Ethereum.

The third way is to control more than 2/3 of the MPC nodes after TSS generation and prevent them from sending the TSS result to the target chain to withhold governance messages. In future plans, the MPC Network will be upgraded to MPC Blockchain, and anyone can send the TSS result to the target chain, making it impossible to withhold governance messages from Ethereum through the TSS transmission path.

Regarding the trust mechanism of zkRouter, there are also two ways for an adversary to withhold governance messages on Ethereum.

The first way is to block zkRouter from successfully obtaining governance messages on chain, either by disabling the network of all Relayer nodes that obtains messages in zkRouter, or by controlling all Relayer nodes so that they cannot obtain or respond to governance messages. Or by disabling all node services that provide transaction queries on Ethereum, so that Relayer has no way to obtain governance messages.

The second way is to disable Ethereum network and so that governance messages cannot be confirmed by consensus or Ethereum’s consensus result is tampered with.

Attacking the transmission of proof to the target chain in zkRouter is ineffective, as long as the target chain is working normally, anyone can send proof to the target chain.

14. 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 behaviour and describe in words how slashing works in your system.
The security of Multichain is upheld by the MPC network, a group of trusted nodes. Additionally, the application project has the flexibility to either run its own MPC node or choose a trusted node to form the TSS threshold. Running an MPC node requires a certain amount of veMULTI to be locked up.

Multichain released the zkRouter. The main purpose of zkRouter is to solve the problem of inter-chain consensus verification. Unlike traditional consensus mechanisms that rely on node agreement, ZKP technology only requires one honest node to relay proofs for secure cross-chain communication. Malicious nodes cannot generate valid proofs, ensuring that the trustless security model can reduce dependence on trusted nodes. Once the conversion to zkRouter has been made, then the question of slashing would not apply.

15. Provide any additional information you would like here.
How Multichain can contribute to the Uniswap community:
a. zkRouter: Following the launch of zkRouter by Multichain, we plan to dedicate to upgrading the MPC bridge to zkRouter bridge specifically for the Uniswap community in the near future.

b. BNB chain: Multichain offers a significant advantage on BNB. Currently, Multichain’s TVL stands at $1.84 billion, with $326.24 million TVL on the BNB chain alone. This figure accounts for 17.73% of Multichain’s overall TVL. Multichain’s total volume on all supported chains is $97.78 billion, with $12.5 billion total volume on the BNB chain. This translates to a 12.78% share of Multichain’s total volume, which is significant given the platform’s overall size. Additionally, Multichain allows for easy integration with the BNB chain and supports connections to 30 other chains. Notably, a number of 900 tokens have been bridged to BNB chain via Multichain.

When compared to other cross-chain bridges currently available in the market, Multichain stands out for its extensive support of public chains and asset types, as well as the vast scale of assets on its chain. In the case of BNB chain, Multichain’s data outperforms other similar protocols by a large margin. Details can be seen in the figure below.

In summary, we are confident that Multichain has the potential to bring significant benefits to the Uniswap community and achieve great success.

[devinwalsh]

Hi all, I want to clarify requirements for 1) bridge providers and 2) those who have built (or at this point, designed) bridge agnostic solutions.

All applications (answering the 15 questions in the original post, below in a forum comment) must be submitted by tomorrow, Friday, February 17th.

Payments to the UF multisig (0xe571dC7A558bb6D68FfE264c3d7BB98B0C6C73fC) must be made by next Friday, February 24th.

Bridge providers must:

1. Be launched on mainnet, and have audits completed by at least two audit firms
2. Answer the 15 questions listed in the forum. Please post responses to the question directly, do not alter the format of your response from Q&A.
3. Pay $5,000 in USDC to the Uniswap Foundation (0xe571dC7A558bb6D68FfE264c3d7BB98B0C6C73fC), 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.

Bridge agnostic solutions:

1. No requirement to be launched on mainnet or have audits completed, as many of these solutions have been designed over the past few weeks. However, at minimum, a technical specification document must be provided.
2. Answer the 15 questions listed in the forum. Please post responses to the question directly, do not alter the format of your response from Q&A. You may not have all answers yet, particularly if the solution has not yet been deployed. Where relevant, add caveats related to the current state of a solution’s design or development.
3. Pay $5,000 in USDC to the Uniswap Foundation (0xe571dC7A558bb6D68FfE264c3d7BB98B0C6C73fC), 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.

[priyeshugarg]

# Integration of Router Protocol into Multi-Bridge Implementation

Hi all, Priyeshu here from Router Protocol — one of the earliest cross-chain projects which started building the cross-chain interoperability layer in 2020.

The governance on the subject of Uniswap governance is of seminal nature, which will lay the foundation of a cross-chain future. We strongly believe that the future is going to be cross-chain and Uniswap’s governance layer is going to be the first large-scale implementation of a cross-chain messaging protocol.

Last year bridges contributed to a lot of hacks and moving forward, large-scale adoption and usage after proper due diligence is needed to restore the trust of the wider community in bridges — because they are inevitable as different layer1s and layer2s emerge and continue to fragment communities and liquidity.

We like the idea of the multibridge aggregator because that would enable the system to be more secure and the requirement of obtaining a quorum on top of the bridges without making Uniswap have to lock in with one bridge. The solution would be very relevant for high-value projects like Uniswap which have a large amount of liquidity to secure.

Hence, we are raising a PR request to add Router Protocol into the Multi-Bridge implementation.

The PR link is: added Router Protocol adapters by Shivam78288 · Pull Request #235 · celer-network/sgn-v2-contracts · GitHub

Some background about Router Protocol: We are a cross-chain interoperability layer backed by the likes of Coinbase, Polygon, and Wintermute. Our solution to the cross-chain problem is a PoS blockchain that validates all cross-chain transactions. So far Router Protocol has allowed over $800m in bridge volume to move through. Our auditors include Halborn Security, Hacken, and Oak Security. We also run a security bug bounty on ImmuneFi and have never had a security incident in our 1 year+ of mainnet due to robust security practices.

[amartin]

Dear Uniswap community & @devinwalsh,

I’d like to nominate myself for the role of PM in the cross-chain bridge assessment process. I’m Alex, one of the co-founders of The Cross Chain Coalition, the leading research & media community for cross chain development.

Background
Over the past year, our team has researched, analyzed, and reported on all bridges mentioned in the proposal. Given our commitment to understanding each solution in the space along with our history of education & research, I feel I’d be an excellent addition to the committee.

In the past year, the CCC has become a thriving community of 15,000+ members, made up of mostly developers and founders. To get us there, we’ve successfully held IRL meetups and events attended by thousands of people across the globe. To spotlight cross chain builders and foster web3 adoption, we’ve hosted demo days and events with numerous partners across Fortune 500 brands, most notably TechCrunch. And to further highlight cross chain development, our weekly newsletter has grown into the must read Cross Chain development resource of the week. Our contributors come from over 30 projects to cover real time updates from builders in the space.

The choice of bridge provider is important for Uniswap, but vitally influential for the entire crypto industry. I would love to represent the Cross Chain Coalition as the PM in this process.

Conflicts of Interest
I don’t have any conflicts of interest here. The ethos of our community is to celebrate all progress made towards cross chain development. I don’t have a dog in the fight - I’ve been committed to fair reporting in our media assets & events. Our community contains members from each of the bridges mentioned, therefore representation is equally distributed!

If any referrals are needed - feel free to hop in the community or talk to any of the cross-chain protocols themselves!

Socials:

• Twitter: alexmartin_55
• Telegram: amartin55

Community:

• Twitter: crosschainco
• Telegram: crosschaincoalition
• Website: crosschaincoaliton . com
• Newsletter: crosschaindev on substack

[priyeshugarg]

Bridge Assessment answers by Router Protocol

1. List 3 succinct reasons why you believe your bridge/solution would best serve Uniswap governance.

1. PoS-based security: Router Chain is economically secured by validators.
2. Strong BSC presence: Router has seen a strong presence on the BSC chain since its launch. Almost 27% of our transactions had BSC as either the source or destination chain.
3. Strong focus on Research: We are exploring various composable security modules including Optimistic Rollups and ZKP to enhance the security of Router Protocol.

2. How long has the system been running on mainnet?

Router Protocol’s latest version Router V2 is on the devnet. However, it should be noted that Router Protocol’s V1 has been on the mainnet since January 2022.

Router V2 is — Router chain, a layer 1 blockchain that leverages tendermint’s Byzantine Fault Tolerant (BFT) consensus engine. As a Proof of Stake (PoS) blockchain, the Router chain is primarily run by a network of validators with economic incentives to act honestly. The Router chain is built using the Cosmos SDK and encapsulates all the features of Cosmos, including fast block times, robust security mechanisms, and, most importantly, CosmWasm - a security-first smart contract platform.

By leveraging the CosmWasm toolkit, developers can start building secure blockchain applications on the Router chain from scratch or port their existing applications to the Router chain with minimal overhead.

The documentation is available here: https://devnet-docs.routerprotocol.com/ and the white paper is available here: Whitepaper

3. How much value has the system secured? (Current TVL, total transaction volume)

Router protocol’s V1 has had over 100k+ transactions since its launch with a transaction volume of over $630M. The current TVL in the ecosystem is around $526k.

Source: DeFiLlama

4. Provide a background on your team.

The Router Protocol team comprises many industry veterans. The team is led by MIT alumnus Ramani Ramachandran.

Ramani Ramachandran (Co-founder & CEO)

Ramani Ramachandran (Ram) is the Founder and CEO of Router Labs, which runs Router Protocol. Ram has been in crypto since 2014. Prior to Crypto, Ram was in the financial services industry and spent time across various functions including product management, research, fundraising, and investments across the US, Europe, and Asia.

Shubham Singh (Co-founder & CTO)

Full-stack Developer and Technical Architect building in crypto and blockchain since 2016; Built a crypto-index (108token) as well as Fordex - the world’s first stablecoin DEX.

Chandan Choudhary (Co-Founder)

Head of Strategy at Bitpolo, a leading Indian crypto exchange; Veteran trader and advisor across asset classes spanning over 15 years. Energy trader at Futures first; Managed crypto fund, generating 4x returns; Head of Ops & Market Research at Tradelab

Priyeshu Garg ( Co-Founder )

Priyeshu leads the research and developer-relations wing at Router. Past stints include software engineering at Ola, crypto journalism at Cryptoslate and product at Qredo.

Mankena Venkatesh (Blockchain Engineer)

He is a core engineer at Router Protocol currently building Routerchain. He previously worked as a Blockchain engineer at Matic (now Polygon) and Injective protocol.

Prof. Ashutosh Sahoo (Chief of Strategy & Marketing)

Prof. Ashutosh Sahoo is a blockchain ecosystem growth specialist. Since 2021 he has been involved in building a trade finance protocol on blockchain, Polytrade, and Reef - a substrate-based Layer 1 as the Chief Growth Officer. Prior to his foray into blockchain and academia, Prof. Sahoo has held leadership roles for over 15 years in strategy , operations, sales and marketing functions in FMCG, IT, manufacturing and real estate industries with brands of global renown like Hewlett-Packard, Johnson & Johnson, Lodha Group, Trump Organization and Sobha Realty.

5. Please link your developer documentation.

The documentation is available here: https://devnet-docs.routerprotocol.com/ and the white paper is available here: Whitepaper

6. Does the bridge support arbitrary message passing?

Yes, we support arbitrary message passing. The best way to send arbitrary messages between different blockchains is Router CrossTalk.

Router crosstalk is the framework that can be used to pass messages across chains. In simple terms, this library leverages Router’s infrastructure to allow contracts on one chain to pass instructions to contracts deployed on another chain without needing to deploy any contracts on the Router chain. The library is structured in a way that it can be integrated seamlessly into your development environment to allow for cross-chain message passing without disturbing other parts of your product.

7. Has the currently deployed bridge code been audited? By a third party? What attack vectors and vulnerabilities were identified, if any? Have the identified vulnerabilities been remedied?

The V1 bridge was audited by multiple auditors - Halborn Security, Hacken, and Oak Security.
All the vulnerabilities in the V1 architecture were fixed as part of the audit process.

The current v2 architecture which we are proposing to use for this integration is still in devnet phase with testnet planned around April and Mainnet around July. We will be getting Router V2 audited by veteran auditors like Informal Systems, Oak security, Zokyo etc.

8. Is there a bug bounty program?

We run a security bug bounty on ImmuneFi for Router v1 and the same will continue once we open up Router v2 for audit and security process. We have rewards upto $200,000 available for the Immunefi bug bounty program.

9. List ANY portion of the functional bridge that is upgradeable and explain how the upgrade process works.

As of now, the contract is upgradeable in the devnet phase. But on mainnet, it will be upgradeable with the ⅔ voting consensus on the router chain.

Hence, effectively a governance vote will be required to upgrade contracts in the mainnet.

10. Do any contracts have an owner or owner-like entity? If so, what can the owner do?

We do have an owner-like entity. It can only modify the base bridge fee that dApps need to pay for a cross-chain transaction on the source chain and do emergency pause. Pause is majorly added so that we can stop the bridge in case a chain is hacked for that particular chain.

11. 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?

In Router v2, the Router chain acts as the bridge. Router chain is built using the cosmos SDK. Hence, it leverages tendermint’s Byzantine Fault Tolerant (BFT) consensus engine. As a Proof of Stake (PoS) blockchain, the Router chain is primarily run by a network of validators with economic incentives to act honestly. The trust assumption is that there will be ⅔+1 validators who will act honestly.

However, we will be providing customizability to dApps to add their own security layer on top of the PoS-based mechanism inherited by default from the Router chain. DApps can add optimistic layers as well to make their system more secure.

12. How can an adversary pass a fraudulent message from Ethereum to the destination chain? Please give specific and concrete examples.

For an adversary to pass a fraudulent message — they will have to control ⅔+1 stake of the Router consensus. The security is based on the PoS scheme.

13. How can an adversary withhold a valid governance message from Ethereum to the destination chain? Please give specific and concrete examples.

There are 2 ways to block the governance from Ethereum.

The first way is by attacking the network of the orchestrators and making them paralyzed. This would mean that the request would never get created on the Router chain for further execution and hence, block the message from Ethereum to the destination chain.

The second way is to gain control of ⅓ orchestrators / validators. If ⅓ or more validators are blocked from voting or vote incorrectly we will not be able to achieve consensus and hence. the message will not get executed on the destination chain.

14. 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.

Validators have to stake $ROUTE tokens on the Router chain. Any validator having excessive downtime or engaging in any kind of malicious activity is penalized by having a portion of their staked ROUTE slashed.

For attack vectors like double signing, validators liveness, we use cosmos sdk slashing module which is described here x/slashing | Cosmos SDK

While for attack vectors like cross chain message tampering, message withholding etc we will be implementing our custom slashing mechanism which will be available in testnet phase in April.

15. Provide any additional information you would like here.

Router is backed by some of the leading investors including Coinbase Ventures, Wintermute, QCP Capital, Polygon, and Woodstock Fund.