Learn about Axelar

Dive into all the components that come together to form the Axelar network, for a high-level understanding of the vision and design; go deeper and gain technical knowledge of specialized functions, including our CLI and SDK.

Gateway smart contracts allow Axelar to communicate messages across all connected chains. For each EVM chain connected to Axelar network, a Gateway contract is deployed to that chain. This Gateway contract is used to pass messages from the Axelar network to the connected chain, and the Gateway contract is controlled by a key, which is held jointly by all the Axelar validators. This is accomplished through a multi-party cryptography scheme, where the key is divided into many pieces, called key shares. Each validator holds many key shares, and the amount of shares is dictated by the amount of staked AXL tokens the validator has. The Gateway can only execute actions on the external chain if the number of validators holding key shares who authorize the action reaches a set threshold.

The Gateway contract is used by Axelar network to execute cross-chain transactions. Transactions must be confirmed by a vote of validators before they are authorized by the Gateway. This allows Axelar to securely mint and burn tokens or approve General Message Passing transactions across all connected chains.

Axelar validators play two main roles in the network.

First, the validators participate in consensus on the Axelar network, producing blocks and validating transactions as with other proof-of-stake chains. Specifically, they perform the generic duties expected from validators of all Cosmos SDK-based chains. For more information about what Cosmos SDK validators do, read the Cosmos SDK validator docs.

Beyond this, Axelar validators also have additional duties as they are responsible for verifying all cross-chain activity being processed by the network. This requires validators to run nodes for Axelar-supported chains, and observe those external chains for activity. For example, in a cross-chain flow moving a message or tokens from chain A to chain B, the user initiates the transaction on chain A’s Axelar Gateway, and waits for the Axelar network to confirm it. This confirmation is done by the validators. A vote is started on the Axelar network, asking each validator to observe their chain A nodes for the transaction made by the user. The validators then cast votes on whether or not the transaction was observed on their chain A node. The votes are tallied and if the number of confirmation votes surpasses a set threshold, the transaction is considered confirmed by the Axelar network.

At this point, Axelar’s multi-party cryptography scheme kicks in. The corresponding command on the destination chain B — such as approving a contract call, or minting and releasing tokens through the Gateway — must be signed and issued to chain B’s Axelar Gateway. Each Gateway contract is controlled by a key that is able to issue commands to the Gateway and approve transactions by signing. Each Axelar validator holds a piece of this key, called a key share. Validators agree through their confirmation votes to confirm the transaction and sign the command that executes it on chain B, which completes the cross-chain transaction. Once enough key shares have agreed, the transaction can proceed.

This same process authenticates any cross-chain activity, whether passing general messages or transferring tokens. As you can see, Axelar validators handle the important task of authenticating cross-chain activity, and authorizing the transfer of messages and funds.

As Axelar grows and connects more and more chains, it becomes increasingly restrictive to require every Axelar validator to run a node for every chain supported by the network. Instead, Axelar validators are incentivized to run nodes for as many supported chains as possible, through increased staking rewards, based on the number of chains they support.

Relayer services are a type of optional convenience services provided by Axelar. These are tasks that can be performed by anyone, and no form of trust is required to authorize or complete the task. These tasks are still important however, as they must be done by someone to enable successful cross-chain communication. Because relayer services do not require any element of trust, and can be implemented by anyone, app developers within the Axelar community can choose to build their own version of existing relayer services for their app to use, instead of using the existing Axelar relayer services.

One example of a relayer service is starting confirmation votes. During a cross-chain transaction moving a message or tokens from chain A to chain B, the user first initiates the transaction on chain A’s Axelar Gateway. Next, Axelar network validators monitor chain A for that transaction, and vote to confirm it. Axelar relayer services are responsible for starting off the vote for the confirmation: they submit a request on the Axelar network for validators to observe chain A for the transaction. Without relayer services, the validators would not know which transactions they should be monitoring.

The gas receiver is an example of Axelar relayer services.

During General Message Passing, a cross-chain smart contract call is approved by Axelar network validators, and the approval is stored in the Axelar Gateway on the destination chain. This transaction is approved and ready to be executed, but it will not be executed immediately. In order to complete the General Message Passing workflow, the executable destination contract needs to be called with the exact parameters approved by the Axelar Gateway, however, this contract call incurs a gas fee that needs to be paid.

Application developers using Axelar for General Message Passing have two options. They can build their own relayer services on the destination chain, which will cover the gas fees required for the final executable smart contract call; or they can pay gas fees with the Axelar Gas Receiver on the source chain.

The Gas Receiver is a smart contract that accepts tokens as payment to cover costs of contract execution for general message passing transactions. First, send funds to the Gas Receiver on the source chain, and specify the general message passing transaction that should be covered, as well as the payment token and amount. Axelar relayer services will confirm the gas payment on the source chain, then automatically execute the smart contract call on the destination chain when it gets approved.

Tech stack diagram & network overview

Read Axelar’s tech stack blog post.

Watch an in-depth tech stack walkthrough video.

Follow a step by step tutorial for building a cross-chain app.

Learn how to add a new EVM chain to the network.

Learn how to build apps with Axelar using the AxelarJS SDK

Learn about how to interact with an Axelar node through a command line interface (CLI).