Docs
IntegrationsSolana

Overview

Send and receive GMP messages and interchain tokens from Solana programs.

Solana is integrated with the Axelar Network via the Amplifier. This enables cross-chain communication between Solana and other blockchains in the Axelar ecosystem.

Axelar provides two cross-chain protocols on Solana:

  1. General Message Passing (GMP) — Send and receive arbitrary cross-chain messages between Solana programs and contracts on other chains.
  2. Interchain Token Service (ITS) — Send and receive cross-chain token transfers, optionally with execution data attached. ITS also supports deploying interchain tokens, registering canonical tokens, and linking existing tokens across chains.

The core packages are in the axelar-amplifier-solana repository.

💡

Using an AI agent?

Copy this page with Copy Markdown at the top and give it to your agent, with what you want to build or the program you want to make cross-chain. The copied page links to the Markdown of the other pages it refers to, so the agent can read them too. Review what it writes, and test on testnet before mainnet.

Architecture Overview

Outbound GMP Flow

Your Program → Gas Service (pay gas) → Gateway (call_contract) → Axelar Network → Destination Chain
  1. Your program pays for cross-chain gas via CPI to the Gas Service.
  2. Your program sends the message via CPI to the Gateway's call_contract instruction.
  3. Axelar's relayer picks up the message and routes it to the destination chain.

Inbound GMP Flow

Source Chain → Axelar Network → Gateway (approve_message) → Your Program (execute)
  1. Axelar's relayer submits the message to the Gateway, which approves it.
  2. The relayer calls your program's execute instruction.
  3. Your program validates the message via CPI to the Gateway and processes the payload.

Outbound ITS Flow

Your Program → ITS (interchain_transfer) → Gateway → Axelar Network → Destination Chain
  1. Your program calls the ITS program's interchain_transfer instruction via CPI.
  2. ITS locks/burns the tokens and sends the message through the Gateway.

Inbound ITS Flow

Source Chain → Axelar Network → Gateway → ITS → Your Program (execute_with_interchain_token)
  1. The Gateway approves the message. ITS receives it, decodes the transfer, and mints/unlocks tokens.
  2. Tokens are deposited into an Associated Token Account (ATA) whose authority is the destination_token_authority PDA — derived from seeds [b"axelar-its-token-authority"] and your program's ID.
  3. If the transfer carries data, ITS calls your program's execute_with_interchain_token instruction via CPI. Without data, your program isn't called.
  4. Your program receives the tokens and can spend them by signing as the destination_token_authority PDA.

Prerequisites and Setup

This guide assumes you are using the Anchor framework. The macros provided by the Gateway and ITS SDKs are Anchor-specific convenience helpers, but the underlying account structures and CPI calls can be implemented without Anchor if your project requires a different approach.

Add the following dependencies to your Cargo.toml:

[dependencies]
anchor-lang = "1.2.0"

# For GMP (sending and receiving cross-chain messages)
solana-axelar-gateway = { version = "1.1.2", default-features = false, features = ["cpi", "mainnet"] }
solana-axelar-gas-service = { version = "1.1.2", default-features = false, features = ["cpi", "mainnet"] }

# For ITS (sending and receiving cross-chain token transfers)
solana-axelar-its = { version = "1.1.2", default-features = false, features = ["cpi", "mainnet"] }
anchor-spl = "1.2.0"
💡

The cpi feature is required so your program can make Cross-Program Invocations to the Gateway, Gas Service and ITS programs.

The network feature (mainnet or testnet) sets the program IDs your program checks against. The crates default to devnet-amplifier, so without default-features = false and a network feature, your program accepts calls only from the devnet programs. Use the same network feature on every Axelar crate.

For deployed program addresses (Gateway, ITS, Gas Service), see the contract addresses page.

Solana-Specific Concepts

If you're new to Solana development, here are the key concepts used throughout these docs:

  • Program Derived Addresses (PDAs): Solana programs use PDAs instead of private keys for signing. Your program will derive PDAs to authorize calls to the Gateway and ITS programs.
  • Cross-Program Invocations (CPIs): Interaction with the Gateway, Gas Service, and ITS happens via CPIs — one program calling another on-chain.
  • Account Model: Unlike EVM's storage model, Solana uses an account-based architecture where state is stored in separate accounts that are passed to instructions.
  • Anchor Framework: Provides helpful abstractions for account validation, serialization, and CPI generation.

Next Steps

Resources

On this page