Cross-Chain Bridge Assessment Process

ArjunChand · February 17, 2023, 12:11pm

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!

modong · February 17, 2023, 3:21pm

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.

sergeynog · February 17, 2023, 3:46pm

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?

Axelar has been running on mainnet since Jan 13, 2022.
Axelar is the canonical interoperability provider for Osmosis, elected through governance by the Cosmos community. The Osmosis DAO followed a thorough diligence process.
Major partnerships include Interoperability for Polygon Supernets, Circle’s Composable USDC, and many others.

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.

| Developer Documentation → https://docs.axelar.dev/
| Block Explorer → https://axelarscan.io/
| Examples → GitHub - axelarnetwork/axelar-examples: Sample cross-chain dapps & contracts using the Axelar protocol.
| GitHub → GitHub - axelarnetwork/axelar-local-dev: A local developer environment for building your cross-chain dapps.
| Security → https://axelar.network/blog/security-at-axelar-core
| Developer Discord → Axelar Network

(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

the Axelar decentralized network, powered by delegated proof-of-stake consensus and many safety features, and
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.

Sawa · February 17, 2023, 7:10pm

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

owl · February 17, 2023, 7:53pm

Gnosis team is working on a new concept and an approach to bridges that could be beneficial for the Uniswap cross-chain governance.

It aligns with the Multi-bridge proposals by @modong and @Kydo but we want to focus on two aspects:

Additive security
Instead of choosing one security model over the other and making certain trade-offs, we can use more than one models and control each other’s integrity.
Standardization (at the lowest level)
The lowest possible level for standardization which will decouple the overall architecture from the security model is the block header.

Putting the two concepts above together, we can have different bridges with different security approaches (e.g. ZK light client based, Committee based) that can provide the block header information of the source chain acting as Block Header Oracles.

If all oracles (or all oracles above a certain threshold) agree, the block header is considered valid.
In the case of conflicting oracle information, governance and an external conflict resolution mechanism need to resolve it.

On top of the block headers, we need merkle proofs for specific events or storage slots.
On top these proofs, we can build application logic, such as Uniswap Governance specific contracts.

We therefore clearly see three tiers in this new approach:
Application (top)
Proof (mid)
Block header (bottom)

(My account is not allowed to add media for some reason… Here there was supposed to be a diagram which you can find in the link below)

More information on the above in the following Etherearch post: (I cannot add links either for some reason… ethresear.ch /t/a-principled-approach-to-bridges/14725)

Status and Roadmap
The concept development is currently in an early stage but we plan to publish the first part (Header Storage) in the next weeks.

Although we are still in an early stage, we believe it would be beneficial for the community if this approach could be also considered in the assessment for potential future improvements in the cross-chain Uniswap Governance.

We are looking forward to hearing your feedback!

Wormhole · February 17, 2023, 8:58pm

WH Questions

List 3 succinct reasons why you believe your bridge/solution would best serve Uniswap governance.
Modularity and Scalability: Wormhole’s relayer-free model enables Uniswap to seamlessly expand governance to new chains without reliance on Wormhole to officially roll out its full suite integration. Any developer can permissionlessly deploy a read-only contract on the new destination chain and configure them with the current Wormhole Guardian set.
Critically, this compliments the Uniswap community’s sense of urgency to deploy Uni v3 onto other L1s and L2s prior to the license expiration. Relying on complex infrastructure like the operation of a relayer network may impede on those time sensitive ambitions.

Lightweight and Implementation Ready: Wormhole’s cross-chain governance module for Uniswap is tested and implementation ready. The contracts are currently live on ETH and BNB — the solution can be easily scaled to other EVM chains. The application is lightweight as Wormhole’s Guardian network is only used to attest finalized governance decisions on Ethereum.
I. Ethereum Message Sender: UniswapWormholeMessageSender | Address 0x128Ce3A3D48f27CE35A3F810cF2cddD2f6879b13 | Etherscan
II. BNB Chain Message Receiver: UniswapWormholeMessageReceiver | Address 0x3ee84fFaC05E05907E6AC89921f000aE966De001 | BscScan

Security and Decentralization: Wormhole has nineteen guardians comprised of institutional PoS validator companies who jointly attest to messages. Our Guardians are some of the largest and most respected PoS validators — collectively representing tens of billions of staked capital across Ethereum, Polygon, and more. Each Guardian holds equal weight in consensus and governance. Of the 19 guardians, Wormhole requires over two-thirds to reach consensus and pass verification - thus, we assume that at least one-third of our guardian set is honest.

Despite Wormhole’s high degree of decentralization, we remain resolute on improving our trust assumptions — as such, contributors are placing heavy investments in moving towards a completely trustless system based on zero knowledge proofs. This architecture leverages zero-knowledge proofs as a mechanism for directly attesting to the consensus rules of the blockchain. Light clients provide a mechanism for doing exactly this. We aim to share more on our ZK roadmap soon.
How long has the system been running on mainnet?
Wormhole is one of the first and longest serving generic cross-chain messaging protocols. It has been running on mainnet since August 2021.
How much value has the system secured? (Current TVL, total transaction volume)
Wormhole currently secures $300 million in TVL (token bridge only).
Since inception, nearly $35 billion in cumulative transaction volume has taken place on Wormhole via users bridging tokens over 22 connected chains — this activity comes through organic usage, no farming or token based incentives.
Provide a background on your team.
All Wormhole code is open source and built in the open by dozens of contributors including both individuals as well as contributors affiliated with the Wormhole Foundation, Jump Crypto, and more. Wormhole also has contributions from within 19 Guardian members spanning P2P, Everstake, Chorus One, Staked.US, Figment and more. Together, Wormhole is one of the most decentralized projects in crypto in both number and diversity of its contributors.
Hendrik Hofstadt is a Director of the Wormhole Foundation and is also the chairman of the supervisory board at Neodyme AG. Prior to Wormhole, Hendrik co-founded and served as CEO for Certus One, a leading blockchain infrastructure company, which was acquired by Jump Crypto in 2021.
Please link your developer documentation.
Check out the Wormhole xDapp Book. The first section of the book comprehensively outlines the core elements of Wormhole’s architecture and security while the second section assists developers set up a development environment and get started composing atop Wormhole.
Wormhole is fully open source — an intentional decision to push for the best in-class infrastructure and encourage the broader bridge community to transparently build out in the open. Our Github repository can be found here.
Additional information on the Wormhole: Ecosystem, Guardian Network, Discord
Does the bridge support arbitrary message passing?
Yes, Wormhole is a generic messaging protocol. Since inception, nearly 230 million messages have been transmitted, around 2 million messages are transmitted daily — some are regular messages (e.g. Pyth oracle data) while others are token bridges. Wormhole’s daily message load is equivalent to an L1, which demonstrates its reliability and robust throughput.
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?
Wormhole has been audited 25+ times by leading audit firms, including Certik, Trail of Bits, and OtterSec, and the cohort of auditors continues to grow. You can see the complete list of auditors and publicized findings here. Those 25 audits are in addition to Wormhole’s already rigorous internal auditing standards, where a team of 6 experienced security engineers regularly perform review the protocol’s security.
Is there a bug bounty program?
Yes. We remain committed to engaging with the whitehat community with clear and transparent discourse processes and bounty payoffs. Wormhole has paid out some of the largest bug bounties in crypto (see here) — our program has pushed Wormhole’s security forward and made the protocol more robust.

Wormhole hosts two bug bounty programs, both have a top payout of 2.5 million dollars:
- An Immunifi program and a self-hosted program
We strive to ensure our whitehat disclosure processes are clear and transparent — and are not hidden behind opaque payoff structures and obscure disclosure emails.
List ANY portion of the functional bridge that is upgradeable and explain how the upgrade process works.
Wormhole’s core contracts are upgradeable, contract upgrades are managed via Wormhole’s on-chain governance system. The on-chain governance system requires Guardians to manually vote on governance proposals which originate inside the Guardian Network and are then submitted to ecosystem contracts. Consequently, governance actions are held to the same security standard as the rest of the system (e.g. Wormhole core messaging). That is, a supermajority of the Guardians (13 of 19) are required to pass any governance action. The Governance system is fully open source in the core repository.

As we’ve mentioned before, while the Wormhole proxy contract can point to different implementations, the Wormhole implementation contract is immutable. Thus it is trivial to verify governance messages against a specified implementation. While there are multiple ways for Uniswap to accomplish this, the most straightforward is just including the pinned implementation as an external library in the deployment.
Do any contracts have an owner or owner-like entity? If so, what can the owner do?
As discussed above, governance actions can only be implemented if supermajority of the Guardians (13 of 19) vote to approve the proposal. Through governance, the Guardians can upgrade contract implementations and change the current Guadian set.
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?
Wormhole’s core messaging layer relies on the standard trust assumption of the PoA consensus with 19 Guardians. All messages passing through Wormhole require a minimum of observation and signing by a majority of the Wormhole Guardian set (13 of 19) — a minority (7 of 19) Guardians may refuse to sign a fraudulent message and thwart an attack.
The Wormhole Guardian set are comprised of professional PoS validators companies and collectively represent tens of billions of staked capital across a variety of PoS L1s including Ethereum, Polygon, Polkadot, and many more. The Guardian set includes names Figment, Staked, P2P, Chorus One — the full Guardian set can be found here.
How can an adversary pass a fraudulent message from Ethereum to the destination chain? Please give specific and concrete examples.
Any single adversary cannot pass a fraudulent message as all messages passing through Wormhole require a minimum of observation and signing by a majority of the Wormhole Guardian set (13 of 19). Any minority (7 of 19) Guardians may refuse to sign a fraudulent message and thwart an attack.

Importantly, simple yet customized message recall functions can be built by individual integrators. In this case, Uniswap could simply build “edge contracts” to introduce a time delay on message acceptance, providing an integrator with an opportunity to recall the message before it becomes effective. See below for a sample technical model:

Consider the sample technical model below (another can be found here):

Governance Network921×884 120 KB

Governance continues to take place using the existing GovernerBeta contract and Uniswap’s existing UI.

The GovernerBeta contract feeds into the GovernanceMessenger contract on Ethereum, which serializes the requests and passes them into the Ethereum Wormhole endpoint.

Wormhole produces a VAA (verifiable action approval) for this message, which can now be submitted to the GovernanceMessageReceiver contract on the target chain.

The GovernanceMessageReceiver contract on the target chain verifies the authenticity of the VAA using the local Wormhole endpoint and passes the instruction into a local Timelock contract, which owns the local Factory. Once the Timelock contract is cleared, the instructions can be executed.

Note that a Timelock contract is put on each individual chain to add an optional layer of control over the universal bridge into the system. As an extra signer, the chain’s native bridge could act as an escape hatch by which pending proposals in the Timelock can be canceled.

Notice that there is no relayer dependency in this schematic. Any user can submit the VAA to the GovernanceMessageReceiver contract on the target chain.

This model is very easy to maintain and enhance. Subject to Uniswap governance approval, receiver contracts can be upgraded over time. Moreover, anyone can deploy the Wormhole receiver contracts on new destination chains to process VAAs without waiting for Wormhole to formally support those chains.

Wormhole message security waits for consensus to be reached on the source chain — additionally, Guardians run full nodes to protect Wormhole against consensus-level exploits in the connected chains and further reduce contagion risk. If a blockchain’s consensus is violated, the Guardians will disconnect from the network until the issue is resolved.

How can an adversary withhold a valid governance message from Ethereum to the destination chain? Please give specific and concrete examples.
A single adversary cannot withhold a valid governance message — successfully refusing a valid governance message requires collusion among a minority contingent of Guardians (7 of 19).
Any fraudulent message would be immediately attributable to the offending Guardian to the rest of the Guardian network, resulting in the subsequent expulsion from the Guardian network.
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.
As mentioned above, Wormhole’s Guardians are leading PoS validators and collectively represent tens of billions staked across a number of L1s. Should they act maliciously (such as sign or forge fraudulent messages), they risk reputational consequences, external PoS businesses, and ejection from the Wormhole Guardian set.

Consequently, there is little incentive for an individual Guardian to act maliciously. Even if a Guardian were to succeed in forging a fraudulent message, it would not affect the network state because a single signature isn’t enough to establish the super-majority required to gain quorum. Finally, a fraudulent message would be immediately attributable to the offending Guardian to the rest of the Guardian network.
Provide any additional information you would like here.
Wormhole has taken a pragmatic approach to bridging -19 PoA Guardian set with the leading PoS validators, full nodes, and off-chain security features. We believe this is a nicely packaged solution that strikes the right balance between flexibility and safety, however, additional validation mechanisms are easily composable with Wormhole.

Following up on discussions in a previous thread, Wormhole contributors built out two examples of potential add-ons to the typical integration: an additional off-chain signer and a two-of-two bridge approach. Medium post can be found here.

Technical working examples are available here: https://github.com/wormhole-foundation/example-composable-verification

These forms of composable verification enable Uniswap to layer their signers or other trusted signers on top of Wormhole, extending the already robust Guardian set with additional validators.

jkol · February 17, 2023, 9:44pm

Hey everyone, reporting back from the Hyperlane team as promised in the above post. Here are answers to the UF’s questionnaire. Before we get started, we want to be clear, we are not proposing that Hyperlane should be picked as a standalone option, and only proposing it be considered as either an implementation option for the MMA design, or one of the options through an MMA design.

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

a. Hyperlane was designed to support customization of security models, including aggregating multiple third party bridges. No protocol changes are needed in order to support this. Any advancements in the field of interchain security can be easily incorporated into a Hyperlane deployment through an Interchain Security Module.

b. As a core team, Hyperlane is very philosophically and ideologically aligned with the Uniswap ethos. We have opted for a design that maximizes permissionless-ness. We work in public. We open-source every bit of our protocol. Utilizing Hyperlane guarantees Uniswap will be choosing a partner that is truly aligned with its mission and values.
Don’t take our word for it, join our discord and see for yourself!

c. Hyperlane’s Permissionless Interoperability and overall design means future deployments, even those on non-evm chains, can happen without any need for intervention by Hyperlane core developers.
How long has the system been running on mainnet?

V2 has been launched on mainnet for roughly 4 weeks. A similar version of the protocol, V1, has been running for upwards of 6 months.
How much value has the system secured? (Current TVL, total transaction volume)

V2 is still fairly new, and a dedicated token bridge product has not yet been launched. Hyperlane’s take on token bridging, Warp Routes, was just launched today. The system has secured over 50k messages on mainnet, and over 300k messages in total.
Provide a background on your team.

On the whole, we are a group of crypto natives. >85% of the team has been in crypto for 4-6 years, with the latest additions having 1+ year of crypto experience on average. Our team includes experience from like Gauntlet, Google, Celo, Uniswap, Amazon, Nethermind, Kyve and more. The team is mission driven and is solely focused on expanding the crypto-economy by providing technology to connect blockchains permissionlessly. We believe that by doing so we increase to limits of what is possible, growing the overall potential of the entire industry.

Team founders—

Nam Chu Hoai - Prior to working on Hyperlane, Nam was an early engineer at Celo where he worked on all levels of the stack, from the protocol to the application layer. Prior to Celo he’d been a senior engineer at Wellframe, an enterprise healthcare technology provider. As a teenager, Nam was one of the first developers to build iphone applications via Cydia, prior even to the creation of the appstore! Nam studied Computer Science at Boston University.

Asa Oines - Prior to working on Hyperlane Asa was the first engineer at Celo and the Protocol Lead. At Celo he was the first to write a POS design implemented fully in smart contracts, and played a vital role in all protocol design and architecture decisions. Prior to his work on the Celo protocol, he was an engineer at Google where he worked on Natural Language Processing systems. Asa studied Computer Science at MIT.

Jon Kol - Prior to working on Hyperlane Jon co-lead the investment team at Galaxy Digital, a firm with a wide array of operating businesses within the Crypto industry. In addition to his duties on the investment team he spearheaded a number of the firms operating initiatives, particularly those on the bleeding edge of Crypto. Prior to Galaxy he was a Crypto investor at Passport Capital, and a bond trader at Morgan Stanley. Jon studied Economics at UC Berkeley.
Please link your developer documentation.
1. Main docs page https://docs.hyperlane.xyz/docs/
2. Quickstart guides https://docs.hyperlane.xyz/docs/build-with-hyperlane/quickstarts
3. Deploy Hyperlane to your chain of choice https://docs.hyperlane.xyz/docs/deploy/deploy-hyperlane
4. Hyperlane Github https://github.com/hyperlane-xyz
5. Hyperlane Explorer https://explorer.hyperlane.xyz/
6. Hyperlane Discord https://discord.gg/hyperlane
Does the bridge support arbitrary message passing?

Yes. You can try it out for yourself and send your first message in minutes!
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, V2 has been audited by Hacken, a report is to be published shortly. V1 was previously audited by Hacken and FYEO.

Issues identified by Hacken in the audit were remedied as part of the audit process.
Is there a bug bounty program?

Yes, an ImmuneFi program sporting one of the largest bounties on ImmuneFi (6th largest), at $2.5m. The program can be found here: https://immunefi.com/bounty/hyperlane/
List ANY portion of the functional bridge that is upgradeable and explain how the upgrade process works.

The Mailbox contract logic is currently upgradeable using the transparent proxy pattern as implemented by Open Zeppelin. Upgradability will be delayed by a [1 week] timelock.
Do any contracts have an owner or owner-like entity? If so, what can the owner do?

The Mailbox contracts are owned by a 3/6 multisig with signers from Abacus Works. The owner can change the default ISM. If users do not specify their own ISM, the default ISM will be used to validate inbound messages. The Mailbox proxy contract is also owned by this multisig, which allows the multisig to arbitrarily change the Mailbox bytecode.
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?

Hyperlane’s security model is encoded in Interchain Security Module (ISM) smart contracts. Hyperlane users can specify their own ISM, which encodes their desired trust assumptions. At present, Hyperlane only supports Multisig ISMs, allowing Hyperlane users to specify their own validator set. In the short term, additional ISMs will allow Hyperlane users to mix and match ISMs (e.g. require 5/9 signatures from set A AND 3/3 signatures from set B OR require 9/9 signatures from set A). In the medium term, Hyperlane will support staking and slashing of validators, adding economic security. In the long term, ISMs will be developed for additional security models, including an optimistic ISM and light-client ISMs.
How can an adversary pass a fraudulent message from Ethereum to the destination chain? Please give specific and concrete examples.

In order to pass a fraudulent message from Ethereum to Alice’s smart contract on the destination chain, that adversary would need to compromise the security model specified by Alice’s ISM. If, for example, that ISM specified “require 5/9 signatures from set A AND 3/3 signatures from set B OR require 9/9 signatures from set A”, the adversary would need to compromise 5/9 validators from set A AND 3/3 validators from set B OR 9/9 validators from set A. This could be done by compromising key credentials (typically AWS KMS keys) or convincing validators to run a modified version of the Hyperlane Validator binary that signs a fraudulent Mailbox merkle root. Alternatively, if Alice’s smart contract contains logic to change the ISM, if an adversary were able to assume control of Alice’s contract, they could change to an ISM that they have control over (e.g. require 1/1 signatures from the adversary) and use that to pass fraudulent messages. Finally, if the Abacus Works multisig was compromised, an adversary could upgrade the Mailbox contract on the destination chain to allow passing of fraudulent messages.
How can an adversary withhold a valid governance message from Ethereum to the destination chain? Please give specific and concrete examples.

In order to withhold a valid governance message from Ethereum to Alice’s smart contract on the destination chain, that adversary would need to be able to impact the liveness of the security model specified by Alice’s ISM. If, for example, that ISM specified “require 5/9 signatures from set A AND 3/3 signatures from set B OR require 9/9 signatures from set A”, the adversary would need to be able to censor 5/9 validators from set A OR 1/3 validators from set B. Since Hyperlane validators are not networked with each other, and simply read smart contract state and write to S3 buckets, this would be exceedingly difficult without compromising the machine (or credentials, if run in the cloud) being used to run a validator. If the adversary controls one or more validators, they can withhold signatures, but because validators sign merkle roots, signatures can only be withheld globally. In other words, it is impossible for validators cannot censor some messages but not others without signing a fraudulent merkle root, which in the short term will be grounds for slashing. Finally, the Abacus Works multisig has the ability to pause and unpause the Mailbox contract. When the Mailbox is paused on a destination chain, interchain messages are not deliverable to that chain.
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.

Hyperlane does not yet implement staking, and therefore does not yet implement slashing. Verifying fraud proofs is fairly straightforward, as the Mailbox smart contract on each chain maintains a commitment to the entire history of messages.
Provide any additional information you would like here.
1. Hyperlane will support the MMA design regardless of whether Hyperlane is chosen as an implementation option for it or not. We believe firmly reliance on a single provider for security is against the best interests of the protocol, and hope that delegates and voters can see this to be true. Uniswap must optimize only for security. Safety over every parameter in this case. Latency or cost are completely meaningless in the realm of governance, and the MMA approach is most likely to reduce security risks and maximize safety.
2. Hyperlane will be implementing Proof of Stake to provide economic security to users of the protocol. Hyperlane’s design provides strong guarantees regarding the ability to permissionlessly slash without the need for governance, and provides for verifiable fraud proofs.
3. The Hyperlane core team is happy to expand on any of the above questions or additional ones at any time. Our public discord is the best place to reach us, alternatively Twitter, or email work just as well.

Kydo · February 17, 2023, 11:11pm

Kydo from Stanford Blockchain Club here.

Thank you to all the community delegates and bridge providers supporting the MMA design. If you are interested (as a bridge or delegate) to be part of the MMA design process, we welcome you to join our conversation. Just drop @Kydo a message here or on Twitter @0xkydo.

Multi-Message Aggregation (MMA) Design Question List:

Please note: the design is still under development and some minor changes could happen. However, these changes do not influence the overall security, liveness, and trust models of the design.

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

Better security and better availability: Using MMA, a Uniswap governance message with multiple copies are sent through different bridges to the destination chains, and will only be executed at the destination chain when the same message has been delivered by a quorum of different bridges. The likelihood of a large number of high-quality bridges concurrently getting exploited is strictly smaller than using a single bridge. Moreover, assuming all participating bridges have high availability, MMA provides better availability compared to a single bridge.
Vendor-lock-in free: Choosing MMA means that Uniswap will not be locked into one single vendor and therefore do not suffer from interest alignment risks or service quality risks down the road.
Simple and flexible: MMA is a straightforward smart contract framework consisting of around 350 lines of code. There is no need to operate any off-chain components. Its simple logic makes it easy to be thoroughly audited and formally verified. Moreover, it offers an adapter framework that is simple to integrate. This is evident from the successful integration of Celer, deBridge, Router Protocol, and Wormhole.

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

It is not running on mainnet.

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

Depends on the underlying bridge protocols.

4. Provide a background on your team.

MMA is a community effort. We are made up of 7 Uniswap delegates and 4 bridge providers/aggregators.

5. Please link your developer documentation.

Please see the description of the MMA architecture and integration guide here GitHub - celer-network/multibridge: Send Cross-Chain Messages through Multiple Bridges
We will move the repo and documentation to a Uniswap-delegate-led repo this weekend.

6. Does the bridge support arbitrary message passing?

Yes, arbitrary message passing is supported through bridges integrated into MMA solution. The current MMA design can be illustrated in the diagram below.

┌────────────────────────────────────────────────────────────────────────────────────────────┐
│ Source chain                                                                               │
│                                                                                            │
│                                                ┌─────────────────┐   ┌───────────────────┐ │
│                                             ┌─►│ Bridge1 Adapter ├──►│ Bridge1 Contracts │ │
│                                             │  └─────────────────┘   └───────────────────┘ │
│        remoteCall           dispatchMessage │                                              │
│ ┌────────┐    ┌────────────────────┐        │  ┌─────────────────┐   ┌───────────────────┐ │
│ │ Caller ├───►│ MultiMessageSender ├────────┼─►│ Bridge2 Adapter ├──►│ Bridge2 Contracts │ │
│ └────────┘    └────────────────────┘        │  └─────────────────┘   └───────────────────┘ │
│                                             │                                              │
│                                             │  ┌─────────────────┐   ┌───────────────────┐ │
│                                             └─►│ Bridge3 Adapter ├──►│ Bridge3 Contracts │ │
│                                                └─────────────────┘   └───────────────────┘ │
│                                                                                            │
└────────────────────────────────────────────────────────────────────────────────────────────┘

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

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?

The first audit is done by Peckshield and Halborn is engaged to do another audit. Peckshield audit report can be found here. Halborn is WIP. ETA - Wednesday, Feb 22nd
In the future, the MMA core contracts (MultiMessageSender & MultiMessageReceiver) will be formally verified.

8. Is there a bug bounty program?

No

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

All contract code in MMA are not upgradable. Uniswap Ethereum governance can change the configuration of the MMA including adding and remove bridge adapters and changing the quroum threshold of bridges.
The upgrade process is straightforward. If Uniswap wants to remove/add a bridge from the MMA design, it simply adds/removes it through a contract call from Uniswap governance.
Here is the documentation for configuration changes. And here is the example deployment and configuration changes on testnet using MMA.

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

There is no persist owner-like entity in the MMA solution contracts. An owner exists for MultiBridgeReceiver contract only for initialization and will be burnt once it is setup. No owner exist in any integrated bridge adapter.

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?

The security of MMA relies on the quroum among integrated bridges. Assuming k is the quroum and N is the total number of integrated bridge. As long as k out of N bridges are passing the same governance calldata in the message, the governance action will be executed.

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

There are two ways for an adversary to pass a fraudulent message from Ethereum to the destination chain: 1) the adversary compromises k out of the N bridges. Or 2) the adversary exploits the MultiBridgeSender or the MultiBridgeReceiver contracts to fake message passed by Uniswap governance. The latter concern can be addressed by thourough auditing and formal verification of the simple logic present.

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 only censor a governance message from passing through MMA when (N-k+1) out of N bridge providers are offline or compromised.

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.

The slashing mechanism in MMA is simple, removing the bridge from the set of approved bridge set. Additional, native slashing mechanisms for individual bridges still exist.

15. Provide any additional information you would like here:

MMA is a community-driven effort. The effort is led by a group of experienced Uniswap delegates and multiple bridge/aggregator providers. In the spirit of open source, we also would love to credit the amazing contributors to the project. Celer has contributed most of the implementation, conducted audits and deBridge and Router also integrated their solution with the adapter interface. Peckshield has provided the first audit pro bono. Hyperlane also constructed its parallel design based on ISM.
It is important to note that there is no bridge-specific dependency in the MMA solution and it is bridge-neutral. We welcome community feedbacks. Moreover, we believe the MMA design is not just beneficial to Uniswap. It is a generalized solution for any DAO that relies on cross-chain governance.
We believe the MMA design works in conjunction with the bridge assessment team’s final deliverable. If the MMA design is chosen at the end, we can use the bridge assessment team’s evaluations of the bridges as the selection criteria for the initial bridge participants.
MMA is a public good. It not only is open source and free for anyone to use but also leverages emerging ERC-5164 standards and aims to bring more standardization to the bridging space.

AlexSmirnov · February 18, 2023, 1:52am

Hey! Alex from deBridge here. Here’s an overview of deBridge related to the questions from the Uniswap Foundation:

deBridge is a secure cross-chain infrastructure enabling seamless interoperability between blockchains, powering transfers of any messages and liquidity with zero slippage and zero locked liquidity at risk.

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

Security: deBridge has taken a unique approach and implemented an off-chain validation mechanism where all messages are signed by a set of validators who are elected by and work for deBridge governance. Validators are obliged to sign a unique identifier of every message that is sent through deBridge smart contract with their private key and then make the signatures public so anyone can execute messages on the destination chain. deBridge smart contract checks the validity of all the signatures and in the case at least 2/3rd of signatures are valid, delivers the message to the recipient.
Validators don’t communicate with each other and they never expose their IP addresses making it very difficult to attack the infrastructure.
Unlimited throughput and scalability: deBridge doesn’t have its own blockchain or intermediary consensus layer, that’s why there is no throughput bottleneck. deBridge also doesn’t need to bootstrap liquidity pools in order to scale up to new chains. In case Uniswap governance decides to deploy on new chains that are not yet supported by deBridge, we will be able to quickly add support for these chains.
Optimal gas-efficiency: At deBridge, validators never broadcast any transactions. Hence, they never bear gas costs, unlike other interoperability protocols where gas costs of the validation layer are born by the message sender.

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

deBridge has been live on mainnet since February 2022. The protocol has been running successfully since day one with 100% uptime, 100% message deliverability, and no security/reliability issues.

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

deBridge is a cross-chain infrastructure that enables generic message transfers. The protocol has processed more than 131,000 messages from over 67,000 unique users. All protocol stats can be found in our deBridge explorer.

deSwap is the first value-transfer protocol built on top of deBridge and has processed ~$94M of volume without any incentives and liquidity minings. In deSwap, we have never been chasing volume as the primary goal, but rather to build a capital-efficient solution with a sustainable economy that doesn’t require TVL and distribution of liquidity incentives.

We also believe that cross-chain value transfer protocols shouldn’t have continuously locked liquidity or large TVL. That’s why we’re launching DLN, an asynchronous value transfer protocol built on top of the deBridge infrastructure. It’s using a fundamentally new paradigm called “liquidity on demand” where any cross-chain trade can be settled natively with zero TVL, solving problems with security, scalability, and capital-efficiency of classical value-transfer bridges based on liquidity pools. More information can be found here.

4. Provide a background on your team.

deBridge was started in early 2021 after winning a Chainlink hackathon among 140+ projects. The project’s founding team and overall technology and product team have extensive experience in blockchain and crypto development including building custody solutions, distributed systems, and other applications for banks and other companies.

deBridge’s CEO and Co-Founder, Alex Smirnov, is a mathematician, researcher, and developer. He has led and developed various blockchain solutions and dApps, and came out of academia where he was working on his Ph.D. in mechanics and mathematics. Now, he’s leading deBridge where his focus spans areas including protocol design, product management, ecosystem, and operations.

The team’s CTO and Co-Founder, Yaro Artyukh, has eleven years of experience in software development, six of which were involved in the development of different fintech and blockchain solutions. Yaro leads the development of all components for the deBridge protocol and architecture, making sure we have the go-to secure cross-chain infrastructure for any projects and users.

In sum, the team has a security-first mindset and approach when building infrastructure to be reliable and stable.

5. Please link your developer documentation.

Developer portal: deBridge Finance
Developer documentation: https://docs.debridge.finance/
deBridge Explorer: https://explorer.debridge.finance/
Security: 10 Strategies for Cross-Chain Security

Cross-chain Dapp example:

We cover all aspects of deBridge in our docs including a general overview of the protocol, smart contract, and use case examples, how our generic messaging framework works, building with our development tooling, and more.

6. Does the bridge support arbitrary message passing?

Yes, deBridge is a generic messaging infrastructure that enables arbitrary message passing. This goes for all types of messages including governance voting, smart contract logic, and contract calls.

Learn more here: Getting started - deBridge

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. Security will always be deBridge’s primary focus area since it’s difficult to build a secure and reliable cross-chain infrastructure, and we want to make sure builders and users have a secure interoperable framework that they can build and interact with.

We have had 17+ audits up until this point where we have worked with 4 different security auditors in total. We have made sure to devote significant resources towards auditing our smart contracts, and also other aspects of the protocol including the deBridge node, our UI, Cloudflare, and other areas – all potential attack vectors in different ways. There have not been identified vulnerabilities in the deBridge protocol.

All security audits can be found here: GitHub - debridge-finance/debridge-security: deBridge security audits

8. Is there a bug bounty program?

Yes, we have an ongoing bug bounty program with Immunefi. This was initiated even before we went live on mainnet to make sure white hats, researchers, and others in the blockchain space help us discover any potential vulnerabilities in the architecture and overall protocol.

Our bug bounty overview can be found here: deBridge Bug Bounties | Immunefi

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

Every on-chain component of deBridge, including but not limited to:

deBridgeGate (the core gate contract)
SignatureVerifier (the contract responsible for verifying message signatures and ensuring they are from trusted validators)
CallProxy (the contract responsible for performing calls to target contracts) –

is represented as an upgradable contract using the transparent proxy pattern.

All proxies are currently controlled by a Safe multisig account shared across the deBride executive team. During the next few weeks, we are going to add deBridge validators and several reputable and experienced people in the industry as signatories to this account.

Any upgrade of smart contracts will involve a multi-step process:

The upgrade should be fully audited by our security providers.
The logic implemented by the upgrade will be described on the deBridge forum so every participant of the multisig account can validate the upgrade in advance and make sure it doesn’t harm nor influence any integrations performed with deBridge infrastructure.
Safe transaction to be formed by the core team.
Signing transactions by all multisig participants.
Execution of the signed transaction.

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

deBridge core contracts expose several administrative methods accessible to the controlling Safe multisig. These methods permit managing various protocol settings such as: pausing/unpausing the protocol; enabling/disabling chains where messages can be sent to/from; adding/removing validators’ addresses responsible for messages confirmation; setting signature acceptance thresholds and protocol fees.

Important to note: After introducing the deBridge token, governance will take control over the protocol and all the administrative processes.

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?

Any non-canonical bridge has inevitably a validation layer with consensus participants, and like all bridging solutions applying to this Assessment Process, deBridge bears the assumption that consensus participants will never collude to forge messages.

One of the goals here is to make consensus participants bear financial responsibility and maximize their stake that acts as financial insurance. That’s why deBridge has a delegated staking and slashing module as a part of the protocol design (the module is not live yet and will be launched later this year).

Read more about our slashing and delegated staking here:

https://docs.debridge.finance/the-core-protocol/slashing-and-delegated-staking

deBridge has selected 12 professional and experienced infrastructure providers based on their performance e.g. stability of infrastructure, uptime, number of missed transactions, and validation speed. This includes HashQuark, Bware, and Stakin among others. After the launch of the deBridge DAO, governance will have the ability to decide on how many validators the network should have and who should be the validators.

The full list of deBridge validators can be found here: Debridge - Cross-chain Bridge

With this in mind, we can go into the security features to ensure we have a secure and reliable protocol. These include:

Slashing Mechanism (to be launched in 2023): Validators have an important role in the deBridge protocol design. deBridge uses a slashing mechanism to disincentivize validators from colluding and acting against the best interest of the protocol.
Transaction finality specifications: Validators need to wait for a specific number of block confirmations and sign transactions only when they have achieved their finality. This prevents double-spending since transactions become irreversible after achieving finality.
Validation of nonce sequence: A nonce is the unique sequence number assigned to every transaction passing through the deBridge protocol. Validators are always required to confirm transactions in an ascending order which helps to avoid double-spending and improves overall protocol security against reorgs and 51% attacks.

More details about our security measures can be found here.

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

Assuming the security of deBridge node and smart contracts, there’s only one way a fraudulent message can go from Ethereum to another chain. This is in case 2/3 (8 out of 12) validators come together to collude and sign a fraudulent (non-existing) message. Here, someone would need to get access to the private keys of at least 8 validators to sign a fraudulent message in order to execute it through the deBridge smart contract on the destination chain.

Thanks to deBridge off-chain validation, validators never communicate with each other and never broadcast any transactions. They never expose their IP addresses making it very difficult to attack the infrastructure as no one knows where validators are running the infrastructure.

Moreover, the number of validators will grow over time to increase the decentralization of deBridge and to make it more difficult for adversaries to do something maliciously.

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

In case there’s an adversary that wants to censor a message, this can be achieved by 5/12 of the validators coming together. Validators that censor messages will also be slashed by protocol governance

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.

There are some specific ramifications and security precautions that we have thought about when designing the deBridge architecture. The main one is slashing mechanics where validators are required to provide financial guarantees in a form of collateral (their own + collateral delegated to them by delegators/users) in a delegated staking smart contract. This is to disincentivize colluding among validators, and the collateral will act as a guarantee of validators’ acting as they should and in the best interest of deBridge, since they otherwise will be slashed.

The slashing works the way that if validators decide to act maliciously, their stake will be slashed by the deBridge governance to payout to the affected users of the infrastructure.

––

deBridge is in favor of the MMA design option as Uniswap’s go-to implementation. We believe this will benefit the Uniswap protocol the most while bringing the best secure and reliable option.

LayerZeroLabs · February 18, 2023, 2:17am

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

Leading Adoption: LayerZero is the most widely used cross-chain messaging protocol by a significant margin (2k contracts deployed on mainnet, nearly 20k contracts on testnet). The protocol supports thousands of applications and has secured millions of messages and billions of dollars.

Longstanding Security: The protocol has never suffered a single exploit despite being deployed and used at scale. It is no coincidence that LayerZero is the most widely adopted cross-chain messaging protocol and also has never suffered an exploit. Since inception, LayerZero Labs has been committed to a set of best-in-class security practices (see below for breakdown). All of the core protocol code is immutable meaning the smart contracts cannot be upgraded by the LayerZero Labs team once deployed. In contrast, the majority of the stolen user funds ($3.1B in 2022) from cross-chain bridges and messaging protocols are attributed to upgrades made by cross-chain messaging teams and the consequent application contagion. Immutability matters.

Protocol Alignment: Uniswap is the gold standard for immutable and permissionless systems; the protocol was deliberately built with completely immutable core contracts and designed to limit risk exposure to the protocol while leaving some surface area of control to governance. LayerZero is built with the exact same principles: completely immutable core contracts and agency in the hands of (Uniswap) governance to control security hyperparameters. We believe the gold standard for a secure messaging layer is one that allows protocol ownership and transparency of immutable contracts.

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

11 Months

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

The system currently secures billions in TVL, has secured a peak of more than $8.4b in TVL and has processed more than $6b+ total transaction volume.

4. Provide a background on your team.

The LayerZero Labs team includes founders with multiple venture backed exits and leading engineers from AWS, Coinbase, the office of the CTO at Redhat and backgrounds in academia, research and algorithms for some of the most widely adopted technologies across all of the internet stack. We’ve also been backed by one of the strongest cap tables in the space, winning votes of confidence in the team and underlying technology from world class organizations such as Sequoia, a16z, Coinbase, Circle, and Uniswap Labs.

5. Please link your developer documentation.

What is LayerZero - LayerZero Docs
Github & Code Examples: LayerZero-Labs · GitHub
LayerZero Scan: https://layerzeroscan.com/
Community:
- Discord: LayerZero
- Telegram: Telegram: Join Group Chat
- Twitter: https://twitter.com/LayerZero_Labs

6. Does the bridge support arbitrary message passing?

Yes, LayerZero’s arbitrary messaging primitive is described here.

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

LayerZero Labs has commissioned 35+ audits with the most recent audits on Github here. Nearly all code written by LayerZero Labs since inception have been immutable smart contracts audited externally and rigorously reviewed internally at least 3+ times each. LayerZero is the only major cross-chain messaging protocol to have secured significant transaction volume ($5B+) over time without any exploit, compromise of key infrastructure, or loss of user funds.

8. Is there a bug bounty program?

Yes, LayerZero Labs offers the highest bug bounty program in the world at $15m.

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

There is no part of the LayerZero protocol that is upgradeable. Our proposal has the Uniswap DAO in control of choosing its own hyperparameters so that only the Uniswap DAO can change with an on-chain governance vote.

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

Yes, the owner can set default hyperparameters for messaging. Our proposal has the Uniswap DAO in control of choosing its own hyperparameters so that only the Uniswap DAO can change with an on-chain governance vote.

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 its core the LayerZero protocol allows the user application to set an arbitrary number of parties to attest the validity of a message between two chains. We propose that the DAO set Chainlink as the oracle and a consortium of Uniswap Delegates to act as a decentralized relayer network.

We have already spoken to a number of delegates who have agreed to participate as validators within the relayer, however should the DAO not wish to use this they can set an alternative relayer such as LayerZero Labs, Blockdaemon or Gelato.

The trust assumption would be that Chainlink and the chosen Relayer are not actively colluding against the Foundation’s wishes to forge messages. Bear in mind that Chainlink already secures $75B+ of dollars today and has secured $7T+ of economic value of transactions and the delegates are by far the most economically aligned with the Uniswap DAO and already have a significant surface of influence over Uniswap governance via voting power.

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

The risk of an adversary passing a fraudulent message from Ethereum to the destination chain is near zero; For a message to be forged, the adversary would need to simultaneously and independently corrupt the entire consortium of Uniswap delegates as well as Chainlink. It’s worth noting that if the consortium of Uniswap delegates wanted to collude they already likely have enough voting power to collude directly via governance and have no need to do it via the messaging layer on top of the additional burden of needing to corrupt Chainlink as well.

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

The consortium of Uniswap delegates and Chainlink would need to be willfully withholding the message. In this case, it would be both obvious to everyone that this was happening and who was responsible and allow the Uniswap DAO to change their configuration to remove the malicious party and successfully deliver 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.

If any of the actors in the Uniswap delegate network were to act maliciously and sign an incorrect message, it would be publicly observable and the other Uniswap delegates would withhold signature. This would carry huge reputational risk to the malicious delegate and result in the Uniswap DAO ejecting them from the relayer network.

Chainlink oracles in the Chainlink DON carry huge reputational risk and already secure $75B+ today. If one were to sign a forged message, they would face removal from the Chainlink DON and risk huge reputational risk in all of their core businesses.

15. Provide any additional information you would like here.

We have deployed our omnichain governance executor on Goerli testnet and BNB testnet and executed a fee switch from (0,0) to (4,5). Below are the contract addresses and the layerzeroscan transaction.

proposalSender on ethereum-goerli: 0x78F386bf7F5c638b14e166Fa31F8c66BBb654b4B

governanceExecutor on bnb-testnet: 0x3CE8305175Bfa090278568461aee8e64B5C220F5

Uniswap v3 pool on bsc-testnet: 0x881A6726B06CEc80Dd512f5f2556242ECaCA8700

Here is the transaction on LayerZero Scan: Cross Chain Message | LayerZero

Security in anything boils down to the weakest link. The most common weak links in messaging protocols are (1) client diversity and (2) upgradeability.

1) Client diversity:

Many middlechain messaging protocols and bridges celebrate their “decentralization” by touting the number of validators in their network. For example a system might have 19 validators, and to achieve consensus, their service needs at least 13 signatures. However, those features are not the weakest link in this system; the client diversity is. All of these validators are running the same piece of software developed by the same team. The weakest link comes from the team that provides the source code and software updates. A simple bug or hack from external parties could push code to force signatures on malicious network traffic.

This isn’t a new concern in crypto, as it was a fairly significant issue with the Ethereum community before POS when most of the clients and miners in the network were running Geth. Today Ethereum has the luxury of 4 or 5 unique clients built and maintained by different respective development teams thereby reducing the risk of developer-related attacks (e.g. pushing an upgrade with a smart contract bug, human engineered hack). Pre-POS, one of the main reasons lack of client diversity wasn’t a major concern with Ethereum was the fact that if Geth performed an attack, the network could rollback to a previous version of Geth and erase from history the previous attack; a necessary rollback would be a major blow to Ethereum but not a fatal one. In contrast, lack of client diversity is a major risk for bridges because the bridges themselves reach finality; bridges don’t have the luxury of rolling back chains, every action is final. Therefore when using a middlechain messaging protocol– by design, lacking client diversity– users and applications are not accepting the security of X validator decentralized network but rather the security of the weakest link: the creator company itself.

(2) Upgradeability:

Most, if not all, messaging frameworks (besides LayerZero – the entire protocol is composed of immutable smart contracts) are upgradeable. Developer teams push upgradeable code so they can optimize for rapid releases of the latest and greatest technology and enjoy the advantage of fixing bugs or issues in their code with limited overhead time. This feature is a double edged sword; if teams have the power to fix issues, it also means they have the power to create them. In other words, even the most secure application built on top of a mutable messaging framework will always carry existential risk the code that is in production today is not the same code in production tomorrow.

Upgradability has been a long standing source of significant and repeated issues within the existing messaging frameworks. The last two bug bounties paid out by Wormhole were due to upgradeability issues. The Wormhole developer team upgraded a contract and forgot to set parameters. They left themselves exposed for weeks to an attack and were incredibly fortunate to have whitehats report it and collect a partial payout of the $10m bounty. Shortly after this first payout, the team performed the same issue again and paid another $10m bounty. Had a blackhat found this issue both times, the attacker could have bricked the bridge and locked up $1.8B. In 2022, Wormhole additionally lost over $325M. The recent hack of the Nomad bridge which occurred this summer was due to an upgrade which introduced a bug that allowed anyone to forge arbitrary messages and resulted in the exploit of more than $200M that still has never been recovered.

Commitment to a security operations and engineering mandate of immutable code is a challenging but critical path to take in designing the strongest, most secure, and high integrity infrastructure for developers to build upon.

As your team has familiarized themselves, at a high-level, LayerZero’s architecture consists of endpoints (immutable smart contract libraries) and independent oracles and relayers. The independence and diversity of available oracles and relayers are a unique aspect of the protocol design. LayerZero has an ever-growing array of oracles and relayers all running their own custom client software, meaning that when an application chooses, say Chainlink Oracles and the LayerZero Labs Relayer, the application developers know that both components are built by teams running completely different clients. This significantly reduces the attack surface of the messaging framework. Additionally, LayerZero by design empowers applications with the option to run a component within their messaging layer. For example, an application can opt to use multiple oracles and relayers, each their own custom clients, one of which is run by the application itself. Thus, the security of the messaging layer remains decentralized but backstopped by the veto of the application-run oracle or relayer.

LayerZero’s code is completely immutable and LayerZero Labs can never upgrade the existing code. One of our team’s core theses is that the best-in-class messaging protocol can and should evolve with best security practices and cryptographic research. In practice, LayerZero Labs can write new immutable smart contract libraries to offer as additional libraries for applications to choose from / opt-in to. Applications always maintain the choice to opt-in to libraries set as default just as they may choose to evaluate new offerings of libraries and point their contracts accordingly. A developer can choose to use the same libraries that have secured billions of dollars in TVL over the past year and maintain usage of those libraries for the next 20+ years without ever having to accept new code without interference from any LayerZero Labs activity. A developer can choose to use the longest tested library for a month and then opt later to use a library leveraging novel cryptographic proofs. LayerZero evolves and scales with research while protecting the agency and chosen security of the application developer in perpetuity. This design puts security in the hands of applications and does not render applications dependent on LayerZero Labs in any way.

umaroy · February 18, 2023, 3:34am

Hi all,

Uma from Succinct: succinct.xyz here. We’re building a cross-chain interoperability solution secured with zkSNARKs that is significantly more decentralized, permissionless and censorship resistant compared to existing bridging solutions. While our protocol has not been deployed to mainnet as of right now, we plan on deploying our protocol to mainnet quite soon and I wanted to post in this forum, if not for official consideration, then to raise awareness of a new generation of bridging solutions that are highly aligned with the decentralization, permissionless and censorship resistant properties that Uniswap governance cares about.

For some background on the general principal of light-client bridging enabled by zkSNARKs, here is an informational blog post that our team wrote: blog.succinct.xyz/post/2022/09/20/proof-of-consensus/ about the general idea.

List 3 succinct reasons why you believe your bridge/solution would best serve Uniswap governance.
1. Uniswap as a protocol fiercely cares about decentralization, censorship resistance and permissionlessness. This is evident in the deployment of all versions of the core protocol as non-upgradeable contracts with DAO-controlled voting for any protocol-level changes. Current bridging solutions that rely on permissioned multisigs or PoS validator sets do not inherit the underlying security of Ethereum and compromise on many of Uniswap’s core values. We believe that on-chain succinct light clients powered by zkSNARK technology is the first time it’s possible for a bridging solution to align fully with Uniswap’s core values.
2. Permissioned multisigs that back most existing bridges can forge fraudulent messages or censor valid messages. Permissionless, on-chain systems that verify the consensus of a source chain in the execution layer of a target chain are censorship resistant and not forgeable.
3. As highlighted in the blog-post linked to above, we believe that zkSNARK-enabled succinct light clients are the end-game of cross-chain interoperability. Some of the cons of zkSNARK bridging currently include that it is slower than normal multisig bridging and costs more gas (due to the need to verify a zk proof on-chain vs. the minimal cost of verifying signatures from a multisig). For the governance use-case, where latency and gas-costs are relatively unimportant (as governance has a timelock anyways and messages are infrequent), the cons of zkSNARK bridging are not relevant.
How long has the system been running on mainnet?
- Our system is not currently deployed on mainnet, as we are working with relatively newer technology (zkSNARKs) compared to the rest of the bridging landscape. Our current plan for mainnet deployment is quite soon (we have already deployed a system to testnet and are stress-testing it before our mainnet launch) and we believe that Uniswap governance should consider us as a viable solution in the near-term future.
How much value has the system secured? (Current TVL, total transaction volume)
- N/A for aforementioned reasons
Provide a background on your team.
- The assembled team has deep expertise in zkSNARKs, blockchain and consensus. The core engineering team has experience from some of the best academic institutions (MIT, Stanford, UC Berkeley) and professional experience from top-tier engineering and technology companies, including Google, Celo, NVIDIA, and Plaid. Additionally, our team and company originated from collaboration with idealogically aligned ecosystem partners, such as 0xPARC (0xPARC) and Gnosis DAO, who generously gave us a grant that got us our start: GIP-57: Should Gnosis DAO support research of a zkSNARK-enabled light client and bridge? - GIPs - Gnosis
Please link your developer documentation.
- Our initial documentation is being updated in real-time before our mainnet launch but an early (very rough draft) version with some of the interfaces is available here: docs.succinct.xyz/build-with-telepathy/arbitrary-messaging
Does the bridge support arbitrary message passing?
- Yes this is the only thing our bridge supports right now and our main focus as a company.
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?
- We have engaged 3 audit firms to audit our system end-to-end. These audit reports will be public prior to our mainnet launch.
  - Veridise is a premier zkSNARK auditing firm that also does formal verification of circuits. Veridise has audited our zkSNARK circuits at the heart of our system.
  - Trail of Bits is a top-tier blockchain security firm that audited our zkSNARK circuits and smart contracts.
  - Zellic is another top-tier auditor that we have engaged for our smart contracts.
Is there a bug bounty program?
- We plan on having a generous bug bounty program with Immunifi once our mainnet deployment goes live.
List ANY portion of the functional bridge that is upgradeable and explain how the upgrade process works.
- Our system is secured by an Ethereum light client running on-chain. The core light client is permissionless: it is not upgradeable and has no owner. Anyone can submit header updates to the light client and the updates are validated by the zkSNARK proof validation.
- The messaging protocol that uses the on-chain Ethereum light client is permissionless (anyone can submit messages), as the messages are validated against headers from the light client to verify they were actually sent on Ethereum. The messaging protocol is configurable and flexible to have whatever upgradeability pattern (or lack thereof) that the user desires, and our mainnet deployment will have a few different options for users to select between.
Do any contracts have an owner or owner-like entity? If so, what can the owner do?
- Addressed above.
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?
- The security model for this bridge is light client security. At a high-level we are trusting the honesty of the Ethereum validators involved in the Ethereum light client protocol. Like all other bridging protocols, the security model also includes correct implementation of the protocol as an assumption. More details about the protocol and its trust assumptions can be found here: docs.succinct.xyz/protocol/overview.
How can an adversary pass a fraudulent message from Ethereum to the destination chain? Please give specific and concrete examples.
- Like any bridge, if there are implementation bugs then the adversary can pass fraudulent messages if they hack the implementation of our system.
- If the adversary is able to systematically bribe Ethereum validators to compromise Ethereum’s light client protocol (extremely unlikely), they will also be able to trasmit a fraudulent header.
How can an adversary withhold a valid governance message from Ethereum to the destination chain? Please give specific and concrete examples.
- Similar to above, if there are implementation bugs or if an adversary is able to systematically bribe Ethereum validators to compromise Ethereum’s light client protocol and bribe them to not sign a series of valid headers (which is extremely unlikely).
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.
- N/A to our system as it is permissionless
Provide any additional information you would like here.
- We encourage Uniswap governance to consider a new generation of bridging solutions powered by on-chain Succinct light clients and zkSNARKs that are able to provide much of the security properties they care about.

zokyo · February 18, 2023, 5:27am

Dear Uniswap community,

I would like to nominate Zokyo as a strong candidate and technical expert for selecting a cross-chain solution for Uniswap governance.

Our team has extensive experience designing and securing cross chain infrastructure and have conducted audits for projects like Router Protocol, LayerZero, and Symbiosis.

Over the last four years, we have audited, tested, and secured over $200 billion in TVL, and our experience speaks for itself.

Introducing Zokyo

Zokyo secures, builds, and invests in legendary crypto/web3 projects. We keep pace with in-house development teams and provide blockchain security, design, and development talent to startups and enterprise organizations as needed.

As a go-to crypto/web3 security, token economic, and development partner working with some of the most progressive companies since 2018, we are highly experienced in tackling some of the most challenging problems with an entrepreneurial spirit.

With immediate access to in-demand skills ranging from security auditing, cryptography, white-hat hacking, mathematical specifications of network design, UI/UX design, QA, and full-stack engineering, we help companies accelerate time to market and achieve their goals.

We have consulted and audited smart contracts multiple major bridging and cross-chain messaging protocols and audited many projects which have integrated bridges and messaging protocols.

Zokyo has also performed comprehensive security audits for applications that have chosen to implement their own cross-chain solutions, including Symbosis, one of the most novel cross-chain liquidity engines.

Apart from providing auditing and security work for cross-chain specific teams, Zokyo has worked extensively with a wide range of clients, including Umami Labs, RailGun, LimitBreak, FileCoin, Mysten Labs, SushiSwap, Near Foundation, and more. Our commitment to crypto/web3 security is reflected in our extensive range of clients, who trust us to audit and fortify their code.

Our Team

Stefan Andrei, Zokyo’s CTO, will be the engineer representing Zokyo. Andrei is a highly experienced blockchain security expert who played a key role in multiple projects. He has expertise in general bridge architecture and is the lead auditor for multiple significant smart contract audits. Andrei also contributed to developing and securing MultiversX’s WebAssembly VM. He also worked on developing and securing a cross-shard/multi-shard decentralized lending application.

Andrei’s experience as a senior smart contract auditor and his experience in developing and securing multi-sharding applications will undoubtedly be an asset to this project. If selected, Andrei (and Zokyo) will strive to optimize security and governance across the platform from day one.

Andrei’s socials:

Twitter: @0xStefanAndrei

GitHub: stefanandy

Zokyo socials:

Twitter: @zokyo_io

GitHub: zokyo

Website: zokyo.io

The selection of a bridge provider by Uniswap holds great importance for the entire cryptocurrency industry. At Zokyo, our mission is to elevate crypto/web3 security standards. As such, we are pleased to offer our services pro bono.

Conflicts of Interest

Ethics form the foundation of our values. Despite our previous work with cross-chain protocols including Router Protocol, LayerZero, and Symbiosis, we are dedicated to impartiality, objectivity, and fairness. Our primary role is that of a security auditing services provider who furnishes impartial evaluations. We aim to identify the optimal cross-chain solution for Uniswap governance, irrespective of specific bridge(s).

We are confident that Zokyo is the right choice for this job, and we are excited to participate in the assessment process and contribute to the best of our abilities.

mysteryfigure · February 18, 2023, 6:39am

We’d like to offer a neutral and scientific perspective on the whole discussion by pointing to a recent paper comparing arbitrary message-passing protocols.

Arbitrary Message Passing across Blockchains

Please feel free to point out any mistakes or inappropriateness though.

ChainPort · February 21, 2023, 6:22pm

Nominating ChainPort for UNI Cross-Chain Support

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

A. ChainPort employs full fund segragation, meaning contracts operating the bridge hold only an operating budget, and over 95% of funds are secured by MPC (Fireblocks) and/or Multi-Sig Vault Contracts (Gnosis).

B. ChainPort enables a customized custodian solution, which can enable the Uniswap DAO to act as signatory holding and managing the frozen tokens in the MPC and/or Multi-Sig Vaults. This means the community/DAO can act as a requires layer of security for keeping the origin UNI safe and out of circulation while that supply is mirrored on the target chains.

C. On target chains, the mintable tokens created by ChainPort have various security mechanisms which can be delegated to the control of the UNI Governance DAO.

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

App.ChainPort.io has been live since May 2021. You can view stats for last 12 months on our stats page

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

Currently:
~170M$ TVL
605.46M$ Lifetime Port Volume
66,586 Ports to date
More stats on the stats page.

4. Provide a background on your team.

ChainPort is built and maintained by DcentraLab,
you can meet our team on Linkedin

5. Please link your developer documentation.

ChainPort Docs

6. Does the bridge support arbitrary message passing?

no, only token transfers currently. Arbitrary message passing is currently not in a mature enough state in terms of security,
hence all other bridges getting hacked on the protocol level…
Nevertheless we are working on a 2.0 version with more generalized messaging framework, and will release it once we believe it will not require bug iterations on the backs of production users and funds…

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?

The first audit was made by CyberUnitTech:
ChainPort CyberUnitTech Audit

You can review quite a few of the more updated audits made by Certik here: ChainPort Certik Audits

We also have a TrailOfBits 8 Engineering week audit performed on the backend and contracts code, which has just been concluded and we’d be happy to share it with the assessment team (it is not available online).

In all audits, any medium and up issues have been resolved, and all pertinent or actual low and below issues as well. The major vulnerability in a custodian bridge solution is the custodianship, which we resolve by multiple layers of security and segregated permissions, including also the project representatives, and our own DAO congresses and distributed multi-sig schemas.

You can read more about our security approach here: ChainPort Security

8. Is there a bug bounty program?

We’re in final stages of installing it. Running in the past we’ve seen it become very spammy, we’re working on a refined methodology for getting actual value of the program.

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

as discussed the funds themselves are 95% in gnosis vaults and/or Fireblocks MPC vaults (per the preferences of the project, e.g. UNI governance can decide where to store the origin UNI frozen on source chain). The target token is upgradable and governable by either a congress of DcentraLab representatives, or a congress of DcentraLab reps and UNI reps, or by UNI Governance reps directly.

Gnosis vaults are upgradable but will require signature of UNI DAO as well
Target Tokens (UNI on target chains) can be set to be governable and upgradable only by approval/signature from UNI DAO.
The contracts (main bridge and side bridge) operating the bridging itself, hold 5% or less of the supply (for main bridge), or have a minting capability which can be set to be frozen by the UNI DAO in cases of emergency. These 2 contracts are upgradable by a DcentraLab DAO congress vote (a cold wallet multi-sig contract schema of geo distributed representatives.

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

The bridge contracts have the DcentraLab Congress as governer.
The bridged tokens contracts has a dedicated Congress as controller, which can also be set to be a dedicated congress with UNI DAO reps included or a UNI DAO contract included as signer.
Congresses can perform security actions as unfreezing the bridge after security mechanisms trigger freezing, or making security operations on the tokens (freezing/unfreezing tokens, freezing/unfreezing accounts etc…)

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?

For the custom custody model, we remove most trust assumptions, and enable the project/DAO itself (in this case UNI DAO) to trust only itself for the majority of financially risky operations:

UNI DAO signature will be required along with the DcentraLab Congress to free up UNI reserves (rebalance bridge) - which means the TVL will be guarded directly ALSO by UNI DAO (in addition to the DcentraLab Congress).
UNI DAO signature will be allowed to freeze minted tokens on side/target chains.
UNI DAO signature will be required to unfreeze token in case of freeze, and will be able to freeze token or minting of the token,
UNI DAO signature will be required to upgrade side chain tokens.
UNI DAO will be able to run your own version of the bridge monitor, to auto-freeze minting and the token in case a discrepancy in the accounting/minting takes place (e.g. minted appear as higher then deposited amounts cross the network etc…)

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

The ChainPort system only accepts messages from the chainport contracts, so the only way to pass a fraudulent message would be to somehow take over the chainport contracts themselves (i.e. get physical access to a majority of the DAO signers). Even then, UNI DAO will have control over the reserves, and minting, and the tokens on target chains, so no real damage can be accrued and minting + the tokens can be frozen in such unlikely case until it is resolved.

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

In the current system, this can be possible if a malicious actor hacked many layers of server security and somehow took down the backend. But once the backend has redundancy mechanism so this is unlikely. But even in such case, once backend is back online it will continue processing messages where left of. As soon as valid event is emitted, it will eventually be processed.

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.

We don’t rely or depend on external actors, only on direct interest actors, in this case, the UNI DAO will partake in the security, so is serving a self-interest in protecting the UNI cross-chain network.

15. Provide any additional information you would like here.

You can read more about the custom custodian solution here: ChainPort Custom Custody Solution for DAOs/Projects

We are working on ChainPort 2.0 which will offer generalized cross chain messaging and a more decentralized message relay, validation and verification mechanisms.

We believe that the other currently available more “Decentralized” solutions are premature and much more prone to hacking, which is why our approach is to very slowly decentralize, while keeping security as main concern.

We are also now supporting Cardano utilizing a highly secure approach, which also enables the UNI DAO to govern and control the entire minted supply on Cardano in a DAO like manner, for enhanced security. We can share more on this in a dedicated discussion.

devinwalsh · February 23, 2023, 7:48pm

Hi all, I just posted an update on where we are in the process on Twitter here.

Committee members applicants: I believe we have been in touch with each of you at this point. If not, please DM the UF on Twitter ASAP (here). We are in the process of finalizing community members and should be able to announce them, and kick off the assessment process, next week.

Bridges & bridge agnostic solutions: thank you to all who have posted in the forum to apply. If we are not already in contact with you, reach out to the UF via Twitter ASAP (here) to connect. Also, please send 5000 USDC to the UF multisig (0xe571dC7A558bb6D68FfE264c3d7BB98B0C6C73fC) and send us the transaction hash once completed (either post in the forum or send to us over Twitter/Telegram). This payment will need to be made in order to kick off diligence.

jse · February 24, 2023, 9:19am

A custodian solution like this is probably the best option to avoid hacks.

erezbk · February 24, 2023, 10:40am

UNI is too important to be protected with anything less then the ChainPort custodian bridge solution. Bridging UNI will most probably will do very good for the token trading volume, exposure, and user base, and ChainPort can offer out of te box 14 chains including all those Uniswap supports now

susansumner · February 24, 2023, 11:15am

ChainPort has a great team behind it. Constant updates and lots of supported chains. Intuitive UI, fast ports, and most of all SECURITY focused.

monet-supply · February 24, 2023, 10:54pm

Think the recent situation with Wormhole/Jump and Oasis.app provides important context that should be considered in the bridge evaluation process.

Personally, this has significantly reduced my confidence in Wormhole’s capability to provide a neutral, trust minimized solution for Uniswap’s governance message passing.

Naught · February 25, 2023, 3:06am

Could you expand on why this reduces confidence in Wormholes capabilities?

From what I read it seems Oasis’s contracts being upgradable and controlled by an Oasis multisig allowed the stolens funds to be accessed in it’s vault and sent back to Wormhole via a court order.

Does this imply that Wormhole will censor or seize bridge messages/funds if ordered by court?

Topic		Replies	Views
[RFC] Ammended Deployment Proposal Process Governance-Meta	4	3026	March 15, 2024
UF Bridge Assessment Committee Results - Framework and Evaluations Governance-Meta	1	2562	June 15, 2023
Cross-chain Deployment Guide Governance-Meta	2	6962	April 25, 2024
UF Bridge Recommendations Governance-Meta	0	1519	June 15, 2023
Proposed Template for Future Cross-chain Deployment Proposals Governance-Meta	6	6283	May 6, 2022

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

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

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

4. Provide a background on your team.

5. Please link your developer documentation.

6. Does the bridge support arbitrary message passing?

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

8. Is there a bug bounty program?

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

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

11. What is the security model of the bridge? Please describe the security model for the current implementation of the bridge. What trust assumptions are you making?

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

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

14. What are the ramifications of fraud to the malicious actor(s)? If it is legal ramification, please share the suite of legal action you can provide. If it is slashing, please point us to the codebase of the slashing behavior and describe in words how slashing works in your system.

15. Appendix

A multi-path instantiation for Uniswap

Dear Uniswap Community,

WH Questions

Nominating ChainPort for UNI Cross-Chain Support

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

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

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

4. Provide a background on your team.

5. Please link your developer documentation.

6. Does the bridge support arbitrary message passing?

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

8. Is there a bug bounty program?

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

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

11. What is the security model of the bridge? Please describe the security model for the current implementation of the bridge. What trust assumptions are you making?

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

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

14. What are the ramifications of fraud to the malicious actor(s)? If it is legal ramification, please share the suite of legal action you can provide. If it is slashing, please point us to the codebase of the slashing behavior and describe in words how slashing works in your system.

15. Provide any additional information you would like here.

Related topics