Navigating Arbitrary Messaging Bridges: A Comparison Framework
Axelar vs. LayerZero vs. Nomad vs. Wormhole vs. Celer IM vs. anyCall vs. Hyperlane
Introduction
Based on our experience talking with developers, interacting with users, and pitching our product at LI.FI, it seems the term “cross-chain bridge” has become synonymous with “token bridge” — meaning a liquidity network or trusted third party facilitating the transfer of token X from chain A to chain B.
However, token transfers are just scratching the surface of what can be communicated between blockchains. Cross-chain bridges can do much more than pass token X from chain A to chain B. For example, bridges can be used to facilitate cross-chain governance, token launches, contract calls, gaming experiences, etc.
There is a whole ecosystem of platforms that we at LI.FI call “arbitrary messaging bridges” (AMBs) working to expand the scope of cross-chain communication. As the name suggests, these bridges allow for any piece of data, including tokens, the state of a chain, a contract call, an NFT, or governance votes, to be moved from chain A to chain B.
This article is written to take a deep dive into the arbitrary messaging bridge space. LI.FI’s goal is to present a comparison framework for analyzing different AMBs so that developers can quickly assess the pros and cons of building on a particular AMB. Furthermore, we want to give bridge and dApp users an overview of the security trade-offs made in the cross-chain space.
This article will explore the design, security, and trust assumptions of seven data messaging bridges: LayerZero, Wormhole, Nomad, Celer Inter-chain Message (IM), Multichain’s anyCall, Hyperlane (previously Abacus), and Axelar. From there, we will compare the seven bridges using the LI.FI evaluation matrix.
We will cover the following about each arbitrary messaging bridge:
Overview — This section will include:
A brief description of the AMB
Standout features of the bridge design and tech
Network effects which improve the overall value of the AMB and the user experience
2. How it works; transaction lifecycle — The process of sending messages from one blockchain to another, understanding the different components of the bridge design, and the role of key stakeholders involved in each transaction.
3. Security — Theoretical security guarantees of the bridge design and the security measures taken to ensure the implementation security of the AMB.
4. Trust assumptions — Design trade-offs made by each AMB and their potential consequences.
After analyzing each AMB based on the above framework, the reader will be able to develop a good understanding of a bridge’s design, strengths and weaknesses (security guarantees and trade-offs), and how it works. The framework will then be summarized with a comparative analysis using LI.FI’s evaluation matrix.
With that being said, let’s dive in!
Axelar
Overview
Axelar Network describes itself as a full-stack decentralized transport layer delivering secure cross-chain messages across Web3. It provides a uniform cross-chain messaging solution for both developers and users. Developers can use Axelar gateway contracts and connect to any EVM contract on any chain without having to make any changes to their chains or UIs.
Axelar’s main selling points revolve around its extensive developer kit and its connection with Cosmos-based chains like Osmosis and Juno. Moreover, Axelar is a Cosmos-based chain itself and uses its own blockchain for validation. This feature is key in Axelar’s design and is the reason for many of its strengths and some trade-offs.
Some of Axelar’s best features include:
“Plug-and-play” integration with simple SDKs and APIs — Axelar takes a universal approach to building and enabling developers to go cross-chain. It offers universal composability of programs with any-to-any cross-chain capability, allowing dApps to tap into different blockchain ecosystems frictionlessly. Moreover, it offers comprehensive documentation and tools like Axelarscan, which make building on Axelar a good experience.
Axelar as the translation layer — Axelar is consensus agnostic, allowing it to connect with all chains. It is interoperable with EVM chains, Bitcoin, and Cosmos-based chains. The consensus agnostic characteristic of Axelar gives the team the flexibility to add any new chains seamlessly. At the network layer, this enables any new connection to the Axelar Network to benefit from all the previously interconnected ecosystems. Thus, Axelar acts as the translation layer that unifies unique languages of different types of blockchains.
Reduced costs for users — Users only pay fees in the asset being transferred on the source chain, and all the other fees (finalization, relay) are taken care of in the backend. The Axelar Foundation also subsidized transfer costs in case of gas price fluctuations in the destination chain. Moreover, Axelar uses batched transactions to further reduce costs and plans to add more code-level gas optimizations in the future.
Single validator signatures — Axelar Network requires only a single signature to authorize transactions. This signature represents the collective decision of the majority of validators and enables Axelar to scale as it keeps the transactions small, reduces costs, and makes it easier for Axelar to connect and interconnect other chains.
Scalability through IBC — Multiple application or chain-specific forks of Axelar can be spun up. This enables Axelar to scale to an arbitrary number of applications or networks. In the future, all these forks can be secured through Cosmos’ Interchain Security.
Additionally, the Axelar Network enjoys the following network effects:
Connection with the Cosmos community — The project has deep roots in the Cosmos ecosystem and has seen active involvement from the community in terms of development and governance. It connects to several Cosmos-based and non-EVM chains like Terra Classic, Osmosis, Secret Network, and Junø, among others, and facilitates significant amounts of bridged volumes to these ecosystems.
Strong presence on EVM Chains — Axelar has also established itself on EVM chains such as Polygon, Avalanche, Fantom, Near, and Polkadot (Moonbeam), supporting significant cross-chain transactions to and from them. For instance, Axelar’s axlUSDC/USDC pool on Polygon is consistently among the top 3 pools by daily volume on Curve. Moreover, Axelar has strong partnerships with major dApps on NEAR protocol’s Aurora.
Network Connectivity — As of September 2022, Axelar supports 23 chains: Ethereum, BNB Chain, Avalanche, Polygon, Fantom, Moonbeam, Aurora, Cosmos, Osmosis, e-Money, Juno, Crescent, Injective, Terra, Secret, Kujira, AssetMantle, Evmos, Fetch.ai, KI, Regen, Stargaze, and, of course, Axelar.
Partnerships and integrations — A wide range of applications and blockchain ecosystems leverage Axelar’s tech to offer cross-chain features. For example, dApps like Prime Protocol, Astroport, Cosmos app chains like Osmosis Kujira, Avalanche subnets like Heroes of NFT, Pocketworlds, and NFT projects such as MintDAO, Omnisea, among others.
Experienced team — Axelar has an established core team with expertise in cryptography, consensus, and distributed systems. Sergey Gorbunov and Georgios Vlachos, the co-founders of Axelar, are also founding team members of Algorand and have years of experience in building blockchain infrastructure.
Funding — It has raised over $65 million in funding, most recently raising $35M at a $1B valuation in its Series B round.
How It Works — Transaction Lifecycle
The Axelar Network has two functional layers:
The Core Infrastructure Layer — This layer consists of Axelar Network itself, which is maintained by a set of validators executing transactions. Additionally, this layer also consists of gateways that act as smart contracts to connect the Axelar Network with the other blockchains. Validators maintain the operations of the gateway protocol. They read incoming transactions from the source chain gateways, reach a consensus, and then write to the gateway on the destination chains to execute a transaction. Once this process is complete, the funds are locked on the source chain, and an equal amount of canonical assets are minted on the destination chain.
The Application Development Layer — This layer consists of SDKs/APIs, which make the core infrastructure layer of Axelar available for developers to go cross-chain. The APIs enable developers to send generalized messages across chains which opens up a world of possibilities in terms of cross-chain actions. For instance, developers can lock/unlock and transfer crypto assets across chains or execute cross-application triggers.
Here’s how Axelar works at a high level:
Step 1 — A user requesting a cross-chain transfer of information waits for either the token deposit or action to be confirmed by Axelar Validators on chain A.
Step 2 — Axelar Validators observe their chain A nodes and cast votes on whether the transaction occurred on chain A.
Step 3 — If the number of Axelar Validators surpasses the set threshold, the chain A transaction s confirmed by the Axelar Network.
Step 4 — The votes by Axelar Validators also act as signatures for the Gateway smart contract on Axlear, which uses multi-party cryptography to secure the issuance of tokens/data across chains. Once enough Validators confirm a transaction on chain A, the requisite data on chain B is relayed to the deposit address.
Security
Axelar offers the following security features:
Leverages IBC’s security — Axelar leverages IBC, the gold standard for cross-chain security, to communicate with other IBC-compatible chains.
Isolated module functionalities — Axelar reduces the risks of different network connections from spilling over by isolating functionalities in modules at the Cosmos SDK level. This allows Axelar to isolate chains from each other. For example, there are separate modules for EVM chains and IBC-enabled chains.
Ability to freeze transfers — Axelar can use a special command to freeze transfers from one or all chains in cases when a particular chain is under attack, or there is an ecosystem-wide black swan event. This allows Axelar to pause all the incoming and outgoing processing requests related to a specific chain.
Reduced extent of stolen funds through rate-limit functionality — To minimize attacks, Axelar’s ERC-20 contracts have a rate-limit functionality that reduces the amount of funds that can be stolen at the time of an attack.
Security through AXL token economics — Axelar aims to use the AXL token to enhance the security and decentralization of the system. The AXL tokenomics have been designed to incentivize honest activity among the validator set by giving them healthy staking rewards. Moreover, the team seeks to decentralize the validator set and increase the active members in community governance through the wide distribution of the AXL token.
Unbounded number of validators — Axelar uses Threshold Signature Schemes (TSS), and as a result, it can support as many validators as required.
Once Cosmos’ Interchain Security launches, the security offered by Axelar will increase manifolds. Axelar would then be able to leverage the economic security offered by the Cosmos Hub’s validator set.
Trust Assumptions
Axelar makes the following trust assumptions:
External verification by a set of validators — Axelar uses a validator set with 51 validators (48 active right now) to execute transactions. A message must be signed by ⅔ of the validators to be passed. As a result, the security of an application using Axelar is dependent on Axelar’s consensus. However, Axelar does offer application-based security as it allows applications to customize its codebase as per their requirements. For instance, applications’ governance can elect their own permissioned set of validators and relayers, which can then be used for validating transactions by spinning up a fork of Axelar.
Skewed voting power — Out of Axelar’s 51 validators, only 20 hold meaningful voting power (> 1%). This reduces the actual security of the system as Axelar has a weighted Threshold Signature Scheme (TSS) which would mean the other 27 validators with very low voting power will not be able to influence decisions. However, once the AXL token is live, the voting power is expected to be distributed more evenly. Moreover, Axelar plans to implement quadratic voting to validate and process cross-chain transactions. Quadratic voting will make Axelar’s network more decentralized and significantly improve the skewed voting power concern.
Progressive decentralization — Axelar currently uses governed multisigs for deploying system upgrades. While governed multisigs are a bottleneck for decentralization, it allows Axelar to offer features such as the rate limit functionality. As Axelar makes progress on its roadmap, it aims to eliminate or decentralize the governance multisigs by giving power to the community.
Lesser validators for certain chains — For a new chain to be added, Axelar requires 80% of the validators (or validator supermajority) to run a node for the chain. However, on the flip side, this means that Axelar does not require its validators to run nodes for all the chains it supports. As a result, it is possible for some chains supported by Axelar to have a lower number of validators securing transactions.
Community & Resources
You can learn more about Axelar and stay updated about its community through the following:
LayerZero
Overview
LayerZero is a generalized data messaging protocol that describes itself as an “omni-chain” solution. It is designed to carry lightweight messages across a bevy of chains via gas-efficient, non-upgradeable smart contracts.
LayerZero’s main selling point is a lack of extra trust assumptions when validating cross-chain transactions. Some of LayerZero’s best features include:
Simplicity — The goal for LayerZero is to put developers first. User applications building with LayerZero simply need to implement two functions — send and receive. If it can be written in Solidity, Rust, etc., then an application can be built on-chain right now. Furthermore, as there is no middleman in the system, two high-throughput chains can interact without constraint.
Lightweight Clients — running smart contracts on Layer 1 can be extremely expensive. Therefore, LayerZero exports storage and fetching of transaction data to Oracles and Relayers, the two off-chain entities whose relationship ensures valid transactions, allowing the Ultra Light Node endpoints to be small and cost-effective. Furthermore, its lightweight clients’ low operating costs allow for the quick incorporation of new chains.
Potential — LayerZero, as its name suggests, is a ground-level piece of infrastructure that can be utilized by liquidity networks, multi-chain yield aggregators, multi-chain lending protocols, and many other dApps to build out super interesting and uniquely multi-chain crypto use-cases.
LayerZero Scan — Cross-chain transactions are now tied together in a single database via LayerZero Scan, which allows users and developers to easily pull state, status, and timing of transactions.
Additionally, LayerZero is already receiving major attention and enjoys the following network effects:
Funding — The LayerZero team came out of stealth recently with a funding round led by crypto giants Multicoin Capital and Binance Labs and has since received more funding from A16z, Sequoia, and FTX as tri-leads in a $135M round, raising at a $1B valuation. LayerZero is also backed by Coinbase, Gemini, PayPal, Uniswap, among others.
Apps building on it — Major dApps like Stargate have already built cross-chain applications on top of LayerZero. Other examples include Radiant, which is building a multi-chain lending protocol, and SushiSwap, which recently launched a cross-chain AMM. You can find the growing list of LayerZero-based dApps here.
Network connectivity — As of September 2022, LayerZero supports 11 chains: Ethereum, BNB Chain, Avalanche, Polygon, Arbitrum, Optimism, Fantom, Swimmer, DFK, Harmony, and Moonbeam.
How It Works — Transaction Lifecycle
The most basic component of LayerZero are the “Endpoints” found on supported chains. These endpoints are implemented as a series of smart contracts that allow domains to communicate with each other, with each chain having its own “Library” in the LayerZero system. Each Endpoint comes with a messaging library native to the domain the Endpoint sits on, along with a proxy, which makes sure the Endpoint uses the correct library version. Once deployed, the Endpoints are like smart contracts that cannot be shut down, allowing for an immutable flow of messages.
From there, LayerZero relies upon two off-chain entities, an Oracle and a Relayer, to pass messages between the endpoints found on different domains. In this setup, an oracle (like Chainlink) forwards a block header from domain A to domain B, while a separate relayer passes a transaction proof from domain A to domain B. If the two match and the proof is validated by the block header, then the cross-chain message is sent to the destination address.
To summarize the relationship between relayers and oracles:
The job of a LayerZero oracle is to simply relay generic data (aka block headers) from the source domain to the destination domain. It is a third-party service expected to be run via ChainLink.
The job of a relayer, which is also a third-party entity, is to fetch the proof of a specified transaction. Notably, under the parameters laid out by LayerZero, anyone can be a relayer, which helps make sure it is a decentralized system.
The only condition for Oracles and Relayers that matters is that they are run independently and do not collude. If they do not collude, LayerZero is secure. If somehow, Oracles and Relayers end up colluding, LayerZero’s security structure is majorly compromised.
A LayerZero transaction/message only requires source gasIn a single call. A transaction begins with a User Application (UA) starting a transaction (aka doing something on-chain). This transaction is then broken up into multiple parts (proof and block header) via the Oracle and Relayer in a flow that is facilitated by a LayerZero Endpoint. Once the Oracle and Relayer send their respective information from the source chain and the LayerZero Endpoint validates that the information is correct, the message is translated and executed on the destination chain.
A general transaction on LayerZero would go as follows:
Let’s break that down step by step:
Step 1 — A User Application (like Stargate) uses LayerZero’s reference Relayer and executes a series of actions as part of a transaction. The User Application sends a request to LayerZero’s Communicator with information about the transaction, such as a transaction identifier, data to be transferred from A to B (payload), identifier pointing to the User Application's smart contract on Chain B (dst), etc.
Step 2 — The Communicator sends this data in the form of a LayerZero Packet to the Validator.
Step 3 — The Validator sends the transaction identifier and the identifier for the smart contract on Chain B to the Network. As a result, the Network gets notified that the block header from Chain A needs to be sent to Chain B.
TL;DR of Steps 1–3 — A User Application packages and transmits the data on Chain A to LayerZero’s endpoint on Chain A.
Step 4 — The Validator forwards this information to the Relayer. As a result, the Relayer is notified to prefetch the transaction proof and send it to Chain B.
Step 5 — The Network sends the identifier for the smart contract on Chain B along with the block ID of the transaction to the Oracle. As a result, the Oracle is notified to fetch the block header for the current block on Chain A and send it to Chain B.
TL;DR of Steps 4–5 — LayerZero’s Endpoints on Chain A send the transaction’s information to LayerZero’s reference Relayer, whereas the block ID of the transaction is sent to the Oracle.
Step 6 — The Oracle then obtains the block header from Chain A.
Step 7 — The Relayer receives the transaction proof from Chain A and stores it off-chain.
Summary of Steps 6–7 — The Relayer and the Oracle receive the transaction proof and block header, respectively, from Chain A.
Step 8 — The Oracle waits for a certain number of block confirmations before confirming that the block has been successfully committed on Chain A. Post confirmation, the Oracle sends the block header to the Network on Chain B.
Step 9 — The Network sends the block hash to the Validator.
Step 10 — The Validator forwards the block hash to the Relayer.
Step 11 — The Relayer sends a list of any data structures that match the current block.
Step 12 — The Validator ensures that the transaction is valid and committed by going through the transaction proof and the block headers stored by the Network. If the block header and transaction proof match, the transaction information is sent to the communicator in the form of a Packet.
Step 13 — The Communicator emits the information (Packet) to the User Application on Chain B.
Summary of Steps 9–13 — LayerZero’s Endpoint on Chain B obtains the information initiated by the User Application on Chain A using the block header and emits it to the User Application on Chain B.
This way, the User Application uses LayerZero to send transaction information (like tokens) from Chain A to Chain B.
Security
LayerZero Offers the following security features:
Valid delivery— The Independence of the Oracle and Relayer is the basis for LayerZero’s security. If a block header and transaction proof provided by two independent entities match, then the delivery of a transaction is valid. If they do not match, then it is not valid. This is a highly secure mechanism, as the statistical probability of a transaction proof and blockhead matching without knowledge of the other beforehand is low.
High cost of attack — In the worst-case scenario, an Oracle and Relayer could be run by the same entity and collude maliciously — meaning that a block header and a transaction proof provided by an Oracle and Relayer are invalid, yet still match due to collusion overriding the system. However, this is a siloed risk even if Oracle 1 and Relayer A collude maliciously, as only the applications using Oracle 1 as the oracle and Relayer A for information will be affected. All the other oracles and relayers continue to operate as usual. Therefore, the cost of the attack becomes very high for little reward as you can only attack a specific pool of funds and not the entire funds in the system. This is a small risk, however, because if a User Application has a specific risk profile and doesn’t trust either the Oracle or Relayer of a particular configuration they can opt to run one part of this themselves to eliminate any possibility of collusion.
Simple and effective design — As LayerZero does not add any extra bells and whistles to its bridging mechanism via a token, lock and mint mechanisms, etc., the security of LayerZero can be traced down to the chains wherein its Endpoints reside.
Risk sharding — LayerZero allows user applications to choose different Oracle/Relayer combinations to spread out the risk of someone attempting to make two independent entities collude via bribing or malicious attack.
Risk shielding — Users can run their own relayers — meaning that for a user to trustlessly depend on LayerZero, then all they need to do is run their own relayer and trust that the Oracle is independent of themselves.
Pre-Crime— This feature allows a relayer to stop a hack before it happens. Relayers can fork a destination blockchain before the delivery of a message and run a transaction locally, allowing the relayer to verify that no malicious action (defined by each User Application) occurred. This acts as an additional layer of security on top of audits and bug bounties for dApps.
Trust Assumptions
LayerZero makes the following trust assumptions:
Progressive decentralization — The number of relayers on the network will grow, progressively decentralizing the messaging system’s most important security mechanism.
Dependence on Relayer and Oracle — LayerZero users are dependent on the security of the Relayer and the Oracle to pass messages across chains. There is not really anything on-chain related to the ownership of the funds and data themselves.
Operational risks — LayerZero relies on third parties (oracles and relayers) for its functioning, which adds operational risks beyond LayerZero’s control.
Reliance on chains’ security— LayerZero does not add an intermediary to cross-chain transactions, however, it does rely on the native chain of an Endpoint to function correctly. If a chain was to be 51% attacked, it is unclear how LayerZero would be able to handle such an event.
Community & Resources
You can learn more about LayerZero and stay updated about its community through the following:
Nomad
Overview
Nomad is an interoperability protocol enabling users and dApps to send arbitrary messages across chains. It is an extended implementation of the Optics Protocol (OPTimistic Interchain Communication), and the team includes many of the same core team members.
On Aug 2, the Nomad bridge was hacked for $190M because of an implementation error during a routine upgrade. The team has managed to recover over $37M (20% of the stolen funds) through the tremendous work of whitehat hackers. It’s important to note that the hack does not reflect Nomad’s design as it was an implementation-level issue. You can learn more about the hack here. This write-up focuses on the verification mechanism underlying Nomad, how it works, its security, and design trade-offs.
Nomad introduces a new flavor to the cross-chain industry: optimistically verified bridges that trade latency (or speed) in the design space for security. This is a new tradeoff that could arguably make the interoperability trilemma a quadrilemma.
Inspired by optimistic systems, such as optimistic rollups, Nomad boasts similar features to such mechanisms. Some of Nomad’s best features include:
Minimal trust assumptions — Nomad has a challenge period where watchers observing the system can flag fraud. This design requires Nomad to only have a single honest verifier assumption (1 of n watchers to correctly verify updates) to ensure security.
Minimum costs for users — The user only has to pay network gas fees while Nomad takes care of the rest and subsidizes the relaying and processing cost (for all chains except Ethereum) while taking no platform fees.
Simple user experience — Nomad offers a simple and cost-minimized user experience with additional features for users’ convenience, like the ability to transfer assets across chains to different addresses.
Additionally, even in its early days, Nomad has developed tremendous network effects:
Partnership with Connext — Nomad and Connext have a close partnership, and together they form a modular interoperability stack, as seen in Connext’s Amarok upgrade.
Network connectivity — As of September 2022, Nomad supports six chains: Ethereum, Moonbeam, Evmos, Milkomeda, Gnosis Chain, and Avalanche.
Experienced team — Nomad has an established core team with a great reputation and relationships with other industry leaders.
Funding — Nomad raised $22 million in the seed round led by Polychain Capital. It is backed by high-profile institutions and angel investors.
How It Works — Transaction Lifecycle
Here’s how Nomad works at a high level:
Step 1 — Users or dApps post data to the home contract on the source chain, where all the message/data is added and committed to a Merkle tree (message tree).
Step 2 — An off-chain agent called an Updater notarizes or signs the root of the Merkle tree with the data.
In the future, the Updaters will have to submit a bonding stake on the source chain, which will get slashed in the event of fraud.
Step 3 –This root is read and forwarded by the Relayer to the destination chain in an “update”, posted to the replica contract.
Step 4 — Once posted, a 30-minute fraud-proof window opens up, during which a Watcher can prove fraud and stop the data from going through.
Step 5 — If no fraud proofs are submitted within the 30-minute window, a Processor
submits the Merkle proof of the data in the replica contract on the destination chain.
Security
Nomad offers the following security features:
Challenge window — Nomad introduces a 30-minute challenge window to ensure watchers in the system can confirm fraud proofs on-chain and prevent fraudulent updates by the Updater. However, this comes at the cost of latency. It’s important to note that this challenge window can be different for different channels, i.e., 30-minutes is a conservative window, and certain channels (like Polygon <> Avalanche) can have a shorter window.
Allows the addition of independent watchers — Nomad enables xApps (cross-chain applications) to run additional watchers (however, at the moment watchers are being run by the Nomad team). This allows communities to have their own delegated watchers supervise a particular route. For example, if an xApp builds on Nomad, its community can choose and enroll its own delegated watcher, responsible for preventing attacks.
Crypto-economic security — The cost for an attacker to exploit the Nomad system is unknown. This is because even if one honest watcher can submit fraud proofs, the attack will fail. As a result, no amount of funds can guarantee an attacker that the attack will succeed.
Censorship resistance through penalties — Updaters (or validators) are penalized for censoring messages, which is treated as fraud and will result in their bonded stake getting slashed.
Trust Assumptions
Nomad makes the following trust assumptions:
Contracts governed by multi-sigs — Currently, Nomad’s smart contracts are governed by multi-sigs. Either ⅗ or ⅔ signatures are needed to upgrade the contracts.
Updater is the only validator — Nomad’s system relies on the updater to maintain uptime.
To disincentivize downtime, Nomad intends to leverage slashing and rotation for Updaters.
Centralized updater — Given the updater is the only “validator”, an updater for a given channel can cause liveness failures by not signing the updates. Nomad uses slashing to disincentivize this and plans to decentralize the updater in the future.
Permissioned Watcher set — Nomad has a permissioned Watcher set — meaning that currently, there could be a known cost to attack the system since the watchers are fixed and can be corrupted. However, xApps can overcome this by running their own delegated watchers.
Permissioned watchers can censor messages — Watchers are a critical part of Nomad’s design, and their role allows any single Watcher to raise a challenge against transactions by submitting fraud proofs. These Watchers can censor messages and prevent xApps from receiving them. However, xApps can remove such watchers from their allow list and prevent censorship.
Liveness tradeoff — Nomad trades off liveness for security. This can lead to application level halts, i.e., the application will stop receiving messages if an Updater faces downtime. However, trading-off liveness means that as long as the underlying chain is secure, the theoretical worst-case scenario for Nomad is a system halt and not a loss of funds.
Progressive decentralization — Currently, Nomad runs in a permissioned environment as many of the important roles in its architecture are dependent on the Nomad core team. However, the team has plans to decentralize the system over time (after making go-to-market progress) and enable Nomad to operate in a non-custodial, trust-minimized, permissionless, and decentralized manner.
Community & Resources
You can learn more about Nomad and stay updated about its community through the following:
Wormhole
Overview
Despite being best known for its token and NFT bridging solution, Wormhole is actually an arbitrary message-passing protocol allowing for cross-chain exchanges of data between fourteen chains and counting. In particular, it’s widely known for connecting Ethereum to the Solana and Terra ecosystems.
The simple message passing mechanism allows for a plethora of cross-chain use cases enabled by dApps transferring assets and source chain data between networks to provide services on a destination chain. Wormhole’s design is founded on the idea that a decentralized set of “Guardians” (aka nodes/validators) can be trusted to verify cross-chain transactions being emitted from Core Bridge contracts deployed on all connected networks.
Some of Wormhole’s best features include:
Non-EVM compatibility— Wormhole is one of the few messaging solutions that connects non-EVM compatible chains like Solana, Acala, Terra Classic, and Terra 2.0 to EVM-compatible chains like Ethereum and Polygon. Wormhole supports messaging across 14 blockchains, including Ethereum, Solana, Terra, Binance Smart Chain, Polygon, Avalanche, and Fantom, along with Oasis, etc.
Top tier validators— Wormhole is a proof-of-authority network secured by 19 “Guardians” that ensures cross-chain messages are safely transmitted. Among the “Guardians” are major companies like FTX, Certus One, Everstake, Staked, and Chorus One.
Seamless user experience — Wormhole charges exceedingly small fees (100 lamport, or less than a cent) when transacting from Solana. Furthermore, users simply need to create a transaction on the source chain and redeem it on the destination chain to execute a cross-chain transfer.
Additionally, the Wormhole team has the following network effects:
High TVL — Wormhole's Portal token bridge has amassed nearly $500M in total value-locked into the bridge, making it one of the biggest bridging mechanisms in crypto. At its peak, TVL was over $4.6B but has reduced drastically since the UST depeg.
Go-to assets on Solana — Wormhole’s assets are the most widely used wrapped assets within the Solana ecosystem and have the most liquidity. For example, Wormhole ETH on Solana is simply listed as ETH on every dApp.
Network connectivity — As of September 2022, Wormhole supports 14 chains: Solana, Ethereum, Terra Classic, BNB Chain, Polygon, Avalanche, Oasis, Aurora, Fantom, Karura, Acala, Klaytn, Celo, and Terra.
Backed by Jump Crypto — Wormhole is one of the few bridges to have recovered from a major hack, such as the $326 million exploit in 2022. Furthermore, Wormhole’s backers, such as Jump Crypto, are some of the most ambitious and well-funded in the crypto space.
How It Works — Transaction Lifecycle
Wormhole’s design is simple. It is a proof-of-authority network governed by 19 validators. Each blockchain supported by Wormhole is home to a “Core Bridge” contract. The core contracts emit messages to Guardians who verify and sign (aka approve) the message. This verified message is then relayed to the destination chain, where the message is processed and the cross-chain transaction finalized.
It is the guardian’s sole role to monitor the state of each supported Wormhole blockchain. Each Guardian observes and signs messages in isolation, with the resulting collection of signatures representing proof that a certain message is agreed upon by the Wormhole network. A message is only authentic if 2/3rds+ of Guardians have signed it.
To summarize, this is how the Wormhole messaging system works:
The Wormhole Crypto Network Explained
Security
Wormhole offers the following security features:
Doxxed guardians— The proof-of-authority network design incentivizes Wormhole guardians to act in good faith, as any collusion or malicious attacks would be able to be traced back to only a group of 19 entities. In Wormhole’s case, the fact that companies like Jump Crypto and FTX are running Guardians is a social form of security, as these are multi-billion dollar firms that do not want to mar their reputation by signing transactions erroneously.
Liveness assumptions— Since the Guardian system is run by some of the biggest validators in the crypto space, liveness can almost be guaranteed and could even be better than the chains they validate for.
Additional security with the Governor feature — The Governor limits the amount of assets that can be transferred out of a particular chain within a given time period. This provides a passive security check against external risks such as smart contract bugs or runtime vulnerabilities. It is a security measure that reduces the potential and extent of user harm.
Audits and bounty system— Wormhole has been audited by Neodyme and Kudelski (x2). It has audits by OtterSec, Certik, Halborn, Trail of Bits, and Coinspect scheduled for Q3 2022. Moreover, it has the largest bounty in the crypto space via a $10 million offer on Immunefi.
Easy process for white-hat hackers to contribute — Wormhole has developed several strategies to make it easier for white-hat hackers to find security bugs in Wormhole, disclose them, and help secure the network. For instance, whitehats can review Wormhole’s existing unit and integration test and disclose vulnerabilities.
Trust Assumptions
Wormhole makes the following trust assumptions:
Externally verified by Guardians — Wormhole’s proof-of-authority system inherently trusts that Guardians can be trusted to verify transactions and that over 1/3rd of Guardians will not collude at a certain time.
Guardians care about reputation — Wormhole relies on the fact that the potential benefit of collusion is lesser than the reputational cost of collusion for its Guardians. However, this could become a major issue if the benefits for ⅓ of the guardians outweigh the reputational cost of collusion.
Validators don’t have a bond — Guardians’ stake is not bonded, i.e., their stake won’t be slashed, or they won’t be penalized if they act maliciously. Thus, user funds are not protected by any bonding or slashing mechanism.
Institutional backing — Wormhole has created deep partnerships with Jump Crypto, FTX, and the Solana ecosystem, and its growth (and recovery in the face of future exploits) is dependent on those relationships continuing to lead to network effects.
Smart Contract — Just like any smart contract-based system, there are inherent risks and vulnerabilities, especially in the context of the “Core Bridge” contract that allows chains to communicate with the Guardian network.
Community & Resources
You can learn more about Wormhole and stay updated about its community through the following:
Celer IM
Overview
Celer Inter-chain Message (Celer IM) is designed as a “plug and play” cross-chain composability solution for building cross-chain dApps to promote efficient liquidity utilization, coherent application logic, and shared state across tens of chains. Essentially, Celer IM offers devs an easy way to immediately take a dApp cross-chain.
The Celer IM architecture is powered by a combination of on-chain smart contracts that receive and send messages and the Celer State Guardian Network, a proof-of-stake blockchain built on Tendermint specializing in authenticating cross-chain messages. cBridge, a fungible token and NFT bridging application, is built with this architecture as a “built-in” cross-chain dApp. With the combination, Celer IM enables a robust set of use cases for dApps like cross-chain DEXes, yield aggregators, lending protocols, multi-chain NFTs, and more.
Some of Celer IM’s best features include:
Plug and Play — New and existing dApps can integrate Celer IM through a simple plug-in contract that often requires no code modifications to deployed code.
Support for all types of chains — Celer IM enables the transfer of arbitrary data like contract calls, messages, tokens, NFTs, and data between L1s, sidechains, and L2s.
Improved UX — Celer IM allows multiple functions like bridge and swap to be performed within a single user experience. As a result, the users have to go through fewer clicks, significantly improving a dApp’s UX.
Transaction Flexibility — dApps can send a message and fungible tokens in one transaction. However, if the need arises, dApps utilizing Celer IM can also just pass a message across chains.
Security of Celer– Cross-chain dApps built on top of Celer can choose two different security models with different tradeoffs on delay. By default, inter-chain dApps rely on the security of the State Guardian Network (Cosmos PoS-based chain) by processing messages routed from another chain without delay. Developers can also choose to use an optimistic rollup-like security model with additional cross-chain communication delay.
Potential Bridge Expansion — While Celer IM was initially built using cBridge as its go-to asset bridge for passing fungible tokens across chains, the protocol has plans to add other asset bridges to its repertoire.
Additionally, Celer IM has developed tremendous network effects:
High volume and TVL — cBridge has processed $10.4 billion in cross-chain transactions and has $173.19 million in total value locked into its protocol, which supports 25 bridges.
CELR token — CELR is a top 300 token with a market capitalization of roughly $100 million.
Network connectivity — As of September 2022, Celer IM supports arbitrary message passing and cross-chain contract calls across nine chains: Ethereum, BNB Chain, Polygon, Fantom, Avalanche, Arbitrum, Moonriver, Optimism, and Aurora.
Partnerships and integrations — Celer IM launched with nine partners, including SynFutures, Ooki, and Rubic.
How It Works — Transaction Lifecycle
As mentioned above, Celer IM utilizes the SGN’s ability to validate cross-chain messages emitted from one chain and pass them on to another chain. The entire process takes roughly eight steps and is bookended by a user initiating an action on the source chain and receiving a token or message on the destination chain. Composing with Celer cBridge, Celer IM’s architecture enables both token and arbitrary data to be passed together (or separately) in one transaction, unlocking tons of potential for developers to build on top of.
This is what it looks like at a high level:
Let’s break this down. First, for clarification purposes, the blue lines above show how token transfers flow through the Celer IM architecture. The green lines show arbitrary data flowing through Celer IM.
The transaction flow can be grouped into the following actions:
Step 1 — A user interacts with a dApp utilizing the Celer IM plug-in and performs an action such as attempting to swap token A on Chain X for token B on Chain Y.
Step 2 — The Celer IM plug-in contract splits the user request into two parts: token information sent to cBridge and message information sent to the “MessageBus.”
Step 3 — From there, the MessageBus and cBridge relay information to the SGN, which validates the transaction via a signature after both the message and token transfer are confirmed to have occurred on the destination chain.
Step 4 — The executor, an open node on the destination chain, accepts the request from the SGN and executes the final logic on the destination chain.
Step 5 — After this, the submitted information (both token and message) is called to the destination application, and, for example, the user receives token B on Chain Y.
Notably, Celer IM can also facilitate the transfer of data without moving a fungible token. The flow looks like this:
Security
Celer IM offers the following security features:
SGN — The State Guardian Network routes messages and cross-chain fund transfers for Celer IM. The network is a proof-of-stake network built on Tendermint secured via CELR staking. With SGN, the network is secured via staking and slashing mechanisms similar to those seen on Cosmos, Ethereum 2.0, and Polygon. As of September 2022, SGN has 21 validators staking roughly $42 million worth of CELR to the network, with entities such as Binance and Everstake running validators.
Optimistic Fallback— Celer offers dApps a second security model that should work securely even under the worst-case scenario (two-thirds of the validators behave maliciously). Instead of instantly confirming messages routed through the SGN, a message must be committed into a “quarantine” zone for a limited time before the message can be confirmed for the destination application. During this delay, dApps can implement (or commission an SGN node as) a guardian service to double-authenticate messages.
Audits and bounty system— PeckShield and SlowMist have audited Celer IM. Furthermore, cBridge has one of the more extensive bounty programs in the space via a $2 million offer on Immunefi.
Trust Assumptions
Celer makes the following trust assumptions:
External Verification under PoS model — Celer IM uses a validator set with 21 validators to execute transactions. A message must be signed by ⅔ of staked value. Based on current staking numbers, it would only take ⅓ (7 entities) to maliciously conspire to leave the chain exposed to harmful activity. Celer IM assumes that the slashing mechanics of CELR and the reputational pressure that comes with validating a public blockchain will lead to validators acting honestly.
Trust-any under the optimistic rollup model — When operating under the optimistic fallback model, the security assumption is that as long as there is still one application guardian that stays honest and functional, malicious cross-chain messages will not be processed.
Structural integrity of cBridge and SGN — Celer IM is built on the assumption that both the SGN and cBridge consistently stay live, do not get exploited, and, most importantly, work as expected.
CELR stakers and value — Celer IM leans heavily upon CELR through staking. Furthermore, users of Celer IM have to pay fees in CELR to the SGN for its services in reaching cross-chain consensus. If the CELR token drastically fell in price, the security of the SGN would most likely also fall.
Celer IM Plug-in — One of the main conveniences of Celer IM is its “plug and play” nature. However, as with all smart contract native entities, if the Celer IM smart contracts that dApps use to pass messages across chains fail, the consequences could be dire.
Community & Resources
You can learn more about Celer IM and stay updated about its community through the following:
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:
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 Axelar and stay updated about its community through the following:
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):
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 liquidity layer 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).
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.
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 Comparison
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 :)
FAQ: Navigating Arbitrary Messaging Bridges: A Comparison Framework
Get Started With LI.FI Today
Enjoyed reading our research? To learn more about us:
- Head to our link portal at link3.to
- Read our SDK ‘quick start’ at docs.li.fi
- Subscribe to our newsletter on Substack
- Follow our Telegram Newsletter
- Follow us on X & LinkedIn
Disclaimer: This article is only meant for informational purposes. The projects mentioned in the article are our partners, but we encourage you to do your due diligence before using or buying tokens of any protocol mentioned. This is not financial advice.
