CCIP v1.6.0 SVM Router API Reference

Router

Below is a complete API reference for the ccip_send instruction from the CCIP Router program.

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.