Cross-Chain Bridge Assessment Process

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.


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

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


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.


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


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

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

Think the recent situation with Wormhole/Jump and 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.


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?

This is the most secure method of bridging.

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.

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!


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.


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

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

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

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

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.

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.

DM me here!

Process has kicked off for the first set of solutions. However, we are also planning how bridges might be reviewed in the future. MAP Protocol could be a part of that.

Uniswap Bridge Assessment Committee: Community Update #1

The Uniswap Bridge Assessment Committee has kicked off its deep dive into the bridges under consideration and multi-messaging aggregation solutions provided by the community.

The following is a brief progress update.

Bridge Assessment Framework

Using the crosschain risk framework, the Committee members designed an extensive framework to assess the bridges under consideration. At a high level, it covers the protocol architecture as well as implementation, operational, and network risks. Each category is further broken down into more granular topics to ensure an effective and precise analysis of the bridges. The framework’s goal is to clearly identify and assess the protocol’s security, resilience, reliability, and sustainability.

Wormhole Assessment

The Committee has conducted the Wormhole risk assessment based on the publicly available information along with further diligence questions sent to the Wormhole Foundation. Overall, the assessment went well, but there still remains a few open items that we hope to close out in the coming days.

As the assessment process kicked off, the committee identified a number of areas that could be strengthened for the purposes of the Uniswap governance use case.

  • The Committee suggested relevant improvements to the implementation of the Uniswap-Wormhole connector, including message timeouts, ordering and replay protection, and worked alongside the Wormhole team to implement these changes.
  • The team also observed that two contracts were still controlled by the deployer EOA instead of Uniswap governance timelock, after its deployment. This was partly a result of a two-phase ownership transfer model used by the messaging bridge connector, which made transferring ownership over to the Uniswap governance contract difficult. This incongruence in the transfer model with Uniswap governance was not identified prior to deployment but has since been addressed. The Committee worked alongside the Wormhole team, GFX Labs, and the Uniswap Foundation, and this issue was quickly rectified by deploying an updated implementation with a single-stage ownership transfer model.

Committee Expansion

The Committee will be expanding with an additional 2-3 members, primarily on the auditing and engineering side. Our most recent member is Kimberly Adams, the Ex-cofounder of Bridge Network. Her expertise lies in designing system architectures and scaling blockchain-based products over the past 8 years. We are thrilled to welcome Kimberly and continue growing the team as we contribute to the wider cross-chain and Uniswap community.

Next Steps

While waiting for additional information to close out the Wormhole assessment, the Committee will be initiating a review of Bridge Agnostic Solutions to understand how bridge diversity will impact the output. This will inform the iterative research we conduct into each bridge structure and how we ensure recommend a holistic recommendation on a path forward for the Uniswap community.

We have established a strong foundation through our Wormhole analysis that will streamline each subsequent bridge. From this process, the team has a more precise understanding of the time required to conduct a thorough assessment and provide the most valuable output for the community. We are working swiftly and anticipate the completion of our work to be done by end of April or early May.

If you have any questions, please reach out to @benhoneill on Twitter or Telegram.


It’s great to hear that you’re interested in discussing the use of Arbitrary Message Bridges (AMBs) for cross-chain communication in the context of Uniswap. Aggregating multiple AMBs provides benefits such as data immutability and increased security, which helps ensure that messages are transmitted accurately and without being tampered with.

However, there are downsides to using multiple AMBs, including increased costs and slower execution times. As Uniswap is deployed on multiple chains and governance scales rapidly, a cheaper and more viable solution may be needed to move forward.

But the same security can be achieved at a lower cost by just using a single AMB instead of aggregating multiple AMBs (which involves doing the same operation multiple times, increasing the cost & execution times).

Explaining it a bit more,

  • Deliver the message using one of the AMB, using Layerzero (or) Hyperlane (or) Wormhole (or) Axelar.

  • Split the message into n fragments and deliver them using n different relayers, of which one could be Uniswap’s own relayer.

  • Merge the message based on the index of the relayer and validate it against the message delivered by the AMB (which has some validations)

  • The same result is achieved at a much lower cost.


  • If AMB is corrupted, and all the relayers are honest, the message will fail to execute on the destination side.

  • If the relayers are corrupted (imagine corrupting the n number of relayers against the, and the AMB is honest, the message will fail to execute on the destination side.

  • The message will fail to execute if the AMB and all relayers are corrupted, except Uniswap’s one relayer. Hence the network is safe until the last relayer is corrupted.


  • If we want more AMBs then we can use 2 AMBs and more relayers, where 1 AMB can send entire message and once can be used for fragments (again less cost provided the AMB cost is directly proportional to the size of the message)

  • Can use AMBs to send small fragements of message, again less cost.

1 Like

This is an interesting idea. Thank you for sharing.

From the conversation we had around this is that: Uniswap should not be running its own bridging/relaying infra. If we can, why do we need these external bridges in the first place? It does not make sense for the DAO to own some AWS instances or let community members run this at this given moment.