Introduction
Overview
Future of Cross-Chain Governance
History
Current State of Bridging
Standardization
EIP-5164
Cross-Chain Messaging
Multi-Bridge
Risks
Bridge Hacks
What characterizes effective cross-chain governance?
Example of effective cross-chain governance: Aave
The need for cross-chain governance
What protocols need cross-chain governance
Why do these protocols need cross-chain governance?
Bridge Overview
deBridge
Celer
Synapse
Wormhole
Multichain
Hop
Connext
Axelar
LayerZero
Comparisons
Conclusion
Abstract
Cross-chain messaging has been a significant problem within the blockchain industry. With different chains being developed that offer a variety of benefits to users and developers, it makes sense that protocols with deployments on already existing chains would want to deploy on new blockchains. As it stands, many of the most significant protocols utilize some sort of governance mechanism to manage the protocol, its updates, and other decisions of influence to the posterity of its users. In order to maintain the state of the protocol amongst its different cross-chain deployments, the question has been raised as to which solution is the best. Bridges are needed to communicate cross-chain; they are the primitive that support smart contracts from one chain passing messages to smart contracts on another chain. In this paper we try to approach the solution to this question by first understanding the background of cross-chain governance, then exploring the current cross-chain governance solutions through comprehensive case studies of a bridge solution’s technical capabilities/vulnerabilities, and finally extracting the best option through comparison. As bridges are extremely diverse in their construction, our appendix includes a section with insights from prominent individuals in the space and their opinions on the bridge ecosystem.
Introduction
The decentralized finance ecosystem (DeFi) is growing rapidly, with the need to integrate different blockchain networks becoming crucial because transacting in a fragmented market is inefficient. Cross-chain governance involves the coordination and management of DeFi protocols across various blockchain networks. This allows them to harness the distinct strengths of different blockchains while managing the state of the protocol as it relates to transmitting the results reached through governance. These results could include risk parameter updates, introducing new or closing existing markets, etc.
Cross-chain governance is especially relevant to DeFi as it fosters improved interoperability between distinct protocols who were not initially sharing a chain. For example, if an incumbent like Aave wanted to deploy on Arbitrum (which it has) then it could result in more efficient financial transactions for users who want to lever up and gain exposure to the DeFi projects native to Arbitrum. This not only benefits users, but also developers who may not have previously been able to experiment with product development under conditions other than those which they are relegated to on ETH mainnet. By exposing developers to more freedom of development we increase the probability of innovation.
Another key advantage of cross-chain governance is its potential to decrease systemic failures in the DeFi ecosystem. By promoting better coordination and communication among different blockchain networks, cross-chain governance can make it easier to respond to high risk events such as black swans. Using Aave again as an example, since their interest rates and risk parameters are not automated to respond to the market, the DAO was forced to act swiftly in response to the Vyper Exploit of curve. During this event, CRV Aave v2 ETH was the most exposed market. The probability that Aave would incur crippling bad debt, initiating cascading liquidations across all of DeFi was extremely high. Although this event and the risks associated with it were confined to ETH mainnet, we can see how it becomes important to be able transmit important governance messages cross-chain in response to market shocks and black swans.
The future is ripe for improvements in cross-chain governance. Current projects are making it evident that they intend on bridging their protocol to other chains to take advantage of the supply and demand found on these chains. Finding the best solution would minimize the discrepancies and risks associated in the transmission of governance messages across chains while maximizing the functionality for DeFi participants in a multi-chain world.
History of Cross Chain Governance
On January 31, 2022, the first cross-chain governance proposal for DeFi was approved on the Aave Polygon Market. The proposal introduced new assets on Aave, including $GHST, $BAL, $CRV, $DPI, $LINK, and $SUSHI. The proposal was initiated on Ethereum and then transmitted to Polygon via FxPortal. Subsequently, the Aave cross-chain governance bridge contract received the data, decoded it, and queued the action, pending a timelock1
Cross-chain governance is not without risks. Most notably, Vitalik Buterin has highlighted that cross-chain applications are distinctly susceptible to 51% attacks on one network. Expanding cross-chain applications could exacerbate security vulnerabilities by spreading system-wide contagion if a single small-cap network is compromised2 The example here applies to connecting L1s with other L1s such as ETH <> Solana. It is much safer to retain respective tokens to their underlying L1 to ensure the canonical state of the chain should one of them experience a 51% attack. This implies that it is more favorable to bridge from between an L1 and L2 where the L2 inherits its security from the L1. This describes the relationship between chains like ETH mainnet as the L1 and Arbitrum as the L2.
The current trajectory of innovation suggests, despite these warnings, that both cross-chain protocols and cross-chain governance are inevitable. As such, it's crucial to explore cross-chain bridges that minimize security risks and enable dApps to capitalize on the numerous benefits of the architecture of other chains..
In December 2022, 0xPlasma Labs, an active participant and contributor to the Uniswap ecosystem's growth, put forward a proposal to introduce the Uniswap v3 protocol to the BNB PoS chain. They posited that this step offered a significant opportunity for Uniswap to broaden its user base and potentially stimulate further growth and DeFi adoption. Within the same year as the first cross-chain governance proposal we are prepared to ask the hard questions related to optimality as it applies to creating a ubiquitous method of maintaining the state of a DeFi protocol by using cross-chain governance.
A major component of building for the future is finding ways to maintain the integrity of governance from one chain to another. Cross-chain governance primarily involves the execution of governance activities on a mature blockchain, like Ethereum, while applying the governance results on a less mature or remote blockchain. To streamline this process, a bridge or multiple bridges can be used. It's noteworthy that different architectures may impose varied functional considerations related to cross-chain deployments, such as safety and liveness failures, and censorship risks. These challenges could compromise the bridge, leading to invalid governance actions, delay or even prevention of remote governance, and blocking of valid governance messages respectively. It does not make sense to select a solution that incurs the same risks we are trying to mitigate.
Participants in the proposal discussion stressed the need to assess the risks involved with cross-chain governance and bridge infrastructure. The rest of this report will examine various bridges mentioned in this proposal and beyond, and discuss the relevance of cross-chain governance.
Current State
Fundamentally, there are two types of bridges, trusted bridges, dependent on a central entity and trust assumptions where users cede control of their assets, and trustless bridges, a decentralized alternative. The main difference between these two types are whom/what the user is entrusting their assets, for trusted bridges it is a centralized third party, and for trustless bridges it is the programmability of the smart contracts.
To maximize security of trustless bridges it requires to maximize the number and diversity of those that verify the system (ie. validators). Usually, this means trying to have the validators match Ethereum’s validator profile. This is hard to implement and scale given that it requires agents with skin in the game to actively participate in securing the bridge. Trusted bridges instead use external verification, meaning that a deposit is not secured by a validator and instead by the external validation process used by the trusted party, which leaves the user at the fate off the centralized bridge operators (ie. multi-chain/anyswap design). Regardless of the underlying architecture of the bridge, we still need to depend on someone, somewhere in the world, to secure and verify the value transfer of a cross-chain message whether it be for governance purposes or simply transferring assets cross-chain.
From these fundamental forms of securing cross-chain message providers, we can distinguish characteristics of bridge design:
LMB bridges (lock mint and burn) - LMB bridges usually guarantee instant finality since assets are burned on the home chain and minted on the native chain.
Liquidity networks - Liquidity networks do not allow for instant finality, and instead have a single asset pool tied to additional asset pools on other blockchains for access to shared liquidity.
From these designs often arise tradeoffs that fit a classic trilemma problem for bridges and one for interoperability.
When asked about the Bridging Trilemma, Ryan Zarick from LayerZero claims bridges can only have two of three characteristics3:
Instant finality: Reception of assets on the destination chain occurs immediately after transaction execution on the home chain.
Native assets: Destination chain assets are native rather than minted by the bridge.
Unified liquidity: Single liquidity pool for assets between the home and destination chains.
In the Interoperability trilemma, Arjun Bhuptani from Connext claims protocols can only have two of three characteristics4:
Trustlessness: Same security assurance as the underlying domain (ie. Ethereum)
Extensibility: Ability to be supported by any domain (ie. Ethereum and Avalanche)
Generalizability: capable of handling arbitrary cross-domain data.
Standardization
Blockchains are developed to be immutable ledgers where anyone can access the history of transactions publicly available on the chain’s block explorer. Unfortunately, this does not imply that it is easy to support this data. Programming languages developed specifically for developing on blockchains are used to create smart contracts.. The Ethereum Virtual Machine (EVM) integrates with Solidity and creates an abstraction layer between the executing code and the machine, ensuring only one state of the blockchain exists at any block. Mathematically, the state transition of Ethereum can be represented as the following:
where S is the old state, T is the new transactions, and S' is the new state. Practically, EVM operates in a sandboxed environment, executing smart contracts' bytecode in isolation and charging users in gas units for each instruction, with costs paid in ether.
Chain-specific handling is prone to errors because of the unique characteristics of different chains such as the programming language they use, how they secure their blockchain, and the integration overhead experienced when trying to integrate chains that are fundamentally different. We should not be writing code that runs at such a low level. Instead, there should be an initiative to standardize cross-chain messaging as it pertains to industry-critical activities such as governance. Standardization of cross-chain messaging should make this easier to implement and scale to current protocols while maintaining a production-ready structure for all those protocols that seek to deploy on different chains in the future. In this section, we touch on two standards being developed in this problem space
EIP-5164
EIP-5164 defines a cross-chain execution interface for EVM-based blockchains5 This will enable contracts to call one another by sending cross-chain messages by utilizing a message dispatcher and a message executor.
This is proposed in an effort to minimize the overhead required to coordinate state changes across multiple EVM-based blockchains. This is because they normally depend on native or third-party bridges which require more custom integrations.
As posited in the EIP, defining a simple, common specification will increase code reuse and allow the use of common bridge implementations.
Cross-Chain Messaging
Cross-chain messaging (XCM) is a standard way to communicate between consensus systems, in an effort to enable cross-consensus interactions6 In our case we can consider these interactions to be those related to governance.
The key to standardization with this messaging system is that it doesn’t define how messages are delivered, but how they should look, act, and contain relative instructions to the on-chain actions the message is intended to perform. This is made possible by the core design principles outlined by the Polkadot team as being asynchronous, absolute, asymmetric, and agnostic. These more “one-way” characteristics ensure finality, efficiency and generality in message sending.
Overall this mechanism highlights key functionality which could be considered for future attempts at standardization of the cross-chain messaging infrastructure. These are that XCM supports rich data, is programmable, is secure and trustless, and enables cross-consensus.
Multi-Bridge
Multi-Message Aggregation (MMA)7 serves as an enhanced security protocol for cross-chain communication in a decentralized blockchain network. It's a form of message transmission across chains that resembles a diversified delivery system. Rather than relying on a single transmission medium or 'bridge', transactional messages are disseminated over several. In this parallel transmission method, a message is only validated and processed when a specific number of these bridges have successfully relayed identical data, meeting a quorum. By mandating consensus among multiple bridges, the complexity of potential malicious attempts within the system is significantly increased. To propagate a false message, an attacker would need to compromise multiple bridges concurrently, which is considerably more challenging, thereby offering an additional security layer.
MMA is a security module that enhances cross-chain communication. It uses multiple Arbitrary Messaging Bridges (AMBs) to pass messages from one EVM (Ethereum Virtual Machine) chain to another. This means that instead of relying on one bridge for communication, messages are sent through several. Even if one bridge is exploited, no malicious actions can be executed on the destination chain. This is because the message is only considered valid and executed when the same message is delivered by a quorum (a certain number) of different bridges.
Think of MMA as a postal system for blockchains. Traditionally, a letter (analogous to a blockchain transaction) is sent via one postal service (equivalent to a single bridge in MMA). However, MMA utilizes several postal services to distribute identical copies of the letter. The recipient will only regard the letter as valid and respond accordingly when it has been delivered by a set number of these services. For instance, if 3 postal services dispatch copies of the letter, a quorum is achieved if 2 out of the 3 postal services can agree that the copies are identical, thus successfully delivering the letter to the recipient. This mechanism makes it significantly more difficult for malicious entities to corrupt the system, as they would need to exploit multiple postal services simultaneously to deliver a deceptive letter. This principle forms the foundation of the enhanced security offered by MMA in cross-chain communication.
Risks
Understanding the risks associated with this problem space helps identify the vulnerabilities that certain designs incur. This can aid in the development of solutions that address the shortcomings of current solutions. As we will see, some design choices naturally accrue capital from depositors looking to bridge, making them attractive to those with malicious intents. This is not a risk that suddenly disappears. Cross-chain messaging solutions must be designed to discourage such attacks, much like the PoS consensus mechanism of ETH mainnet. This becomes relevant to cross-chain governance when we consider the high value of cross-chain messages and the implications for a DeFi protocol whose critical decision making mechanism is exploited.
Malicious actors have stolen over $2.5B in bridge hacks between 2021 and 2022, with the most recent bridge failure (multi-chain) essentially draining Fantom chain of all viable liquidity. To this end, we acknowledge that the worst case scenario for a bridge hack is the destabilization of an entire chain.
Given two networks (source & destination) where the state of the destination is dependent on the state of the source, cross-chain protocols must ensure the following security principles8:
Only states that are valid and final in the source network are communicated to the destination network
All relevant state transitions in the source network are relayed to the destination network in a timely manner
Any invariants that emerge from the cross-chain interactions are preserved
Risks which can compromise these security principles are:
Network Consensus Risk - If the underlying network fails, it can create inconsistent state changes across chains that cannot be reconciled.
Protocol Architecture Risk - The design assumptions and constraints of each layer of cross-chain protocol architecture can be a source of significant risk.
Protocol Implementation Risk - Complex on and off - chain components increase risks and vulnerabilities. This type of risk has thus far been the most common cause of bridge hacks witnessed over the last couple of years.
Protocol Operation Risk - Management of the protocol by key actors could be a central point of failure. The most damning evidence of this can be seen in the recent multi-chain failure.9
Evidently, due to the main risks attributable to failures are protocol operation and protocol architecture risks.
As previously mentioned, Vitalik is not the most optimistic when it comes to supporting a cross-chain ecosystem. The probability attributed to 51% attacks should be much less than bug exploits etc.
Bridge Hacks
To understand the real world impact of these risks we provide a table with the large bridge hacks since 2021.
What characterizes effective cross-chain governance?
The primary function requirement for cross-chain governance is the ability to send governance messages from Ethereum (or any other source chain for that matter) to remote chains for execution.
This should embody the basic qualities currently found in governance like transparency, accountability, and efficiency.
Transparent: open to all stakeholders.
Accountable: Voters / delegates are accountable for their actions.
Efficient: The governance process should not be overly burdensome for users.
These basic qualities define the characteristics of any active protocol governance. It’s reasonable to assume that protocols won't attempt the feat of a cross-chain deployment before they optimize their systems, acquire a strong base of users, and fully decentralize as a DAO to enable governance.
We’ve discussed the different kinds of solutions available to enable cross-chain governance. These bridge solutions come with their own unique architecture, benefits and drawbacks. If their objective is to enable cross-chain governance then they should make it easy and safe. These are qualities that any effective mechanism which handles critical data should embody. Some common characteristics of an effective cross-chain governance mechanism include:
Resilience: Effective cross-chain governance should be resilient to the failure of any specific cross-chain protocol.
Security: Effective cross-chain governance should be secure and protect against attacks on the governance of a protocol. The security of a cross-chain governance mechanism is what determines its resilience.
Extensibility: Effective cross-chain governance should be extensible to support new governance requirements as they emerge.10
Example of effective cross-chain governance: Aave
Aave currently extends governance on Ethereum to Polygon, Arbitrum, and Optimism.11 Aave currently has greater than $4.5 billion in total value locked. As a lending market protocol Aave has found success in deploying on different chains to cater to the users looking for leverage from a trusted protocol there. Their governance is among the most active in DeFi with teams such as Gauntlet and Chaos Labs providing protocol specific risk analysis and parameterization updates to maintain safe markets. In addition to that there is a variety of active delegates with industry specific knowledge ready to vote on such proposals.
Their cross-chain governance solution is built around the core bridge executor base smart contract which contains logic to facilitate queueing, delay and execution of sets of actions on downstream networks. It just needs to be extended to the specific downstream network where Aave has a deployment.
When a cross-chain governance proposal is passed on Ethereum, a cross-chain transaction can queue sets of actions for execution on the downstream chain. These actions cannot be executed until a certain delay has passed, though a specified (potentially zero) guardian address has the power to cancel the execution of these actions. If the delay period passes and the actions are not canceled, the actions can be executed during the grace period time window by anyone on the downstream chain.
Aave readily displays all of the characteristics of effective cross-chain governance. Their governance mechanism is transparent, accountable and efficient. In addition their messaging mechanism is resilient, secure, and extensible. It is resilient because it is actually developed and maintained by Aave rather than depending on external cross-chain protocols. It is also secure and extensible by design.
The need for cross-chain governance
What protocols need cross chain governance?
DeFi is currently the most rational application for cross chain governance. It is the sector that has most found its product market fit within blockchain technology. However there are many other developing sectors of the industry that could benefit from governance, especially cross-chain governance.
Naturally, users take to bridges to transfer their assets between chains to take advantage of dislocations in price or for certain other profitable opportunities like lower gas costs or unique protocols. This incentivizes those protocols which have found success on source chains, like Ethereum, to make deployments on other chains where this supply and demand lives. This necessitates cross-chain governance, primarily to uphold the functionality and longevity of the protocol on other chains.
As other sectors like on-chain Gaming and on-chain Social Networks develop, they can utilize governance and cross-chain governance to perform much of the same duties we witness in DeFi. This is under the assumption that they elect to decentralize (which may or may not be the case in the future). These types of protocols will depend a lot on the social interaction of participants and they will require software updates.
A particularly interesting sector that benefits from cross-chain communication, and has the potential to establish governance mechanisms is healthcare. Managing patients’ data cross-chain in a transparent manner is becoming increasingly important.12 This applies to information on medical records, records of authorization and proof of utilization of the data, provider directories, information on medicines and their supply chains as well as insurance and damage information.
Why do these protocols need cross-chain governance?
Identifying the existing use implementations of cross-chain governance as well as the potential implementations of cross-chain governance begs the question: Why do these protocols need cross-chain governance?
The main utility for governance is to update or introduce anything new to the protocol. Although the functionality is basic, it takes shape in different forms within different sectors. In DeFi this can look like parameter updates, new markets, treasury management, etc. While in gaming or social this could look like new features or activities, software updates, etc.
In the healthcare sector this actually translates to real world applications such as those related to data storage, security, and allocation of funds.13 It becomes increasingly important to consider support for different chains as healthcare systems tend to use different private blockchains from one another while research and investment DAOs are generally located on public blockchains like ETH mainnet.
Such dependencies for all of the sectors identified should be managed by governance. This not only appeals to the ethos of blockchain technology by decentralizing the decision making power and opening up the potential for participants to determine the future developments of a protocol.
Deployments on other chains are often beneficial to projects and users who can experience the unique benefits of a respective chain such as lower gas costs or anonymity. However, instances of a protocol on other chains increase the complexity of decision making given the increased number of options. Simplifying the process of governance and concentrating it to a single interface would make managing the deployments on different chains more streamlined while supporting robust decision making pratices.
A checklist for identifying DeFi protocols which could benefit from cross-chain governance may include but is not limited to the following:
Deployment on a source chain
An L1 like ETH mainnet.
High TVL on the source chain
TVL indicates different things for different sectors. This could mean money, users, data. Whatever value is important to define the protocol’s legitimacy should be present at scale.
Active governance on source chain
Information indicating that the launch on another would capture and cater to a significant number of users.
Bridge Overview
Different bridge architectures use different strategies to mitigate specific risks inherent to cross-chain communication. Currently, there is no single bridge design that comprehensively addresses all of the risks and serves as a one-size-fits-all solution. The technical stacks of each bridge model differ, resulting in variations in aspects like verification, trust assumptions, and other mechanisms. Additionally, there are also differences in governance formats as well. Governance is required for bridge operation as most bridges are not fully decentralized. Governance is a reliable method for implementing protocol improvements, allowing dispute resolutions, and creating a responsive system for parameter change and incentive alignment.
deBridge
deBridge is a cross-chain interoperability and liquidity transfer protocol, facilitating the decentralized transfer of data and assets across various blockchains. deBridge protocol considerably extends the scope of traditional bridges by enabling generic cross-chain message transfers. It allows developers and builders to interlink any smart contracts across different blockchains, thereby allowing data transfer and transaction calls (messages containing executable instructions, or CALLDATA) within the same transaction. As it currently stands, deBridge does not employ any governance mechanism, but has plans to launch a governance token in the foreseeable future alongside a delegated staking module to implement bridge slashing and fee distribution logic.
This innovation paves the way for limitless opportunities to construct complex cross-chain interactions, such as multi-chain applications, next-layer protocols, automated cross-chain arbitraging services, object or NFT bridges, and more! Acting as a generic messaging protocol and cross-chain interoperability infrastructure, deBridge can be utilized to develop any arbitrary cross-chain applications (deApps). Notable solutions built on top of deBridge include:
deSwap – A solution for capital-efficient cross-chain swaps between arbitrary liquid assets.
dePort – A native bridge for assets that enables protocols to bridge tokens and create utility for their synthetic representation (deTokens) in other chains.
deNFT – An infrastructure for cross-chain NFT transfers and a solution to create cross-chain native NFTs (currently a work in progress). The protocol comprises two key layers:
Protocol Layer – A set of on-chain smart contracts used for asset management, routing of cross-chain transactions, cross-validation of validators' signatures, and consensus reaching among validators. The transactions are only treated as valid if they achieve the minimum required threshold of validators' signatures. Governance manages the parameters of the smart contracts, such as fees, supported chains, the whitelist of elected validators, validators' payout ratio, etc.
Infrastructure Layer – Constituted by a set of reputable validators operating a deBridge node along with full nodes of every blockchain supported by the protocol.
deBridge has adopted a distinctive approach with an off-chain transaction validation mechanic where validators don't need to broadcast transactions and incur gas costs. Each cross-chain transaction initiated through the deBridge smart contract gets a unique hash (Submission Id). deBridge validators monitor all transactions passing through the smart contract of the protocol and sign the hash with their private key as soon as the transaction reaches its finality.
The resulting signature is saved into IPFS so anyone can access it. Any arbitrary user or keeper can collect validator signatures from IPFS and relay them to the deBridge smart contract in the target chain along with all transaction parameters. Based on these parameters, the deBridge smart contract will restore a unique hash of the transaction and cross-validate its signatures from all assigned validators. If the minimum required number of signatures is valid, the DebridgeGate smart contract delivers the message on the destination chain by executing its call data.
The capability to transfer arbitrary data creates opportunities for true cross-chain composability of smart contracts and protocols that can interact with each other, even though they operate in different blockchain ecosystems. An example could be an algorithmic stablecoin protocol on Ethereum that opens positions in a perpetual markets protocol on Solana or Arbitrum to maintain the peg of its asset. deBridge facilitates the development of a new generation of cross-chain protocols and applications previously impossible. Some of the use cases include:
Cross-chain swaps
Multi-chain governance
Cross-chain lending
Cross-chain yield farming
Benefits:
Supports transfer of arbitrary data in addition to assets. This allows more complex cross-chain usage apart from simple transfers.
Uses an offchain validation model to avoid expensive onchain overhead, helping minimize transaction fees for users.
Other characteristics:
High transaction fees: Auction-based fees on deBridge may spike during network congestion, causing users to pay more for timely transactions.
Limited network support: deBridge's incompatibility with certain blockchains may limit asset swap options, potentially reducing liquidity.
Centralization risks: deBridge's reliance on a few liquidity providers might lead to network dominance, introducing centralization risks.
Liquidity: deBridge's small network may struggle to provide enough liquidity for certain assets, potentially affecting transaction execution and pricing. In contrast, bridges like Uniswap offer more liquidity due to their larger user base.
Celer
cBridge is a multi-chain, cross-layer asset bridge, offering instantaneous transfers with an extensive number of chains, minimal fees, and zero trust. As a non-custodial asset bridge, it supports over 110 tokens across more than 30 blockchains and layer-2 rollups.
cBridge introduces an excellent cross-chain token bridging experience with profound liquidity for users, highly efficient and user-friendly liquidity management for cBridge node operators and liquidity providers who prefer not to operate cBridge nodes, and new exciting developer-oriented features such as general message bridging for scenarios like cross-chain DEX and NFTs. All of these features are enabled by extending the existing functionalities and services provided by the Celer State Guardian Network (SGN), which is powered by validators and stakers in the system with value capture. As it stands Celer does have a governance model. Users can get engaged and vote on the Celer forum which displays Celer Improvement Proposals (CIPs) and discussions about parameter adjustments.
At a low level, the SGN functions as a sidechain which monitors transactions related to Celer’s connected chains. It transfers information between Celer’s chains and external blockchains like Ethereum. The SGN is secured by validators staking the CELR token.
At a high level, the SGN is a specialized PoS chain responsible for monitoring L1 transactions related to L2 state and reliably transferring layer-2 information back to layer-1 when necessary. In the Celer State Channel, the SGN aids in storing channel states and counters malicious settlements on L1 when required. In the Celer layer2.finance rollup chain, the SGN functions as a decentralized block producer network to pass call data and state roots back to the L1 blockchain and submit fraud-proof from any SGN node, even when the entire PoS consensus fails.
Benefits:
Deep liquidity: Allows significantly larger transfer sizes.
Simplicity: Provides an option to condense two-step operations into a single click.
Native gas token unwrapping: For example, transfer WETH from BSC to unwrapped ETH on Arbitrum.
Expands to more tokens and chains.
Insured bridge node service level: If the bridge node is unavailable during a transfer initiation, the cBridge node's bond can cover the opportunity cost.
LPs aren't required to run a cBridge node: In version 2.0, Celer introduced a mode where the SGN itself serves as a "cBridge node." For LPs satisfied with PoS-consensus-level security based on CELR token economics in the SGN, they can delegate liquidity to the network without operating a node themselves.
Simplified Liquidity Provider (LP) experience: No need to mint synthetic tokens, manage volatile token pair AMM pools, or deal with high impermanent loss and complex rebalancing. Simply add liquidity to the preferred chain and start earning fees.
High liquidity efficiency: No need for double liquidity locking, fully utilizing liquidity with the highest yield.
Incentivized liquidity rebalance: Assists with one-sided liquidity movement. An AMM-style bonding curve and a flexible liquidity mining mechanism are employed to incentivize LPs and arbitrageurs to rebalance liquidity cross-chain.
High-quality service node scheduling: For LPs operating self-custodial cBridge nodes, the SGN acts as the decentralized layer to allocate user transfer requests to different LPs through policies that incentivize high-quality service and competitive pricing.
Security:
Celer utilizes two different security models—an optimistic-rollup inspired model and a L1-PoS-blockchain security model. Each comes with its own delay and security assumptions tradeoffs that developers and users can freely select from or set. The security model is highly adaptable, and even for a single application, developers can choose to build a hybrid model based on the "value" or "significance" of each cross-chain message.
Celer's cBridge supports a hybrid model allowing various tradeoffs to be dynamically chosen by the connecting chain based on the cross-chain transfer amount, token, and source/destination chain.
Benefits:
Low cost transfers by not relying on external validator sets that require high gas fees
Modular architecture allows for flexibility in security tradeoffs on a per-message basis. Applications can choose their desired level.
SGN and staking enables transaction security and consensus without centralization.
Other characteristics:
Centralized validators: cBridge employs a system of centralized validators to secure its network and facilitate transactions. While this offers quicker transaction times and lower fees, it introduces some centralization risks as the network relies on the validators to operate effectively.
Limited network and token support: Despite supporting a vast number of tokens and chains, cBridge may not be compatible with every blockchain ecosystem or token. This limitation could restrict the scope of its services.
Celer IM
Apart from the cBridge, Celer also has something known as Celer IM, or the Celer Interchain Message Framework. This framework is for building cross-chain applications that send messages and execution logic to different destination chains. Its main components are the MessageBus and the State Guardian Network (SGN). Celer IM uses dApp plugins as entry point contracts for users to start cross-chain message flow. Furthermore, the MessageBus smart contract delivers and handles transaction execution on the destination chain. A typical transaction pathway would be a user calling a dApp plugin to start the cross-chain interaction. The plugin then sends a message to the MessageBus and proper funds to the cBridge. The SGN then routes messages and funds, generating signatures. After this, an Executor relays the guardian signatures to give permission to carry out the action to the MessageBus. Finally, the MessageBus verifies the signatures and calls the dApp plugin to execute the necessary logic.
From this process arises the utility of the CELR token. The State Guardian Network requires CELR staking for validator permission. SGN fees are paid in CELR by dApps associated with Celer IM. These fees are then distributed to stakers. CELER provides security and permits cross-chain flow in Celer IM. Thus, in summary, Celer IM allows cross-chain dapp transaction paths through its MessageBus system in a manner that resembles a subscription service, where the dApp Plugin users pay Celer for their cross-chain interactions.
Synapse
Synapse Bridge facilitates users to effortlessly swap on-chain assets across over 15 EVM and non-EVM blockchains in a secure and reliable way.
The bridge supports two distinct types of bridging:
Canonical Token Bridging: This involves bridging of wrapped assets across various chains.
Liquidity-based Bridging: This pertains to bridging of native assets across cross-chain stableswap pools.
Synapse Bridge is also an ideal solution for developers interested in natively integrating cross-chain asset swapping into their applications. Through the use of the bridge, developers are equipped to construct genuinely cross-chain DeFi applications. These include cross-chain DEX, lending platforms, margin systems, derivatives markets, yield aggregators, and much more. The cross-chain AMM allows users to benefit from profound liquidity, low fees, and minimal slippage. Synapse Bridge has gained recognition as one of the most extensively used and trusted bridges, with it having processed nearly $11 billion in total volume and having catered to hundreds of thousands of users, as well as large-scale dapps like DeFi Kingdoms.
Synapse DAO utilizes governance to steer the evolution of the protocol through community control. SYN holders can propose updates, changes, or new features, which are then voted on by the DAO. To pass, proposals require over 50% of votes plus one additional vote, and must achieve a minimum quorum of 5 million SYN staked in the vote. Over time, the Synapse DAO aims to transition more authority to the community, providing governance participants jurisdiction over factors like transaction fees, chain connections, incentives, upgrades, and emergency response measures if vulnerabilities arise. For example, governance can launch bridges to new chains to expand reach, such as Synapse's recent deployment to Coinbase's ecosystem, Base.
Cross-Chain AMM
During the bridging process, if users desire to receive bridged assets native to a different destination chain that is linked but separate from the Synapse network (for example, receiving native ETH on Arbitrum), the Synapse AMM is invoked to execute the transactions. Synapse AMM pools utilize a stableswap algorithm to price transactions and encourage asset rebalancing during the swapping and bridging process. These pools are deployed on each chain interconnected with the Synapse Network, allowing for swift and trustless liquidity flows between all such chains.
This effectively creates a cross-chain dynamic pricing system for all assets supported by the Synapse Network based on user demand, continuously relocating capital to the most sought-after ecosystems. As a pool within a single destination chain becomes imbalanced due to unidirectional capital flow, arbitrageurs are incentivized via the AMM's pricing to rebalance the pool through other on- and off-ramps, generating fees for protocol revenue in the process.
Benefit
Generalized AMM design helps maintain price parity and incentives rebalancing across all chains
Upcoming Synapse Chain will allow trustless messaging with a new optimistic model
Strong focus on usability - one of the most widely used bridges with integration into major dapps and L2s.
The Synapse Chain is an upcoming Ethereum optimistic rollup that is meant to serve as an interoperability layer for cross-chain messaging and other use cases. Synapse Chain will achieve generalized cross-chain messaging and will use an optimistic verification security model for verifying its cross-chain messages, rather than the traditional externally verified bridges. In optimistic verification, off-chain actors coordinate to find and flag malicious actors during a time period. This L2 will use SYN as its gas and staking token to pay the optimistic verification guards. Synapse Chain has four different roles that enable the optimistic verification mechanism for securing cross-chain transactions:
Notaries: These participants are responsible for signing merkle root and bonding SYN behind attestations
Broadcasters: This group is responsible for forwarding updates from source chain contracts to replica contracts based elsewhere
Guards: These participants are required for observing cross-chain messages and submitting fraud proofs upon the detection of malice
Executors: This group is necessary for posting the final transaction once the time period has been completed without detection of a malicious state update.
Wormhole
Wormhole strives to function as a decentralized cross-chain solution that facilitates the transfer of assets across disparate blockchains. The platform introduces xAssets and xDapps, enhancing performance, market accessibility, extensibility, and composability. Wormhole's publishMessage execution strategy varies by chain, eliminating the need for a target address or chain in its functions.
The platform features a Guardian Network, composed of 19 validators, along with a collection of specialized and generic relayers to assist in transactions. xAssets, which are fungible tokens, necessitate attestation via Verifiable Assertions of Attestations (VAAs), whereas NFTs don't require such attestation. Moreover, Wormhole supports contract-controlled transfers and enables the development of xDapps.
Wormhole uses many different components, both off-chain and on-chain. On-chain components include:
Wormhole Core Contract: This is the primary contract that Guardians follow. This contract is fundamental for enabling cross-chain communication. All cross-chain applications that use Wormhole use this contract whether directly or indirectly.
Emitter: This is a type of contract that calls the message on the Core Contract, which will then write and add an event to the transaction logs about a message from the Emitter contract. There are several types of Emitter contracts.
xAsset Contracts: These are contracts that convert normal tokens into cross-chain bridging tokens, or, xAssets.
Relay Contracts: These are contracts that interface with cross-chain applications to send messages to specific destination chains using a relayer network.
Worm Router Contracts: These are contracts that permit developers to create cross-chain dapp that any user on a Wormhole supported chain may use.
Transaction Logs: These logs allow Guardian validators to observe messages.
Off-chain components include:
Guardian Network: Guardians/Validators form a p2p network that observe and validate messages emitted by the Core Contract.
Spies: This party subscribes to published messages from the Guardian Network. Spies observe network traffic.
Guardians: Guardians are the 19 validators that form the Guardian Network
VAAs/Verifiable Action Approvals: These are the signed attestations of observed messages.
Relayers: Offchain process that relays a VAA to the destination chain
Governance decisions are made by Wormhole Guardians, and only a ⅔ supermajority of Guardians are required to pass an action. This means that Wormhole’s governance process may be more centralized than average especially given the nature that its validator network is currently comprised of 19 validators.
Benefits
Use of Guardians and VAAs to validate transfers increases censorship resistance compared to bridges that only use external validators
Specialized and generic relayer network improves transaction latency and cost efficiency
Multichain
Multichain enables frictionless value transfer between blockchains using its Cross-Chain Router Protocol (CRP). This open source infrastructure powers a network of chain-to-chain bridges secured and operated by a decentralized network of nodes running secure multi-party computation (SMPC). The bridges connect two blockchains using a threshold-distributed signature algorithm. This generates a public key that corresponds to private keys split across independent SMPC nodes. The nodes collectively control a Decentralized Management Account on the origin chain that holds bridged assets. When assets are sent to this account, equivalent "wrapped" tokens are minted by a smart contract on the destination chain and sent to the recipient's wallet. The reverse process burns tokens when assets are redeemed to the origin chain. The SMPC nodes facilitate the release and custody of assets between chains.
For native assets like USDC, Multichain relies on liquidity pools to route transfers. Tokens are added to pools on each chain, enabling them to be swapped cross-chain while maintaining overall pool balances. If a pool runs low, "anyAsset'' tokens represent the user's share until more liquidity enters the pool. For assets bridged using Multichain's Anyswap contracts, supply is minted and controlled by Multichain directly. No liquidity pools are needed, so supply is unlimited. Some assets use a hybrid approach with native tokens on certain chains but bridged tokens on chains newly added by Multichain. The CRP provides a generalized protocol for managing assets across chains. Developers can leverage the open source bridges and APIs to connect blockchains and enable cross-chain applications. Multichain aims to create an internet of blockchains built on seamless interoperability.
The Multichain network operates via Secure Multi-Party Computation (SMPC) nodes. These nodes collaboratively sign transactions, requiring a consensus for successful execution. The nodes collectively control a Decentralized Management Account on the origin chain that holds bridged assets, acting as the joint custodian of funds. When assets are sent to this account, equivalent "wrapped" tokens are minted by a smart contract on the destination chain and sent to the recipient's wallet, just as one bank branch will issue you funds when you deposit at another branch. The bridge function of Multichain is designed to securely lock assets on one end while promptly minting them on the other. The procedure to establish a new bridge generally takes around two weeks. Multichain V2 operates as a bridge, while V3 serves as a router capable of leveraging existing liquidity. Notably, assets that have undergone the multichain bridging process don't necessarily need to be routed via the original chain. This allows for greater flexibility and efficiency in asset transfer.
Assumptions
Requires liquidity providers and arbitrageurs to behave rationally and rebalance pools. Otherwise transfers may stall due to insufficient liquidity.
Relies on honest behavior of blockchains connected. Issues like chain reorganizations could disrupt asset transfers.
Bridges are secured by a network of SMPC nodes. Threshold signatures prevent theft, but the system assumes nodes are online and functioning properly.
Updates
In 2022, Multichain added bridges for Bitcoin, NEAR, and Celo assets, expanding ecosystem connectivity. Additionally, the Multichain Router v2 was released, improving capital efficiency by sharing liquidity between router and bridges. Alongside these changes came Anyswap V6, which enhanced security by separating mint/burn from transfer logic.
Benefits
Anyswap contracts allow unlimited bridged token supply without liquidity pools, simplifying liquidity management.
Open source router protocol enables developers to easily integrate chains and build cross-chain dapps.
Hybrid model combines benefits of native transfers on supported chains with bridging on new chains
In July 2023, Multichain experienced an exploit where large amounts were being withdrawn from the protocol. The abnormal transfers made many suspect that it was an inside job or a rug pull. Following the withdrawals, Multichain’s CEO became unresponsive after “losing MPC keys” and was eventually arrested by Chinese authorities, along with the rest of the core development team for Multichain. Furthermore, Chinese authorities also arrested family members of the CEO, after it was found that the CEO’s sister had some of the funds transferred to two wallet addresses that she owned. This hack significantly affected the Fantom community, as Multichain was a major bridge for the protocol, and thus its TVL dropped substantially.
Hop Protocol
The Hop Protocol is a special bridge interoperability solution that focuses on connecting L1s and L2s by converting tokens between a canonical and noncanonical state. This means that it connects the L1 mainnet to both rollups (Arbitrum and Optimism) and sidechains (Polygon). Most rollups usually have their own rollup bridges, serving as a sort of “state sponsored” bridge.
Hop approaches scalable bridging in different ways: by creating a cross-chain token that can be moved between rollups as a universal currency, and by employing an AMM to swap bridge tokens and their "canonical" tokens on the corresponding rollups to incentivize liquidity rebalancing.
This means that when some amount of ETH is deposited into the Hop Protocol, then some amount of hETH can be minted on a desired bridge. Bonders serve as users that front their liquidity on the destination chain in exchange for a fee from the user. The liquidity of the Bonder is returned when the transfer propagates through the L1 on a larger bundle deemed the "Transfer Root''. These roots are defined as bundles of transactions, merkle roots, and destination chain ids.
Hop's bridge architecture is not completely trustless as it requires trust assumptions due to their system's requirement for fast arbitrary messaging.
The Hop Protocol uses a multi-stage governance process that involves both onchain and offchain components. Discussion and communication happens offchain through a discourse forum and snapshop for vote signaling in order to gauge sentiment. Onchain formal proposals can be launched and voted for through a governance portal. 1M HOP is required for a delegate to submit a proposal. Every proposal has a 7 day voting period, with votes weighted by the HOP holdings. Furthermore, .3% HOP voting quorum is required to pass proposals with a 2 day timelock before passed proposals are executed. The proposal process happens in the following stages: an initial discussion, temperature check vote on Snapshot, and formal vote onchain.
Assumptions
The Hop Protocol makes some trust assumptions in order to enable fast, arbitrary messaging between chains:
The role of the Bonder relies on a trusted third party to provide upfront liquidity for transfers before settlement on layer-1. This could potentially be decentralized.
The protocol relies on honest behavior of the blockchain networks it connects. If one chain experiences a consensus failure or chain reorganization, it could disrupt the integrity of bundled transfers.
The network requires participants like arbitrageurs and liquidity providers to behave rationally to maintain token price parity and rebalance liquidity.
Updates
Development in 2023 is focused on Hop V2 Core Messenger. This messaging protocol will allow trustless communication between chains using native bridges. Messages are aggregated into bundles, hashed, and propagated via layer-1. The Core Messenger prioritizes security over speed. Faster optimistic and collateralized messaging models can layer on top for time-sensitive use cases. Hop V2 will enable a suite of cross-chain modules for transfers, swaps, NFTs, omnichain tokens, and custom functionality. This will significantly expand the Hop ecosystem and scale the network by bundling more messages per layer-1 settlement. Hop V2 Messaging unlocks low-level infrastructure so developers can focus on high-value composability.
Benefits
Bundling transfers into “Transfer Roots” allows aggregating transactions to reduce costs.
Upcoming Core Messenger will provide generalized trustless messaging
Modular design will enable cross-chain module for transfers, swaps, NFTs, and more.
Connext
Connext is a cross-chain swap platform that uses signature-based locking of messaging liquidity transfer. It has a centralized router but not a security problem. It is susceptible to griefing or censoring, but there is no loss of funds. Connext is another interoperability bridge founded on the thesis of decentralization. Connext launched in 2021. The core part of Connext is the transfer of calldata using its NXTP protocol. NXTP is Connext's solution for a trustless, low-cost, and easily extensible base protocol. NXTP has a unique set of characteristics that allow it to achieve its low-costs and trustlessness. For example, NXTP does not use an external set of validators to control user funds, but rather it uses a lock/unlock mechanism to ensure fund transfer security. It can be used on all chains whether a base L1 or a scalability solution like a rollup or a sidechain. Because the NXTP protocol does not interact with Ethereum when passing messages through L2s or side-chains it does not require high fee issuance.
Similar to deBridge, Connext does not currently have a governance mechanism in place and thus does not have a community forum nor tokens for participants to interact with. However, Connext is set to launch their airdrop in the coming fall. Their token, NEXT, a cross-chain native xERC20, will be used for governance within the Connext network through the Connext DAO. Apart from the information surrounding airdrop eligibility, there has yet to be anything released about the parameters the Connext token will control for the bridge network.
On a high level, the NXTP protocol is a smart contract with a lock and unlock mechanism. For transactions this is a three phase process.
Route Auction: During this phase the user signals their destination route to the network. The routers in the network then respond with bids that contain time and price range commitments for user transaction fulfillment
Preparation: After the user accepts the router bid, then the auction is completed and the user must submit another transaction containing the signed bid to the Transaction Manager contract. After completing, the users' funds will be unlocked on the destination chain
Fulfillment: After the preparation phase, the user submits a signed message and sends it to a relayer. The relayer is another Router that earns a fee for the submission; the role of the relayer is to submit the message between the user and the Transaction manager. Upon completion, the Router is able to claim their locked funds.
Contracts: All participants have their assets held in contracts, which are necessary for the lock/unlock feature of NXTP.
Subgraphs: These capture on-chain events, allowing for query and response.
SDK: Users can create SDKs for listing and creating auctions.
txService: Sends transactions to the chain
Messaging: Messages are used for sending data for the preparation phase and transfer of funds.
Router: The routers on the network receive signals for events from the messaging service and the subgraphs. Using these messages, they send transaction instructions to the txService
Assumptions
While Connext is extremely efficient for connectivity, speed, security, and capital efficiency, it lacks in the statefulness department. Connext can send calldata, it is limited, and can only transfer specific assets and execute certain cross-chain contract calls. Nevertheless, NXTP still allows for a degree of statefulness.
Updates
Connext has formed a partnership with Inverter Protocol to expand both projects' capabilities for cross-chain interactions. This collaboration will allow Connext to be integrated into Inverter's system of smart contract modules and templates. Two key features will be enabled initially. First, Connext's Chain Abstraction Toolkit will let users fund Inverter-based projects from any blockchain network. This makes it easier for founders to access investments no matter what chain their backers use. Second, a new Payment Processing Module will let Inverter contracts distribute payments across chains. This can facilitate use cases like payroll across chains or cooperation between DAOs on different networks.
Looking ahead, Connext aims to embed itself even deeper into Inverter's architecture. The roadmap includes adding Connext to Inverter's software toolkit to enable cross-chain workflows for new developers. Connext will also build a Smart Contract Mixin that can monitor activity across chains and trigger actions in response. And support for Cross-Chain Tokens will allow more dynamic value transfer between Inverter's modules. This collaboration combines Inverter's flexible smart contract modules with Connext's bridging capabilities. It promises to make both platforms more powerful for launching cross-chain dApps with real-world use cases.
Chain abstraction is a core component of Connext’s roadmap. Enabling developers to utilize xCalls they plan to develop modules with different streamlined applications. The first of which will be xGovernance.
Benefits
Signature-based locking provides security without external validator overhead
Low transaction fees due to avoiding on-chain validation steps
Upcoming smart contract integrations to embed Connext deeper into dapp transaction flow.
Axelar
Axelar is a cross-chain messaging platform that approaches interoperability from a holistic perspective. It seeks to achieve generalized cross-chain messaging by forming an interoperability layer complete with its own toolkit — the Axelar SDKs — to allow developers to create contracts that can call other contracts established on its interoperability layer. Essentially, any developer can create a contract using the Axelar SDK and this contract can then be called by any of Axelar’s supported networks. The Axelar network runs nodes containing execution client software of their supported networks, so if a contract is deployed on Ethereum, as long as there is an Axelar node running execution client software for Avalanche, then the contract can be called on that chain as well. Axelar’s interoperability layer is fully proof of stake, and uses the Axelar token as its native token. For any cross-chain transaction, all of the network's nodes maintain threshold signatures on accounts on each chain to perform the necessary actions or custody funds for the Axelar network.
Axelar governance influences key network parameters and functionality, such as base inflation rates and reward amounts for the AXL token, network gas fees and gas estimation formula for connected chains, validator thresholds for new additions, upgrades to the Axelar network and smart contracts, compromised chain disconnections, and voting on adding new support for new EVM chains. Axelar aims to transition more parameters and decisions to governance participants over time, meaning that there will be community control over factors like transaction fees, chain connections, and emergency responses. For example, governance can adjust gas fee formulas as conditions change per chain, set minimum validator approvals to add a new chain, or coordinate a network upgrade for Axelar.
On a higher level, here's how the Axelar Network works:
Axelar operates on Proof-of-Stake validators. These validators are nodes that participate in the consensus process of the Axelar network while running execution clients of the desired blockchain. Each validator has a weight that represents their voting power, all validators weights added up are equal to 1.
Validators are elected through stake delegation. Users with stake in the network can elect to run a validator node or delegate their voting power to an existing validator.
In order to validate blocks, Axelar needs a correct number of validators to approve, this is the threshold measure of the minimum consensus for decisions in the network.
One key feature of the Axelar network is that it uses threshold signatures. Threshold signatures allow a group of parties to split a key for a signature in a manner such that subsets of parties can collaborate to produce a signature, but no subnet below a certain number can produce a signature or even know the full key.
Assumptions
The network works under the assumption that there is partially synchronous communication, meaning that the network may be asynchronous until some stabilization time, but after this time, communication becomes synchronous again. This is a compromise between complete synchrony (fixed time for message delivery) and asynchrony (arbitrarily long wait periods for messages).
Axelar is building a decentralized network that seamlessly connects different blockchain ecosystems. This allows assets, data, and transactions to flow between chains, unlocking new cross-chain applications.
The core problem Axelar aims to solve is that the blockchain world today is highly fragmented. Networks like Polygon, Ethereum, and Bitcoin all have distinctive features that make them attractive to different parties. Nevertheless, these chains currently operate in total silos, unable to interoperate.
Axelar's network leverages validators to run nodes and maintain lightweight clients for multiple blockchains. This gives the validators a live view into the state of all connected chains. The validators manage threshold accounts on each chain, which facilitate cross-chain transfers using multi-signature technology.
Axelar features a modular architecture with two core protocol layers:
The Cross-Chain Gateway Protocol (CGP) handles discovery, routing, and data transmission across chains. This protocol allows any blockchain to integrate easily without custom engineering work. Platform developers can simply plug their chain into the network.
The Cross-Chain Transfer Protocol (CTP) provides a simple API for dApps to perform operations like token transfers, contract calls, data queries across chains. Developers can build on one chain while accessing liquidity and users on all connected chains.
By combining these protocols, Axelar creates a universal interoperability substrate. This unlocks new Web3 use cases like decentralized exchanges aggregating liquidity across chains, NFT marketplaces with cross-chain auctions, and blockchain games with asset portability.
Axelar uses threshold cryptography and a decentralized validator pool to secure bridges between chains. Key generation and transaction signing involves multi-party computation across validators to prevent theft. The network is designed for maximum decentralization and uses robust governance mechanisms to recover funds if the network stalls.
Updates
At the beginning of 2022, Axelar went live on mainnet, allowing for communication between the Ethereum and Cosmos ecosystems. It also recently released the AXL token, and expanded its governance. Currently, Axelar is working with Circle for the creation of composable USDC.
Benefits
SDKs allow developers to easily integrate cross-chain calls into applications.
Threshold cryptography and distributed validation increases censorship resistance.
LayerZero
LayerZero is a cross-chain messaging platform that allows native communication between blockchains without relying on intermediary chains or tokens. Its goal is to provide omnichain interoperability using a network of validators.
The core innovation of LayerZero is its trustless valid delivery. This means that a message can be delivered from one chain to another only requiring the originating transaction to be proven valid and committed. LayerZero is able to securely relay transactions and data between chains by using threshold cryptography and independent oracles and relayers. LayerZero is a sophisticated arbitrary messaging bridge, which, at its core functions as a generalized data messaging protocol. LayerZero is underpinned by endpoints present on its supported chains that facilitate inter-domain communication. These endpoints are smart contracts that enable cross-chain communication. Each chain possesses a unique library within the LayerZero ecosystem.
As mentioned previously, traditional cross-chain bridging methods accomplish bridging through middle chains or onchain light nodes, which both have their own tradeoffs. LayerZero amplifies the light node concept with the introduction of the Ultra Light Node, which offers light node security at the cost efficiency of a middle chain. Instead of storing all block headers sequentially, they are streamed on-demand by oracles.
LayerZero relies on oracles and relayers to establish a direct communication between networks. Here, the oracle functions as an independent consensus layer that reduces friction to finality. The oracle provides the block header and the relayer provides the proof associated with the transaction in question. This allows LayerZero to achieve low latency and low complexity, at the cost of a higher overhead cost due to the use of oracles. The reason why the relayer/oracle format allows LayerZero to achieve trustless valid delivery is because the Oracle and Relayers both operate independently, so long as they do not collude, it is infeasible for them to alter a valid transaction proof or block header. Fundamentally, this means that LayerZero will be capable of delivering messages without trusting either the Relayer or the Oracle.
Assumptions
The main trust assumptions behind the LayerZero protocol are the following:
No collusion among oracles and relayers
Finality guarantees of each blockchain within the LayerZero ecosystem
Accuracy of oracles. The oracle must provide the correct block header on each given chain.
Security:
The delivery of cross-chain governance decisions calls for a robust message-passing infrastructure that can withstand a myriad of attack vectors. This segment scrutinizes the security of different bridge solutions by examining their core technologies, potential centralization risks, and historical security breaches.
The typical path of a cross-chain governance message commences at a multisig on the source chain. Once a consensus is reached within the multisig, a message is generated and sent to one or more destination chains. The process of transmitting the message is inherently off-chain, which represents the fundamental challenge of bridging. An optimal bridge would safeguard the integrity of the data and ensure the message is delivered promptly and accurately.
Apart from valid delivery, LayerZero ensures that it is costly to perform an attack. For example, in a possible collusion scenario where an Oracle and Relayer are run by the same group, an oracle can provide false information and gain approval from themselves and override the independence in place. First, this risk is isolated, as the only affected group would be the application that uses that specific Oracle. Thus, in order for the entire network to be compromised, each oracle would have to be compromised as well, which creates an extremely high price to execute an attack. Nevertheless, this is still dangerous as some applications may carry more specific and valuable data than others. Hence, LayerZero allows the option to choose different combinations of Oracles and Relayers to decrease the risk of collusion.
Finally, LayerZero also has a feature known as Pre-Crime, a capability which would prevent hacks before occurring. Essentially, before a message is delivered to its destination chain, the relayer could locally simulate the execution of the transaction to foresee possible malicious consequences. For example, let's say a decentralized exchange (DEX) built on LayerZero wants to prevent front-running of trades. When a trade transaction is sent across LayerZero, the relayer could locally simulate the execution to check the atomicity condition - that is, the taker's tokens are transferred if and only if the maker's tokens are transferred. If the relayer detects that the transaction would only transfer the taker's (Alice's) tokens to the maker (Bob) without debiting Bob's account, it would recognize this violation of atomicity. The relayer would then refuse to deliver the transaction, preventing the front-running attempt.
Benefits
Ultra lightweight client reduces gas costs compared to onchain alternatives
Pre-crime simulation can halt delivery of transactions that would lead to undesirable states
Flexibile trust model allows users and apps to customize O/R selection.
Trust Assumptions
Oracle/relayer independence: LayerZero depends on the independence of these parties to prevent collusion and establish valid delivery for messages.
Availability and accuracy: Oracles and relayers must be online at all times and provide correct data for the network to function properly.
Transaction finality: source chains need adequate transaction finality to prevent a possible rollback.
Cryptographic assumptions: LayerZero relies on cryptographic assumptions to secure threshold signatures.
Attack Resistances
Valid delivery: L0 matches block headers and transaction proofs from independent O/R sources to ensure messages correctly show a committed transaction
Pre-crime simulation: Rs can locally simulate transactions to detect possible malice.
Sharding/shielding: Users are able to run their own relayers and choose their own O/R combinations to limit collusion risk.
Custom configurations: Applications can customize their libraries to prevent unauthorized modifications from LayerZero
The LayerZero Omnichain Governance Executor enables cross-chain governance through an omnichain messaging protocol meant to be an extension developers can use on top of existing on-chain governance systems to support proposal execution across multiple chains, thus it is naturally seamless with governance architectures across the board. At present, the current implementation in use for omnichain governance with Uniswap only supports cross-chain proposals between Ethereum and Avalanche.
On the main voting chain there is a required cost of gas to encode payload data and check whether the destination chain is a trusted source, and then emit events. Subsequently, a LayerZeroEndpoint.send() requires gas for threshold signature verification, and transmitting the message across chains. On the destination chain, gas is required to receive the payload of data and verify the proof from the delivered message for the intended recipient. The OmnichainGovernanceExecutor contract requires gas to actually execute the proposal on the destination chain as well, by calling the proper contract functions. In summary, the primary gas costs are for encoding and transmitting the data on the voting chain, validating the message proof on the destination chain, and executing the proposed actions on the destination chain.
Comparisons
Below we have aggregated the different characteristics of the case studies mentioned above.
A few things to note based off of these comparisons:
Multichain was hacked and is no longer in operation so it should be considered the worst solution available.
LayerZero is the only cross-chain solution with a live example governance module.
The dominant type of trusted entities is the external validator set.
Conclusion
This report introduces the topic of cross-chain governance. It highlights the risks associated with different architectures of bridges which enable cross-chain governance. It also lays out the immediate need for cross-chain governance, considering what protocols could use it and why they would use it. This report culminates with the comparison of LayerZero’s governance module with those outlined in the case studies. Finishing with first hand remarks from a handful of thought leaders in reference to cross-chain governance.
Cross-chain governance is important as it enables protocols to maintain integrity and community across blockchains, but effective implementation requires navigating complex tradeoffs. While some form of cross-chain governance itself is necessary, in the end it should be considered if governance in the traditional sense is a bug or a feature. There are many discussions around whether governance may be phased out in place of better decision-making solutions, such as naturally dynamic protocol parameters or through automation.
Bridges relying solely on external validator sets like Wormhole provide fantastic finality but incur high gas fees. Consortium bridges such as Celer offer efficiency yet introduce centralization risks with their validator pools. Optimistic rollups optimized for speed also compromise full security guarantees. And finally, trusted bridge designs are naturally centralized.
It appears that the many different solutions explored in this report have plans to or have already developed their own governance modules using their cross-chain messaging infrastructure to be easily integrated with protocols who need cross-chain governance. In a competitive industry such as blockchain, it appears that first movers will most likely collect market share. Switching costs associated with migrating governance mechanisms can be high, and it will most likely be the case that any first mover would then work with their clients to deliver the best experience. This could mean that in the future most protocols use one market leading cross-chain messaging protocol for governance purposes.
However, we also explored the idea of a multi-bridge mechanism. It would be interesting to see a case where cross-chain messaging protocols partner to test a mult-bridge mechanism with their governance modules. Essentially a multi-bridge governance module.
When it comes to the trust assumptions made by the different cross-chain messaging solutions it will be interesting to see how restaking impacts the space. Guardians, oracles, and relayers are all potential actively validated services which could benefit from the added security guarantees of restaking.
At the moment, LayerZero is the market leader as it relates to the delivery of their governance module. Their infrastructure provides a compelling balance of decentralization and strong security guarantees. Its dependence on oracles and relayers for valid message delivery is a trust assumption. However, LayerZero mitigates this through custom validator selection, along with other solutions like sharding. No solution perfectly optimizes every metric of course, but LayerZero’s emphasis on security for governance actions is what matters in the case of cross-chain governance.
https://multi-message-aggregation.gitbook.io/multi-message-aggregation/start-here/multi-message-aggregation
https://crosschainriskframework.github.io/framework/01intro/introduction/#security-risks
https://uniswap.notion.site/Bridge-Assessment-Report-0c8477afadce425abac9c0bd175ca382#66580513ec4d41ce85449cc5d969c534
https://github.com/aave/governance-crosschain-bridges
https://www.frontiersin.org/articles/10.3389/fbloc.2021.732112/full
https://www.wundermanthompson.com/insight/decentralizing-healthcare
https://synapse.mirror.xyz/L6dBb7aXIJ1Ll5_sxP2bIJxVEYNd43ZzIV6dRylQJxw
https://docs.synapseprotocol.com/protocol/synapse-chain