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.

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).
    • 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.
    • 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.
    • Pool configuration: The TokenAdminRegistry maps each mint to exactly one token pool configuration. This ensures that during cross-chain transfers, only the authorized token pool implementation can interact with the token.

  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.
    • Validation Against Registry: 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.
    • 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 for the token pool to either lock tokens in its Associated Token Account (ATA) or burn them from circulation, depending on the pool implementation.

OffRamp

  1. Verification and Token Pool Validation

    On the destination blockchain, the OffRamp program receives validated CCIP Messages containing information about which tokens to transfer, the intended receiver, and the source chain details. Before finalizing the transfer, the OffRamp performs a series of validations:

    • It checks the TokenAdminRegistry PDA (owned by the Router) to confirm that the provided token pool accounts are the authorized ones for that token mint.
    • It validates that the address lookup table and TokenAdminRegistry PDAs match the mint's registry record to ensure interaction with the correct token pool program.
    • It verifies its own authorization to call the token pool by checking a special PDA, which is derived from the allowed_offramp seed, source chain selector, and offramp program ID. This PDA must exist and be owned by the Router, preventing unauthorized offramps from minting or releasing tokens.

  2. Direct CPI to release_or_mint_tokens

    Once all validations are successful, the OffRamp makes a CPI call to the token pool program, involving the release_or_mint_tokens instruction. For this CPI, the Offramp uses a special PDA signer derived using the external_token_pools_signer seed, which the token pool recognizes as an authorized caller.

Token

On Solana, the token to be transferred across blockchains is an SPL Mint managed by one of the standard Solana token programs, either the original SPL Token or the newer Token-2022. To learn more , read the Tokens compatibility requirements.

Token Pool

A Token Pool is a self-contained program responsible for executing cross-chain token transfers for a specific token.

How Token Pools Work

  • Separate Token Pools Per Blockchain
    • You deploy a corresponding pool program for each blockchain that interacts with your token, then configure remote chains information to enable cross-chain transfers.
  • Token Pool Operations
    • When acting as a source chain pool (called by the Router in ccip_send):
      • BurnMint token pool: Transfers tokens from the sender's ATA to the pool's ATA, then burns them from the pool's ATA.
      • LockRelease token pool: Locks tokens by transferring them from the sender ATA to the pool's ATA.
    • When acting as a destination chain pool (called by the OffRamp):
      • BurnMint token pool: Mints tokens to a receiver's ATA.
      • LockRelease token pool: Transfers (releases) tokens from the pool's ATA to the receiver's ATA.

For an in-depth overview of token pool programs, see the Token Pools page.

Get the latest Chainlink content straight to your inbox.