Solana Integration

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.

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.
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.
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.
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. ITS calls your program’s execute_with_interchain_token instruction via CPI.
  4. Your program receives the tokens and can spend them by signing as the destination_token_authority PDA.

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.0.0-rc.5"


# For GMP (sending and receiving cross-chain messages)
solana-axelar-gateway = { version = "1.0.1", features = ["cpi"] }


# For ITS (sending and receiving cross-chain token transfers)
solana-axelar-its = { version = "1.0.1", features = ["cpi"] }
anchor-spl = "1.0.0-rc.5"

💡

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

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

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.

Edit on GitHub