Cross-Chain Bridge Assessment Process

29

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.

image
image1400×438 79.3 KB

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

  • Security: deBridge has taken a unique approach and implemented an off-chain validation mechanism where all messages are signed by a set of validators who are elected by and work for deBridge governance. Validators are obliged to sign a unique identifier of every message that is sent through deBridge smart contract with their private key and then make the signatures public so anyone can execute messages on the destination chain. deBridge smart contract checks the validity of all the signatures and in the case at least 2/3rd of signatures are valid, delivers the message to the recipient.
    Validators don’t communicate with each other and they never expose their IP addresses making it very difficult to attack the infrastructure.

  • Unlimited throughput and scalability: deBridge doesn’t have its own blockchain or intermediary consensus layer, that’s why there is no throughput bottleneck. deBridge also doesn’t need to bootstrap liquidity pools in order to scale up to new chains. In case Uniswap governance decides to deploy on new chains that are not yet supported by deBridge, we will be able to quickly add support for these chains.

  • Optimal gas-efficiency: At deBridge, validators never broadcast any transactions. Hence, they never bear gas costs, unlike other interoperability protocols where gas costs of the validation layer are born by the message sender.

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

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

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

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

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

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

4. Provide a background on your team.

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

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

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

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

5. Please link your developer documentation.

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

Cross-chain Dapp example:

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

6. Does the bridge support arbitrary message passing?

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

Learn more here: Getting started - deBridge

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

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

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

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

8. Is there a bug bounty program?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Read more about our slashing and delegated staking here:

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

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

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

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

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

More details about our security measures can be found here.

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

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

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

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

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

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

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

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

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

––

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

2 Likes
30

omnichain-governance-executor
omnichain-governance-executor1764×721 8.32 KB

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.

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.

3 Likes
31

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.

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

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.

35

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.

2 Likes
38

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)

image
image1920×966 80.5 KB

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.

8 Likes
39

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.

4 Likes
40

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

2 Likes
41

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

42

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

1 Like
43

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

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

2 Likes
44

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?

45

This is the most secure method of bridging.

46

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.

47

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!

10 Likes
48

It is great seeing the committee moving forward with a group of capable and unbiased people.

I am Kydo from Stanford Blockchain Club and am a community member advocating for the bridge-agnostic solution(s).

I want to make a small clarification that these 3 bridge-agnostic solutions are actually one solution, we are calling the design Multi-Message Aggregation (MMA)

You can find the current implementation here: GitHub - MultiMessageAggregation/multibridge at EIP5164

We believe these solutions share the same goals and can be implemented within the same design. We applaud @modong from Celer, @owl from Gnosis, and the ERC-5164 authors for their contributions to the design.

8 Likes
49

Great discussion guys. At Coinchange recently we wrote a 50-pages research report on Crosschain Interoperability and Security along with co-authors from LiFi and Hacken. In Part 4 of the report, we do talk about a Bridge Risk Framework. Would be happy to contribute to the assessment committee. @devinwalsh

50

Jerome here, Head of Research at Coinchange.
Here (coinchangeio under resources find crosschain-interoperability-report) is the research report mentionned by Pratik. I’m supporting the post from Pratik, our WIP Bridge Risk Assessment Framework will benefit from the set of questions and answers provided by the different bridges in this very active discussion, as they are the most condensed version of each bridge description and security aspects.

However, from the questions we already created and gathered from some of the frameworks mentionned by LIFI here and more:

We believe the questions list is missing some detailed aspect, that we think should be addressed which could help the assessment committee to arrive to a conclusion.
We will also be very attentive to the outcome of the assessment comittee and the likely creation of a Uniswap Bridge Risk Assessment group where a comprehensive framework might be created. We would be happy to contribute and make this project set a precedent for the crosschain interoperability in the future.

Finally we are reassured that some of the most qualified individuals today on crosschain technologies like @ermyas, @drinkcoffee and Jasraj are part of the Bridge Assessment committee.

1 Like
51

Nominating MAP Protocol for UNI Cross-Chain Deployment

Hi all, MAP Protocol (MAPO) here. Built on Light-client & ZK technology, MAP Protocol is an interoperable omnichain layer for Web3 which enables 100% Nakamoto Style cross-chain communication with zero privileged roles. MAP Protocol can connect both EVMs and non-EVMs; it has now connected to Ethereum, BNB Chain, Polygon, and NEAR and will soon connect to Cosmos Hub, PlatON, Klytan, and other major EVM & Non-EVMs.

We believe a multi-bridge agonistic solution will be a win-win for all parties involved and especially for UNI members. With our innovative light client and ZK cross-chain solution, we genuinely hope MAPO could be part of the effort and solution to empower UniSwap to grow with greater security and interoperability.

Below are our answers to the 15 questions.

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

1. The level of cross-chain decentralization and security

Popular cross-chain solutions, namely MPC, Oracle + Relayer, and Light client, have sacrificed decentralization in some way or another, but MAP Protocol has kept the integrity of decentralization and security.

Specifically, in an MPC cross-chain solution, the whole verification process’s security rests in the hands of a few selected entities, which is a centralized way for verification and already contributed to several cross-chain hacks such as Ronin Bridge and Harmony Bridge. Oracle + Relayer cross-chain solution eliminates privileged parties from the verification process but cannot avoid the collusion risk between oracle and relayer.

However, MAP Protocol’s light client and ZK cross-chain verification mechanism can eliminate privileged roles and collusion risks from the cross-chain verification process because light clients used for cross-chain verification has the self-verifiable capability; the whole cross-chain verification process can be fully on-chain in a truly decentralized manner, no centralized or privileged entities involved.

With the same adherence to decentralization, we believe our cross-chain solution will be the most suitable one for retaining decentralization and keeping cross-chain space secure.

2. Full coverage for ​​EVMs and Non-EVMs

Unlike most cross-chain solutions that only support EVM cross-chain or one-way cross-chain, MAP Protocol is able to connect both EVMs and Non-EVMs. This is because MAP Protocol can innovatively embed each destination chain’s algorithm as pre-compiled contracts to facilitate light-client deployments on MAPO Relay Chain. MAP Protocol started connecting to Cosmos Hub last month. Once it has completed wrapping light clients with Cosmos IBC standards and enters the testing phase, Cosmos inter-chain network can technically connect with other chains in a fully decentralized way. This will mark MAP Protocol to be the first cross-chain solution that allows Cosmos inter-chain network to communicate with other chains with light client technology.

With the growth of Web3 in general and the increase of users on other chains, UNI may consider deploying on other EVM and Non-EVM chains in the future to tap into more users and onboard them to the UNI community. MAPO’s extendability and full-chain coverage ability can help UNI in the long term to achieve permissionless growth.

3. Continuous technical innovation

Innovation is at the core of MAP Protocol. We were the first and only cross-chain solution that achieves truly trustless communication in the cross-chain space with full-chain connectivity. Up till now, we’ve connected to Ethereum, Polygon, BNB Chain, and NEAR, and will soon connect to Cosmos Hub, Klytan, and Avalanche.

This full-chain utility supports data and messaging cross-chain as well. Most recently, we helped CATASTROPHY, an NFT Multipass, to allow CATASTROPHY holders seamlessly access their BUIDL benefits and unlock various tools across multiple blockchains and platforms without any restrictions. We have also innovatively utilized ZK technology for cross-chain verification. MAPO is working on applying the most advanced ZK to bring down the on-chain gas fees and further increase the efficiency of cross-chain communication.

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

MAP Protocol has launched Mainnet since August 2022. You can access MAPO Mainnet via this link https://maposcan.io/

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

As MAP Protocol was only launched early this year, the current total transaction volume is around $529,850 for now.

4. Provide a background on your team.

With the mission of constructing a cross-chain peer-to-peer e-cash payment system infrastructure, a team of experienced blockchain research experts, smart contract developers, and bottom-layer blockchain engineering experts came together and started to build MAPO in 2019.

After almost four years of full-stack development effort, MAP Protocol is now contributed by a group of distributed team members. Core members are based in the US, Singapore, South Korea, Hong Kong, and Dubai. MAP Protocol has around 20 to 40 full-time members. With technical innovation being the core focus, 80% to 90% of our core team members are developers.

The technical team is experienced in blockchain research and development and has joined MAP Protocol’s endeavor since day one. Phil Lau, MAP Protocol’s CTO, is a member of IEEE Computer Society Blockchain and Distributed Ledgers Committee Technical Board, and Frank Wen, MAP Protocol’s chief scientist, is an expert in applied cryptography and a Core developer of Bitcoin Cash (PoW).

5. Please link your developer documentation.

6. Does the bridge support arbitrary message passing?

Yes, as an omnichain infrastructure, MAP Protocol supports any cross-chain message passing; thus, any events on Ethereum can be passed to the destination chain in a trustless way.

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, MAP Protocol has completed comprehensive audits on all products. The audit report is available here MAP Protocol - Web3 Security Leaderboard. The issues identified in the audits are generally low in terms of severity and mainly have to do with the hash-to-point algorithms of the compiled signatures in the MAPO Relay Chain. Now, all vulnerabilities identified in the audits have been fixed and reviewed.

Cross-chain bridges have been the NO.1 target for hackers in recent years, which is why MAP Protocol puts security as one of the top priorities. MAP Protocol has partnered with world-leading third-party code auditing firms to conduct exhaustive auditing of any important updates of our codes.

8. Is there a bug bounty program?

Our bug bounty program is in the final stage of implementation. To ensure the bug bounty program can run smoothly without being spammy, we’re working internally to refine the designs and mechanism of the program.

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

Yes, MAP Protocol’s contracts are upgradeable. The ability to upgrade is controlled by an MPC contract, but we will change the MPC contract to on-chain governance on MAPO Relay Chain for greater decentralization and security.

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

If contracts include bridge functionality, then the contracts of Butter will be included, which does have an owner. The owner of Butter’s smart contracts is an MPC contract, where the owner can set the types of assets that the bridge can support and the transaction fees.

Note: Butter is an omnichain solution built upon MAP Protocol for secure and seamless asset movement.

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?

Cross-chain communication enabled by MAP Protocol is based on light clients, which is implemented via cryptography. Our cross-chain solution aligns with Nakamato’s philosophy of decentralization, where no trusted third parties engage in the verification process.

MAP Protocol’s light clients are built into the chain or deployed to the chain as a smart contracts to update and save the validators’ information of MAPO blockchain periodically and to verify the proof generated by MAPO blockchain. The light client follows these steps to verify the proof data:

  1. Compute the epoch number of the block header and get the validators record by epoch number. If no record exists, an error is returned.
  2. Use the validators to verify the ecdsa signature of the block header, and use validator and the aggregated G2 public key to verify the BLS signature of the block header. This proves the validity of the block header. If verification fails, an error is returned.
  3. All the receipts hashes in a MAPO block construct a Merkle Patricia Tree, and the tree root is recorded in the block header. The light client retrieves the tree leaf through the tree root from block header, the key index, and the proof in the proof data. Then it checks whether the tree leaf equals the hash of the receipt included in the proof data. If not, an error is returned.

If all the above verifications pass, the proof data is proven to be valid.

How light client works in MAP Protocol
How light client works in MAP Protocol1280×720 193 KB

Take Chain A to Chain B communication as an example. The block header information of chain A is updated by the inter-chain messenger to the light client of chain A on chain B. If there is a fake transaction from a hacker trying to cross from chain A to chain B, the transaction will not be verified by the light client as valid unless the hacker attacks the entire blockchain A as a whole. With light-client being the core verification component in this cross-chain design, it would be impossible for a hacker to obtain a valid signature from validators on chain A, hence chain B will not accept such an invalid cross-chain request initiated by the hacker.

MAP Protocol’s cross-chain communication is based on light clients; thus, the whole verification process is fully on-chain, and we do not hold trust assumptions for cross-chain verification.

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

No fraudulent message can be passed from the source chain (Ethereum) to the target chain. In MAP Protocol’s security design, when a fraudulent message passes to the MAPO relay chain, the proof it creates cannot pass the verification of light-client on Ethereum.

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

As light clients (which are self-verifying) are the ones responsible for verifying cross-chain communication, there will not exist scenarios where a valid governance message from Ethereum is withheld and unable to pass to the destination chain with MAP Protocol’s cross-chain solution. In fact, as long as the massage is valid, anyone should be able to pass the message from Ethereum to the target chain.

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

With our fully trustless security design, any fraud action can be checked, and the network will reject fraud messages. Messenger and Maintainer are two cornerstones for cross-chain communication in MAP Protocol. It can be possible that Maintainer or Messenger does not work properly; however, no matter how they can act out, they cannot impact cross-chain verification or allow fraud messages to pass. What they may impact is cross-chain efficiency, but will never affect cross-chain security.

Currently, we do not have a slashing mechanism for Maintainer but we do have an alarm system to prevent Maintainer from acting out. If Maintainer does not submit cross-chain messages to the light client, it will trigger an alarm. Additionally, to be a Maintainer, the party will need to stake $MAPO to work and get rewards, and if they do not work properly, they cannot get rewards or their staked tokens. The slashing mechanism for Messenger, on the other hand, is customizable by individual projects, thus fully depending on how the project wants to work.

Note: Maintainer is an independent inter-chain messenger responsible for updating the latest status of light clients and submitting block headers’ info on each chain as a transaction ultimately to the target chain. Messenger is an independent inter-chain program, working for MAPO Service (an omnichain SDK for dApp developers). It listens to relevant events as preset in the program and builds a proof on the ledger of the source chain; then transmits the message of the event and proof to Vault or Data on the destination chain.

  1. Provide any additional information you would like here.

As the truly trustless omnichain infrastructure in the blockchain space, we believe that we can contribute to the Uniswap community with our adherence to decentralization and continuous technical innovation.

We know there are many popular cross-chain solutions but they either compromise on the principle of decentralization and the level of security or they are unable to connect all EVM and Non-EVMs. As MAP Protocol will soon connect to Cosmos Hub, it will be another milestone for blockchain interoperability and connect members in Cosmos Hub to members in Uniswap, thus allowing decentralized finance can truly thrive from the bottom up.

Comparison.pptx
Comparison.pptx1280×720 111 KB

52

Hi there, Kari from MAP Protocol here. May I know where to get the latest updates on the assessment process? And is it still possible to add another cross-chain solution for the assessment at current stage?

MAP Protocol is an omnichain infrastructure built upon light client and ZK technology. We are the truly trustless cross-chain solution with full-chain connectivity on the market, and we would really like to contribute to the Uniswap community with unwavering decentralization and security risks kept at bay.