Cross-Chain Bridge Assessment Process

5

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.

Test results:

Happy to answer any questions!

5 Likes
6

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

4 Likes
7

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.

12 Likes
8

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.

6 Likes
9

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:

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:

  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.

4 Likes
10

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.

11

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.

1 Like
12

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.

2 Likes
13

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:

Zellic socials:

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.

3 Likes
14

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.

4 Likes
15

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.

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.

826×445 22.2 KB

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

1035×540 116 KB

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.

10 Likes
16

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.

Screen Shot 2023-02-16 at 17.01.43
Screen Shot 2023-02-16 at 17.01.431912×434 160 KB

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

2 Likes
17

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.
4 Likes
18

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

1 Like
19

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
1 Like
20

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.

1600×581 158 KB

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.

21

Greetings to the Uniswap community,

I want to take this opportunity to nominate myself for the PM role in the Cross-Chain Assessment Process outlined by @devinwalsh.

I’m Arjun Chand, Research Lead at LI.FI (a bridge aggregator supporting 13 bridges).

Background and Qualifications

As a bridge aggregator, it’s crucial that LI.FI understands the strengths and weaknesses of different bridges as this helps us decide what each bridge brings to the table and, at the same time, the trade-offs they’ve made to be able to provide that functionality. Since the beginning, we’ve invested time and resources into learning about bridges and educating users and developers about them. I’ve been working with LI.FI as a Researcher since the company’s inception and have spearheaded the Research efforts along with meaningful contributions in marketing and business development.

In the past 1.5 years, we’ve researched the bridging landscape extensively, publishing several articles, including:

  • Bridge analysis frameworks – We’ve created frameworks to break down the different bridge types and help users and developers understand the various trade-offs they’ve made.

– Navigating Arbitrary Messaging Bridges: A Comparison Framework – breakdown of all the differentiating messaging bridges (including all the bridges in review for this proposal)

– With Bridges, Trust is a Spectrum: an analysis of different bridges’ design trade-offs. We’ve also worked on a quantified framework for the same.

– Crosschain Risk Framework: a high-level systematic overview of the security risks in cross-chain protocols and a set of risk controls and best practices to mitigate the likelihood and severity of risks.

  • Bridge deep dives – we’ve written comprehensive deep dives on bridges like Connext, Hop, Multichain, cBridge, Hyphen, Across, and others, covering their architecture and design, how they work, security assumptions, and features.

  • Bridge ecosystem overview articles that provide readers with a better understanding of the current bridging landscape and different concepts related to bridges.

– The Bridge Stack: a snapshot of the bridging industry.

– What are Blockchain Bridges and How Can We Classify Them?: a breakdown of trusted vs. trustless bridges

– Blockchain Bridges: everything you need to know about bridges (written for Ethereum.org)

  • Cross-Chain Insider Substack that provides weekly updates related to bridges and the multi-chain ecosystem along with simplified breakdowns of everything happening in the bridging ecosystem.

I believe we can build upon, combine, and quantify some of this work to build the Cross-Chain Bridge Assessment Framework for Uniswap.

Closing Remarks

I have spent the last 18 months learning about different bridge designs and their strengths and weaknesses. I have developed a good understanding of how they work and what each has to offer. I have no conflicts of interest here as LI.FI is a bridge aggregator, which means we’re neutral and unbiased when selecting bridges, and I abide by these principles.

I would love to contribute to building the Cross-Chain Bridge Assessment Framework and become a part of the bridge selection committee as the PM.

Thank you!

4 Likes
22

Celer Network would like to submit our proposal and answer the listed questions.

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

  • Celer is secure.

    • Celer’s protocol security design is comprehensive, built on Cosmos SDK which has been battle tested by many blockchains, including BNB Chain, Polygon PoS, and Cosmos. Celer’s PoS validators are among the most trusted in the blockchain community. Additionally, Celer offers an optimistic-rollup-like security framework for Uniswap to ensure its security even in the event of total consensus failure.
    • Celer has a flawless security track record and is the only cross-chain infrastructure with significant usage (>$5b in cross-chain volume) that has no critical vulnerabilities exploited or identified.
    • Celer implements a comprehensive security monitoring and communication process. Celer DAO has a dedicated 24/7 security team that builds and maintains an automated security monitoring system. This team can immediately communicate with both the Uniswap and Celer communities in the event of any security incidents.

  • Celer has achieved remarkable adoption, attracting well-known names like Metamask and PancakeSwap who opted to integrate Celer after thoroughly evaluating available solutions. Additionally, Celer has become widely adopted for numerous use cases such as asset bridges, cross-chain governance, cross-chain NFT bidding, cross-chain yield farming, cross-chain perpetual futures liquidity provision, one-click cross-chain swaps, and NFT bridging, with over 1.31 million cross-chain messages processed. Celer’s asset bridge, cBridge, supports 40 chains and 833 token bridges, facilitating $12.7 billion in cross-chain transaction volume and serving 333,000 unique addresses.

  • Celer remains dedicated to innovating towards a trust-free and open DeFi ecosystem. The Celer DAO and community developers have invested significant efforts in developing zk proofs. Soon, Celer will release a generalized messaging framework based on succinct proof of consensus. Furthermore, in the best interest of the Uniswap community and the broader DeFi ecosystem, Celer proposed a multi-messaging-aggregation solution. This proposal, supported by many delegates and industry participants, aims to establish a vendor-lock-in-free future for Uniswap and the entire DeFi ecosystem.

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

Celer’s cross-chain solutions were first launched in the form of an asset-only bridge in July 22nd, 2021. Building on this success, Celer released the generalized cross-chain messaging functionality on mainnet on April 15th, 2022. The core component of Celer’s cross-chain solutions, the State Guardian Network, has been running on mainnet since November 2020.

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

Current TVL: $215M

Total Transaction Volume: $12.8 billion

4. Provide a background on your team.

Celer was co-founded in 2018 by four industry veterans and entrepreneurs, each of whom holds a PhD from a prestigious institution like MIT, Princeton, UC Berkeley, and UIUC. Their security-first approach to development is rooted in their experiences securing critical networking infrastructure in Fortune 50 companies, safely operating the largest-scale Software Defined Network, and designing high-performance networking chips with zero tolerance for error.

Today, the Celer Network developer community has grown to a global network of core contributors with a similar background, as well as a large community of ecosystem developers who build exciting cross-chain applications using Celer. Before expanding to a generalized interoperability protocol, Celer released the world’s first Generalized State Channel Network, which laid the groundwork for its cross-chain efforts.

5. Please link your developer documentation.

Please see the followings:

6. Does the bridge support arbitrary message passing?

Yes, Celer supports arbitrary messaging, and its usefulness is exemplified by a number of high-impact use cases running on mainnet today. FutureSwap, for instance, uses Celer for its cross-chain governance, while PancakeSwap leverages Celer to allow users to provide liquidity on Ethereum and receive yield mining rewards on BNB Chain.

Additionally, Celer has already developed, deployed and tested a Uniswap cross-chain governance system on testnet, which employs a comprehensive security model. When a Uniswap governance decision is made on Ethereum, the governance contract calls the sendMessage function of a “send box” contract, which takes in the destination chain IDs, message to be passed, and destination contract addresses. The message contains the serialized bytes of the governance function call data, and an event is emitted containing the message.

Validators in Celer’s State Guardian Network, which is a Cosmos SDK based blockchain, witness the message and reach consensus that the message exists. The validators then generate a stake-weighted multisignature attestation that is stored on the chain.

A message executor, which can be run by Uniswap or validators of Celer Network, collects the message and calls executeMessage of a receiver contract. After necessary on-chain validation of the message, the message is put into a “quarantine zone” for a configurable period. During the quarantine period, validators in the SGN, the application’s executor, and potentially other third parties (collectively, App Guardians) can monitor and cross-check the message that arrived on the destination chain with what was sent on the source chain. If there is any mismatch, the message path is cut off immediately and the message is not executed.

Once the quarantine clock times out, the message is executed by the receiver smart contract, which calls the Uniswap contracts on the destination chain with the function and parameters specified in the message, completing the cross-chain governance process. This solution ensures the security of Uniswap’s cross-chain governance even if Celer’s State Guardian Network is completely compromised, as long as there is still one honest and live app guardian.

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?

Celer’s cross-chain solutions and frameworks was audited by Certik, Slowmist and Peckshield for 15 times. No critical vulnerabilities were ever identified in any of the audits for the current production code of Celer.

The audits are archived at

8. Is there a bug bounty program?

Celer was the first cross-chain interoperability infrastructure to establish a bug bounty program on ImmuneFi, with the program published on November 18, 2021, and a maximum prize of $2M. Celer has maintained a flawless security track record with no vulnerabilities discovered through these bug bounty programs.

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

Celer’s cross-chain messaging smart contract will no longer support upgradability, and this change will take effect in the coming days. The owner role and upgradability were initially included as a security measure, but it will soon be impossible to upgrade the messaging contracts that connect to Uniswap.

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

After the ownership deprecation, no owner-like key or entity exists.

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?

Protocol security

Celer’s State Guardian Network (SGN), which is based on the Cosmos SDK consensus framework, forms the foundation of its cross-chain security model. Validators with CELR tokens stake delegations in the SGN to witness message events on the source chain and reach consensus, generating a stake-weighted multisignature attestation that is stored on the chain. An executor then relays the attestation and message to the destination chain “inbox” smart contract, which checks its validity and signatures. In case of malicious activity by any guardians, their staked CELR will be slashed by the consensus protocol. Celer’s SGN validators are run by well-known entities, such as Binance, OK Exchange, IOSG, Everstake, Forbole, Ankr, 01-Node, Infstone, RockX, HashQuark, Klever and more. In addition, smart contract restrictions are in place to prevent any single validator from surpassing ⅓ stake.

Celer also provides an application framework that enables an optimistic-rollup-like delay and two-phase-commit pattern for cross-chain message execution. With this framework, each cross-chain message must be committed to the destination blockchain’s “quarantine zone” and trigger a mandatory time delay before it can be confirmed and executed to the final destination application. This delay allows enough time for App Guardians, run by SGN validators, dApp developers, or other third parties like security firms, to cross-validate the message on the source chain. If any App Guardian detects a mismatch, it can prevent the message from being processed before the delay expires, ensuring that even if the entire SGN consensus acts maliciously, the application can remain secure without executing malicious messages.

Security monitoring

While protocol security forms the foundation of cross-chain infrastructures, security monitoring, communication and, when possible, rapid responses are equally important. Many past bridge security incidents were due to the omission of this aspect. To address this, Celer DAO has a dedicated 24/7 security monitoring team that maintains an automated sentinel system to monitor various aspects of the system, including validator performance, stake distribution changes, cross-chain message parity between source and destination chains, system TVL, and cross-chain asset volume, among others. When an anomaly is detected, the team analyzes on-chain and real-world data, such as security incidents in connected chains. If a security issue is identified, the team communicates immediately with Celer’s community and partner community. This process will allow Celer ecosystem projects to implement any emergency responses if possible.

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

In the default security model, an adversary can pass a fraudulent message if they compromise validators holding more than ⅔ stakes at the same time.

However, in the Uniswap implementation using the optimistic-rollup-like delay and two-phase-commit pattern, an adversary must compromise all App Guardians and SGN validators holding more than ⅔ stake at the same time to pass a fraudulent message.

In practice, hacking multiple validators to compromise a consensus protocol is a difficult task and likely to leave traces. Celer validators use the battle-tested Cosmos SDK, eliminating the need to open a wide range of external ports. This allows validator servers to sit behind strict firewall rules, making it difficult for a malicious party to gain server access via an external path. Even if they do gain access via internal compromises, there is a good chance that their actions can be detected by validators’ internal monitoring tools, such as KMS audit log monitoring, 2FA-SSH access log monitoring, and other standard DevOps security practices. Malicious access attempts may also leave traces of node liveness when attempting to tamper with the validator software and raise alert on the external security monitoring front. Therefore, whenever a validator node drops offline, they will rotate keys and review access logs to ensure no malicious access attempt has happened.

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

By default, if an adversary compromises validators holding more than 1/3 of the stake at the same time, they can withhold a valid governance message.

When using the optimistic-rollup-like delay and two-phase-commit pattern, an adversary needs to compromise at least one App Guardian or enough SGN validators holding more than 1/3 of the stake.

However, we want to emphasize that withholding is a much lesser concern, since the Celer community and stakers can revoke the staking power of any malicious validator. Additionally, application developers can adjust the list of App Guardians through a governance multisig.

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.

Celer’s security model ensures that any set of validators with less than 1/3 stake cannot generate a invalid block with invalid cross-chain messages, and they will be penalized by having their stakes slashed.

Moreover, Celer’s State Guardian Network validators are publicly run by reputable PoS validators and renowned entities such as Binance, OKEX, IOSG, Everstake, Forbole, Ankr, 01-Node, Infstone, RockX, HashQuark, and Klever, among others. For these entities, a security breach or fraudulent validator would cause significant damage to their core business revenue and brand reputation.

15. Provide any additional information you would like here.

Celer has been an active contributor to Uniswap’s cross-chain governance efforts since the beginning. In fact, Celer, in collaboration with 0xPlasm team, was among the firsts to implement a single-bridge cross-chain governance solution. In addition, Celer was also the first to implement a multi-bridge solution that advocates for an open and vendor-lock-in-free future for Uniswap and the broader DeFi ecosystem.

Celer community has built through bulls and bears with unwavering persistence to bring blockchain to mass adoption. With its impeccable track record, Celer continues to innovate and will soon release a zk succinct proof-based cross-chain solution that further reduces the need for trust in application use cases such as cross-chain governance.

In summary, we are confident that Celer, in combination with a neutral vendor-lock-in-free multi-bridge architecture, is the optimal solution for Uniswap cross-chain governance.

3 Likes
23

hey All. Please find answers below from the Axelar Network.

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

  • Technology: The Axelar Network is powered by a decentralized Proof of Stake protocol with multiple layers of security features and an ability to further customize security for Uniswap, if needed.
  • Team: The team has deep roots in cryptography, distributed systems, and consensus and has been designing and building secure infrastructure for many years.
  • Traction: The Axelar Network has been live for over a year, integrated over 32 chains through its stack to date, processed over $1.7 billion in volume, and working with major DEXs, Wallets, L1/L2, stablecoins, and other partners throughout the industry.

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

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

  • To date, Axelar has a TVL of $126 million and has processed over $1.78 billion in asset transfer volume. Over 32 networks have been connected to the Axelar network, and the network has processed 350k+ cross-chain transactions (Transfers | Axelarscan).
  • The network supports General Message Passing and many applications leverage it – bridging NFT, performing swaps, etc. These applications don’t “lock” TVL, but enable applications to compose across the ecosystems.

4. Provide a background on your team.

  • The assembled team has deep expertise in cryptography, distributed systems, and consensus. The core engineering team has research experience in some of the top academic institutions (e.g., MIT, Waterloo), and professional experience in some of the most renowned technology companies, such as Google, IBM, and Microsoft.
  • Co-founders Sergey Gorbunov and Georgios Vlachos were founding team members at Algorand, and are winners of multiple academic awards in cryptography. ​​
  • Core engineer João Sousa built the first practical implementation of Byzantine consensus, BFTSmart, which has inspired many researchers and this industry over the years.
  • Sergey Gorbunov has designed and published many core cryptographic protocols. He also led the effort to standardize BLS signatures; the standard in its draft in CFRG was followed by Ethereum 2.0 implementations and others.
  • Overall, the team has been assembled to build best-in-class security from the ground up: from design to engineering and operations around the network.
  • Here is our team page.

5. Please link your developer documentation.

(Please select “Developer” under “pick-a-role” to access the developer channel)

6. Does the bridge support arbitrary message passing?

  • Yes, arbitrary message passing was described in the Axelar white paper in January 2021, and Axelar released its General Message Passing (GMP) capability to mainnet in April 2022. For example, GMP enables developers building on one chain to call any function on any other connected chain. (We use the word “function” to encompass both smart contracts at the application layer and functions built at the protocol layer, as in Cosmos, for example.) That means complete composability across Web3.
  • Like all Axelar functions, General Message Passing relies on a permissionless validator set (delegated proof-of-stake) for security and a decentralized protocol that handles routing and translation.
  • Learn more here: General Message Passing | Axelar Network

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?

  • Yes, the Axelar network code has been audited over 30 times and continues to go through continuous and rigorous audits.
  • Audits can be found here: GitHub - axelarnetwork/audits: Axelar network audits, with relevant findings, addressed before production deployments.

8. Is there a bug bounty program?

  • Yes, Axelar’s $2.25 million bug bounty program has been live since March 10, 2022, on Immunefi.
  • Axelar network and contracts are all open-source. We actively encourage comments and revisions from white-hat hackers.

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

  • The Axelar network can be upgraded following delegated proof-of-stake consensus. That is, anyone can post a proposal on the Axelar network and the Axelar token holders may elect to approve/deny it and the associated upgrade. Axelar network is controlled by a permissionless validator set and governance, as it is built on the Cosmos SDK.

  • A full list of network parameters and governance methods is available here.

  • The current instantiation of the Axelar Gateway contracts on the EVM chains are effectively light-clients: they’re responsible for keeping track of the Axelar validator set and communicating with applications that leverage Axelar.

  • Only the Axelar validators can collectively authorize decisions to process cross-chain transactions from/to the Gateways.

  • In the current instantiation, the gateways are upgradable subject to approval from an offline committee (4/8 threshold). This will change in the immediate future when all validators also need to collectively approve any upgrades to the gateways, essentially establishing end-to-end security via the Proof of Stake decentralized protocol.

For Uniswap, we can launch new Gateway contracts that are customized. For example, contracts can be non-upgradable, or Uniswap delegates or UNI token holders can govern upgrades. Such contracts would be governed by the Uniswap community while leveraging Axelar’s permissionless validator set for passing messages across chains. (See the Appendix for more details.) See the Appendix for more details.

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

  • The answer is incorporated above.

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?

Robust security comes from (a) the right design, (b) engineering practices, and (c) application-level security add-ons.

(A) The design: A decentralized permissionless network with a many-to-many communication model. The decentralized and permissionless model has the best practical security guarantees as it encourages diverse validator deployments, incentivizes validators to guard their keys, promotes good behavior, and punishes bad behavior.

  • Axelar is the full-stack decentralized transport layer. At the core, it is powered by delegated proof-of-stake consensus to validate cross-chain messages. Applications can instantiate additional validation logic across connected paths that may be governed by the application token, permissioned set, light-client, zk proofs, or other available technologies. Our approach is to:

    • (a) Offer the best-in-class security via decentralization as the default that solves most use cases for developers.
    • (b) Allow developers to customize security as needed.

  • The Axelar network itself comprises a validator set responsible for maintaining the network and executing transactions. The validators run the Cross-Chain Gateway Protocol, a multi-party cryptography overlay that sits on top of a Layer-1 blockchain. They are responsible for performing read and write operations to Gateways deployed on connected external chains, voting and attesting to events on those chains.

  • Axelar Gateways are effectively smart contracts that connect the Axelar network to its interconnected external chains. Validators monitor Gateways for incoming transactions, which the validators READ. They then reach a consensus on the validity of that transaction and, once agreed, WRITE to the destination chain’s Gateway to execute the cross-chain transaction.

  • The validators and Gateways compose the core infrastructure layer. They guarantee both safety and liveness of the core functions governed by delegated proof-of-stake. It’s important to note that relaying across Axelar and its interconnected networks is completely permissionless. This guarantees that no one can censor user transactions and delivers 100% liveness guarantees (assuming the interconnected networks and the Axelar network are running). If relayers are down, the user or anyone else can post transactions, themselves. If one of the interconnected networks is halted or undergoing an upgrade, the packets are just queued up at the network layer and can subsequently be posted (or re-posted) when the networks are back up.

  • Proof-of-stake decentralized design at the core - Axelar is built using battle-tested delegated proof-of-stake consensus with a diverse and dynamic validator set. Anyone can join, anyone can participate, and anyone can contribute to the security of the network.

  • Novel quadratic voting mechanism increases decentralization of the network - to further decentralize the network, cross-chain messages are approved iff they’re authorized via the quadratic voting rule. That is, the voting power of each validator is equivalent to the square root of their stake. A threshold of validators (currently 60%), weighted by the square root of the stakes, must collectively co-authorize every cross-chain request. With quadratic voting, as validators accumulate stake, it gets harder for them to accumulate voting power.

  • Amplify stake security - With Interchain Security available in the Cosmos ecosystem in the coming months, one network can “borrow” the security of other networks. This would allow it to increase the stake used for validation on the network, making any economic attack much more difficult. We also have plans to allow ETH holders to contribute to Axelar’s security, via the restaking model that Eigenlayer introduced recently.

(B) Engineering and operational practices:

  • Key rotations on the network - Validators of the Axelar network maintain keys that allow them to co-authorize cross-chain requests, similarly to how they co-authorize every block on the blockchain. Validators are strongly encouraged to implement best practices for isolating these keys and are required to rotate them periodically. Key rotations secure the network against a persistent attacker, who might try to accumulate malicious keys by compromising validators sequentially.
  • Continuous unit tests & end-to-end tests through the stack - While audits are great, achieving robust security often comes from having the right internal processes to identify and correct bugs. Continuous unit tests and end-to-end tests help discover vulnerabilities and bugs early in the pipeline.
  • Audits and bug bounties (see above).

(C) Application-level security add-ons:

  • Customize security - Additional paths can be secured by deploying additional validator sets, light-clients, and/or zero-knowledge proofs when available. We think this will be the best instantiation for the Uniswap community: leverage the robust Axelar network for all default traffic. If there is a highly valuable/sensitive transaction, utilize the additional UNI elected validator set for co-signing. See the Appendix for more details on how we propose customizing security for Uniswap.
  • Rate limits - The Gateways and the Axelar network have a rate-limiting function, which limits how much of each asset can be transferred in a given time interval.

Sitting atop the validators and Gateways are Axelar services and APIs that enable developers to access the tools and infrastructure enabled by those validators and Gateways. These services and APIs do not add any security assumptions: they make developers’ and users’ interactions in the interchain much simpler, but are fully permissionless: anyone can execute the relevant functions on-chain, themselves].

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

  • A majority of Axelar validators attest to messages that pass from Ethereum to a destination chain. The voting threshold is 60%, based on the validator’s quadratic stake (current stake distribution: Validators | Axelarscan). An adversary who can corrupt 60% of voting power can pass fraudulent messages. The adversary could try to corrupt enough servers to do this, but mechanisms such as key rotations & rate limits minimize the potential of these attacks.

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

  • The adversary can withhold messages by attacking validators that hold 40% of the quadratic stake. This can be done by corrupting validators or launching a denial-of-service attack.
  • Note that because relaying is permissionless, those attacks don’t apply to relayers. If certain relayers are compromised, any community member can come in and relay the message.

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.

  • Axelar validators get slashed on the Cosmos SDK level, the same way that validators of any other Cosmos chains get slashed for misbehavior.
  • There is a penalty for validators who don’t maintain sufficient uptime. When a validator doesn’t vote on enough cross-chain events, they’re penalized with a loss of stake and rewards.
  • Validators who misbehave significantly (double signing blocks, not participating for a long period of time) get jailed.

Slashing and locking in the Axelar network

Rewards slashing in the Axelar network is designed to incentivize validators to avoid undesirable behavior, such as losing liveness, failing to vote correctly on external chains’ events, double-signing, etc. Rewards are accrued at the end of every block and released depending on the reward type. The slashing mechanisms in the Axelar network are unique to each inflation component.

Within the TM consensus rewards, the slashing rules are set as follows:

  • Validators will lose the TM Consensus rewards if they lose liveness and get jailed if they don’t participate for a longer duration.
  • Validators need to sign 50% of the blocks in every 35,000-block window.
  • Given a block time of five seconds, this corresponds to maintaining total liveness for at least one day in every two-day window.
  • They lose 0.01% of rewards per block for downtime and 2% for double signing blocks.

If the validators lose liveness for more than 50% of the window, then they are locked (“jailed” in Cosmos terminology, forbidden from rejoining the validator set) for two hours (about 1,440 blocks), after which they would need to unlock themselves. Axelar network implements an unbonding period of seven days.

For multi-party signing protocols (MSigs), the liveness of the broadcaster account is signaled through “heartbeat” messages sent every 50 blocks by the validator. Validators are considered “active” if their latest heartbeat message was received within the last 50 blocks, they are not suspended from MSigs, they have missed signing less than 5% of the blocks in the last signed-blocks window for consensus, and are considered “live” by the consensus layer. Accrued rewards are released whenever validators submit a heartbeat. A snapshot of “active” validators is taken to determine participation in MSig protocol. If an “active” validator failed to participate in MSigs, then they are considered to have lost liveness and are suspended from further MSigs participation for 8,500 blocks (which is about ½ day with five-second block times), along with losing their accrued rewards. If a validator fails to submit a heartbeat message, they stop accruing MSig rewards for every block until their next heartbeat. For example, in the diagram below, a validator missed the 3rd and 6th heartbeat, so they don’t accrue (i.e lose) MSig rewards for 2 * 50 = 100 blocks.

For external chain voting, all validators registered as chain maintainers can vote on events. A validator’s share of voting power is equivalent to the square root of the stake delegated to them, divided by the square root of the total stake delegated to all validators. Validators who submitted the majority vote have their accrued rewards released. To incentivize liveness and good behavior, validators who fail to vote or submit the minority vote lose their accrued rewards.

15. Appendix

A multi-path instantiation for Uniswap

We propose to instantiate interoperability for Uniswap by passing messages via

  1. the Axelar decentralized network, powered by delegated proof-of-stake consensus and many safety features, and
  2. augment it with an additional Uniswap-specific validator set and a secondary Gateway II (could even elect two additional validator sets).

The Uniswap-specific validator set may be elected by the UNI token holders.

  • We deploy a validatorElector contract on Ethereum where UNI token holders can select an external validator set.
  • The elected validators download and run an instance of the Axelar external worker process.
  • This process allows them to listen for events from the source chains, and co-sign and authorize cross-chain transactions that are subsequently approved at the destination Gateway II.

Next, a custom Message Auth Policy contract can be instantiated to authorize messages of different value/importance from the two independent Gateways. For instance, we can authorize messages of lower importance as long as one of the Gateways approves them. We can authorize messages of higher importance if and only if both Gateways approve them. See our recent blog post for how to instantiate deployments based on different validation logic using Axelar (https://axelar.network/blog/future-proof-interop-path-adaptability-for-cross-chain-dapps).

Composing bridge Gateways and custom logic between them is not new to us. In fact, this is precisely the instantiation we’re collaborating on with Circle for the Composable USDC.

Finally, as different validation logic becomes available (e.g., light clients, ZK-proofs), they can be implemented between the Axelar network and its interconnected chains. No need to have external validator methods once these connections go live, but we can still rely on multiple validation paths to avoid dealing with bugs.

Given our proposal incorporates the multi-path approval framework, if the community decides to go to the multi-bridge provider model, the Axelar team would be open to working with another provider that can implement/deploy an independent Gateway/validation logic.

3 Likes
24

Dear Uniswap Community,

I would like to nominate myself as an engineer on the cross-bridge assessment team.
With five years of software engineering experience in both traditional and decentralized
finance domains, and as a partner engineer at cLabs, I am confident in my ability to make
valuable contributions to the assessment process.

At cLabs, I played a critical role in the successful deployment of Uniswap on Celo,
which involved a deep understanding of cross-chain bridges and the deployment of the Optics governance bridge. I would like to disclose that I am involved in the maintenance of Optics but I hold no obvious bias towards any specific bridge technology, and my
commitment is to provide objective and valuable insight during the assessment process.

My motivation for joining the team is driven by a strong interest in decentralized
finance and the role that cross-chain bridges play in supporting its growth.
I recognize the need for diligent assessment and clarity to ensure the
Uniswap community has what it needs to continue making informed decisions.

My socials
Twitter: 0xsawa
Github: jesse-sawa

Sincerely,
Jesse

3 Likes