CCIP v1.6.0 SVM Router API Reference

Router

Below is a complete API reference for the CCIP Router program instructions.

Message Sending

ccip_send

This instruction is the entry point for sending a cross-chain message from an SVM-based blockchain to a specified destination blockchain.

fn ccip_send(
    ctx: Context<CcipSend>,
    dest_chain_selector: u64,
    message: SVM2AnyMessage,
    token_indexes: Vec<u8>
) -> Result<[u8; 32]>;

Parameters

Context (Accounts)

These are the required accounts passed alongside the instructions. For relevant PDAs, the instructions on how to derive seeds are given below.

How remaining_accounts and token_indexes Work

When you call the Router's ccip_send instruction, you pass:

1. A list of token_amounts you want to transfer cross-chain.
2. A slice of remaining_accounts containing the per-token PDAs (e.g., user token ATA, pool config, token admin registry PDA, etc.).
3. A token_indexes array tells the Router where in remaining_accounts each token's sub-slice begins.

Reason for remaining_accounts

On Solana, each Anchor instruction has a fixed set of named accounts. However, CCIP must handle any number of tokens, each requiring many accounts. Rather than define a massive static context, the Router uses Anchor's dynamic ctx.remaining_accounts: All token-specific accounts are packed into one slice.

Reason for token_indexes

The Router must figure out which segment of that slice corresponds to token #0, token #1, etc. So you provide an integer offset in token_indexes[i] indicating where the ith token's accounts begin inside remaining_accounts.

The Router:

• Slices out [start..end) for the ith token's accounts. The subslice is from start up to but not including end. This is how you indicate that the token i's accounts occupy positions start, start+1, …, end-1.
• Validates each account.
• Calls the appropriate token pool to the lock-or-burn operation on them.

Structure of Each Token's Sub-slice

Inside each token's sub-slice, the Router expects:

1. The user's token account (ATA).
2. The token's chain PDAs.
3. Lookup table PDAs, token admin registry, pool program, pool config, pool signer, token program, the mint, etc.

In total, it is typically 12 or more accounts per token. Repeat that "per-token chunk" of ~12 accounts for each token if you have multiple tokens. These accounts are extracted in this order:

Examples

One Token Transfer

Suppose you want to send one token (myMint) cross-chain:

1. token_amounts: length = 1, e.g. [{ token: myMint_pubkey, amount: 1000000 }].
2. token_indexes: [1]. Meaning:
   • The 0th token's remaining_accounts sub-slice will be [token_indexes[0] .. endOfArray), i.e. [1..].
   • The user's Associated Token Account (ATA) for that token is found at remaining_accounts[0].
3. Your remaining_accounts must have:
   • 1 user's ATA (the sender ATA for the single token).
   • 12 pool-related accounts (pool config, chain config, token program, etc.). That is 13 total.

Two Token Transfers

Suppose you want to send two tokens (mintA and mintB) cross-chain:

1. token_amounts: length = 2, e.g. [{ token: mintA_pubkey, amount: 1000000 },{ token: mintB_pubkey, amount: 2000000 } ].
2. token_indexes must be length=2 since there are two tokens, and token_indexes = [2, 14]. Explanation:
   • After we skip the user ATAs at indices [0..2), we want the next 12 accounts for the first token to lie in [2..14), and then the next 12 for the second token to lie in [14..end).
   • The Router program will use token_indexes:
     1. For the first token: The sub slice is [2..14).
     2. For the second token: The sub slice is [14…endOfArray).
3. Your remaining_accounts must have:
   • 2 user ATAs (one for mintA, one for mintB).
   • 12 pool accounts for mintA.
   • 12 pool accounts for mintB.

Thus 2 + 12 + 12 = 26 accounts in remaining_accounts.

get_fee

Queries the Router for the fee required to send a cross-chain message. This is a permissionless call that calculates fees without verifying curse status to avoid RMN CPI overhead.

fn get_fee(
    ctx: Context<GetFee>,
    dest_chain_selector: u64,
    message: SVM2AnyMessage,
) -> Result<GetFeeResult>;

Parameters

Return Value

struct GetFeeResult {
    pub amount: u64,    // Fee amount in the specified fee token
    pub juels: u128,    // Fee value converted to LINK juels
    pub token: Pubkey,  // The fee token address
}

Context (Accounts)

Remaining Accounts Structure for get_fee

The remaining_accounts must be provided in this specific order for each token being transferred:

1. Billing Token Config: Token-specific billing configuration under the Fee Quoter program
   • Derivation: ["fee_billing_token_config", token_mint] under the fee_quoter program
2. Per-Chain Per-Token Config: Chain and token specific fee overrides under the Fee Quoter program
   • Derivation: ["per_chain_per_token_config", dest_chain_selector, token_mint] under the fee_quoter program

Example for 2 tokens:

remaining_accounts = [
    billing_config_token_A,       // Token A billing config
    per_chain_config_token_A,     // Token A per-chain config
    billing_config_token_B,       // Token B billing config
    per_chain_config_token_B,     // Token B per-chain config
]

Usage Notes

• Permissionless: Anyone can call this instruction to query fees
• No Curse Check: Does not verify RMN curse status for performance
• Fee Calculation: Returns both the fee amount in the specified token and the equivalent value in LINK juels
• Token Support: Supports both native SOL and SPL token fee payments

Token Administration

These instructions manage token administrator roles and token registration with CCIP.

owner_propose_administrator

Proposes a token administrator for a given SPL token. This is used for self-service registration when you control the token's mint authority.

fn owner_propose_administrator(
    ctx: Context<RegisterTokenAdminRegistryByOwner>,
    token_admin_registry_admin: Pubkey,
) -> Result<()>;

Parameters

Context (Accounts)

Authorization

• Caller: Must be the SPL token's mint_authority
• Registry State: TokenAdminRegistry PDA must not already exist for this mint

owner_override_pending_administrator

Overrides the pending administrator before they accept the role. Can only be called by the token's mint authority.

fn owner_override_pending_administrator(
    ctx: Context<OverridePendingTokenAdminRegistryByOwner>,
    token_admin_registry_admin: Pubkey,
) -> Result<()>;

Parameters

Context (Accounts)

Authorization

• Caller: Must be the SPL token's mint_authority
• Registry State: TokenAdminRegistry PDA must exist but have no accepted administrator yet

ccip_admin_propose_administrator

Proposes a token administrator via CCIP governance. Used when the caller cannot access the mint authority.

fn ccip_admin_propose_administrator(
    ctx: Context<RegisterTokenAdminRegistryByCCIPAdmin>,
    token_admin_registry_admin: Pubkey,
) -> Result<()>;

Parameters

Context (Accounts)

Authorization

• Caller: Must be the Router program's upgrade authority
• Registry State: TokenAdminRegistry PDA must not already exist for this mint

accept_admin_role_token_admin_registry

Accepts the administrator role for a token. Must be called by the pending administrator to finalize registration.

fn accept_admin_role_token_admin_registry(
    ctx: Context<AcceptAdminRoleTokenAdminRegistry>,
) -> Result<()>;

Parameters

This instruction takes no additional parameters.

Context (Accounts)

Authorization

• Caller: Must match the pending_administrator field in the TokenAdminRegistry PDA
• Registry State: TokenAdminRegistry PDA must exist with a pending administrator

transfer_admin_role_token_admin_registry

Transfers the administrator role to a new administrator. This is a two-step process requiring the new admin to accept.

fn transfer_admin_role_token_admin_registry(
    ctx: Context<ModifyTokenAdminRegistry>,
    new_admin: Pubkey,
) -> Result<()>;

Parameters

Context (Accounts)

Authorization

• Caller: Must be the current administrator listed in the TokenAdminRegistry PDA
• Registry State: TokenAdminRegistry PDA must exist with an active administrator

set_pool

Sets the Address Lookup Table that defines the token pool for cross-chain transfers. This enables or disables a token for CCIP.

fn set_pool(
    ctx: Context<SetPoolTokenAdminRegistry>,
    writable_indexes: Vec<u8>,
) -> Result<()>;

Parameters

Context (Accounts)

Authorization

• Caller: Must be the current administrator listed in the TokenAdminRegistry PDA
• Pool Validation: If not zero address, the lookup table must contain at least the minimum required accounts

Pool Status

• Enable Token: Set pool_lookuptable to a valid Address Lookup Table with required pool accounts
• Disable Token: Set pool_lookuptable to zero address (Pubkey::default()) to delist from CCIP

set_pool_supports_auto_derivation

Configures whether a token pool supports automatic account derivation for cross-chain transfers.

fn set_pool_supports_auto_derivation(
    ctx: Context<EditPoolTokenAdminRegistry>,
    mint: Pubkey,
    supports_auto_derivation: bool,
) -> Result<()>;

Parameters

Context (Accounts)

Authorization

• Caller: Must be the current administrator listed in the TokenAdminRegistry PDA

Auto-Derivation Impact

• Enabled (true): The Router validates only static accounts in the Address Lookup Table, allowing the pool to handle additional dynamically-derived accounts
• Disabled (false): The Router validates all accounts against the static Address Lookup Table, expecting a complete and fixed account set