Cross-Chain Token Standard - Architecture (SVM)

The Cross-Chain Token (CCT) architecture offers a streamlined, self-service approach to enabling cross-chain operations to any token. The CCT standard is token logic agnostic, meaning token developers can deploy pre-audited token pool contracts to turn any SPL-compatible token into a CCT or deploy their own custom token pool contracts for bespoke token use cases. Importantly, CCTs do not require token developers to inherit any CCIP-specific code within their token's smart contract.

The CCT standard leverages the Chainlink Cross-Chain Interoperability Protocol (CCIP) for cross-chain transfers and allows token developers to configure, manage, and transfer tokens across multiple blockchains.

The architecture diagrams below provide an overview of how CCT fits within the CCIP ecosystem, illustrating the interaction between key components.

Source Chain

Cross-Chain Token Standard - Architecture (SVM) - Source Chain

Destination Chain

Cross-Chain Token Standard - Architecture (SVM) - Destination Chain

The CCIP architecture for SVM-based blockchains (e.g., Solana) is described on this page, where we focus specifically on cross-chain token management.

Architecture

This document explains the four key components of CCIP's Cross-Chain Token architecture on SVM:

  1. Token: SPL token requirements and registration for CCIP integration
  2. Token Pool: Self-contained programs that execute cross-chain token operations
  3. Router: Central coordinator for token administration and outbound transfers
  4. OffRamp: Handler for inbound cross-chain token reception and release

Each component builds on the previous, forming a secure, integrated system for cross-chain token transfers. The sections below are organized in dependency order - understanding each component provides the foundation for understanding how they work together in the complete architecture.

Token

In the Cross-Chain Token (CCT) architecture, the token is an SPL Mint managed by either the standard SPL Token program or Token-2022 (Token Extensions). To enable cross-chain transfers, every token requires:

  1. Registration: Establishes a token administrator role and creates the TokenAdminRegistry PDA that governs CCIP integration
  2. Pool-Specific Requirements: Token requirements vary by chosen pool type:
    • BurnMint pools: Must support mint_to and burn instructions; mint authority must be transferable to the pool
    • LockRelease pools: Must support transfer_checked instruction; no mint authority requirements
  3. Compatibility: Must support standard token interfaces including Associated Token Accounts and provide decimal precision

For detailed compatibility requirements and pool type selection guidance, see Tokens documentation. For the complete registration process and administrator role management, see Registration & Administration.

Token Pool

A Token Pool is a self-contained program responsible for executing cross-chain token transfers for a specific token. Each token must have exactly one pool per blockchain, deployed using one of three approaches: self-serve mode (recommended), self-deployed standard pools, or custom pools.

Cross-Chain Token Operations:

  • Source Chain Operations (called by Router during ccip_send):

    • BurnMint pools: Transfer tokens from sender's ATA to pool's ATA, then burn from pool's ATA
    • LockRelease pools: Lock tokens by transferring from sender's ATA to pool's ATA

  • Destination Chain Operations (called by OffRamp during execute):

    • BurnMint pools: Mint tokens directly to receiver's ATA
    • LockRelease pools: Release tokens by transferring from pool's ATA to receiver's ATA

For comprehensive implementation details, deployment approaches, and technical requirements, see Token Pools documentation.

Router

The CCIP Router program is central to cross-chain token management. It has two flows:

  1. Token Administration

    • TokenAdminRegistry (one PDA per mint): Stores the designated CCIP token administrator public key for a specific token mint (distinct from the SPL token's own mint authority) and references the token's pool address lookup table (ALT). The PDA is derived using seeds [seed::TOKEN_ADMIN_REGISTRY, mint.key().as_ref()]. This registry is created during token registration (see Token section) and governs all subsequent CCIP operations for that token.

    • Token Pool Address Lookup Table: A Solana address lookup table that precisely defines the set of account addresses (including pool configuration PDAs, pool signer PDAs, and other required accounts) that are authorized for cross-chain operations with this token. The ALT contains a minimum of 9 required accounts in a specific order.

    • Administrator Methods: The token administrator can register or update cross-chain support for their mint through a sequence of instructions:

      1. owner_propose_administrator: Initiated by the mint authority to designate a token administrator.
      2. accept_admin_role_token_admin_registry: Confirmation by the proposed administrator to accept the role.
      3. set_pool: Links the token to a specific token pool configuration via an address lookup table, including writable account indexes for proper permission management.

      For detailed step-by-step procedures, sequence diagrams, and complete registration workflows, see Registration & Administration.

    • Pool configuration: The TokenAdminRegistry maps each mint to exactly one token pool configuration through the ALT. This ensures that during cross-chain transfers, only the authorized token pool implementation can interact with the token. The registry also includes a supports_auto_derivation flag for enhanced account derivation capabilities.

    • Security Architecture: The one-to-one mapping between tokens and pools provides critical security guarantees:

      • Single Authorized Pool: Each token mint can only have one authorized pool configuration, preventing unauthorized token handling
      • Atomic Pool Updates: Changing pool configurations requires updating the entire ALT reference, ensuring consistent state
      • Access Control: Only the registry administrator can modify pool assignments, maintaining strict governance

    • Enhanced Account Derivation: When supports_auto_derivation is enabled, token pools can dynamically derive additional accounts during cross-chain operations. This allows pools to handle complex transfer scenarios with varying account requirements while maintaining security through the registry's controlled environment.

  2. Lock or Burn Flow (when sending tokens cross-chain)

    • ccip_send entrypoint: When a CCIP sender initiates a cross-chain token transfer, they invoke the ccip_send instruction on the Router, providing the token mint, amount, destination chain, receiver address, and other transaction parameters.
    • Multi-step Validation: The Router performs comprehensive validation:
      • Verifies the destination chain is not cursed (via RMN Remote CPI)
      • Checks sender authorization against allow-list if enabled
      • Validates token amounts are non-zero
      • Ensures proper account relationships and permissions
    • Registry Validation: The sender must provide the token pool account addresses as part of the transaction. The Router validates these accounts by checking them against the addresses stored in the address lookup table (ALT) referenced by the mint's TokenAdminRegistry PDA, including proper writable permissions.
    • Fee Processing: Before token interaction, the Router handles fee collection either in native SOL (with wrapping to WSOL) or supported fee SPL tokens through the fee quoter program.
    • CPI to lock_or_burn_tokens: After validation, the Router executes a CPI call to the token pool's lock_or_burn_tokens instruction, passing the appropriate context including nonce information and destination chain details for the token pool to either lock tokens in its Associated Token Account (ATA) or burn them from circulation, depending on the pool implementation (see Token Pool section for operation details).

OffRamp

The CCIP OffRamp program handles cross-chain token reception and release on the destination chain. This section focuses specifically on the execute phase. For the complete OffRamp functionality including commit phase and general message processing, see OffRamp Components.

During the execute phase, when processing messages containing token transfers, the OffRamp performs comprehensive token-specific validations and operations.

  1. Token Pool Authorization Validation

    Before releasing or minting tokens, the OffRamp validates its authorization to interact with token pools:

    • Router Authorization Check: Verifies a special PDA exists, derived using seeds [seed::ALLOWED_OFFRAMP, source_chain_selector.to_le_bytes().as_ref(), offramp.key().as_ref()] with the Router as the program ID. This PDA must be owned by the Router, ensuring only authorized OffRamps can trigger token operations.
    • TokenAdminRegistry Validation: Checks the TokenAdminRegistry PDA (owned by the Router) to confirm the provided token pool accounts match the authorized configuration for the token mint.
    • Address Lookup Table Verification: Validates that the address lookup table and TokenAdminRegistry PDAs correspond to the mint's registry record, ensuring interaction with the correct token pool program.

  2. Token Pool Operations

    Once authorization is confirmed, the OffRamp executes token operations:

    • CPI to release_or_mint_tokens: Makes a cross-program invocation to the token pool's release_or_mint_tokens instruction, passing the validated cross-chain token transfer details.
    • Authorization Signer: Uses the external_token_pools_signer PDA as the CPI signer, derived using seeds [seed::EXTERNAL_TOKEN_POOLS_SIGNER, pool_program.key().as_ref()] with the OffRamp as the program ID. Token pools recognize this as an authorized caller from the OffRamp.
    • Token Balance Verification: Validates that the recipient's Associated Token Account receives the correct amount of tokens as specified by the pool's response.

  3. Cross-Chain Token Operations

    The OffRamp handles different token pool types based on their configuration:

    • BurnMint token pools: Mint new tokens directly to the recipient's ATA
    • LockRelease token pools: Transfer (release) tokens from the pool's ATA to the recipient's ATA

The OffRamp ensures secure token operations by leveraging the same TokenAdminRegistry and address lookup table system established by the Router (see Token section), maintaining the one-to-one mapping between tokens and their authorized pools while providing the necessary authorization for cross-chain token reception.

Component Integration

The four components work together to enable secure cross-chain transfers:

  1. Token Registration: Creates the TokenAdminRegistry PDA that authorizes all subsequent operations and links to the designated token pool
  2. Token Pool Deployment: Provides the execution logic for transfers, with the specific pool type (BurnMint or LockRelease) determined by the token's requirements and operational preferences
  3. Router Coordination: Manages token administration through the TokenAdminRegistry and validates outbound transfers by ensuring proper authorization against the pool's Address Lookup Table
  4. OffRamp Execution: Validates authorization against the same TokenAdminRegistry system and executes inbound transfers through CPI calls to the authorized token pool

This architecture ensures that every cross-chain token operation is governed by the initial registration decision, maintaining security and consistency across the entire transfer lifecycle. The one-to-one mapping between tokens and pools, established during registration and enforced by all components, provides the foundation for secure cross-chain token transfers.

Get the latest Chainlink content straight to your inbox.