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:

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

1. 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.
2. 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 — Using multi-party cryptography, the Axelar validator set signs off on a list of commands confirmed by the votes. If the signatures cross the set threshold by the quadratic voting power of validators, a signed batch of commands is prepared.
• Step 5 — The signed batch of commands is relayed to the Gateway on chain B by Axelar microservices (or anyone else; the service is permissionless), which secures the transportation of tokens/data across chains.

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 relies on decentralized proof-of-stake consensus. As a result, it can support as many validators as required. In the current set, there is a maximum of 50 validators. This value can be increased via on-chain governance.
• Audits and bug bounties — Axelar has had a significant number of audits, particularly recurring audits that review any changes to the protocol. Axelar also offers a $2.25M bug bounty on Immunefi.

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 50 validators (48 active at the time of writing) to execute transactions. A message must be signed by ⅔ of the validators to be passed by their quadratic voting power. As a result, the security of an application using Axelar is more secure than Axelar’s consensus. Additionally, Axelar offers application-based security as it allows applications to customize their 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 48 active validators, about 10 hold less than 1% of the voting power. If the voting power were to become more concentrated, this could reduce the actual security of a proof-of-stake system such as Axelar, by skewing voting power in favor of an elite group of validators. However, once the AXL token is live, the voting power is expected to be distributed more evenly. Moreover, Axelar has implemented quadratic voting to validate and process cross-chain transactions. Quadratic voting makes Axelar’s network more decentralized and significantly improves the skewed voting power concern. Read more here about quadratic voting and Axelar’s security approach, and view validators’ share of stake and their quadratic voting power on the Axelar block explorer, axelarscan.io.
• Progressive decentralization — Upgrades on the Axelar network are already enforced by an on-chain decentralized governance mechanism. However, smart contract upgrades use a governed multisig. While governed multisigs are a bottleneck for decentralization, this allows Axelar to offer features such as the rate limit functionality. As Axelar progresses on its roadmap, it aims to have the validator set jointly approve smart contract upgrades to decentralize the network further.
• Possible liveness issues as validators can choose which chains to support— For a new chain to be added, Axelar requires 60% of the validators by their quadratic voting power to run a node for that chain. While validators have the choice to maintain a certain EVM chain, the vote majority threshold is still 60% of the quadratic voting power of the total validator set. So, if an EVM chain doesn’t have enough supporting validators, only liveness is affected, not security. Moreover, these thresholds can also be increased via on-chain governance.

Community & Resources

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

• Official Website
• Docs
• Axelar for Developers
• Whitepaper
• Github
• Block Explorer
• Medium
• Twitter
• Discord

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 gas in 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:

• Official Website
• Docs
• LayerZero for Developers
• Whitepaper
• Github
• Analytics Dashboard
• Medium
• Twitter
• Discord

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:

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 2/3rd of Guardians will not collude at a certain time.
• Censorship risk— 1/3rd of Wormhole’s Guardians can collude to censor a message.
• 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.

Community & Resources

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