Evaluating Cross-Chain Messaging Protocols

Security and usability are important for cross-chain messaging protocol

There are two main criteria for evaluating cross-chain messaging protocols. These are security and usability.


Regarding interoperability, security means two things. First is the protocol’s ability to prevent the delivery of invalid messages. Second is the protocol’s ability to prevent the censorship of valid messages. Invalid messages are messages that have not originated from a source chain. Valid messages are messages that do originate from a source chain. Due to the prevalence of exploits involving invalid messages, the first seems to get more attention, but protecting against both is critical since either can result in the loss of user funds. Take, for example, Alice is moving funds from Ethereum to Polygon. She deposits her funds to a bridging contract on Ethereum. This contract sends a pay-out message to its sibling contract on Polygon. If that message never arrives or is censored, Alice loses the funds she deposited on Ethereum.

The interoperability space, at the moment, does not have a universally accepted way to measure security. Hence, protocols baselessly claim to be secure one day and get exploited the next. It is a problem for developers since they cannot determine whether a messaging protocol’s security is adequate for their applications. Eventually, they disregard security models and just settle on using the protocol with the biggest brand regardless of whether it is secure.

For the interoperability space to be mature, the process of measuring security must be much more rigorous. There must be a clear and transparent standard for security that can be applied to any protocol in the space. For our evaluation, we use a variant of one proposed by the team at Connext (Link 1, Link 2), and reduce messaging protocol security to three factors: trust minimization, implementation security, and economic security.

Trust Minimization

Trust minimization refers to reducing the number of trust assumptions needed to ensure the delivery of only valid messages. Since the likelihood of an interoperability protocol being exploited increases significantly if any trust assumptions fail, protocols are seen as more secure if they have fewer trust assumptions. This is why trust minimization comes up quite a bit in conversations concerning the security of cross-chain messaging protocols. Furthermore, protocols are seen as more trust-minimized if their trust assumptions rely less on any specific entity behaving honestly. For example, permissionless disputer systems are more trust-minimized than permissionless validator networks. To compromise a permissionless disputer system, every possible participant in the network must be malicious. This reduces the dependence on any one particular entity to maintain security. In contrast, depending on the implementation, a permissionless validator network only requires the corruption of the majority. This places slightly more trust in each network member to maintain security.

Similarly, permissionless validator networks are more trust minimized than permissioned validator networks, i.e., multi-sigs, because they do not require trust in any specific entity, whereas multi-sigs trust a specific preapproved set of validators to maintain security. This relationship extends to interoperability protocols built around these systems. Many exploits in the interoperability space have been due to failed trust assumptions, typically those of multi-sigs. The biggest example is the Ronin hack, which lost almost $540M. It is important to note that trust minimization is a theoretical property of a system. A protocol can be trust-minimized and not secure if it fails in more practical security areas, such as implementation and economic security.

Implementation Security

Implementation Security refers to the robustness of the implementation of a protocol. Regardless of how trust-minimized or economically secure an interoperability protocol is, it is doomed if its implementation is not secure. A perfect demonstration of this is the Nomad bridge hack. Despite being a more trust-minimized and economically secure interoperability protocol than other cross-chain protocols, Nomad got hacked and lost nearly $200M because of a bug in its implementation.

Although imperfect, it’s possible to gauge the robustness of an interoperability protocol’s implementation by considering three things:

  1. the complexity of the implementation,

  2. the quality of audits, and

  3. the amount of time the code has been publicly available.

2 and 3 are obviously not perfect. A protocol can be audited and still have fatal errors. Also, code can be publicly available for years without anyone digging deep enough to find vulnerabilities. Highly effective ways to avoid issues with implementation security are (1) to rely on simple implementations that are easy to audit and reason about, and (2) to rely on built-in security systems, e.g., time delays that allow applications to catch and prevent exploits before they occur.

Economic Security

Economic Security refers to the strength of the economic incentives that discourage off-chain actors from behaving dishonestly. As before, it does not matter how trust-minimized or how secure a protocol is implemented. It is doomed if it has weak economic security. Economic security can be measured by two factors: how much the participants in a network stand to gain by behaving maliciously and the likelihood of them being successful if they behave maliciously.

Within interoperability protocols, those with permissionless disputer systems have the strongest economic security since the likelihood of success for malicious behavior is very low. Unless every disputer is onboard, the chance of success is zero. Furthermore, it is impossible to get all disputers onboard since anyone can be a disputer.

Multisigs have the weakest economic security since the likelihood of success, and economic gain for malicious behavior is high. This makes them very vulnerable to exploits. Most multi-sig-based interoperability protocols attempt to reduce this by relying on some element of social trust. Since people know who the off-chain actors are, they are less likely to behave maliciously. That being said, it still happens sometimes hence the term rug pulling.

Permissionless validator-based systems sit right in between permissionless disputer systems and multi-sigs. Until the amount of money controlled by the protocol exceeds the amount staked by the validators, the protocol is quite secure. But the moment the value on top of the interoperability protocol exceeds the validator stakes, their economic security models collapse.


Usability refers to factors that can promote or hinder a protocol’s usage. Those factors are usually (1) cost, (2) speed, and (3) extensibility for interoperability protocols.


Cost refers to the fee one must pay to send a message from one chain to another. It’s usually split into two parts: (1) the network fee, best described as the cost of sending the message to the entity responsible for delivering it, and (2) the delivery fee, which is the fee paid to the entity to deliver the message. Costly cross-chain messaging protocols score low on usability, so developers and users usually avoid them.


Speed refers to the time it takes for a message to go from one chain to another. Depending on the protocol’s design and the source chain’s time to finality, it could take a few seconds or hours to deliver new messages. An interoperability protocol scores high on usability if it can deliver messages promptly.


Extensibility refers to the ability to support any chain. An interoperability protocol’s design may limit its availability to chains and domains with specific properties and characteristics. For example, IBC works primarily for fast-finality blockchains. Even among fast-finality blockchains, it exhibits its full range of security on Tendermint blockchains. IBC is an example of an interoperability protocol with low extensibility. The extensibility of a cross-chain protocol increases with the number of chains it can support, and so does its usability.

Last updated