Rough notes #2: Axelar

Axelar Network: Connecting Applications with Blockchain Ecosystems by Sergey Gorbunov and Georgios Vlachos, published in January 2021.

“To enable applications to communicate across blockchain ecosystems frictionlessly, we propose Axelar. Axelar stack provides a decentralized network, protocols, tools, and APIs that allow simple cross-chain communication. Axelar protocol suite consists of cross-border routing and transfer protocols.”

The two questions the authors pose are:

  1. Can we enable application builders to build on the best platform for their needs while still communicating across multiple blockchain ecosystems?
  2. Can we allow users to interact with any application on any blockchain directly from their wallets?

High-level goals:

While multiple interoperability protocols now exist, their adoption is still fairly limited. It’s more or less clear that the future is multichain, but the road ahead is fuzzy. Most ecosystems currently racing towards biggest adoption / market cap and their developers don’t have time for any cross-chain development. As a result, many custom bridges had appeared.

Existing solutions do not scale well (“We have also seen a few other single-purpose bridges by platform developers that rewrite state-transition logic in smart contracts to bridge to other ecosystems [1, 7]. They suffer from multiple scalability issues, do not allow the ecosystem to scale uniformly, and introduce additional dependencies for applications”).

Why just not use IBC?

There’s a claim that IBC requires Tendermint consensus, which is false. Any consensus with finality is supported. IBC does require in-protocol light clients, but so does Axelar (see below). IBC does not provide any high-level application protocols (see below).

General info

At the base layer there’s a dPoS blockchain that is responsible for storing the state of multiple blockchains that the platform is connected to. “Governance rules allow network participants to enact protocol decisions such as which blockchains to bridge and which assets to support.”

“The validators collectively maintain threshold signature accounts on other blockchains (e.g., 80% of validators must approve and co-sign any transaction out of it), which allows them to lock and unlock assets and state across chains and to post state on other blockchains, the “outgoing bridges.”

NOTE that threshold signature bridges can be unsecure, but this is less the case here if the validator set is sufficiently large and decentralized.

“As part of consensus, validators run light-client software of other blockchains, allowing them to verify the state of other blockchains. The validators report these states to the Axelar blockchain, and once enough of them report, the state of Bitcoin, Ethereum, and other chains is recorded on Axelar.”

In the beginning validator generate threshold key for each outgoing bridge. When the validator set changes, the key is regenerated.

“Axelar sets the safety threshold to 90%, meaning that almost all validators will need to collude to withdraw any funds that are locked by its network or forge state proofs”

Network synchrony assumptions

“When connecting chains through Axelar, the connection works assuming the strongest network assumptions out of these chains, which is synchrony in the case of connecting Bitcoin and Cosmos, for instance.”

What if the network stalls or a connected chain breaks?

“To address any potential stall of the Axelar network itself, each threshold bridge account on a blockchain X that the Axelar validators collectively control has an “emergency unlock key””

“If chain X that is connected to Axelar breaks, there are a couple options:

Cross-Chain Gateway Protocol (CGP)

This protocol allows:

The user posts a request q on one of the bridge accounts. Validators who need to validate both chains (what if they don’t?) query the state. Once 2/3+ validators returns the same result, it’s signed and returned to the user.

Transferring is more or less similar (pegged tokens are created for those frozen on a bridge account).

Cross-Chain Transfer Protocol (CTP)

“Applications can leverage cross-chain features by calling CTP queries analogous to HTTP/HTTPS GET/POST methods. These queries are subsequently picked up by CGP layer for execution and results are returned back to the users.


Axelar is a common relay chain to forward messages from one blockchain to another (“decentralized crosschain read/write oracle”) using threshold-signature based bridges and light clients.

The novelty comes from the set of high-level protocols (CGP and CTP) for cross-chain application calls, which is unavailable in the existing protocols (e.g. IBC).

To learn more, you can go to their website. Don’t forget to like this and subscribe. Joking :) I don’t care. I read whitepapers for fun.


comments powered by Disqus