Overview

Axelar is a permissionless PoS consensus network powered by the $AXL token, connecting 60+ blockchains, spanning consensus methods including Cosmos & EVM. The network enables cross-chain communication and token transfers, making it possible to build interchain applications whose business logic and operations grow beyond a single chain. With Axelar, developers can add interoperability to their apps and make it possible to run complex logic across chains, like automated gas payments & 1-time deposit addresses.

Axelar provides a full-stack decentralized transport layer, allowing seamless connectivity between different blockchain ecosystems, applications, assets, and users. The key components of Axelar include:

• Decentralized Network: Axelar operates as a decentralized network, meaning it is not controlled by any single entity or organization. Instead, it relies on a network of validators and participants who contribute to its security, reliability, and overall functionality.
• Gateway Smart Contracts: Axelar uses a set of gateway smart contracts that serve as the bridge between the Axelar Network and external blockchain chains. These gateway contracts facilitate the secure movement of assets and messages across different blockchains, enabling cross-chain transactions and interactions.
• Software Development Kit (SDK): Axelar provides a comprehensive SDK of protocols and APIs that developers can use to integrate cross-chain capabilities into their applications. This SDK allows developers to build on their preferred blockchain platform while still having access to assets, data, and users on other connected blockchain ecosystems.

Axelar Network

The Axelar network offers a uniform solution to cross-chain communication. Interchain apps built on Axelar are truly permissionless, meaning that their transactions cannot be censored by any oracle, relayer or validator. This is achieved with a decentralized network that bridges blockchain ecosystems speaking different languages, along with a protocol suite that provides APIs for applications to conduct cross-chain requests seamlessly.

Axelar supports two main types of interchain capabilities:

• Send Tokens: Send fungible tokens securely between many Cosmos and EVM Chains, as well as other complex transfers. This can be done in 3 ways:
  • Call the function sendToken from any source chain. This is an API method that allows you to send any token supported directly on the Axelar network to any recipient on a destination chain.
  • Get a deposit address using the Axelar JS SDK.
  • For tokens that are not natively supported, developers can build their own custom Interchain Token. 
• General Message Passing: Call smart contract functions across blockchains. You can compose DeFi functions, move NFTs cross-chain, or perform cross-chain calls of any kind that sync state securely between dApps on various ecosystems.

This is achieved with an architecture that consists of 3 primary components:

• A decentralized network built using Cosmos technologies.
• A set of gateway contracts that provide connectivity between the Axelar network and its interconnected external chains. 
• APIs and SDK for developers to track and manage cross-chain transactions and messages. 

Satellite

Satellite is a web application built on top of the Axelar Network. It provides an easy to use interface which enables users to transfer their crypto assets from one chain to another.

To make asset transfers using Satellite, you need the following prerequisites:

• Desktop browser with the Keplr and MetaMask wallet extensions.
• Funds to cover transaction fees.
  • For transferring assets from an EVM chain (e.g., Ethereum), you will need enough native tokens (e.g., $ETH) in your MetaMask wallet.
  • For transferring assets from a Cosmos-based chain, you will need enough native tokens of that Cosmos-based chain in your Keplr wallet to cover the transaction fees.

There is a fee on all transactions made through the network. The amount of the fee is dependent on the selected source chain, destination chain, and asset. As a user, you will need to ensure there are funds on the source chain (in the form of native tokens) to pay for transaction fees to that chain. 

General Message Passing (GMP)

Axelar’s General Message Passing (GMP) enables developers to achieve complete composability across the Web3 ecosystem by allowing them to call functions on any connected chain, regardless of whether it’s on EVM (Ethereum Virtual Machine) or Cosmos with a deployed Axelar Gateway contract.

Steps involved

• At the source chain:
  • User (dApp) calls a function, either callContract or callContractWithToken, on the Axelar Gateway contract to initiate the GMP call. The function call specifies the target contract on the destination chain and any relevant parameters for the call.
  • Once the GMP call is initiated, the user can track its status either through the Axelar Scan interface at https://axelarscan.io/gmp/[txHash] or programmatically using the AxelarJS SDK.
  • The user prepays the relayer gas fee on the source chain to Axelar’s Gas Services contract to ensure smooth processing of the GMP call.
• At the Axelar network:
  • The GMP call enters the Axelar Gateway from the source chain.
  • The Axelar network confirms the call and converts the pre-paid gas, which is in the source chain’s native token, into the destination chain’s native token. This conversion is necessary to facilitate the execution of the call on the destination chain.
• At the destination chain:
  • The GMP call emerges from the Axelar Gateway on the destination chain.
  • The executor service, which is responsible for handling the execution of GMP calls, relays and executes the approved call to the application’s Axelar Executable interface.
  • The application’s Axelar Executable interface processes the GMP call, executing the desired function on the destination chain’s target contract.

If the gas is insufficient to relay the GMP call to the application interface, monitoring and recovery steps come into play. Axelar has mechanisms to detect such scenarios and take appropriate recovery actions to ensure that the GMP call is successfully processed.

Prerequisites

• Both chain A and chain B must be EVM or Cosmos chains with a deployed Axelar Gateway contract. Axelar is continuously expanding its supported chains and technology stacks.
• The application’s executable contract must be deployed on the destination contract, meaning the contract that the application wants to interact with on the target chain.
• The application must be on one of Axelar’s supported EVM chains. A list of supported EVM chains with deployed Axelar Gateway contracts is available, and new chains are regularly added to this list.

GMP Capabilities

Operational since May 2022, GMP enables cross-chain movement of various payloads, including function calls and logic. It utilizes Axelar’s validator set for security and a decentralized protocol for routing and translation.

• Call a Contract on Chain B from Chain A: GMP allows developers building on chain A to call any function, be it a smart contract at the application layer or a function built at the protocol layer (e.g., in Cosmos), on chain B. This enables seamless interactions and data transfers between different blockchains.
• Call a Contract on Chain B from Chain A and Attach Tokens: GMP also supports attaching tokens to the function call. This means developers can initiate a function call on chain B from chain A and include tokens as part of the interaction. This capability enhances the utility and interoperability of tokens across different chains.

Unlike basic cross-chain bridges, GMP supports the secure transfer of arbitrary data, enabling functionalities like composable liquidity and cross-chain computing.

Gateway Smart Contracts

Axelar’s Cross-chain Gateway Protocol (CGP) mirrors the role of the Internet’s Border Gateway Protocol (BGP), focusing on state synchronization and asset transfers across blockchains.

The Gateway smart contracts play a crucial role in enabling communication and message passing across all the connected chains in the Axelar network. For each EVM chain that is connected to the Axelar network, a specific Gateway contract is deployed to that chain.

Key Features of the Gateway Smart Contracts:

• Controlled by Validators: The Gateway contract is controlled by a key that is jointly held by all the Axelar validators. The validators collectively manage the execution of actions on the external chains through this Gateway contract.
• Multi-Party Cryptography Scheme: The key used to control the Gateway contract is divided into multiple pieces, known as key shares. Each validator holds several key shares, and the number of shares held by a validator is determined by the amount of staked $AXL tokens they have. This multi-party cryptography scheme ensures that no single validator has complete control over the Gateway, enhancing security.
• Threshold Authorization: The Gateway contract enforces a threshold mechanism for executing actions on the connected chains. To authorize an action, a predefined number of validators must provide their key shares to reach the set threshold. This ensures that important actions on the external chains require a consensus among the validators, preventing malicious activities.
• Execution of Cross-Chain Transactions: The primary purpose of the Gateway contract is to execute cross-chain transactions securely. For each cross-chain transaction, the validators must confirm and vote on its validity before the Gateway authorizes its execution. This process allows Axelar to securely mint and burn tokens, or approve General Message Passing (GMP) transactions across all the connected chains.

Cross-chain Message Flow

1. dApp Interaction with Axelar Gateway: A dApp user initiates a cross-chain message by interacting with the Axelar Gateway. The Gateway serves as an Axelar-operated installation on the source chain and contains the necessary functions and logic to initiate and process cross-chain messages.
2. Gateways on Connected Chains: For each chain connected to the Axelar network, a Gateway is deployed. This Gateway is used to receive messages from dApps on connected chains and send them into the Axelar network for routing to other connected chains. The Gateway is controlled by a multi-party cryptography scheme, with key shares held by all Axelar validators.
3. Message Processing and Relayers: Once a Gateway receives a message, it generates an event. Relayer services, provided by Axelar or run by independent entities, observe all connected chains and submit these events to the Axelar network for processing. Relayers help ensure that events happening on supported chains are communicated to the Axelar network.
4. Message Validation: Events submitted by relayers to the Axelar network must go through validation to ensure their correctness and trustworthiness. Axelar validators, who already participate in consensus through proof-of-stake, are incentivized to vote on the legitimacy of cross-chain events. Validators verify the submitted events by running their own nodes for the source chains and checking if the events were observed on their source-chain nodes. Once validated, the events are considered legitimate.
5. Translation to Actions on Destination Chain: After validation, the event is processed by the Axelar network’s consensus protocol and recorded in a block. The cross-chain message is then routed into a queue of messages for the destination chain and is ready to be sent to the Gateway on the destination chain.
6. Execution on Destination Chain: The Gateway on the destination chain processes the cross-chain message and executes the desired action, such as calling a smart contract with the provided data.
7. Cross-Chain Message Completion: The cross-chain message has now been successfully processed and executed, completing the cross-chain functionality for the dApp.
8. Gas Receiver: After the cross-chain payload is approved by the Axelar Gateway contract, it needs to be executed on the destination chain. Execution requires covering the gas fee costs, which can be done through Axelar’s Gas and Executor services. Axelar deploys a smart contract called the Gas Receiver to all connected EVM chains (with General Message Passing for Cosmos chains under development). The Gas Receiver allows users to pay for all transaction fees required for their cross-chain message in a one-time payment on the source chain using the source chain’s native token. The Gas Receiver estimates the total gas cost required across the source chain, Axelar network, and destination chain. It converts source-chain tokens (or any token supported by Axelar) into AXL tokens and destination-chain tokens, along with any other required currencies. This simplifies the user experience as they only need to pay the fees on the source chain.
9. Executor Services: Once the Gas Receiver covers the gas fees, the cross-chain payload can be sent to the destination dApp or contract for execution. The Executor Service is responsible for executing the approved payload on the destination chain, performing the desired function call or token transfer. This service ensures that the payload is executed correctly and securely.

Monitoring and recovery are crucial components of Axelar’s cross-chain communication infrastructure, ensuring that users have a reliable and efficient experience when utilizing cross-chain functionality. 

• Axelarscan Explorer: Axelar offers a General Message Passing tracking tool within the Axelarscan explorer. Users or developers can input their source-chain sender address or transaction hash into the Axelarscan search bar to track their cross-chain message. The tracking tool provides detailed information about the message and its current status. If there are any problems or issues with the transaction, the tracking tool suggests possible fixes to help users resolve the problem. This tool provides transparency and visibility into the progress of cross-chain messages, enabling users to monitor the status of their transactions and take appropriate actions if needed.
• Debugging: In case of issues during the execution of cross-chain messages, Axelar provides debugging tools to help identify and resolve any errors or conflicts. Developers can use these tools to analyze the transaction and identify the root cause of the problem, allowing them to make the necessary adjustments or changes to ensure successful execution.

Decentralized Network and Validators

A core aspect of the Axelar network is its underlying decentralized protocols. Validators collectively maintain the network and run nodes to secure the Axelar blockchain. Users elect validators through a delegation process, with voting power proportional to the stake delegated to them. Validators achieve consensus on the state of multiple blockchains connected to the platform.

The Axelar Network is built using the Cosmos SDK, CometBFT, and CosmWasm.

• The Cosmos SDK is an open-source software development kit (SDK) for building sovereign and public PoS blockchains on a custom application layer
• CometBFT is used to securely replicate that state machine on all nodes in the network. It is an application-agnostic engine, handles the networking and consensus layers through two main components: 
  • A consensus algorithm, i.e. Tendermint
  • A socket protocol, i.e. ABCI (Application Blockchain Interface)
• Tendermint is used to validate requests on the source chain and confirm changes on the destination chain. 
• Tendermint consensus provides instant finality and Byzantine fault tolerance. 
  • While this specific consensus approach only verifies cross-chain communication, Axelar can connect diverse forms of consensus. For example, Axelar is one of a few cross-chain protocols able to connect EVM and Cosmos chains.

Axelar Validators and Protocol Threshold

The Axelar network uses a DPoS (Delegated Proof of Stake) consensus mechanism: validators produce new blocks, participate in multiparty signing, and vote on external chain states. 

In the Axelar network, the set of validators at a particular round, denoted as V_r, consists of individuals responsible for running nodes that adhere to the Axelar protocol. 

Tokenholders stake $AXL by delegating tokens to a validator’s staking pool. Only the top 75 validators are in the active set, a parameter that can be adjusted through on-chain governance. 

Both delegating to validators and running a validator are permissionless.

• Each validator possesses a weight, represented as a number between (0, 1], which signifies their voting power. 
• The sum of weights of all validators always amounts to 1.
• A validator is considered “correct” if they operate a node consistent with the rules of the Axelar protocol.

To finalize blocks or sign cross-chain requests, Axelar requires correct validators with a total weight greater than a specified threshold parameter, denoted as F ∈ [0.5, 1]. The protocol threshold (F) is a crucial parameter that determines the minimum voting power required from correct validators to achieve consensus on critical actions in the network.

Axelar operates in a partially synchronous network, where communication becomes synchronous after GST, with an upper bound ∆. Accordingly, Axelar requires a protocol threshold of F = 2/3 for correct validators to finalize blocks and sign cross-chain requests. This threshold ensures that a significant majority of correct validators must agree on critical actions for the network to function securely.

Validators 

An Axelar network validator participates in block creation, multi-party cryptography protocols, and voting. Axelar validators play two essential roles within the network, ensuring secure and reliable cross-chain communication and transactions:

• Consensus and Block Production: Like validators in other proof-of-stake chains based on the Cosmos SDK, Axelar validators participate in the consensus process and are responsible for producing blocks and validating transactions within the Axelar network. They perform the typical duties expected from validators in any Cosmos SDK-based chain, maintaining the overall security and integrity of the network.
• Verification of Cross-Chain Activity: In addition to their standard validator responsibilities, Axelar validators have an additional crucial duty related to cross-chain activity. They are responsible for verifying and confirming all cross-chain transactions and interactions that are processed by the network.
  • Asset Transfer Flow Verification: For instance, in an asset transfer flow where tokens are moved from chain A to chain B, the user initiates the transfer by depositing tokens to a deposit address on chain A. The validators then observe their respective nodes for this deposit transaction. A vote is started in the Axelar network, where validators cast votes on whether they observed the deposit transaction on their chain A node. If a sufficient number of validators confirm the deposit, it is considered confirmed by the Axelar network.
  • Multi-Party Cryptography Scheme: For transfers to a destination chain B with an Axelar Gateway deployed, the tokens need to be minted by the Gateway smart contract and transferred to the user’s address on chain B. Each Gateway contract is controlled by a multi-party cryptography scheme, where the validators hold key shares. By reaching a threshold of confirmation votes, validators can authorize the transfer of tokens from the Gateway contract to the user’s address on chain B, completing the asset transfer.
  • General Message Passing Verification: The process of verifying and authorizing cross-chain transactions is also applicable to passing general messages through the network.

As the Axelar network grows and connects with more chains, it may become impractical for every validator to run a node for every supported chain. To address this, Axelar incentivizes validators to run nodes for as many supported chains as possible by offering increased staking rewards based on the number of chains they support. This ensures that validators are actively involved in observing and verifying cross-chain activities, ensuring the network’s reliability and security. 

Relayer Services

Relayer services provided by Axelar offer optional convenience and assistance in facilitating cross-chain communication and interactions. These services can be performed by anyone, and no trust is required to authorize or complete the tasks. While Axelar provides these relayer services, they are not mandatory, and app developers within the Axelar community have the flexibility to choose whether to use the existing Axelar relayer services or build their own versions tailored to their specific needs.

One specific example of a relayer service is the initiation of deposit confirmation votes. This is relevant in the context of a cross-chain asset transfer, where tokens are moved from chain A to chain B. The process involves the following steps:

1. Generation of Linked Deposit Address: The user initiates the asset transfer by generating a linked deposit address on chain A and sends the desired number of tokens to this address. This deposit address is essential for the validators to monitor and confirm the deposit transaction.
2. Confirmation Vote Initiation: Axelar network validators play a crucial role in verifying cross-chain activities. They monitor the deposit address on chain A for the deposit transaction made by the user. However, to start the confirmation vote for the deposit, the validators need to know which specific addresses they should be monitoring.
3. Role of Relayer Services: Axelar relayer services take on the task of initiating the confirmation vote for the deposit. After the user generates the linked deposit address on chain A, the relayer services receive this information and submit a request on the Axelar network for validators to monitor the deposit address on chain A for any incoming deposit transaction.

By providing this relayer service, Axelar ensures that the validators are aware of the deposit address they need to observe and vote on for confirmation. Without such relayer services, the validators would not have the necessary information to start the vote, potentially leading to delays or inefficiencies in the cross-chain asset transfer process.

Gas Receiver

The gas receiver is a notable example of Axelar relayer services, offering a convenient solution for covering the gas fees required for executing cross-chain smart contract calls during General Message Passing (GMP) transactions.

During GMP, after the cross-chain smart contract call is approved by Axelar network validators and stored in the Axelar Gateway on the destination chain, the transaction is ready for execution. However, to complete the GMP workflow, the final executable smart contract call on the destination chain requires a gas fee to be paid.

Application developers using Axelar for GMP have two options to handle the gas fee:

• Build Custom Relayer Services: Developers can choose to create their own relayer services on the destination chain, which will cover the gas fees needed for the executable smart contract call.
• Utilize Axelar Gas Receiver: Alternatively, developers can utilize the Axelar Gas Receiver, a smart contract deployed on the source chain, to handle gas fee payments. 
  1. Send Funds to Gas Receiver: The developer sends the necessary funds to the Axelar Gas Receiver on the source chain. This payment covers the costs of contract execution for the GMP transaction.
  2. Specify Transaction Details: Along with the funds, the developer specifies the details of the GMP transaction that the payment should cover. This includes information such as the specific smart contract call to be executed, the payment token to be used, and the amount of tokens to be paid as gas.
  3. Gas Payment Confirmation: Axelar relayer services confirm the gas payment on the source chain.
  4. Automated Execution: Once the smart contract call on the destination chain is approved by the Axelar Gateway, the Axelar relayer services automatically execute the contract call on the destination chain, using the funds received from the Gas Receiver to cover the gas fee.

Blockchain Consensus and Validator Election

Axelar can be built upon a Delegated Proof-of-Stake (DPoS) blockchain with instant finality. In this setup, validators execute Byzantine Fault Tolerant (BFT) consensus during each round (i) to finalize the corresponding block. After finalizing a block, a new round of BFT consensus is initiated to finalize the subsequent block, and the process continues in sequence. 

Validators are elected through a stake delegation process, where users with stake can either become validators themselves or delegate their voting power (stake) to existing validators, who then vote on their behalf. 

The validator set can be updated dynamically, with validators joining or leaving the set and users delegating or undelegating their voting power.

Communication Assumptions

Different blockchains operate under varying network assumptions. These assumptions broadly fall into three categories:

• Synchronous Communication: Messages are delivered with a fixed upper bound ∆, where ∆ is a known time taken for message delivery. This assumption is the strongest and most restrictive.
• Asynchronous Communication: Messages may take an arbitrarily long time to be delivered. Asynchronous networks lack a fixed time limit for message delivery and do not allow for BFT protocols.
• Partially Synchronous Communication: Also known as realistic compromise, the network may behave asynchronously until an unknown global stabilization time (GST). After GST, communication becomes synchronous with a known upper bound ∆.

When connecting different blockchains through Axelar, the network assumes the strongest network assumption among the interconnected chains. For instance, if connecting Bitcoin and Cosmos, which both assume synchrony, Axelar will operate under the assumption of synchrony. 

However, the Axelar blockchain itself functions under partial synchrony and thus requires F = 2/3 as the protocol threshold. By assuming that other existing blockchains are secure and leveraging their security, Axelar can enhance its threshold requirements and overall security.

Governance and DPoS

The network’s governance rules empower participants to make decisions on protocol matters, such as bridging blockchains and supporting specific assets. Axelar follows a Delegated Proof-of-Stake (DPoS) model similar to the Cosmos Hub. 

Validators must bond their stake to participate in consensus and provide high-quality service. This model enables a large decentralized validator set with robust incentives to ensure responsible maintenance of bridges and cryptographic threshold schemes.

Cross-Chain Read/Write Oracle

Axelar functions as a decentralized cross-chain read/write oracle. Validators maintain threshold signature accounts on other blockchains, allowing them to lock and unlock assets and state across chains. 

Validators also post state information on other blockchains, establishing “outgoing bridges.” The network becomes aware of the state of external blockchains at any given time, creating “incoming bridges” from other blockchains.

Axelar Virtual Machine

The Axelar Virtual Machine (AVM) is the component that expands Axelar’s capabilities from a focus on bridging and message passing to providing a fully programmable cross-chain layer. 

• Cross-chain smart contracts: AVM allows developers to deploy smart contracts on Axelar, facilitating the creation of cross-chain developer tooling. These smart contracts are instrumental in simplifying user experiences by managing complex cross-chain tasks, such as token conversions.
• Language flexibility: The AVM supports contracts written in any language that can compile to WebAssembly (Wasm), offering developers a wide range of programming options.

The AVM is expected to be a pivotal component in the economics of Axelar’s native token, $AXL. This integration is particularly relevant in the context of scaling the network amid the growing number of Ethereum-based Layer 2 (L2) blockchains.

The initial product developed on the AVM is the Interchain Token Service (ITS), a system that is designed to maintain the fungibility and unique features of native tokens across multiple blockchains. This service facilitates the creation of ‘Interchain Tokens’. 

Interchain Token Service – ITS

The Interchain Token Service (ITS) is a product suite introduced by Axelar to support the creation of Interchain Tokens that maintain cross-chain fungibility and custom functionality. 

• Supports canonical wrappers and standardized tokens, enabling straightforward, one-click deployments across various chains.
• Provides native support for arbitrary data and fast-finality gadgets.
• Allows the deployment of Interchain Tokens on multiple chains simultaneously.
• Interchain Tokens leverage the security protocols of the Axelar network and are compatible with any chain connected to Axelar.

Currently, assets are being bridged between different blockchains, and developers are deploying applications across multiple chains. However, traditional bridged tokens often lose their fungibility and custom features when moved between chains, and it can be costly to mint tokens on multiple chains separately.

There are two major components involved: 

• Interchain Amplifier: Set to enable developers to connect new blockchains to the Axelar network without requiring permission. Especially beneficial for new ecosystems, such as modular blockchains built on Ethereum, and dApps seeking to tailor cross-chain interactions.
• Interchain Maestro: Comparable to Kubernetes in its functionality. Provides a suite of orchestration contracts and templates aimed at aiding in the design, deployment, and management of dApps across multiple chains.

ITS addresses these challenges by providing a solution that extends tokens cross-chain while preserving their native qualities. With ITS, teams can easily manage token supply and features by creating Interchain Tokens. These tokens retain their fungibility even when moved between different chains, meaning that wrapped versions of the same token on different chains are fungible with each other.

Interchain tokens are ERC-20 contracts that can be transferred between blockchains. 

Moreover, Interchain Tokens maintain their custom features across various blockchains, allowing developers to deploy tokens with specialized functionality and capabilities that are accessible and usable on different chains.

• Flow Rate Management: With the TokenManager, Interchain Tokens can have an Operator that has the authority to manage the flow rates of tokens between different chains. The Operator can use the setFlowLimit function on the Interchain Token Service to control how many tokens can be transferred between chains over a specific time period. This feature provides a level of control and flexibility in managing token flows to suit the needs of different applications and use cases.

The token manager is a contract created by the Interchain Token Service that is capable of locking and releasing tokens, or minting and burning them, depending on its type.

The operator is a role for a tokenManager who can set the flowLimit of the token manager to limit the influx/outflux of tokens.

• Executable Tokens: Interchain Tokens can be made executable, meaning they can be included in standard GMP (General Message Passing) messages. This allows for seamless integration with other smart contracts and applications on the blockchain. By making tokens executable, they can participate in complex interactions and transactions, opening up a wide range of possibilities for building decentralized applications that leverage the power of Interchain Tokens.

By combining flow rate management with executability, Interchain Tokens become even more versatile and interactive. They can be dynamically adjusted in their movement between chains and seamlessly participate in various decentralized processes, making them an efficient and powerful tool for applications that require cross-chain functionality.

ITS achieves this with low overhead by leveraging smart contracts and developer tools that automate complex tasks. This automation streamlines the process of creating and managing Interchain Tokens, making it easier for developers to implement cross-chain functionality without sacrificing token features or incurring significant additional costs.

• How to create new Interchain tokens:  https://docs.axelar.dev/dev/send-tokens/interchain-tokens#new-interchain-tokens 
• How to upgrade existing tokens (to make them Interchain tokens): https://docs.axelar.dev/dev/send-tokens/interchain-tokens#making-existing-tokens-interchain 

Existing tokens can be turned into Interchain Tokens by deploying Token Managers, which can implement either a lock/release or mint/burn mechanism. 

Interchain Token Types

• Standardized: A minimal ERC-20, that implements the IInterchainToken and IStandardizedToken interfaces and can be deployed by the service.
• Custom: A custom ERC-20 that can have any features of functionality implemented by the developer. It can optionally implement the IInterchainToken interface to transfer methods directly on the token.
• Canonical: A canonical token is an interchain token built from an existing token that is available on multiple chains.
  • The token deployed to other chains will be a Standardized token. 
  • There can only be one canonical token for every ERC-20.
• Lock/release mechanism:
  • Incoming token transfers will result in the local releasing of locked tokens.
  • Outgoing token transfers will result in the local locking of tokens on this blockchain by the Token Manager.
• Mint/burn mechanism:
  • Incoming token transfers will result in the local minting of new tokens on this blockchain by the Token Manager.
  • Outgoing token transfers will result in the local burning of received tokens

Example use cases of Interchain Tokens

• New sources of liquidity: Interchain Tokens enable free movement of assets across multiple blockchains. By consolidating liquidity resources, DeFi platforms can benefit from larger position sizes across all trading pairs, reducing liquidity fragmentation and streamlining the trading process. This improved liquidity allows users to trade seamlessly with various assets, respond swiftly to market fluctuations, and enhances the overall trading experience and market efficiency.
• Simplified yield farming and staking: Yield farming and staking are popular ways to earn returns in DeFi. Interchain Tokens streamline these practices across multiple blockchains, enabling users to maximize returns without the complexities of understanding different networks. 
• Chain-agnostic wallets: Interchain Tokens may lead to the creation of chain-agnostic wallets. These wallets can consolidate a user’s assets from multiple chains into a single view, simplifying portfolio management. 
• Cross-chain collateralization: Interchain Tokens can be used as collateral in DeFi applications across various blockchains. This cross-chain collateralization opens up new lending and borrowing opportunities, as assets can be used as collateral on different chains. 

Technical Requirements

Creating an open cross-chain network like Axelar requires addressing several technical requirements to ensure security, participation, and seamless communication between validators.

• Open Membership: Axelar aims to be an inclusive network, allowing any user to become a validator as long as they follow the network’s rules and requirements.
• Updates to Membership: As validators join or leave the network, the protocol must handle updates to the validator set effectively and revoke access when a validator leaves the system honestly.
• Incentives and Slashing: To maintain network security, the protocol should be able to identify and penalize malicious validators through mechanisms such as slashing rules.
• Consensus: The cross-chain network requires broadcast and point-to-point private channels for message propagation among validators. Additionally, consensus is needed to agree on the latest state of threshold schemes, which often involve multiple rounds of interaction.
• Key-Management: Validators in Axelar must carefully manage their threshold shares to maintain security. This involves proper key rotation, secure storage, and dividing keys between online and offline parts

Axelar adopts the Delegated Proof-of-Stake (DPoS) model, where the community elects a set of validators responsible for running the consensus. To incorporate threshold signatures into this model, three fundamental functions are performed collectively by validators:

• Threshold Key Generation: Validators initiate a stateful threshold key generation protocol. Each validator participates in this interactive protocol, propagating messages, and executing state transition functions to generate a threshold public key on the Axelar chain.
• Threshold Signing: Signing requests, such as withdrawals from chains, follow similar interactive protocols. Validators process these requests, and state transition between rounds is based on messages propagated via the Axelar blockchain view and local memory.
• Handling Validator Membership Changes: Validators need to be rotated periodically to accommodate new stakeholders. This is done by updating the threshold key to be shared across the new set. Validators are rotated every T blocks to prevent frequent updates and maintain stability.

To ensure that threshold key generation and signing processes are not hindered by validator rotation, Axelar requests that signatures be produced before the next round starts. Validators only proceed to the next round after seeing relevant certificates and signatures for key generation/signing requests from the previous round. To avoid issues with key generation or signing during validator set updates, Axelar does not issue threshold requests during specific rounds.

Technology Stack

Axelar’s fundamental concepts revolve around its permissionless PoS consensus mechanism and cross-chain communication protocol. The network’s architecture allows it to facilitate secure and trustless interoperability between diverse blockchain platforms, enhancing scalability and facilitating interchain transactions.

The Axelar stack encompasses a comprehensive set of protocols, tools, and APIs, empowering applications to communicate effortlessly across different blockchain ecosystems. Key components of the Axelar protocol suite include cross-border routing and transfer protocols, ensuring smooth data exchange between blockchains. The foundation of the network lies in a decentralized open network of validators, enabling widespread participation and accessibility.

To uphold the highest standards of security and performance, Axelar employs Byzantine consensus, cryptographic techniques, and incentive mechanisms. These measures are specifically tailored to meet the safety and liveness requirements essential for cross-chain communication, where unique challenges arise in handling diverse cross-chain requests.

The network relies on validators, collectively running a byzantine consensus protocol and facilitating cross-chain requests. The underlying network is designed to meet the high safety and liveness requirements necessary for cross-chain communication. There are two core protocols at the center of the network.

• Cross-Chain Gateway Protocol (CGP): 
  • Analogous to the Border Gateway Protocol (BGP) on the Internet.
  • CGP connects multiple autonomous blockchain ecosystems and is responsible for routing across them. 
  • CGP enables blockchain platforms to be seamlessly plugged into the global network without necessitating custom changes to their respective chains.
  • This protocol enables seamless connectivity between existing standalone blockchains, such as Bitcoin, Stellar, Terra, Algorand, and interoperability hubs like Cosmos, Avalanche, Ethereum, and Polkadot.

• Cross-Chain Transfer Protocol (CTP): 
  • Analogous to application-level protocols like File Transfer Protocol (FTP) and Hypertext Transfer Protocols (HTTP) on the Internet.
  • CTP is an application-level protocol stack that sits on top of routing protocols (such as CGP). Application developers can utilize the CTP protocol to enable cross-chain requests in their decentralized applications (dApps). 
  • Users can interact with applications on any blockchain via simple API calls, akin to HTTP GET/POST requests. 
  • CTP empowers developers to perform various cross-chain operations, such as locking, unlocking, and transferring assets across different blockchain platforms, executing cross-chain application triggers, and facilitating general cross-chain requests between dApps across various chains. 
  • As a protocol, CTP promotes the composability of programs across different blockchain ecosystems.
  • This protocol facilitates cross-chain communication for applications, enabling them to access global liquidity and communicate with the entire ecosystem using a straightforward API.

Cross-chain Gateway Protocol (CGP)

The Cross-Chain Gateway Protocol (CGP) in Axelar enables state synchronization and asset transfer between different blockchains. The protocol involves the creation of threshold accounts on each chain that control the flow of value and information across the interconnected chains.

Accounts on other chains

• For non-smart contract chains like Bitcoin, Axelar validators create a threshold ECDSA key that controls an ECDSA account on Bitcoin. This key acts as the destination address where users can send deposits.
• For chains that support smart contracts (denoted as SC), the validators create a threshold ECDSA or ED25519 key (depending on the supported key type) known as PKAxelar. This key controls a smart contract account (SCAxelar) on chain SC. The PKAxelar can be queried by any application on SC, allowing it to recognize messages signed by SKAxelar. The protocol also accounts for rotating values of PKAxelar, which are updated over time.

State synchronization

State synchronization involves posting information about the state of a source blockchain S into the state of a destination blockchain D. 

1. The user posts a request (qS) on one of the bridge accounts (or directly to the Axelar blockchain), demanding information about the state of chain S.
2. Axelar validators, who run node software for both chains S and D, query the API of their chain S node software to find the correct answer (aS) to the user’s query.
3. Once > F weighted validators reach a consensus on the answer aS, they are asked to sign it using threshold cryptography.
4. The signature of aS is included in block R + 11 of the Axelar blockchain.
5. Anyone can take the signed value aS from block R + 11 and post it to chain D.
6. Applications on chain D can retrieve the signed value aS, query DAxelar for the latest PKAxelar, and verify that the signature of aS corresponds to PKAxelar.

Cross-chain asset transfers

Cross-chain asset transfer in Axelar allows users to exchange digital assets between different blockchains. This is achieved by extending the protocol’s state synchronization workflow.

Transfer from Source Chain S to Destination Chain D:

1. The user initiates a transfer request (x, wD) by posting it to the threshold bridge account. The request is routed to the Axelar network.
2. Axelar validators use threshold cryptography to create a fresh deposit address (dS) on chain S. The address is posted on the Axelar blockchain.
3. The user learns about the deposit address (dS) by monitoring the Axelar blockchain and sends x amount of S-tokens to address dS via an ordinary transaction (txS) on chain S.
4. The transaction (txS) is posted on Axelar. Validators query their chain S node software to verify the existence of txS and report the result to the Axelar chain.
5. Once a threshold number of validators (> F) confirm the existence of txS at a specific round R, Axelar requests validators to collectively sign a transaction (aD) that sends x amount of pegged-S tokens from DAxelar to the destination address (wD).
6. Validators use threshold cryptography to sign aD, and the signature is included in block R + 11 on the Axelar blockchain.
7. The signed transaction aD can be taken by anyone and posted on chain D to complete the transfer. The assets are then available at the destination address (wD).

Redeem from Destination Chain D to Source Chain S:

1. The user initiates a transfer request (x0, wS) by depositing x0 amount of wrapped-S tokens into a contract (cD) on chain D.
2. The request (x0, wS) is posted on Axelar. Validators query their chain D node software to verify the existence of the request (x0, wS) and report the result to the Axelar chain.
3. Once > F weighted validators confirm the existence of the request (x0, wS) at round R, Axelar requests validators to sign a transaction (aS) that sends x0 amount of S tokens from SAxelar to the destination address (wS).
4. Validators use threshold cryptography to sign aS, and the signature is included in block R + 11 on the Axelar blockchain.
5. The signed transaction aS can be taken by anyone and posted on chain S to complete the redemption. The assets are then available at the destination address (wS).

By following this protocol, cross-chain asset transfers are achieved in a secure and atomic manner. The requests are processed on multiple chains or none at all, ensuring consistency and reliability in the transfer process.

Additionally, timeout events may trigger refund events to refund assets back to the original user in case of failures or delays in the transfer process.

Cross-Chain Transfer Protocol (CTP)

Cross-Chain Transfer Protocol (CTP) is an application-level protocol that simplifies the integration of cross-chain features into applications, particularly those in the decentralized finance (DeFi) space. CTP allows developers to host their applications on any blockchain and interact with other blockchains through threshold bridge accounts.

1. CTP Queries: Application developers host their DeFi applications on a specific blockchain, let’s say chain A. They integrate their smart contracts with threshold bridge accounts to enable cross-chain features. The bridge contract allows the application to register other blockchains it wants to communicate with and assets it wants to leverage.
2. Threshold Bridge Accounts: Suppose a popular DeFi application that resides natively on chain A and registers with a threshold bridge account. The Axelar validators collectively manage the threshold bridge contract on the corresponding chain.
3. User Deposit Request: When a user wants to submit a deposit into a trading pair between assets X and Y, which reside on different chains (A and B, respectively), the request is routed via the threshold bridge account to the Axelar network for processing.
4. Generating Deposits Key: Axelar network, through the use of threshold cryptography and consensus, generates a deposits key for the user on chains A and B. The associated public keys are returned to the application, allowing the user to use their preferred wallet to submit the deposits. The corresponding secret key is shared across all Axelar validators.
5. Confirmation and Updating Cross-Chain Directory: Once the deposits are confirmed, Axelar updates its cross-chain directory to record that the user on chains A and B has deposited the assets.
6. Multi-Party Protocols: Axelar validators execute multi-party protocols to generate a threshold signature that allows updating the threshold bridge account on chain A, where the DeFi application resides.
7. Execution of CTP Query: The CTP query is returned to the DeFi application smart contracts, which can then update its state, exchange rates, execute yield formulas, or perform other application-related actions based on the cross-chain deposit

Throughout this process, the Axelar network acts as a decentralized cross-chain read/write oracle, and the Cross-Chain Gateway Protocol (CGP) functions as the routing layer between different chains, with the Cross-Chain Transfer Protocol (CTP) providing the application-level protocol for easy integration.

Additionally, CTP supports other cross-chain requests, including Public Key Name Services (PKNS) for mapping public keys to identifiable names, cross-chain application triggers, and smart contract composability, where contracts on one chain can update their state based on the state of contracts on another chain or trigger actions on a different chain.

Why the Project was Created

Blockchain technology is rapidly gaining popularity and attracting a diverse range of use cases, from asset tokenization to decentralized finance and other distributed applications. Various blockchain platforms, such as Ethereum, Solana, Cardano, Cosmos, Avalanche, Fantom, Aptos, Sui, Monero and Polkadot, offer distinct features and development environments, making them attractive to different applications and end-users. However, these useful features are often limited to only a small fraction of the overall ecosystem, typically restricted to holders of the native token on each platform.

The idea of Axelar was conceptualized in 2020, with the project being built using Cosmos technology to provide interoperability with Ethereum and other networks, being more than just an interoperability hub for Cosmos chains. 

The primary motivation behind creating Axelar lies in addressing the challenges of interoperability and scalability faced by the blockchain ecosystem. By providing a seamless way for blockchains to communicate and share data, Axelar aims to foster innovation and unlock the potential of cross-chain applications. The ultimate goal is to enable frictionless cross-chain communication across blockchain ecosystems. 

The challenges of fragmentation in the blockchain space have been a persistent obstacle to achieving interoperability and seamless communication between different networks. Axelar’s technology offers a solution to this problem by providing full-stack interoperability that goes beyond simple asset transfers. This encompasses bridging any information or asset, as well as supporting permissionless overlay programmability, smart contract execution, and decentralized application (dApp) use across multiple networks. With this full-stack approach, Axelar aims to reduce friction and create a seamless experience for users across ecosystems and sovereign networks.

As more and more chains enter the market the lack of seamless communication between these ecosystems poses a significant challenge to the interoperability and scalability of decentralized applications. Ultimately, Axelar seeks to bridge the gap between fragmented blockchain ecosystems, fostering a cohesive and interconnected blockchain ecosystem.

Sector Outlook

Axelar is an overlay network for blockchains, offering a range of functionalities for protocols to enhance their cross-chain capabilities. 

• Axelar’s role in the crypto space is analogous to the function of protocols like BGP and HTTP in the internet infrastructure.
• Similar to how Akamai and Cloudflare operate as overlay networks on the internet, Axelar provides enriched services atop existing blockchain networks.

As a result, Axelar operates in the market sector of blockchain interoperability and cross-chain communications. Cross-chain function calls offer several advantages over traditional asset bridging in the blockchain infrastructure:

• Efficiency: Cross-chain function calls can be more efficient in terms of data transfer. Instead of moving entire assets and their metadata across chains, only the necessary instructions and data for the specific function call are sent, resulting in smaller messages. This can lead to faster and more cost-effective transactions.
• Cost: Smaller messages in cross-chain function calls result in lower gas costs for users. Gas fees are a significant consideration in blockchain transactions, and reducing the amount of data transferred can help save on fees.
• Minimizing fragmentation: Keeping assets, such as NFT collections, on a single chain makes it easier to trace their provenance and state. When assets are bridged across multiple chains, it can become more challenging to track and audit them, requiring tools that work across chains. Cross-chain function calls enable actions to be performed on the original chain without the need to bridge assets, reducing fragmentation.
• Simple user experiences: Cross-chain function calls streamline the user experience by allowing users to perform multiple actions with a single transaction on the source chain. Instead of bridging assets and executing separate transactions on the destination chain, users can combine all their intents into one transaction, simplifying the process for users and reducing interaction complexity.

Axelar opens up new possibilities for decentralized applications and enables seamless cross-chain communication without the need for complex asset bridging mechanisms.

Blockchains are expanding in number and diversity, especially as more L2s and appchains start coming out. This is where Axelar will play a critical role to offer a cost-effective solution for protocols to span across multiple chains. 

With the Axelar APIs and SDKs developers can enable cross-chain functionality in an easy way.  

Existing interoperability solutions

Interoperability across blockchains has been a critical challenge in the industry, and several attempts have been made to address it. Existing solutions can be classified into four categories: centralized systems, interoperability hubs, pairwise bridges, and other single-purpose bridges. However, each of these approaches faces limitations, hindering their ability to provide scalable and robust interoperability solutions. Other attempts to tackle interoperability include federated oracles and application-specific interoperable blockchains. However, these solutions also have their limitations and do not provide a comprehensive and scalable interoperability solution.

Centralized Systems

Centralized exchanges have been the primary means of achieving interoperability so far. While they offer scalability and the ability to list any asset or onboard any platform relatively easily, they suffer from significant security issues and lack the necessary robustness, transparency, and open governance required for the emerging decentralized financial system. Centralized solutions are insufficient to power the growth of decentralized applications in the ecosystem.

Interoperability Hubs

Projects like Cosmos, Polkadot, and Avalanche attempt to address interoperability within their ecosystems by using custom inter-chain communication protocols. For instance, Cosmos allows the creation of sidechains (Cosmos Zones) that can communicate with the Cosmos Hub. However, connections to other blockchains and ecosystems speaking different protocols require external technologies. This approach can lead to complexity and limitations when dealing with multiple ecosystems.

Pairwise bridges

Wrapped assets have been introduced to address cross-chain interoperability gaps. These solutions involve custom protocols where smart contracts and collateral are used to secure transfers. However, building bridges for each chain pair requires substantial engineering efforts. Additionally, these bridges may not scale well when one of the underlying blockchains undergoes consensus rule or transaction format upgrades, as all dependent smart contracts would also need to be upgraded. Furthermore, setting up validators and overcollateralizing assets for transfers can limit capital efficiency.

Single-purpose bridges

Some L1 developers have attempted to create single-purpose bridges by rewriting state-transition logic in smart contracts to connect to other ecosystems. However, these bridges suffer from scalability issues and introduce dependencies for applications. Upgrading one platform or bridge may lead to gridlock (network congestion), making it difficult to achieve widespread scalability. Moreover, a sequence of single-purpose bridges does not guarantee seamless communication between applications across different ecosystems.

Competitive Landscape

In the landscape of blockchain interoperability solutions, Axelar distinguishes itself through its full-stack interoperability approach, which includes bridging any information or asset, supporting arbitrary data through General Message Passing (GMP), and enabling permissionless overlay message passing with programmability. 

On the one hand, LayerZero’s methodology relies on a combination of oracles and relayers operating under a 2-of-2 multisig system. It offers customizable configurations, but the decentralization level depends on the specific implementation. As a result, more trust is placed in the standard configurations of oracles and relayers compared to individual Axelar validators.

• Axelar employs a more decentralized validator set to secure interchain messages, as opposed to LayerZero’s reliance on oracles and relayers.
• Axelar requires a two-thirds voting majority for message verification, presenting a more robust security model.

On the other hand, Chainlink’s CCIP depends on a multisig for message verification and ordering. Chainlink oracles are permissionless to run but permissioned for data inclusion in price feeds.

• Axelar’s permissionless validator set stands in contrast to Chainlink’s model, where validators serve all roles without separation (unlike Chainlink’s distinct node roles).
• Axelar’s model might offer a broader and more decentralized approach to cross-chain communication.

All things considered, Axelar’s unique proposition comes from:

• Validator Set Flexibility: Axelar validators can choose which chains they support, allowing for a more diverse and ideologically varied validator set.
• Security Model: Axelar’s model, which does not enforce validation from the entire set, could lead to increased participation and scalability, as it accommodates validators with different priorities and agendas.
• Number of Validators: With 75 validators (and more will be added over), Axelar boasts a larger validator set than most other cross-chain networks, enhancing its security and decentralization.

It is also worth noting that LayerZero has undergone a large upgrade in v2, decoupling liveness from execution and no longer relying on the orchestration of two off-chain components. For instance, in this setup, Axelar could be used as a DVN (Decentralized Verifier Network) in LayerZero v2, verifying the integrity of data transmitted across the network. 

We can also classify Axelar alongside LayerZero and Wormhole as the most notable cross-chain AMP (Arbitrary Message Passing) solutions. They are all interoperability solutions that allow for any piece of data, including tokens, the state of a chain, a contract call, an NFT, or governance votes, to be moved from chain A to chain B. This implies that the interchain transactions that they facilitate are authenticated by third parties who are not part of the involved chains. 

What makes each AMP solution different from each other is their external verification approach or trust mechanisms. For instance, in the case of LayerZero a message is deemed valid when both oracles and relayers concur on its accuracy. Similarly, Wormhole uses a PoA (Proof of Authority) model where its security hinges on a validator set of “Guardians” that observe messages and sign the corresponding payloads. 

Unlike LayerZero and Wormhole, Axelar operates on a Delegated Proof Stake mechanism with the Cosmos SDK, using crypto-economic guarantees for security through a validator set coordinated via Tendermint. This way, validators are incentivized with staking rewards, facing penalties for dishonest behavior or downtime. Therefore, the protocol’s reliability relies on the financial commitment and stake of validators. 

Axelar tries to differentiate itself by supporting interchain applications that are designed to operate seamlessly across multiple chains. Examples of this include Sommelier or Ojo, a multi-chain yield vault and oracle network respectively.

How to Achieve Scalable Cross-chain Communication

Cross-chain communication, at its core, requires heterogeneous networks to find a common language to interact seamlessly. This requires the following high-level properties:

• “Plug-and-play” Integration: The protocol suite should enable blockchain platform builders to integrate cross-chain communication without extensive engineering or custom language integration. It should support frictionless plug-in for any existing or new blockchain, allowing for the addition of new assets with minimal effort.
• Cross-Chain Routing: Similar to how BGP and other routing protocols facilitate network address discovery and routing paths on the Internet, cross-chain communication necessitates the discovery of addresses, applications, and routing paths across different blockchain ecosystems.
• Upgradability Support: If one blockchain ecosystem undergoes changes or upgrades, it should not affect the interoperability of other blockchains. The system must recognize and accommodate these updates with minimal effort, avoiding the need to rewrite state transition logic and ensuring applications do not break.
• Uniform Language for Applications: Applications require a straightforward protocol to lock, unlock, transfer, and communicate with other applications, regardless of the blockchain they reside on. This protocol should be chain-agnostic, supporting simple calls analogous to HTTP/HTTPS protocols for web-server communication. As more networks and assets join the lower-level routing protocols, applications should be able to utilize them without rewriting their software stacks.

In addition to the high-level properties outlined above, the underlying protocol suite must also meet critical security requirements:

• Decentralized Trust: The network and protocols must be decentralized and open, allowing fair participation for everyone.
• High Safety: The system must ensure high safety guarantees to protect assets and state as the cross-chain network processes transactions.
• High Liveness: The system should meet high liveness guarantees to support applications that leverage its cross-chain features effectively.

Meeting a subset of these properties may be straightforward, but achieving a comprehensive solution requires careful consideration of a combination of consensus, cryptographic, and mechanism design protocols. Although some solutions exist, such as federated multisig accounts, they are inherently vulnerable to collusion and censorship attacks and lack the proper incentives to protect the system

Potential Adoption – Cross-chain DeFi

Axelar is for Web3 what Stripe is for mobile and internet applications: it works on the back end, connecting various networks into one-click experiences for all users. As blockchain adoption continues to grow, the demand for interconnected solutions is on the rise. Axelar’s technology has the potential to attract developers seeking to build complex and scalable decentralized applications across different blockchains.

By allowing application developers to add interoperability to their dApps, Axelar helps to make the onboarding of users a lot easier, since users can now get onboard from any ecosystem.  An Axelar integration means that developers can build using functions across any chain.

Axelar’s cross-chain capabilities enable different blockchain networks to communicate seamlessly with each other. This unlocks several prominent use cases and benefits for users and developers in the DeFi space:

• Expanded user base: With blockchain interoperability, DeFi platforms can create financial products and services that were previously not possible on a single blockchain network. This expansion will attract a larger user base, making DeFi more accessible and inclusive.
• Increased liquidity: Cross-chain capabilities allow DeFi applications to communicate with each other across different blockchain networks. This aggregation of liquidity creates a more efficient marketplace, reducing the spread between bid and ask prices, and providing users with more favorable rates for transactions.
• Reduced transaction fees: Cross-chain DeFi enables users to choose the most cost-effective blockchain network for their transactions, reducing transaction fees and avoiding congestion during periods of high network activity.
• Increased accessibility: Users can seamlessly access DeFi platforms irrespective of the blockchain they are on, allowing them to access a broader range of financial products and services.
• Decentralization for better security: Cross-chain interoperability contributes to a more decentralized and secure DeFi ecosystem by eliminating single points of failure and making networks less susceptible to attacks.

Axelar’s General Message Passing (GMP) is a key feature that sets it apart from other interoperability protocols. GMP allows developers to call any function on any connected chain, enabling seamless cross-chain transfers of assets, data, and function calls. With GMP, developers can connect their platforms to multiple other blockchains and create a cross-chain experience, while users can interact with any application and asset across the ecosystem directly from their wallets.

Axelar currently supports more than 60 blockchains, including popular networks like Binance, Ethereum, Fantom, Moonbeam, and Polygon, with plans to integrate more in the future. With Axelar’s cross-chain capabilities, DeFi is expected to witness significant growth and innovation, offering users a more accessible, efficient, and secure decentralized financial ecosystem.

Chains

Axelar connects 64 chains enabling a true cross-chain experience for users. Inside those chains Axelar supports a variety of activities that include cross-chain swaps, universal lending, and cross-chain governance. Axelar’s mission is to support as many chains as possible and connect the whole Web3 ecosystem. 

Using the Protocol

As a network, Axelar embraces openness and community participation. Its governance model is inclusive, allowing developers to propose new integration points, routing mechanisms, and application-level protocols. Users can decide whether to adopt these proposals through voting, and validators will implement approved changes.

The Axelar network offers numerous advantages for multiple audiences:

• For blockchain platform builders: The ability to effortlessly connect their blockchains to all other blockchain ecosystems, requiring only the setup of a threshold account on their chain to plug into the network.
• For dApp builders: Application developers can host their dApps anywhere, facilitating asset locking, unlocking, transfers, and communication with applications on any other chain via the CTP API.
• For users: A seamless experience where users can directly interact with applications across the entire ecosystem from their wallets.

How Axelar Works – Transaction Lifecycle

The Axelar Network operates with two functional layers, the Core Infrastructure Layer and the Application Development Layer.

Core infrastructure layer

The Core Infrastructure Layer is the foundational component of the Axelar Network and plays a critical role in enabling cross-chain communication and interoperability. It consists of the following key elements:

• Axelar Network: The Axelar Network itself serves as the core infrastructure layer. It is a decentralized network of nodes (validators) that facilitate cross-chain transactions and ensure the security and reliability of the entire ecosystem.
• Validators: Validators are responsible for validating and executing transactions on the Axelar Network. They play a crucial role in maintaining the operations of the network and ensuring consensus among different nodes. Validators participate in voting processes to confirm transactions and cross-chain actions.
• Gateways: Gateways are smart contracts that act as bridges between the Axelar Network and other blockchain networks. These smart contracts facilitate the seamless transfer of assets and data across different chains. Gateways play a vital role in enabling cross-chain functionality within the Axelar ecosystem.
• Consensus Mechanism: The core infrastructure layer relies on a decentralized proof-of-stake (PoS) consensus mechanism. Validators, through their stake in the network, participate in consensus and decision-making processes. PoS consensus ensures that the network remains secure, efficient, and resilient to attacks.
• Multi-Chain Interoperability: The core infrastructure layer is designed to achieve multi-chain interoperability. It allows the Axelar Network to connect with various blockchain ecosystems, enabling users and applications to interact with assets and data seamlessly across different chains.
• Transaction Execution: Validators execute cross-chain transactions by observing and confirming transactions on the source chain (where the assets or data are originally held) and then writing the corresponding transactions to the gateway on the destination chain (where the assets or data will be transferred).
• Security Measures: The core infrastructure layer incorporates various security measures to protect against potential attacks and ensure the integrity of cross-chain transactions. These measures may include key rotations, threshold requirements for validation, and other security protocols.

Application Development Layer

The Application Development Layer provides developers with the necessary tools and interfaces to access and utilize the core infrastructure layer for building cross-chain applications. This layer is designed to empower developers and enable them to create decentralized applications (dApps) with seamless cross-chain capabilities. The Application Development Layer consists of the following key elements:

• Software Development Kits (SDKs): Axelar offers SDKs that provide a set of software tools, libraries, and documentation to developers. These SDKs simplify the process of integrating cross-chain functionality into their applications. By using the SDKs, developers can easily interact with the core infrastructure layer of Axelar without having to deal with the complexities of blockchain interoperability themselves.
• Application Programming Interfaces (APIs): APIs serve as an interface between developers and the Axelar Network. They allow developers to make standardized cross-chain function calls, enabling various actions such as asset transfers, data transfers, and other cross-chain interactions. The APIs provided by Axelar open up a world of possibilities for developers to build innovative and powerful cross-chain applications.
• Cross-Chain Actions: The Application Development Layer enables developers to send generalized messages, referred to as General Message Passing (GMP), across different chains. This capability allows developers to perform cross-chain actions, such as locking/unlocking and transferring crypto assets, executing cross-application triggers, and more. The flexibility provided by GMP enables developers to create diverse and sophisticated cross-chain applications.
• User-Friendly Interfaces: Axelar’s Application Development Layer aims to make cross-chain capabilities accessible and user-friendly. By offering straightforward APIs and SDKs, developers can seamlessly integrate cross-chain functionality into their applications, providing users with a smooth experience when interacting with assets and data across multiple blockchain networks.
• Cross-Chain DApps: Developers can leverage the Application Development Layer to build cross-chain decentralized applications (dApps) that can interact with various assets and data on different chains. This opens up new opportunities for dApps to access liquidity, assets, and services from multiple blockchain ecosystems, enhancing the overall functionality and user experience.

High-Level Workflow

1. A user initiates a request for a cross-chain transfer of information or assets.
2. The request is confirmed by Axelar Validators on the source chain (Chain A).
3. Axelar Validators observe their Chain A nodes and cast votes to confirm the transaction’s occurrence on Chain A.
4. If the number of Axelar Validators surpasses the set threshold, the transaction is confirmed by the Axelar Network.
5. The votes from Axelar Validators serve as signatures for the Gateway smart contract on Axelar, which uses multi-party cryptography to securely issue tokens or data across chains.
6. Once enough Validators confirm the transaction on Chain A, the requisite data on the destination chain (Chain B) is relayed to the designated deposit address, completing the cross-chain transfer.

Use Cases and Integrations

DeFi

Axelar supports a growing ecosystem of DeFi applications by providing cross-chain communication capabilities that enhance DeFi experience. The network allows for seamless cross-chain swaps and facilitates the development of wallets with universal borrow-lend features. For example,  Axelar’s GMP enables users to use assets like NFTs on Ethereum as collateral in DeFi apps on any chain, thus improving the functionality and accessibility of DeFi across different blockchain ecosystems.

Stablecoins

Axelar has integrated Circle’s Cross-Chain Transfer Protocol (CCTP), enhancing user experience in a multichain ecosystem. The collaboration between Axelar and Circle aims to facilitate seamless and secure movement of $USDC across different blockchains, eliminating the need for wrapped versions of the stablecoin and reducing fragmentation and the complexity typically associated with cross-chain transactions.

In combination with GMP, this integration offers numerous benefits to users:

• Unified User Experience: One single form of $USDC across multiple chains.
• Enhanced Security: Axelar validators confirm the burning and minting of $USDC on the source and destination chain.
• Efficient Transactions: Users only pay for gas fees and no slippage because $USDC transfers are happening natively without liquidity pools.

Web3 Games

Axelar’s infrastructure supports blockchain-based gaming experiences by allowing any asset on any chain to be used as a currency or credential in games. For example, users can claim game rewards from any chain in which the game is deployed. 

This capability opens up new possibilities for game developers to integrate diverse assets and improve gameplay mechanics that leverage the strengths of different blockchains, thereby creating a more interconnected and rich gaming environment.

NFTs

Axelar enhances the utility of NFTs by enabling cross-chain interactions. Through Axelar, NFTs held on one blockchain can be used in applications on other chains, such as collateral in DeFi platforms, expanding their use cases beyond their native ecosystems. 

This cross-chain functionality allows NFT owners to utilize their assets across the Web3 space.

Wallets

Axelar is integrated with many wallets that utilize its technology to connect as many blockchains as possible.

DAO Governance

Axelar’s integration with Filecoin through the Filecoin Virtual Machine (FVM) significantly enhances DAO governance by enabling DataDAOs to manage data resources securely and decentralized across blockchains. This collaboration utilizes Axelar’s GMP capability and Filecoin’s decentralized storage protocol.

Additionally, Axelar’s Interchain Governance Orchestrator framework supports Uniswap’s deployment on FVM, facilitating cross-chain governance and streamlining multichain dApp management. This framework enables developers to execute governance actions across their deployments from a single place, simplifying complex processes and allowing for seamless integration of decentralized applications into diverse blockchain environments.

Economics

Axelar Ecosystem Map

Axelar Chain Map

Visit Axelarscan.io for the full up-to-date list. 

Business Model

Axelar’s business model revolves around generating revenue from fees and managing costs associated with token emissions. The network carefully manages the emission rate of $AXL tokens to strike a balance between generating revenue from fees and covering the costs associated with validator rewards and ecosystem incentives. 

The emission rate is determined by the underlying protocol and is designed to align with the network’s growth, adoption, and usage. Additionally, Axelar monitors the demand for its services and adjusts its fee structures accordingly to remain competitive in the market. As the network attracts more users, developers, and enterprises, the revenue from fees is expected to increase, contributing to the sustainability of the business model.

Revenue Streams

• Transaction Fees: Axelar generates revenue from transaction fees paid by users for cross-chain transactions and other network usage. These transaction fees are denominated in the native $AXL token and are paid to validators who secure the network and process the transactions.
• Network Usage Fees: In addition to transaction fees, Axelar may implement other network usage fees for specific services or functionalities provided by the platform. For example, there could be fees for using specific APIs, accessing premium features, or participating in certain cross-chain activities.
• Developer and Enterprise Fees: Axelar can introduce fees for developers and enterprises who want to utilize the SDK and APIs to integrate cross-chain capabilities into their applications. These fees can be in the form of licensing fees or subscription models, providing a revenue stream for Axelar.

Costs and Emissions

• Validator Rewards: Axelar incentivizes validators to secure the network and participate in the proof-of-stake consensus mechanism by rewarding them with newly minted $AXL tokens. These rewards are distributed based on the validators’ contributions to network security, consensus, and transaction processing.
• Ecosystem and Community Incentives: Axelar allocates a portion of the total token supply to incentivize ecosystem builders, community contributors, and participants in various programs, such as testnet grants, liquidity rewards, and developer grants. These incentives are essential for fostering the growth and adoption of the Axelar network.
• Insurance Fund and Programs: A portion of the token supply is reserved for community programs, including an insurance fund and insurance programs. These funds serve as a safety net to cover potential losses or risks in the ecosystem, ensuring the longevity and stability of the network.

Tokenomics

$AXL – Axelar Token

The AXL token plays a critical role in ensuring the success and security of the Axelar network.

• $AXL is the native utility token that powers the Axelar network, enabling cross-chain communication and receiving rewards and fees as a result.
• $AXL token holders can use their assets to participate in decentralized governance.

The token economics are designed to achieve four important outcomes for the network:

• Security: $AXL provides incentives for a wide and diverse set of validators to participate in securing the network. Validators play a crucial role in verifying cross-chain messages, authenticating transactions, and maintaining the integrity of the network. By incentivizing validators, Axelar ensures that the network remains secure and resistant to attacks.
• Decentralization: $AXL is distributed among token holders, validators, and participants in network governance decisions. This wide distribution of tokens promotes decentralization, as power is not concentrated in the hands of a few entities. 
• Longevity: $The AXL token design includes incentives that encourage long-term participation and maintenance of the network. 
• Ecosystem Growth: $AXL tokens provide incentives for developers to utilize Axelar’s SDKs and APIs to build cross-chain capabilities into their applications. By offering rewards for integrating with the Axelar network, more developers are motivated to contribute to the growth of the ecosystem, leading to a wider range of applications and increased overall utility.

To meet those objectives, the $AXL token supports four critical functions:

• Transaction Fees and Network Usage: $AXL is used as a medium of exchange for transaction fees and any other fees related to network usage. Users who perform cross-chain transactions or utilize other services on the Axelar network need to pay transaction fees in $AXL. These fees are paid to the validators who run the network and validate transactions.
• Governance: $AXL token holders and their proxies can stake their tokens and participate in the governance of the network. They can propose and vote on various network decisions, such as changes to network parameters or upgrades to the protocol. This democratic governance process allows token holders to have a say in the evolution of the network.
• Incentives for Validators: $AXL token plays a crucial role in providing incentives for validators who participate in the decentralized Proof-of-Stake consensus that secures the network. Validators receive AXL token rewards as incentives to continue securing the network and validating transactions. These rewards are distributed programmatically according to the rules encoded in the network’s protocols and are inflationary in nature, meaning they contribute to increasing the total token supply.
• Ecosystem Rewards: $AXL is also used to reward ecosystem builders and community contributors who contribute to the growth and development of the Axelar network. Developers, community members, and other participants who contribute to the ecosystem can receive $AXL token rewards as a recognition of their efforts.

As time passes, governance proposals will update tokenomics to allow the network to sustainably support more chains by decreasing the rate of token inflation per added chain. 

$AXL Genesis Allocation

At inception, a total of 1 billion $AXL tokens were minted and distributed among various stakeholders and programs.

• Team: A portion of the $AXL tokens was allocated to existing employees and advisors.
• Company: Another portion of $AXL tokens was allocated to Axelar Inc. operational treasury and future employee incentive programs.
• Backers: A portion of $AXL tokens was allocated to seed investors, Series A investors, and Series B investors who had supported Axelar during its funding rounds.
• Community Sale: A public sale of $AXL tokens was conducted after the mainnet launch, with the objective of distributing tokens to multiple members of the community who wished to participate.
• Community Programs: A portion of $AXL tokens was allocated towards various community programs, including testnet incentives, dashboard grants, wallet grants, developer grants, and liquidity rewards. These programs were designed to encourage community participation and engagement in the growth and development of the Axelar network.

Additionally, at least 5% of the total token supply was reserved from the Community Programs allocation. These tokens would be dedicated to an insurance fund and insurance programs, which are intended to provide additional security and protection for the Axelar ecosystem and its participants.

• Company: 29.5%.
  • Core team: 17%.
  • Company operations: 12.5%.
• Backers: 29.54%
  • Seed: 13.4%.
  • Series A: 12.64%.
  • Series B: 3.5%.

• Community sale: 5%.
• Community programs (incl. insurance fund): 35.96%.

$AXL Release Schedule

$axlUSDC

$axlUSDC is a wrapped, multi-chain representation of the $USDC stablecoin, which is pegged to the US dollar. It allows users to utilize $USDC on multiple blockchain networks, providing cross-chain interoperability for this stablecoin.

• Each unit of $axlUSDC is backed by a corresponding unit of $USDC that is locked in an Axelar Gateway on the Ethereum blockchain. This ensures that the value of $axlUSDC is always fully collateralized by an equivalent amount of $USDC.
• Once minted, $axlUSDC can flow between different chains without needing to be routed back through Ethereum. This seamless cross-chain functionality allows users to transfer and utilize $axlUSDC across various blockchain ecosystems.

To acquire axlUSDC, users have three options:

• Swap via liquid pairs on decentralized exchanges (DEXs) that support axlUSDC.
• Swap via Squid, a cross-chain liquidity router built on the Axelar network. 
• Mint via Satellite, a cross-chain bridge developed by Axelar. Satellite enables users to mint $axlUSDC by locking their $USDC on one blockchain and receiving $axlUSDC on another blockchain.

Governance

Axelar network employs a decentralized governance model backed by its permissionless validator set, which is fundamental to the network’s security. This model supports the validation of cross-chain transactions and the administration of network parameters, which is crucial for maintaining Axelar’s operation and facilitating its progressive decentralization strategy.

Validator Set and Consensus

The network starts with a permissionless validator set operating under a delegated proof-of-stake (DPoS) consensus. This structure enhances the network’s security and makes it a robust option for cross-chain functionalities. Validators play a critical role in network governance by voting on key parameters and updates, thus driving the network towards increasing decentralization over time.

Governance Tools and Participation

Axelar provides various tools for stakeholders to help them participate in governance:

• Axelar Forum and Axelarscan: Platforms where $AXL tokens can learn about validators and engage in governance discussions and decisions. 
• Staking: AXL token holders can stake their tokens through a validator and participate in governance.

How to Stake $AXL and Participate in Governance

Step 1: Set up a wallet supporting the Axelar Network.

• Kelpr is a solid choice and will be used in this example.

Step 2: Get native $AXL

• AXL tokens on EVM chains are wrapped versions and need to be converted into native $AXL.
• You can convert any type of token into native $AXL on the Axelar chain by using Squid.
• Buy native $AXL tokens directly from an exchange such as Bybit, Coinbase, etc, and send them to your wallet. Be sure to send it to the Axelar Network. 

Step 3: Stake $AXL

• Once you have $AXL in your Keplr wallet, visit your “Dashboard”.

• From there find the Axelar chain.

• Click “Stake” and choose a validator.
• Select the amount of $AXL you wish to stake and click “Stake”.
• You successfully staked your $AXL tokens and now can participate in Governance.

Key Governance Parameters

Axelar’s governance covers several crucial network parameters, such as:

• Base Inflation Rates and Rewards: Determined for validators and stakers to incentivize network participation, improve security, and increase the longevity of the protocol. In addition, rewarding validators properly encourages them to continue supporting the Axelar network by running nodes on supported chains.
• Additional Chain Rewards: The reward rate per EVM chain is decided by governance.
• Gas Fees and Formulas: Critical for estimating transaction costs across connected chains, ensuring economic feasibility for users and validators.
• Validator Thresholds: A number of validators are required to connect a new EVM chain on to the network.
• Rate Limits: A feature that increases network security.
• Network Upgrades and Smart Contracts: For new implementations to the network and Axelar’s technology.
• Adding EVM Chains: Any new EVM chain needs to go through governance to be added by Axelar. The same process happens if there’s need to disconnect a compromised chain.

Governance Process

The governance process is structured into several phases to ensure community involvement and transparency:

• Proposal Creation: Initiated by community members on the governance forum.
• Forum Discussion: Open for community feedback and clarification.
• Community Voting: Determines whether proposals are accepted or rejected.
• Proposal Implementation: Successful proposals are implemented into the network.

Quadratic Voting

A novel quadratic voting mechanism is employed to increase decentralization, allowing a wide set of validators to participate and secure the network. Validator security policies, such as mandatory key rotations, add an extra layer of protection against potential threats.

In standard proof-of-stake systems, validators with more stake have more influence in the system, leading to stake concentration and potential centralization. Quadratic voting, a groundbreaking approach adopted by Axelar, aims to address this issue by ensuring that the number of votes each validator receives is proportional to the square root of their stake. This means that as validators accumulate more stake, it becomes increasingly difficult for them to accumulate more voting power. The threshold of validators, collectively weighted by the square root of their stakes, must authorize every cross-chain request, ensuring that no single validator can dominate the decision-making process.

By implementing quadratic voting Axelar aims to address certain issues present in traditional blockchain governance models:

• Reducing Power Concentration: Quadratic voting helps by distributing voting power across all stakeholders fostering decentralization.
• Encouraging Participation: By distributing voting power more community members are incentivized to participate in governance as smaller stakeholders can be more impactful with their votes.
• Improving Inclusivity: Including as many community members as possible in governance improves the process by having a diverse set of viewpoints and interests.

Note that Axelar’s implementation of quadratic voting applies specifically to the validation and processing of cross-chain transactions, while the underlying consensus mechanism follows the standard proof-of-stake staking model (1 token, 1 vote) for block production and rewards.

Challenges

Despite its benefits, quadratic voting also introduces specific challenges that must be considered.

• Sybils: Individuals with a lot of tokens can still use other wallets to split their tokens and gain more votes than they would have if their tokens was in a single wallet. In a decentralized environment with limited sybil protection and where 1 address = 1 identity, quadratic voting is vulnerable to sybil attacks. Addressing this issue must include a layer of protection against sybils and ensure that individuals don’t use multiple wallets to vote.
• Allocation of Tokens and Inequity: Quadratic voting works best where all participants have same amount of tokens to vote or similar amounts. The quadratic nature of the cost will eventually put a limit on the impact smaller stakeholders can have. Someone who acquired a substantial amount of tokens can still influence the vote fairly easily. 

Risks

Cross-chain protocols are frequently targeted by malicious actors who attempt to drain funds, exploit vulnerabilities in the form of unauthorized token minting, and sign fraudulent transactions. The nature of these exploits can vary based on the actual protocol that is being targeted, and it can range from rug pulls to compromised bridge permissions that expose private keys. 

For Axelar, the security of the network is powered by a proof-of-stake decentralized design at its core, ensuring that the network is secure and resistant to attacks. However, security is a multidimensional problem with binary outcomes. 

In the case of Axelar, the main security challenge would rely on the fact that it employs a lock and mint mechanism for token bridging. The fact that so much capital needs to be stored somewhere makes it an attractive target for malicious actors to try to exploit it. 

Security features

• Leveraging IBC’s Security: The Inter-Blockchain Communication (IBC) protocol serves as the backbone for cross-chain communication in Axelar. IBC is widely recognized as a robust and secure standard for interchain communication, providing a secure foundation for Axelar’s interactions with other IBC-compatible chains.
• Isolated Module Functionalities: Axelar ensures that different network connections are isolated from each other by segmenting functionalities into modules at the Cosmos Software Development Kit (SDK) level. This approach minimizes the risk of any issues in one chain affecting others, enhancing the overall security of the network.
• Ability to Freeze Transfers: In the event of an attack or an ecosystem-wide crisis, Axelar has the ability to freeze transfers from specific chains or all chains. This feature allows Axelar to take swift action to mitigate potential risks and protect user funds during adverse situations.
• Reduced Extent of Stolen Funds: Axelar’s ERC-20 contracts are equipped with a rate-limit functionality that restricts the amount of funds that can be stolen during an attack. This limitation minimizes the impact of potential breaches, providing an additional layer of security.
• Security through $AXL Token Economics: The native $AXL token plays a crucial role in enhancing the security and decentralization of the Axelar network. The tokenomics of $AXL are designed to incentivize honest behavior among validators by providing healthy staking rewards. Additionally, widespread distribution of the $AXL token is intended to increase active participation in community governance, promoting decentralization.
• Unbounded Number of Validators: Axelar utilizes Threshold Signature Schemes (TSS), which allow the network to support an unlimited number of validators. This scalability feature ensures that Axelar can accommodate a growing validator set as needed.
• Leveraging Cosmos’ Interchain Security: Axelar’s security will receive further reinforcement when Cosmos’ Interchain Security is launched. By leveraging the economic security provided by the validator set of the Cosmos Hub, Axelar’s overall security posture will be enhanced.

Trust Assumptions

Axelar operates on several trust assumptions, which impact the security and decentralization of the network.

• External Verification by Validators: Axelar relies on a set of validators, currently consisting of 48 active validators out of a total of 51, to execute transactions. For a message to be approved, it must be signed by at least ⅔ of the validators. The security of applications using Axelar is dependent on the consensus of these validators. While Axelar offers application-based security and allows applications to customize its codebase, the governance and permissioned set of validators and relayers used by applications depend on Axelar’s underlying validator set.
• Skewed Voting Power: Currently, only 20 out of Axelar’s 51 validators possess meaningful voting power, each holding more than 1% of the voting weight. This skewed distribution of voting power reduces the actual security of the system, as the remaining 27 validators with low voting power may not have significant influence on decisions. The distribution of voting power is expected to become more even with the introduction of the $AXL token, and the implementation of quadratic voting for cross-chain transactions will further address this concern.
• Progressive Decentralization: Axelar currently uses governed multisigs for deploying system upgrades, which can be seen as a bottleneck for decentralization. While this allows Axelar to provide certain features, such as rate limit functionality, it may hinder complete decentralization. However, Axelar plans to progress towards eliminating or decentralizing the governance multisigs, eventually giving more power to the community.
• Lesser Validators for Certain Chains: To add a new chain to the network, Axelar requires 80% of the validators (or validator supermajority) to run a node for that chain. However, Axelar does not mandate its validators to run nodes for all supported chains, which means that some chains may have a lower number of validators securing transactions within the Axelar ecosystem.

Network Security

Axelar addresses security concerns using various mechanisms, including high safety thresholds, maximum decentralization, robust fall-back mechanisms, and shared governance.

 The security of the network is powered by a proof-of-stake decentralized design at its core, ensuring that the network is secure and resistant to attacks. At the same time, a novel quadratic voting mechanism is employed to increase decentralization, allowing a wide set of validators to participate and secure the network. In addition to that, there are validator security policies, such as mandatory key rotations, which add an extra layer of protection against potential threats.

The network functions are also equipped to mitigate malicious interconnected chains, allowing the suspension of traffic from them to prevent potential risks. Contract limits are set to specify how much can be transferred over a specific time period, adding an additional safety measure.

• Maximum Safety: Axelar sets a high safety threshold of 90%, ensuring that the vast majority of validators must collude to withdraw any locked funds or forge state proofs. This threshold provides a strong defense against attacks and ensures that the network remains secure even in rare cases of failure.
• Maximum Decentralization: Axelar utilizes threshold signature schemes, allowing for a large number of validators to participate, ensuring decentralization of the network. This approach ensures that the number of validators is not limited by complexity or fees, unlike multi-signature schemes on other chains.
• Robust Fall-back Mechanisms: To address the possibility of network stalls, Axelar implements an “emergency unlock key” as a fall-back mechanism. This key, shared across reputable parties or the community of a specific blockchain, can be activated to recover assets in case the network stalls.
• Maximum Decentralization of Fall-Back Mechanisms: The fall-back mechanism includes a secondary recovery set of users who can participate without any cost. These users do not need to be online, run nodes, or coordinate with each other. They are only “called on duty” if the Axelar network stalls and cannot recover. 
• Shared Governance: Axelar operates under a common protocol that allows all users to participate in governance decisions. Users can vote on which chains should be supported, and a pool of funds is allocated to reimburse users in emergencies, controlled through governance protocols.
• Fall-Back Mechanisms for Chain Interoperability: In the case of direct bridges between Ethereum and other small blockchains, Axelar needs to address the risk of forged history and potential attacks. Recovery keys can be shared across the communities of each chain, and governance mechanisms can be used to determine actions in case of Axelar stalls.
• Limits and Governance for Recovery: Axelar can impose limits on the value of assets moved in and out of connected chains to mitigate potential risks. Additionally, the governance module can vote on actions to take in various situations, such as restarting connections or determining the fate of assets moved to a broken chain.

The fall-back mechanisms in Axelar provide a safety net in case the network stalls or encounters unexpected issues. These mechanisms are designed to ensure that assets can be recovered and that the network remains secure and reliable. When Axelar stalls due to the high threshold, an “emergency unlock key” takes control of the network. There are multiple ways to instantiate this unlock key, and certain chains/applications may opt to utilize a different variation for the “recovery set” or opt-out completely:

• Option a: Share the Key Across Foundations and Reputable Community Members. In this option, the emergency unlock key is shared across foundations of blockchain projects and reputable individuals in the community. These entities are trusted and can be relied upon to take appropriate actions if Axelar stalls. By involving reputable members, the network gains an additional layer of security.
• Option b: Share the Key Across Elected Parties in Delegated Proof-of-Stake. In this option, the emergency unlock key is shared among parties elected through the delegated Proof-of-Stake (PoS) mechanism. These elected parties are responsible for making decisions and taking actions in case of a network stall. Delegated PoS models allow for efficient consensus and delegation of responsibilities.
• Option c: Share a Custom Key Across Stakeholders/Validators of Chain X. For accounts managing assets and information for a specific chain (e.g., chain X), a custom recovery key is shared across the stakeholders and validators of that chain. Assuming chain X has governance mechanisms in place, these mechanisms can be utilized to determine the course of action if Axelar stalls. This approach ensures that each connected chain has control over its own assets.

Recovery Key Generation

The fall-back mechanisms rely on a recovery key, which is a cryptographic construct used to recover assets in case of network issues. The recovery key is generated using a distributed key-generation protocol with contributions from the recovery users.

1. Each Axelar validator contributes a random value to the recovery key generation process.
2. The recovery secret key is derived by summing up these random values.
3. Instead of performing the summation in plain text, all shares are encrypted under the public keys of the recovery users.
4. The encrypted shares are then homomorphically added up, resulting in a recovery public key (RPK).
5. Potentially thousands of encryptions of the shares of the corresponding secret key (Enci(si)) are distributed to their owners (e.g., posted on-chain).

Use of recovery key in bridge contracts

Axelar bridge contracts include an option to recover funds using the recovery public key (RPK) under specific conditions. If the network encounters issues and stalls, the recovery key can be used to unlock and recover the assets locked by the network. This ensures that users’ assets are not permanently lost even if the network faces unexpected challenges.

Handling broken chains

If a connected chain (e.g., chain X) breaks or experiences issues, Axelar has several options to address the situation as well:

• Limit Asset Movement: Axelar can impose limits on the USD value of assets that can be moved in and out of chain X on any single day. This prevents a malicious chain X from stealing a significant fraction of assets before the issue is detected.
• Governance Decisions: The Axelar governance module allows users to vote on actions to take in various situations. For example, if a benign bug causes issues with chain X, the governance module can decide to restart the connection from where it left off.
• Custom Ethereum Recovery Key: If assets from Ethereum (ETH) have been moved to chain X, a custom Ethereum recovery key can be used to determine the fate of those ETH assets. This allows for tailored recovery procedures based on the specific assets involved.

Enhancing Security in Cross-Chain Swaps

How the network architecture protects against pairwise network connections and contagion in the context of cross-chain swap protocols?

Multichain (formerly known as Anyswap), a protocol for cross-chain bridging and swaps, faced liquidity freeze, causing the depegging of wrapped stablecoins connected to deposits on the native chain. This issue had a ripple effect, potentially spreading contagion to other cross-chain swap providers that had large deposits of these wrapped tokens.

The problem stems from the use of pairwise network connections, where each chain connects one-to-one (point-to-point). In such a network architecture, containing issues and emergencies becomes challenging. Contagion can spread quickly, leading to potential network-wide shutdowns when problems arise.

Axelar, on the other hand, employs a hub-and-spoke network architecture, also known as topology. In this model, important functions like security, governance, and core services are built to be permissionless, allowing for better containment of issues and a more robust network. The hub-and-spoke approach, although it may seem centralized at first glance, doesn’t necessarily imply centralization. Axelar’s core functions are designed to be decentralized, allowing the network to progress towards complete decentralization over time.

The hub-and-spoke topology used by Axelar offers several advantages, including better containment of problems and more efficient handling of emergencies. It allows for a more secure and stable cross-chain infrastructure, enabling users to keep their funds safe and secure during times of network disruptions.

Audits

To ensure the highest level of security, rigorous audits and bug bounties are conducted to identify and address any vulnerabilities in the system.

Economic Attack Vectors

• Validator Collusion: An economic attack vector arises when validators collude to carry out malicious activities. In a decentralized network, validators are expected to act independently and honestly. However, if a group of validators conspires, they can potentially monopolize rewards, control network governance decisions, or disrupt cross-chain communication for their own benefit, leading to centralization and decreased security.
• Governance Manipulation: Decentralized networks often rely on on-chain governance mechanisms where token holders or validators vote on proposals and protocol upgrades. Economic attack vectors may include large token holders or validators forming voting cartels to manipulate the governance process, pushing through unfavorable changes or blocking necessary updates, hindering the network’s development and stability.

Dependencies and Access Controls

• External Bridge Dependencies: Axelar relies on external bridges to connect with other blockchain networks. An attack or malfunction in these bridges can disrupt cross-chain communication, leading to issues with asset transfers, liquidity provision, and overall network functionality. Ensuring the security and resilience of these bridges is crucial to maintaining the interoperability of the Axelar network.
• Access Control to Critical Components: Certain components within the Axelar network, such as the validator set or governance parameters, must be accessed and controlled only by authorized entities. Inadequate access controls or vulnerabilities in key management can lead to unauthorized changes or attacks, jeopardizing the security and stability of the entire network.
• Smart Contract Vulnerabilities: Axelar’s software development kit (SDK) includes various smart contracts that facilitate cross-chain functions. Vulnerabilities in these smart contracts, such as reentrancy bugs or incorrect access controls, can be exploited by attackers to manipulate transactions, drain funds, or disrupt cross-chain operations.

Liquidity Risk

• Interchain Token Liquidity: Interchain tokens, which enable cross-chain transfers of assets, rely on sufficient liquidity to function effectively. Insufficient liquidity for certain interchain tokens can lead to price manipulation, slippage, or difficulty in executing cross-chain swaps, affecting the overall user experience and attractiveness of the platform.
• Liquidity Provider Risks: Liquidity providers play a vital role in decentralized exchanges and platforms. However, they are exposed to impermanent loss and potential smart contract vulnerabilities. If a significant number of liquidity providers exit the network due to financial risks or vulnerabilities, it can result in decreased liquidity and negatively impact the platform’s efficiency.
• Market Price Volatility: Cross-chain transactions involve the movement of assets between different blockchain networks, exposing them to varying market conditions and price fluctuations. Rapid price changes during cross-chain swaps can result in undesirable slippage and adversely affect users’ trading experiences.

Team

 Axelar has an established core team with expertise in cryptography, consensus, and distributed systems. Sergey Gorbunov and Georgios Vlachos, the co-founders of Axelar, are also founding team members of Algorand and have years of experience in building blockchain infrastructure.

Project Investors

Axelar has raised over $65 million in funding, most recently raising $35M at a $1B valuation in its Series B round from notable investors such as Polychain Capital, Dragonfly Capital, North Island Ventures, Rockaway Blockchain Fund, Cygni Capital, Lemniscap, Olive Tree Capital, Blockchange Ventures and Node Capital.

Partnerships and Integrations

A wide range of applications and blockchain ecosystems leverage Axelar’s tech to offer cross-chain features. For example, dApps like Prime Protocol, Astroport, Cosmos app chains like Osmosis Kujira, Avalanche subnets like Heroes of NFT, Pocketworlds, and NFT projects such as MintDAO, Omnisea, among others. In addition, Axelar has partnered with noteworthy companies pushing crypto adoption.

The team is constantly looking for new partnerships and integrations with key projects of the crypto space and companies outside of it to expand its ecosystem.

Axelar and Microsoft

Axelar has partnered with Microsoft to enhance the integration of Web3 technologies with traditional internet systems, focusing on blockchain data integration and interoperability. This partnership facilitates the availability of Axelar’s solutions on Microsoft Azure Marketplace, thereby enabling Microsoft customers to easily access an end-to-end blockchain interoperability solution that is both programmable and secure. The collaboration aims to advance blockchain adoption, streamline data integration, and promote seamless interaction between public and private blockchains.

Axelar and Mastercard

Axelar has joined forces with Mastercard as part of the Start Path Crypto program, designed to advance growth and technical collaboration between emerging blockchain technologies and established financial networks. This partnership aims to integrate Axelar’s cutting-edge interoperability solutions with Mastercard’s vast financial network and customer base. 

By participating in Start Path, Axelar will not only gain access to Mastercard’s extensive channels and expertise but will also explore new possibilities for connecting the decentralized security protocols of Web3 with the structured networks of the global financial system.

Axelar and Onyx by J.P. Morgan

Axelar has partnered with Onyx by J.P. Morgan and Apollo to demonstrate a groundbreaking proof-of-concept under Project Guardian, showcasing the potential of blockchain technology to automate and enhance portfolio management of tokenized financial assets or real-world assets (RWAs) across multiple blockchains. This collaboration leverages Axelar’s cross-chain communication capabilities to facilitate seamless transactions and rebalancing of investment portfolios across multiple blockchains, integrating traditional financial assets with decentralized finance. 

FAQ

• How is axlUSDC secured?
  • Similar to many of the other networks that Axelar secures, $axlUSDC is secured by a dynamic validator set running delegated proof-of-stake (DPoS).
  • When a user deposits $USDC into a Gateway contract on the Ethereum chain, units of $axlUSDC are minted. These Gateways are secured by Axelar’s dynamic validator set through a multiparty cryptography scheme. The validator set holds key shares that collectively control the Gateways, ensuring the security of the wrapped assets.
  • The validation process starts when a cross-chain message is initiated by a dApp user. The message first interacts with an Axelar Gateway deployed on each connected chain. These Gateways receive the messages from dApps and route them into the Axelar network, which then forwards them to the desired connected chain.
  • The control of the Gateway is maintained by a key shared among all Axelar validators. The key is divided into multiple pieces called key shares, with each validator holding several key shares based on the amount of $AXL tokens they have staked. This multi-party cryptography scheme ensures that no single entity has complete control over the Gateway and prevents potential malicious activities.

• Can anyone become a validator on the Axelar Network?
  • Yes, Axelar operates a permissionless validator system where anyone can participate as a validator provided they stake $AXL tokens and comply with the network’s operational requirements, fostering an open and scalable cross-chain ecosystem.

• Why choose Axelar for cross-chain communication?
  • Universal Interoperability: Axelar connects over 60 blockchains, including those based on Cosmos and EVM, enabling seamless interaction across diverse blockchain ecosystems.
  • Decentralized Security: Utilizes a permissionless proof-of-stake consensus model that enhances network security and ensures reliable transaction validation.
  • Developer-Friendly: Provides robust APIs and SDKs that simplify the development of cross-chain applications, making blockchain interactions straightforward for developers.
  • Enhanced User Experience: Supports one-click transactions across different blockchains, significantly improving usability and reducing the complexity typically associated with cross-chain operations.

• What are the differences between Satellite and Squid?
  • Both products are powered by Axelar but operate differently. Satellite focuses on facilitating cross-chain communication by allowing developers to easily integrate and use Axelar’s GMP capabilities in their applications. It simplifies the process of connecting different blockchains and makes it more accessible for users.
  • On the other hand, Squid is a liquidity router that uses Axelar’s technology to provide DeFi services such as cross-chain swaps through liquidity aggregation between DEXs across different blockchains.

• Does Axelar have a roadmap?
  • You can check Axelar’s roadmap with this link.

Community Links

• Website
• Satellite
• Whitepaper
• Developer docs
• Developer resources
• Blog
• Github
• Twitter
• Telegram
• Discord
• Bug Bounty
• Terms of use