[Xangle Digest]

※ This article contains content originally published by a third party. Please refer to the bottom of the article for the copyright notice regarding this content. 

Table of Contents

Multichain’s anyCall
Hyperlane
deBridge
Comparative Analysis: Which AMB to Build on?
Closing Thoughts 

Multichain's anyCall

Overview

anyCall is a generic cross-chain messaging protocol built by Multichain leveraging its Secure Multi-Party Computation (SMPC) network to sign transactions to send messages and contract calls from one chain to another. The team believes that anyCall will be the backbone of the next phase in the evolution of dApp design.

In January 2022, two critical vulnerabilities with the Multichain liquidity pool contract and router contract were exploited, resulting in the loss of $3M in users’ funds. The team worked closely with whitehat hackers and recovered nearly 50% of the total stolen funds.

anyCall expands the brand name and experience of the Multichain team into cross-chain messaging. Some of anyCall’s best features include:

• Ease of deployment — Integrating anyCall is consistent and hassle-free for developers. The quick and easy integration enables developers to add the business logic of cross-chain transfers to their dApps without spending many resources.
• Ability to transfer arbitrary data across chains — anyCall enables the transfer of arbitrary data like smart contracts, messages, tokens, NFTs, and data from one blockchain to another in just one transaction.
• Improved UX — anyCall allows multiple functions (like bridging and swapping) to be performed with a single contract call. As a result, users have to go through fewer steps, improving a dApp’s UX significantly.
• Cross-chain contract calls — This feature enables calling a contract on the destination chain directly from the source chain. anyCall can be used for any type of cross-chain communication, such as sharing information like state, data, and messages across chains.

Additionally, anyCall enjoys the following network effects:

• Connectivity with the Multichain ecosystem — Multichain is one of the most widely used bridging solutions. It has tremendous connectivity and enables users to bridge over 1600+ tokens across 60+ blockchains, including EVM and non-EVM chains.
• Mutlichain’s bridged volume and TVL — Multichain has over $86B in total bridged volume to date and boasted a TVL of over $10B at peak. It constantly does over $50M in daily bridged volume from 3,000+ daily active users.
• Network connectivity — As of September 2022, anyCall supports arbitrary message passing and cross-chain contract calls across 11 chains: BNB Chain, Polygon, Ethereum, Optimism, Gnosis Chain, Fantom, Moonriver, IoTeX, Arbitrum, Avalanche, Harmony.
• Protocol level integrations — anyCall has been integrated by dApps like Curve to support multi-chain gauges, Hundred Finance to offer uniform reward distribution, Fiver for gas to acquire gas tokens by paying in stables, and Fantom Animals to offer omni-chain NFTs.
• MULTI token holders — MULTI is a top 300 token with a market capitalization of roughly $100 million.

How It Works — Transaction Lifecycle

anyCall’s architecture can be divided into two layers — the lower layer and the upper layer. The lower layer consists of an off-chain trust mechanism, whereas the upper layer consists of an on-chain call/trigger API.

The off-chain trust mechanism is responsible for validating messages from the source chain. It triggers the required operations after performing destination chain addressing as per the logic specified by dApps. The upper layer consists of a trigger API on the source chain and a call API on the destination chain. When the API on the source chain is triggered, the off-chain trust mechanism initiates the validation for consensus, and afterward, the call API on the destination chain completes the contract call as specified by the dApp.

anyCall relays messages across chains through the following contracts and functions:

• Step 1, anyCall Function — This function is present on the source chain and plays a key role in storing data to be transferred to the destination chain. The anyCall contract validates and relays messages to the destination chain.
• Step 2, Multichain’s MPC network — The MPC network consists of 24 nodes and is responsible for performing validity checks on messages sent to the anyCall contract by the anyCall Function. The anyCall contract is present in a common MPC address across all supported blockchains. When a message is sent by the anyCall function, MPC nodes ensure the security of the messages before sending them to the destination chain.
• Step 3, anyExec Function — The anyExec Function receives messages from the anyCall contract and executes the request on the destination chain. 

Security

anyCall offers the following security features –

• Multichain’s MPC network — anyCall depends on Multichain’s Multi-Party Computation nodes to verify the information across chains. The MPC network adopts a method where a single private key is subdivided and encrypted among several nodes to ensure the security of the system. It is a distributed mechanism that consists of nodes executing a predetermined amount of signatures per transaction to approve cross-chain movements of assets.
• Audits from external security companies — Multichain conducts detailed security audits from security companies. For anyCall, the team has conducted 2 audits, both by BlockSec — one for the older version and one for the new version of anyCall (both versions are currently live).
• Open bug bounties — Multichain has one of the biggest bug bounties running on Immunefi, with rewards up to $2M for finding vulnerabilities in the system. Moreover, Multichain is also active on other bug bounty platforms to attract whitehat hackers to find potential vulnerabilities.
• Transaction limits — To ensure the security of funds, Multichain has adopted the rule of delayed withdrawals, the length of which is proportional to the amount of the transaction. This ensures that Multichain gets adequate time to validate that transactions are genuine and safe.
• Total volume limits on new chains — For new chains with relatively lower security, Multichain limits the total volume that can be bridged to/from that chain within a certain period. This strategy helps avoid bad asset spillovers to other chains when a particular chain is hacked (ex: Harmony’s $100M hack).
• Security fund — Multichain has an insurance fund where 10% of all transaction fees are stored. These funds can be used to compensate users if any assets are lost under special conditions.

Trust Assumptions

anyCall makes the following trust assumptions:

• Externally verified by the MPC network — anyCall transfers are verified by the MPC network, a group of 24 validator nodes. Thus, users need to trust the nodes to act honestly and also validate correct messages/transfers. ½ or 13 nodes can collude to steal user funds.
• Nodes care about reputation — anyCall’s security relies on the reputational security of the nodes in the MPC network. It assumes that the potential benefits of acting maliciously and colluding to steal user funds are lesser than the reputational costs for the nodes.
• Censorship risk — If 12 MPC nodes collude, they can censor a message through anyCall.

Community & Resources

You can learn more about Multichain’s anyCall and stay updated about its community through the following:

• Official Website
• Docs
• Whitepaper
• Github
• Analytics Dashboard
• Medium
• Twitter
• Telegram

Hyperlane

Overview

Hyperlane, previously known as Abacus, is a generalized interchain messaging protocol offering an on-chain API that sends and receives messages across chains. It is primarily a tool built to empower developers to send data between chains and create natively cross-chain applications. Its key differentiators are Hyperlane’s explicit focus on data passing via APIs and the flexibility it offers to dApps to set up application-specific validators.

Some of Hyperlane’s best features include:

• Easy to integrate API — Hyperlane offers an on-chain API that can be integrated into dApps to send and receive interchain messages. According to Hyperlane, developers can send a simple interchain message to a predeployed smart contract in less than five minutes.
• Local security provided by application-specific validators — Applications can add their own validator sets for security purposes (in addition to Hyperlane’s proof of stake protocol).
• Message observability — Applications can track interchain messages and perform an action when the message is processed on the destination chain. The team plans to add an interchain message explorer to enable complete message observability in the near future.
• Network Connectivity — As of September 2022, Hyperlane supports arbitrary message passing and cross-chain contract calls across seven chains: Arbitrum, Avalanche, BNB Chain, Celo, Ethereum, Optimism, and Polygon.
• Natively interchain DAO governance — Hyperlane is governed by a DAO, and ABC token holders have the power to propose and implement changes to the Hyperlane protocol by voting from any Hyperlane-supported chain.

How It Works — Transaction Lifecycle

Hyperlane uses “Inbox” and “Outbox” smart contracts to send and receive interchain messages. Every chain Hyperlane supports has one Outbox and n-1 Inboxes (one for every other chain). Sending and receiving messages with Hyperlane is a three-step process:

• Step 1 — An application calls Outbox.dispatch() on the source chain. Each message gets inserted as a leaf into an incremental Merkle tree (for gas efficiency) of the Outbox.

Note: The Outbox.dispatch() function consists of all information related to the transaction (such as message content, destination chain ID, and recipient address).

• Step 2 — The latest Outbox Merkle root is signed by the validator set of the source chain. This Merkle root is also signed by application-specific validators (local security) if they exist.
• Step 3 — A Relayer delivers the message to recipients by calling InboxValidatorManager.process(). Doing so provides the message’s Merkle proof, the message, and the signed root mentioned in step 2. The InboxValidatorManager verifies that the root was signed by validators and then calls Inbox.process to verify the Merkle proof. After verification, the Inbox contract calls the recipient.handle() function, and the messages are delivered to the application.

Security

Hyperlane offers the following security features:

• Economic security by the PoS Validator set — Hyperlane security relies on a delegated proof-of-stake protocol. Each Hyperlane-supported chain has its own validator set, and the PoS protocol ensures that there is an economic cost for malicious actions.
• Users select validators — Users can stake ABC tokens and delegate them to Hyperlane validators. The validators with the most tokens delegated to them are chosen to be part of the validator set. There is also a transition window where users can propose to change members of the validator set.
• Application-specific security through sovereign consensus — Hyperlane introduces a new flavor to the world of AMBs. It takes a page out of Cosmos’ application-specific development concept and offers developers the flexibility to enhance the security of their dApp. On top of securing the API with a delegated proof-of-stake protocol that validates messages for all the dApps building on Hyperlane, applications are allowed to specify their own validator set. This gives developers the ability to design their own validator set with application-specific security guarantees.
• Censorship resistance — Unlike most AMBs, Hyperlane validators don’t sign individual messages. Instead, they sign the Merkle root of the Outbox with all the messages bundled together, thereby improving Hyperlane’s censorship resistance, as validators cannot censor specific messages.
• Watchtowers for supervision — Hyperlane’s design consists “watchtowers” that observe an Outbox and the related Inboxes to detect malicious validator activity such as censorship or fraudulent messages. If a watchtower detects malicious activity, it can submit the evidence to the source chain and earn a reward. In such cases, validators are penalized with their stake getting slashed.

Trust Assumptions

Hyperlane makes the following trust assumptions:

• External verification by a validator set — Hyperlane uses a chain-specific validator set to sign messages going from one chain to another. As a result, there’s an inherent trust in the design as users trust that validators verify transactions honestly and do not collude to steal the funds.

Note: Specific details about Hyperlane’s validator set, such as the number of validators, staked capital, etc., are not publicly available.

• Each chain’s security is not the same — Each Hyperlane-supported chain has its own validator set. This means Hyperlane does not require validators to be present on all supported chains. As a result, some chains may be less secure than others if there’s low economic security due to fewer validators. However, Hyperlane offers applications the flexibility to choose the chains they want to send/receive messages across. As a result, if a dApp concludes that a specific chain’s security is insufficient, it can choose not to integrate that chain.
• Slashed stake penalty will always de-incentivize validators from colluding — The stake of Hyperlane validators are bonded, i.e., their stake will be slashed if they act maliciously (collude or censor messages). While users are protected by a slashing mechanism, there is an assumption that it provides economic security in all scenarios. However, in cases where the cost of attack (slashing penalty and reputation) is lower than the amount of capital that can be stolen by colluding, there is more incentive for validators to collude and steal funds rather than acting honestly.

Community & Resources

You can learn more about Hyperlane and stay updated about its community through the following:

• Official Website
• Docs
• Github
• Twitter
• Discord

deBridge

Overview

deBridge is a generic cross-chain messaging and interoperability protocol. It aims to expand the concept of traditional bridges by allowing users and developers to transfer both simple messages and complex data (such as arbitrary messages or call data) from one chain to another.

deBridge’s main selling point is the wide range of developer-friendly tooling it offers, which opens up opportunities for composability and enables developers to build complex cross-chain applications. As an infrastructure platform, deBridge enables developers to leverage its cross-chain messaging functionality by seamlessly integrating any of its tools, such as SDK, API, or widget, depending on their requirements, and build different cross-chain use cases, such as token bridges, NFT bridges, cross-chain staking, lending, payments, credentialing, etc.

Some of deBridge’s best features include:

• Limitless value transfers through deSwap Liquidity Network (DLN) — DLN is a protocol built on top of deBridge introducing a new design that utilizes liquidity across chains on demand instead of locking it in liquidity pools, enabling unlimited asset transfers across chains with 0 TVL.
• Hardhat plugin — deBridge’s hardhat plugin offers a secure environment for dApps building on it to test different features before going live.
• Cross-chain transaction bundling — deBridge lets dApps bundle different transactions into a single transaction, allowing them to offer swaps + interactions in one maneuver (ex: staking).
• Full functionality (even if some blockchains experience downtime) — deBridge’s architecture consists of an off-chain transaction validation mechanism. As a result, if certain blockchains experience downtime, deBridge protocol can continue processing transactions for all other supported chains. Moreover, given the off-chain validation mechanism, deBridge’s validators don’t need to relay any transactions and thus have unlimited throughput. Additionally, since the validators don’t need to communicate with each other, their IP addresses are never exposed, increasing the overall security of the infrastructure.
• Verifiable and open transactions — Details of any cross-chain transfer through deBridge’s infrastructure can be accessed by anyone on deBridge’s Explorer.

Additionally, deBridge enjoys the following network effects:

• deBridge applications — The team behind deBridge has built several deApps that showcase its capabilities. Examples — 1) deSwap: a solution for cross-chain swaps, 2) dePort: a bridge that enables applications to mint synthetic representations of their tokens, 3) deNFT (not launched yet): a solution to build cross-chain native NFTs.
• dApps building on it — deBridge’s infrastructure is being used by several applications. For instance, Thunder Lands recently integrated dePort to scale the Thunder token (TNDR) across chains. Since dePort is built on deBridge protocol, it can be said that Thunder Lands is built on deBridge infrastructure. Similarly, deBridge’s applications are being used by Frontier Wallet, Wirex Wallet, Plato, and Minimax, among others.

• Winner of Chainlink Global Hackathon — deBridge began as a hackathon project in April 2021 at the Chainlink Global Hackathon where it was awarded the Grand Prize.
• Funding — deBridge raised $5.5M in a funding round led by ParaFi. The round also saw participation from Huobi Ventures, Crypto.Com Capital, and Animoca Brands, among others.
• Network connectivity — As of November 2022, deBridge supports 7 blockchains: Ethereum, BNB Chain, Polygon, Arbitrum, Heco, Fantom, and Avalanche. The team plans to add support for non-EVM chains such as Solana (and more) soon.

How It Works — Transaction Lifecycle

A transaction through deBridge’s architecture passes through two key layers:

• Protocol Layer (on-chain) — a set of on-chain smart contracts deployed on all deBridge-supported chains. The parameters of the smart contracts, such as fees, chains, and validators, are managed by deBridge governance.
• Infrastructure Layer (off-chain) — nodes run by validators elected via deBridge’s governance. These validators also run full nodes on all the blockchains supported by deBridge.

Here’s how deBridge works at a high level:

• Step 1: A transaction is assigned a Submission ID (unique hash) when it passes through the smart contract on the source chain (aka deBridgeGate) — this ID is the identifier of each transaction and ensures the uniqueness of the message within the deBridge protocol.
• Step 2: deBridge validators (12) track events emitted by deBridgeGate smart contracts on all supported blockchains. They wait for a specific amount of block confirmations (depending on the chain) until the transaction achieves finality before validating. If the details of the submission are correct, each validator signs the Submission with their own Private Key and publishes it to the deBridge API.
• Step 3: Validator signatures are saved to IPFS (the team plans to add Arweave soon) where they can be retrieved by anyone (user or keeper) to be passed through the deBridgeGate smart contract on the destination chain (aka target chain).
• Step 4: At least ⅔ (8 out of 12) validators must sign a message for it to be confirmed and claimed on the destination chain. If the required number of signatures is met, the transaction is executed by the deBridgeGate smart contract, and the call data is transferred to the target chain.

Source: deBridge Transaction Lifecycle (or lifecycle of a cross-chain call)

Security

deBridge offers the following security features:

• Slashing mechanism — Validators play a crucial role in deBridge’s architecture. deBridge uses a slashing mechanism to disincentivize validators from colluding. All deBridge validators are required to lock collateral (their own + collateral delegated to them) in a delegated staking smart contract. This collateral acts as a guarantee of validators’ fairness, or else their collateral will be slashed.
• Delegated staking — Validators and delegators receive protocol fees as an economic incentive for securing the deBridge architecture. Furthermore, any user who decides to unstake assets must go through a 14 day “cooldown period” before receiving their funds back. This is helpful for two reasons: 1) helps avoid front-running and prevents users from staking opportunistically to capitalize on rewards during periods of high volume, and 2) allows governance time to slash validator collateral in the case of malicious activity.
• Transaction finality specifications — In deBridge’s architecture, validators are required to wait for a specific number of block confirmations and sign transactions only once it achieves finality. As a result, the protocol prevents double-spending since the transaction becomes irreversible after it has achieved ensured finality. Moreover, validators have the flexibility to strengthen finality rules to enhance security when large amounts of funds are being transferred through the protocol within a short block range. This enables the protocol to disincentivize 51% attacks given the increased costs of attack (since it will have to be done over a longer period of time or range of blocks).
• Validation through the Nonce sequence — Nonce refers to the unique sequence number assigned to every transaction passing through the deBridge smart contract. deBridge’s validators are required to always confirm transactions in ascending order of the “Nonces”. This helps avoid double-spending and enhances the protocol’s security against chain reorgs and 51% attacks.
• Balance sheet validation for synthetic assets — To ensure that balances calculated in the deBridge node match balances in the state of the smart contract, validators do balance sheet validation wherein the validation stops if there’s any deviation. This is critical to ensure that synthetic assets are always backed by original assets.
• Audits and Immunefi bug bounty program — deBridge protocol and periphery modules have been audited 17 times by Halborn, Zokyo, Ackee Blockchain, and Neodyme. Additionally, deBridge offers a $200,000 bounty program on Immunefi.
• DAO governance — The team aims to decentralize governance by enabling token holders to participate in voting for critical protocol-related decisions (such as allocating treasury resources and changing the protocol’s parameters).

Trust Assumptions

deBridge makes the following trust assumptions:

• External verification by a set of validators — deBridge uses a validator set with only 12 validators to validate and execute transactions. To be confirmed, a transaction must be signed by at least ⅔ of the validators, i.e., 8. Thus, it’s possible for any 8 validators to collude and steal users’ funds. However, the validators are disincentivized to act maliciously as they bear financial risks for their service as per the delegated staking and slashing module. Moreover, the team recently introduced deSwap Liquidity Network (DLN), which reduces the funds exposed to validator set collusion to a single transfer instead of the entire TVL of deBridge protocol. Furthermore, deBridge plans to scale its validator set using ECDSA threshold signatures or fusion algorithms, increasing the threshold of signatures required for collusion and thus enhancing the protocol’s overall security.
• Validators care about reputation and are economically disincentivized by slashing — deBridge’s architecture requires validators (or anyone as delegators) to stake collateral in order to ensure honest behavior. In case of unfair actions, this collateral can be used for slashing and compensating the affected users. Thus, it can be said that deBridge’s system inherently trusts that the potential benefit of collusion is lesser than the reputational and financial cost (funds locked in delegated staking and slashing contract) of collusion for the validators.
• Validators can censor messages — 5/12 of deBridge’s validators can collude to maliciously censor messages.
• It’s not a necessity for validators to stake their own collateral — deBridge’s validators can choose not to stake their own collateral and only use the delegated one as it’s not a requirement fixed in code for them to stake their own collateral to become a validator. This reduces the financial costs of collusion for the validators. However, in such cases, it’s unlikely that users will delegate to such a validator. Moreover, such a validator will be replaced by governance with one with its own collateral at stake.
• Permissioned validator set — To bootstrap the protocol, the deBridge team picked 12 validators based on their performance (stability of infrastructure, number of missed transactions, and speed of validation) in the v2.0 testnet launched in November 2021. Thus, in its current state, deBridge’s validator set is permissioned. However, after the launch of the governance token, the ability to decide who should be a validator will be passed to governance. Moreover, anyone will be able to apply to be a validator by making a governance proposal.
• The delegated staking and slashing modules are not live yet — deBridge’s security will significantly improve through delegated staking and slashing mechanisms, which will add a layer of economic security to the protocol. However, these features are not live yet; thus, in the current state, fewer preventative measures are in place to disincentivize deBridge’s validators from colluding.
• Progressive decentralization — deBridge protocol is taking an iterative path towards decentralization and will take a huge leap forward in decentralizing the network with the launch of its governance token. However, until then, the team has control over the governance process. Moreover, the delegated staking module will only be deployed when the governance token is live.

Community & Resources

You can learn more about deBridge and stay updated about its community through the following:

• Official Website
• Docs
• deBridge Security
• Getting started with deBridge
• deExplorer
• Github
• Medium
• Twitter
• Discord

Comparative Analysis: Which AMB to Build on?

After analyzing the designs and features of seven AMBs, it’s now time to summarize their design trade-offs, core features, strengths, and weaknesses in the form of a summarized table. The goal is to provide a snapshot view of the AMB ecosystem to make it easier for developers and users to quickly understand different AMB solutions and enable them to pick one to build on or use based on the trade-offs they’re comfortable with and the qualities they like.

In the comparative analysis, we will see how the AMBs stack up against each other based across five categories (with several metrics embedded in each):

1. Bridge Design — Theoretical Security

Each bridge has a different design and a unique way of validating cross-chain messages. As a result, each bridge makes unique trade-offs, sometimes at the cost of security. In this section, we analyze each AMB’s theoretical security by breaking it down into four key aspects:

• Consensus mechanism — How does an AMB determine the validity of messages?
• Validator set collusion — Minimum number of validators that can collude to steal funds.
• Censorship resistance — Minimum numbers of signers that can censor a message passing through the AMB.
• Permissionless-ness — Is the validator set permissionless? Can anyone become a validator and contribute to determining the validity of messages? If yes, how does the AMB achieve permissionless-ness?

2. Practical Security Measures

As we’ve seen with bridge hacks in the past, a single bug can lead to millions of dollars being stolen. Any code can have bugs, and since bridges are a prime target for hackers, it’s important for bridge builders to invest in continuous audits and open bounties. Such practical security measures can help avoid catastrophic hacks stemming from implementation oversights or bugs in the code.

• Audits — Number of audits each AMB has gone through (the more, the better).
• Open bounties with Immunefi — Maximum amount a whitehat hacker can receive as a reward for finding critical vulnerabilities in an AMB’s code for a bug bounty on Immunefi.

3. Protocol History

The crypto ecosystem is constantly evolving. Surviving and staying relevant can be hard since new narratives and niches emerge frequently. Protocol history showcases how long a project has been building in the space. We believe this is an important metric because reliability and trust compound with time — the amount of time a project has survived and managed to stay relevant is a testament to the product’s quality and the caliber of the team.

Moreover, this section also includes hacks, as they are a key event in any project’s history and roadmap. A hack can often derail plans, and thus, for any project that has been hacked, it’s important to investigate the cause and effect to analyze how the team has handled the event and if they have managed to bounce back.

• Time since launch — How many months has the AMB been live?
• Hacks — Has the AMB suffered any major hacks?

4. Connectivity and Usage

Connectivity looks at the number of blockchains supported by each AMB. This metric might seem straightforward but can often be the reason why a project chooses to build on a particular AMB. When projects think about going cross-chain, there are specific blockchains that they want to connect with. If an AMB does not support those blockchains, there’s no utility of the AMB for the project, no matter how solid the tech is. For example, if a project wants to expand to Solana, but an AMB doesn’t support it, the project is likely not to choose that particular AMB and go for one that supports Solana.

Usage highlights some of the dApps that are leveraging each AMB’s product stack to build cross-chain applications.

• Network connectivity — The more blockchains an AMB supports (or connects with), the more options it offers to the projects that are building on it.
• Examples of dApps building on an AMB — List of some projects that are using an AMB to offer cross-chain functionality.

5. Token Bridge’s Performance

Token bridges enable users to transfer assets from one chain to another. They are the flagship use-case for AMBs catering to retail users. Each AMB typically has a token bridge closely linked to it, and there are many overlaps between them — they are built by the same teams and, in most cases, are built on the AMB. Thus, the token bridge’s performance holds importance in measuring an AMB’s success, as, in many ways, it reflects the performance of an AMB.

In this section, we analyze each liquidity layer’s performance by breaking it down into four key metrics:

• Capital efficiency — How efficiently does a token bridge use the capital locked in its pools? This is calculated as the 30 days bridged volume divided by the total value locked (the higher, the better). However, it’s important to note that token bridges can be built using different mechanisms and for different purposes, which directly impacts how they perform regarding capital efficiency. For instance, the capital efficiency metric is more important for liquidity networks like Stargate and cBridge and less for lock and mint bridges like Axelar’s Satellite, Nomad Bridge, and Wormhole’s Portal.
• Total transaction count — How many transactions have been executed using the liquidity layer since launch?
• Total bridged volume — How much volume has passed through the liquidity layer since launch?
• Total Value Locked (TVL) at peak — The highest amount of funds locked in the liquidity layer’s pools in its history.

AMB Comparison Framework

Here’s how the AMBs stack up against each other:

Open the image in a new tab for better visibility or https://drive.google.com/drive/folders/1UyAzLzljQtbVAC8p2q0YcCovHThNDQpq?usp=sharing

Note: The colors are here to help the reader ~navigate~ the chart and quickly understand how AMBs perform relative to each other in terms of certain quantifiable metrics.

Token Bridge Performance

Here’s how the Token Bridges, closely connected with the AMBs, stack up against each other:

Closing Thoughts

Arbitrary messaging bridges are critical pieces of web3 infrastructure. It is absolutely paramount that users and developers can securely (and easily) engage with data across chains — else, the dream of buzzwords like interoperability, modularity, or composability is dead.

In its current state, as evidenced by the above document, the AMB space is still in a “nascent” phase, with lots of different design choices being tested in live action (and, hence, lot’s of hacks).

We wrote this document for users and developers in a way that we hope brings clarity on how AMBs work and what design trade-offs were made. However, we will refrain from “scoring” or “ranking” this group of AMBs for now as we believe that with all of the different flavors of AMBs, scoring them could lead to biased results. Moreover, LI.FI is bridge agnostic and doesn’t favor any specific bridge design and architecture over others.

With that, we encourage you to reach out to our team with any thoughts, feelings, or opinions about this document. The AMB space is always changing and innovating, and LI.FI’s goal is to continuously provide the most accurate and up-to-date information through this document.

Thank you for your time :)

-> Click here to read the full report.