Cross-Chain Bridge Assessment Process

[Sawa]

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]

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:

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

2. 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]

WH Questions

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

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

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

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

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

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

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

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

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

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

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

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

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

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

15. 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]

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.

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

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

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

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

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

6. Does the bridge support arbitrary message passing?

   Yes. You can try it out for yourself and send your first message in minutes!

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

8. 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/

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

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

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?

    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.

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

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

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.

    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.

15. 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]

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.

1. 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]

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:

GitHub - debridge-finance/debridge-cross-chain-dapp-example: A complete...

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]

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]

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.

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

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

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

   • N/A for aforementioned reasons

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

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

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

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?

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

8. Is there a bug bounty program?

   • We plan on having a generous bug bounty program with Immunifi once our mainnet deployment goes live.

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

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

    • Addressed 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?

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

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

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

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.

    • N/A to our system as it is permissionless

15. 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]

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]

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]

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.

1. Gnosis vaults are upgradable but will require signature of UNI DAO as well
2. Target Tokens (UNI on target chains) can be set to be governable and upgradable only by approval/signature from UNI DAO.
3. 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:

1. 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).
2. UNI DAO signature will be allowed to freeze minted tokens on side/target chains.
3. 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,
4. UNI DAO signature will be required to upgrade side chain tokens.
5. 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]

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]

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

[erezbk]

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]

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]

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

Oasis.app 🌴

Blockworks Research

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]

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?

[ReBa]

This is the most secure method of bridging.

[monet-supply]

This is my understanding of the risk. Wormhole runs on consensus between a small number of known entity nodes (basically multisig). So potentially Wormhole could be compelled to censor transactions or seize bridged assets. For fungible assets this might be less of a concern because it would be impossible to single out the target, but for something like Uniswap deployment it would be easy for them to eg transfer ownership to an unauthorized third party or take other actions without impacting bystanders.

[devinwalsh]

Hi all, today we are very excited to announce the creation of the Uniswap Bridge Assessment Committee, and the kickoff of the Assessment process.

First, the Committee. We are very proud of the group that we have assembled thus far. As previously mentioned their mandate will be to diligence the set of bridges and bridge-agnostic solutions listed below. With a focus on the needs of Uniswap governance, they will leverage this diligence to provide a short-term recommendation for how the Uniswap community might approach bridges in the coming weeks. And, they will also provide guidance on the ideal long-term solution to build towards and support, and a recommendation for how Uniswap community may continue to monitor and diligence bridges as the space evolves.

As a reminder, the selection criteria we used to select the engineers included the following: relevant technical experience, understanding of bridge architectures and potential risk vectors, and alignment with Uniswap’s long-term interests, particularly regarding its ability to remain secure as it is deployed across chains. For the PM role, we also looked for excellent organizational skills and experience with technical writing. Importantly, we precluded individuals who have a vested interest in a given bridge team. And, for each candidate, we conducted a reference check that could speak to the individual’s technical competence and character.

We are also seeking to grow the team in the coming weeks. If you meet the criteria above, or have a recommendation to join the Committee, reach out to me on Twitter (here).

Our team members are as follows:

1. Ermyas Abebe. Ermyas is one of the co-authors of the Cross-chain Risk Framework, a framework for analysing cross-chain projects. He was previously a Principal Research Scientist at ConsenSys Software, where he conducted in-depth analyses of crosschain protocols. He is a member of the IEEE ICBC Crosschain Workshop Program Committee. LinkedIn, Twitter.
2. Jasraj “Jazzy” Bedi. Jazzy is the co-founder and CTO of Zellic, Inc, an audit company. In this role he has conducted multiple audits across bridges in the space, and has contributed to in-depth post-mortems of bridge hacks which have occurred in the past. LinkedIn, Twitter.
3. Sean Casey. Sean is the co-CTO and Head of Enzyme Protocol Development at Avantgarde Finance. His expertise lies in smart contract engineering experience and protocol integrations. He has deep knowledge of the Uniswap Protocol, having led Avantgarde’s integration with the Protocol. Avantgarde is also an active Uniswap delegate. LinkedIn.
4. Ben O’Neill (Project Manager). Ben is the VP of Business Operations at Chaos Labs, an on-chain economic security & risk platform that uses simulations to test protocol vulnerabilities across DeFi, bridges, and tokeneconomics. Previously, Ben was the VP of Business Development & Operations at Messari. Notably, while at Messari, Ben led the creation of Messari transparency reports, a product that verified and made public a set of objective standard information across protocols - work that is very analogous to the work of the Bridge Assessment Committee. LinkedIn, Twitter.
5. Peter Robinson. Peter is soon to be the Head of Blockchain Research at Immutable, starting in March (will work with the Bridge group until then). With Ermyas, he is one of the co-authors of the Cross-chain Risk Framework. He was previously a Technical Director, Researcher, and Applied Cryptographer at ConsenSys Software, with a focus on researching and advising on crosschain technologies. He also previously co-chaired the Crosschain Interoperability Working Group for the EEA and is co-chair of the IEEE ICBC Crosschain Workshop Program Committee. He also completed his PhD at the University of Queensland on Crosschain Communications. LinkedIn, Twitter.
6. David Hyland-Wood. David is an entrepreneur and multi-disciplinary engineer with deep expertise across a number of areas. He is currently an Adjunct Associate Professor at the University of Queensland School of Engineering, with a focus on on blockchain and distributed systems consensus. He previously served as a Lead Researcher at ConsenSys Software, focused on developing the first international blockchain standard for PegaSys, the ConsenSys protocol engineering group. He is also a member of the IEEE ICBC Crosschain Workshop Program Committee. LinkedIn.

All Committee members are excited to leverage their expertise in crosschain communication to assist the Uniswap community. They hope that this work will also help the other protocols in navigating decision-making around bridges as well.

Now, onto the bridges and bridge-agnostic solutions. The Committee will be analyzing 8 bridges:

1. Axelar (submission post here)
2. Celer (here)
3. deBridge (here)
4. Hyperlane (here)
5. LayerZero (here)
6. Multichain (here)
7. Router Protocol (here)
8. Wormhole (here)

and 3 bridge-agnostic solutions:

1. Multi-bridge implementation, built by the Celer team (here)
2. Block Header Oracle based solution, being built by Gnosis team (here)
3. ERC-5164: Cross-chain execution (interface supporting execution across EVM networks) (here)

Some bridges may themselves be able to be used as the infrastructure for an agnostic solution as well (as suggested by Hyperlane here). That will also be examined.

@benhoneill and I will keep the community updated with developments and timelines for delivery. If you have any questions please direct them to one of us on behalf of the committee and we will triage appropriately. (Devin Twitter, Ben Twitter)

Bridge teams, I will be connecting you to this group over the next few days.

Thanks all, we are so excited to kick this off!