Approaches to Cross-chain Messaging

Three main approaches for cross-chain messaging

There are three main approaches to general cross-chain messaging. Most protocols fall into one of these categories: (1) Consensus-light-client-based, (2) Validator-based, and (3) Optimistic. Each of these approaches makes different trade-offs between security and usability.

Consensus Light Clients

Consensus light-client-based messaging protocols are interoperability protocols that verify the consensus of a message’s source chain on the destination chain before delivering the message. This verification process usually occurs on an on-chain light client at the destination chain. In PoS chains, the light client tallies all validator votes to ensure that a block has received a supermajority of votes before delivering messages within the block. This approach aims to ensure that invalid messages do not make it to the destination unless the consensus mechanism on the source chain breaks. If the consensus of the source chain is compromised, invalid messages may go through, but as the reasoning goes, applications have more significant problems on their hands at that point. Consensus light-client-based interoperability protocols have garnered much attention and praise, as seen from Cosmos’s IBC.

Here are some of the pros/cons for consensus light-client-based messaging protocols.


  • Trust-minimized: They are an incredible trust-minimized approach to interoperability. This approach has only three trust assumptions. (1) source chain remains uncompromised, (2) destination chain remains uncompromised, (3) the code does not have fatal bugs

  • Fast: They are fast. The moment a transaction containing a message is finalized on the source chain, the associated message can be delivered on the destination chain.


  • Costly: On chains where compute is not cheap, they are quite expensive to run.

  • Not easily extensible: For any chain with differences in consensus mechanisms, a new light client is needed.

  • Difficult to implement: Each chain with its unique consensus mechanisms must be implemented in a smart contract. This increases the chances of having a fatal bug in the protocol that can be exploited later.


In validator-based cross-chain messaging protocols, an off-chain group of validators reaches a consensus on the messages to be delivered. These messages are then sent to the destination chain using some cryptographic system that ensures that the validators reach a consensus before forwarding the message. This cryptographic system is typically multi-sig, a threshold signature, or message proof. Validator-based interoperability protocols fall into three sub-categories:

  • Permissionless validator protocols

  • Permissioned validator protocols

  • App-sanctioned validator protocols

Each category makes different tradeoffs between security and usability.

Permissionless validator protocols

Permissionless validator interoperability protocols are validator-based interoperability protocols where anyone can become a validator, provided they satisfy a few conditions. Usually, this condition is the staking of funds. Because of this, permissionless validator-based interoperability protocols tend to have associated blockchains where consensus occurs. A perfect example is Axelar. However, it is important to note that permissionless validator networks do not necessarily need their own blockchains.

Here are some of the pros/cons for the permissionless validator approach.


  • Easily extensible: Several cryptographic primitives make it possible to represent any group of validators on any chain; for example, as a single account. This single account can deliver messages and value on any chain on behalf of the validators.

  • Can be fast: The protocol can be built using a consensus mechanism/system that allows validators to agree on the validity of messages very fast.


  • Costly: Users must compensate the whole validator network for delivering messages.

  • Cost vs security tradeoff: Until the network has significant volume, it trades between cost and security. The validators verifying the messages stay around for economic gain. Without significant activity, each user must pay more to keep validators around. If the cost reduces, many validators will leave the network, decreasing security—one could attempt to address the tradeoff by subsidizing costs through the staking rewards to validators. Unfortunately, staking rewards are usually not enough to offset the delivery fee.

  • Hard to guarantee trust-minimization: Validators join and leave the network at will. Depending with the implementation and the economics, the network can end up with only a few validators monitoring particular chains thereby making it less trust-minimized.

  • Misaligned incentives: As the protocol usage grows, the value in the applications built on top exceeds the value staked by validators. Once a protocol reaches this state, validators are incentivized to collude and send invalid messages that can exploit the network.

Permissioned Validator Protocols

Permissioned validator interoperability protocols are validator-based interoperability protocols where the protocol preselects the validators. In this approach, the protocol safelists a group of validators responsible for reaching a consensus on messages to deliver. Unlike the permissionless approach, where security depends on economic incentives, security in the permissioned method is largely dependent on the trustworthiness of the validators. Permissioned validator-based interoperability protocols attempt to recruit the most reputable and established entities and companies as validators to add an element of social trust to their security model. An excellent example of this approach is Wormhole.

Here are some of the pros/cons for this approach.


  • Easily Extensible: Like other validator-based models, this approach scores high on extensibility.

  • Can be fast: Again, the protocol can be built using a consensus mechanism/system that allows validators to agree on the validity of messages very fast.


  • Costly: Users need to compensate all the validators in the network, which makes the protocol expensive.

  • Not trust-minimized: The protocol relies on trusting that the validators and whoever controls their permissions are not malicious.

App-sanctioned validator protocols

Unlike the permissionless and permissioned approaches, where all applications share the same set of validators, the app-sanctioned validator approach allows applications to pick their validators. The reasoning behind this approach is that since applications choose their validators, they are less likely to pick malicious entities that could exploit them.

Here are some of the pros/cons for the app-sanctioned validator approach.


  • Easily Extensible: Like other validator-based models, this approach scores high on extensibility.

  • Fast: Applications can improve speed by reducing the number of validators. However, the downside to doing this is that it weakens security further since fewer entities must behave maliciously to compromise an application.

  • Cheap: Similarly, applications can reduce cost by reducing the number of validators.

  • Simplicity: Because the security of the protocol relies on the trustworthiness of the app-selected validators, it becomes easier to implement and manage compared to other approaches


  • Not trust-minimized: security model depends on the trustworthiness of the validators, which is extremely weak. Although validators may not willingly exploit the application, you cannot rule out the possibility of malicious actors using validator keys to exploit the application.

Optimistic Approach

Optimistic messaging protocols are interoperability protocols that rely on off-chain entities who monitor messages being passed across chains to ensure protocol security. Optimistic messaging protocols usually have some entity that passes a message proof to the destination chain. Off-chain entities, usually referred to as disputers or watchers, check the validity of this message proof and dispute it if they deem it invalid. Disputers are compensated for correct disputes and punished for wrong ones.

Here are some of the pros/cons for the optimistic approach.


  • Easily Extensible: Optimistic messaging protocols can be used on any smart contract chain that allows storing and manipulating data.

  • Cheap: They can be cheap since there are not many parties to compensate for delivering the message. The disputers underpinning the network are only rewarded if they identify invalid message proofs. Even in that case, they are typically rewarded from the funds of the person who proposed the invalid message proof.

  • Trust-minimized: If they are designed with permissionless disputers and the right incentives, they are very trust-minimized.


  • Speed: Most implementations are slow since they need to leave some time for watchers to send disputes. However, this speed impact is an implementation detail and not an attribute of the optimistic approach itself. The amount of time the protocol must wait is variable; it depends on a few factors including the amount of value transferred and the level of decentralization on the destination chain, among the validators on the destination chain.


A hybrid messaging protocol is one that combines one of more interoperability approaches to create a more complete messaging protocol. Usually this is used as a way to cover some of the weaknesses of one approach with the strengths of another approach. For example, one can use an optimistic protocol for delivering messages with permissionless disputers, and use an app-sanctioned validator system for delivering message proofs and messages. This would make the protocol cheap, trust-minimized and very extensible, while also being fast.

Last updated