Axelar

Skill is based on axelar-core (Git SHA f303a5a), generated 2026-02-24.

Axelar is a cross-chain overlay network (Cosmos SDK app axelard) that enables cross-chain asset transfers and General Message Passing (GMP) between EVM and Cosmos chains. The nexus module registers chains and assets and tracks transfers; the evm module manages Gateway contracts and signed commands on EVM chains; axelarnet handles IBC and Cosmos contract calls.

Core References

Features

EVM and Gateway

Cosmos / IBC

Multisig and TSS

CLI

Best Practices

Generation Info

• Source: sources/axelar
• Git SHA: f303a5aa961771b475b63bce433ed3b0e6cf3b1a
• Generated: 2026-02-24

Documentation was derived from the axelar-core repository (https://github.com/axelarnetwork/axelar-core). Content was synthesized from:

• README.md — Build (make build-static, make docker-image), gateway bytecode (contract-version.json, contract-artifacts), verify binary, local node, CLI link
• docs/cli/toc.md — Full axelard CLI tree (query/tx for nexus, evm, axelarnet, multisig, tss, snapshot, permission, reward, vote, etc.)
• *docs/cli/.md** — Individual command help (e.g. nexus chains, latest-deposit-address, transfer-rate-limit; evm gateway-address, batched-commands, sign-commands; multisig key-id)
• docs/proto/proto-docs.md — Protobuf API (nexus: Chain, CrossChainAddress, CrossChainTransfer, TransferState, GeneralMessage, FeeInfo, Asset; axelarnet, evm, tss types)
• proto/axelar/ — Nexus exported types (Chain, CrossChainTransfer, GeneralMessage, WasmMessage, FeeInfo, Asset)
• x/ — Modules: nexus, evm, axelarnet, multisig, tss, snapshot, permission, reward, vote

Rate Limits and Fees

When building or operating on Axelar, respect transfer rate limits and fee configuration to avoid failed transfers and ensure correct economics.

Transfer rate limits

• Per (chain, asset): A limit (amount) and a window (duration). Transfers that would exceed the limit in the window are rejected or deferred.
• Query: axelard query nexus transfer-rate-limit [chain] [asset].
• Set: Only chain maintainers (or governance) can set; axelard tx nexus set-transfer-rate-limit [chain] [limit] [window] --from $KEY -y.
• Best practice: Before large transfers or integrations, query the current rate limit and plan batching or timing so stays within the window.

Transfer fees

• Fee info per (chain, asset): fee rate, min fee, max fee. Applied to cross-chain transfers.
• Query: axelard query nexus fee-info [chain] [asset] and axelard query nexus transfer-fee [src] [dst] [amount].
• Register/update: axelard tx nexus register-asset-fee [chain] [asset] [fee-rate] [min-fee] [max-fee] (governance/maintainer).
• Best practice: Always query transfer-fee for the path and amount before sending; ensure user pays at least that fee (or that the app subsidizes it).

Chain maintainers

• Chain maintainers are validators registered for a chain. They can set rate limits and perform routing/retries.
• Query: axelard query nexus chain-maintainers [chain].
• Register/deregister: axelard tx nexus register-chain-maintainer [chain]..., axelard tx nexus deregister-chain-maintainer [chain]... (validator key).
• Best practice: Operators should only register for chains they can maintain (monitoring, retries, rate limit tuning).

Insufficient amount and failed transfers

• Transfers can be in state InsufficientAmount or Failed. Query axelard query nexus transfers-for-chain [chain] insufficient_amount or archived to inspect.
• Retry: IBC retries via axelard tx axelarnet retry-ibc-transfer [transfer-id]; EVM via axelard tx evm retry-event [chain] [event-id].
• Best practice: Monitor pending and failed transfers; surface errors to users and retry when appropriate.

EVM gas and confirmation height

• Each EVM chain has a confirmation height. Events are only processed after that many confirmations.
• Query: axelard query evm confirmation-height [chain].
• Best practice: When estimating time-to-finality for EVM flows, account for confirmation height and destination chain block time.

<!-- Source references:

• https://github.com/axelarnetwork/axelar-core (x/nexus, x/evm, docs/cli)
• proto/axelar/nexus (RateLimit, FeeInfo, TransferFee)

-->

Nexus Module

The nexus module is the central registry for chains and assets and tracks cross-chain transfers and general messages. Use it to query chains, assets, deposit addresses, transfer fees, and rate limits.

Chains and assets

• Chains: Registered chain names and status (activated/deactivated). Filter by status when listing.
• Assets: Per-chain registered assets (denom, native flag). One asset can be registered on multiple chains.

# List all registered chains (optional: --status activated)
axelard query nexus chains --node $NODE -o json

# Assets for a chain
axelard query nexus assets [chain] --node $NODE -o json

# Chains that have a given asset
axelard query nexus chain-by-asset [asset] --node $NODE -o json

Cross-chain transfers

• CrossChainTransfer: Recipient (chain + address), asset (denom + amount), transfer ID, state (Pending, Archived, InsufficientAmount, TransferFailed).
• Transfer direction: From a chain (outbound) or to a chain (inbound).

# Transfers for a chain; state = pending | archived | insufficient_amount
axelard query nexus transfers-for-chain [chain] [state] --node $NODE -o json

# Transfer fee for a path
axelard query nexus transfer-fee [source-chain] [destination-chain] [amount] --node $NODE -o json

Deposit address

For a given recipient (chain + address), the nexus can derive a deposit address on another chain. Sending assets to that deposit address triggers a cross-chain transfer to the recipient.

# Latest deposit address: [deposit chain] [recipient chain] [recipient address]
axelard query nexus latest-deposit-address [deposit-chain] [recipient-chain] [recipient-address] --node $NODE -o json

# Reverse: which recipient corresponds to a deposit address
axelard query nexus recipient-address [chain] [address] --node $NODE -o json

Rate limits and fees

• Transfer rate limit: Per (chain, asset), a limit and a time window. Queried and set by chain maintainers or governance.

# Query rate limit
axelard query nexus transfer-rate-limit [chain] [asset] --node $NODE -o json

# Set rate limit (tx: chain maintainer or authorized); [chain] [limit] [window]
axelard tx nexus set-transfer-rate-limit [chain] [limit] [window] --from $KEY --node $NODE -y

• Fee info: Per-chain, per-asset fee rate and min/max fee.

axelard query nexus fee-info [chain] [asset] --node $NODE -o json

• Register asset fee (governance/maintainer): axelard tx nexus register-asset-fee [chain] [asset] [fee-rate] [min-fee] [max-fee] --from $KEY -y

Chain maintainers

Validators can register as chain maintainers for specific chains (e.g. to set rate limits or handle routing).

axelard query nexus chain-maintainers [chain] --node $NODE -o json
axelard tx nexus register-chain-maintainer [chain]... --from $KEY -y
axelard tx nexus deregister-chain-maintainer [chain]... --from $KEY -y

General messages

• GeneralMessage: Cross-chain message with sender, recipient (CrossChainAddress), payload hash, status (Approved, Processing, Executed, Failed), optional asset, source tx id/index.
• Query by message ID: axelard query nexus message [id] --node $NODE -o json

Params

axelard query nexus params --node $NODE -o json

<!-- Source references:

• https://github.com/axelarnetwork/axelar-core (docs/cli, proto/axelar/nexus)
• proto/axelar/nexus/exported/v1beta1/types.proto

-->

Axelar Overview

Axelar is a cross-chain overlay network that enables cross-chain transfers and General Message Passing (GMP) between connected blockchains. The axelar-core app is a Cosmos SDK application that runs the Axelar network; the main binary is axelard.

Key concepts

• Axelar network: Cosmos-based chain that coordinates validators, gateway signing, and cross-chain state. Users and contracts interact with it to send assets or messages across chains.
• Gateway: On EVM chains, the Axelar Gateway contract holds locked assets and executes commands signed by the network (e.g. mint, transfer, contract calls). Gateway address per chain is stored in the evm module.
• Nexus: Module that registers chains and assets, tracks cross-chain transfers and general messages, and provides deposit addresses and rate limits.
• axelard: CLI and node binary. Use axelard start for a full node; use axelard query / axelard tx for queries and transactions. Default home is $HOME/.axelar.
• vald: Validator process that participates in TSS keygen/signing and submits signatures for gateway commands. Used with axelard vald-start and axelard vald-sign.

Chain types

• EVM chains: Integrated via the evm module and Gateway contracts (see features-evm-gateway). Commands are batched and executed on-chain.
• Cosmos-based chains: Integrated via axelarnet (IBC). Transfers and contract calls are routed through IBC.

Flow (high level)

1. Cross-chain transfer: User locks/sends assets on source chain → Axelar validators observe and create transfer state in nexus → On destination chain, Gateway or IBC releases/mints assets. 2. General Message: Source chain emits a message; after approval, it is routed to the destination (e.g. axelarnet route-message for Cosmos, or GMP on EVM). 3. EVM commands: Validators sign commands; relayers call execute() on the Gateway with batched signed commands from axelard query evm batched-commands / latest-batched-commands.

Key points

• One nexus registry of chains and assets; EVM-specific state (gateway, commands, tokens) lives in the evm module.
• Gateway bytecode and contract artifacts are versioned (see repo contract-version.json and axelar-cgp-solidity releases); make generate produces x/evm/types/contracts.go from contract-artifacts/.
• Full CLI reference: docs/cli/toc.md in the repo; use axelard <cmd> --help for flags.

<!-- Source references:

• https://github.com/axelarnetwork/axelar-core (README.md, docs/cli/toc.md)
• https://docs.axelar.dev/

-->

Multisig and TSS

Axelar uses TSS (Threshold Signature Scheme) so that validators jointly control gateway keys per chain. The multisig module tracks key IDs and keygen sessions; the tss module holds TSS params and heartbeats. vald is the validator process that participates in keygen and signs commands.

Key ID and keygen

• Each chain has an assigned key ID (and optionally a next key for rotation). Keygen produces a new multisig key; validators opt in/out of keygen.

# Key ID for a chain
axelard query multisig key-id [chain] --node $NODE -o json

# Next key ID for rotation (chain + key role)
axelard query multisig next-key-id [chain] --node $NODE -o json

# Keygen session for a key ID
axelard query multisig keygen-session [key-id] --node $NODE -o json

# Key details (public key etc.)
axelard query multisig key [key-id] --node $NODE -o json

Keygen transactions

• Start keygen: Initiate key generation for a key role (e.g. for a new chain or rotation).
• Opt-in / opt-out: Validators (via proxy address) opt in or out of future keygens.

axelard tx multisig keygen start ... --from $KEY -y
axelard tx multisig keygen opt-in --from $KEY -y
axelard tx multisig keygen opt-out --from $KEY -y

Rotation

• Rotate a chain to a new key ID. After rotation, new gateway commands use the new key; confirm operatorship on EVM via confirm-transfer-operatorship.

axelard query multisig next-key-id [chain] --node $NODE -o json
axelard tx multisig rotate [chain] [keyID] --from $KEY -y

TSS params and heartbeat

• TSS module params (e.g. thresholds, key requirements) and validator heartbeats.

axelard query tss params --node $NODE -o json
axelard tx tss heart-beat --from $KEY -y
axelard tx tss update-params ... --from $KEY -y

Vald (validator daemon)

• vald-start: Run the vald process (participates in keygen and signing).
• vald-sign: Sign a hash with the key for a given key ID and validator (for testing or scripting).

axelard vald-start   # long-running
axelard vald-sign [key-id] [validator-addr] [hash]

Snapshot and proxy

• Validators use a proxy address for multisig/TSS operations; snapshot module maps operator ↔ proxy.

axelard query snapshot proxy [operator-address] --node $NODE -o json
axelard query snapshot operator [proxy-address] --node $NODE -o json
axelard tx snapshot register-proxy [proxy-address] --from $KEY -y
axelard tx snapshot deactivate-proxy --from $KEY -y

<!-- Source references:

• https://github.com/axelarnetwork/axelar-core (docs/cli, x/multisig, x/tss, vald)
• proto/axelar/tss/exported/v1beta1/types.proto

-->