Cross-Chain Token Standard - Token Pools (SVM)

On SVM-based blockchains (e.g., Solana), a token pool program mediates the cross-chain transfer of cross-chain tokens by coordinating with the SPL Token Program. This guide describes all the requirements that your token pools must meet.

For architectural context and how token pools fit into the complete CCIP system, see Architecture Overview. For token-specific requirements and pool type selection guidance, see Tokens documentation.

Deployment Approaches

Before diving into the technical details, it's important to understand your three deployment options. Each approach offers different levels of control and responsibility based on your operational preferences and infrastructure requirements.

Approach 1: Self-Serve Mode (Recommended for Most Users)

What it is: Chainlink Labs deploys and maintains the standard token pool programs (BurnMint and LockRelease) on Solana Devnet and Mainnet. You simply initialize your token pool from these existing deployed programs.

Key Benefits:

No need to build, audit, or deploy pool programs yourself
Automatic access to upgrades and security fixes
Fastest time to deployment
Lower operational overhead

Who should use this: Token developers that want to integrate with CCIP quickly without managing infrastructure.

How it works:

Program Admin (Chainlink's upgrade authority) deploys the program and initializes the Global Config PDA with:
- self_served_allowed: true (enables user self-service)
- Default router address for the network
- Default RMN remote address for security
Users can initialize pools for their tokens by calling the initialize instruction, provided they control the token's mint authority
New pools automatically inherit the default router and RMN addresses from the Global Config PDA

Approach 2: Self-Deployed Standard Pools

What it is: You build and deploy the standard Chainlink token pool programs yourself, giving you control over the upgrade authority.

Key Benefits:

Full control over when to apply upgrades
Can customize deployment timing and parameters
Maintain upgrade authority for your pools
Use proven, audited standard implementations

Who should use this: Projects that need control over upgrade timing or have specific governance requirements.

How it works: You compile and deploy the Chainlink-provided BurnMint or LockRelease programs to your chosen address, retaining upgrade authority.

Approach 3: Custom Token Pools

What it is: You build your own token pool program with custom logic while ensuring CCIP compatibility.

Key Benefits:

Complete customization for unique token mechanics
Support for specialized features (rebasing, fee-on-transfer, etc.)
Full control over program logic

Who should use this: Projects with unique token mechanics that standard pools cannot accommodate.

Requirements: Must implement all common technical requirements and follow the specifications detailed in the Custom Token Pools section. Pay special attention to decimal compatibility considerations as custom pools require manual decimal conversion implementation.

Token Handling Mechanisms

Before implementing token pools, you need to choose the appropriate token handling mechanism for your cross-chain token transfers. This strategic decision determines which combination of token pools you'll deploy on source and destination blockchains.

The table below summarizes the different token handling mechanisms and the recommended token pools to deploy for each scenario, ensuring a seamless token transfer process.

Token Handling Mechanism	Source Blockchain Token Pool Type	Destination Blockchain Token Pool Type	How it Works
Burn & Mint	BurnMint	BurnMint	- Standard burn and mint mechanism for CCT transfers.
Lock & Mint	LockRelease	BurnMint	- The source blockchain is the issuing blockchain. - The LockRelease token pool must be deployed on the issuing blockchain.
Burn & Unlock	BurnMint	LockRelease	- The destination blockchain is the issuing blockchain. - The BurnMint token pool burns tokens on the source blockchain, and the LockRelease token pool unlocks tokens on the issuing blockchain.
Lock & Unlock	LockRelease	LockRelease	- Tokens are locked on the source blockchain and unlocked on the destination blockchain. - Can result in fragmented liquidity and requires careful management of liquidity across multiple blockchains to avoid stuck token transfers due to insufficient liquidity locked in the token pool on the destination blockchain.

Decimal Compatibility Considerations

Before implementing token pools, it's critical to understand how decimal differences across blockchains can impact your cross-chain token transfers. This section provides strategic guidance for making informed decisions about token deployment and decimal configuration. For initial decimal planning considerations when deploying your token, see Decimal Planning.

The Decimal Challenge

When deploying a token across multiple blockchains, token developers can configure different decimal places for each blockchain. However, this flexibility comes with important trade-offs:

Example Configuration:

Ethereum: 18 decimals (0.123456789123456789)
Solana: 9 decimals (0.123456789)

What Happens During Transfers: When transferring between blockchains with different decimal precision, CCIP automatically handles conversion but must round numbers to match the destination's configured precision.

Impact on Token Supply

Different decimal configurations can affect your token's total supply across chains:

Transfer Direction	Result	Supply Impact
High → Low Precision	Precision loss due to rounding (e.g., 18 decimals → 9 decimals)	Permanent loss: Tokens burned/locked exceed tokens released
Low → High Precision	No precision loss (e.g., 9 decimals → 18 decimals)	No impact: Perfect conversion possible
Equal Precision	No precision loss (e.g., 18 decimals → 18 decimals)	No impact: Perfect 1:1 transfers

Critical Considerations:

BurnMint Pools: Lost precision results in permanently burned tokens on the source chain
LockRelease Pools: Lost precision results in tokens permanently locked in the source pool
Small amounts are most affected by rounding; large transfers typically see minimal percentage impact

Strategic Recommendations

Primary Recommendation: Deploy tokens with the same number of decimals across all blockchains whenever possible. This completely eliminates precision loss during cross-chain transfers.

When Different Decimals Are Necessary:

Only use different decimals when required by blockchain limitations
Clearly communicate rounding risks to users in your UI
Consider implementing transfer warnings for high-to-low precision transfers
Plan for locked/burned token accumulation in your tokenomics

Development Considerations:

Verify decimal configurations on both source and destination before going live
Test small-amount transfers to understand rounding behavior
Consider implementing minimum transfer amounts to minimize relative precision loss

Standard token pools (BurnMint, LockRelease) handle decimal conversion automatically - no additional implementation required.

Custom token pools must implement decimal conversion manually - see Decimal Implementation Requirements for technical details.

Standard Token Pools: An Overview

Chainlink provides two standard token pool types that implement the token handling mechanisms described above. Each pool type implements specific logic for how tokens are managed during cross-chain transfers. The detailed sections below will help you understand the architecture, requirements, and implementation details for each pool type.

BurnMint Token Pool

The BurnMint token pool provides burn and mint operations for cross-chain token transfers:

How It Works

Outbound token transfer (when the SVM chain is the source chain):

User transfers tokens to the pool's Associated Token Account (ATA)
Pool program burns the tokens using the standard SPL burn instruction
Tokens are permanently removed from circulation on the source chain

Inbound token transfer (when the SVM chain is the destination chain):

Pool program mints new tokens using the SPL mint_to instruction
New tokens are created in the user's associated token account (ATA)
Pool program must control the mint_authority for the token

Architecture Components

SVM Program Architecture Overview:

On SVM-based blockchains like Solana, applications consist of programs (executable code) and accounts (data storage). Programs are stateless and store their data in separate accounts.

Program-Derived Addresses (PDAs) are special accounts with addresses deterministically derived from seeds and a program ID. PDAs have no private keys, allowing programs to "sign" for them. This enables secure, predictable account management.

CCIP Token Pool Architecture:

The BurnMint token pool program uses PDAs to organize data into two categories:

Global PDAs: Shared configuration for all pools deployed from this program
Pool-Specific PDAs: Individual configuration for each token's pool

Each token has its own independent pool (one pool per mint), with pool-specific PDAs derived using the mint address as a seed.

Program-Derived Addresses (PDAs):

Global Configuration:

Global Config PDA (seeds: ["config"]): Program-wide settings including self_served_allowed, default router, and RMN remote addresses

Pool-Specific Configuration (per mint):

Pool State PDA (seeds: ["ccip_tokenpool_config", mint]): Token-specific pool configuration, ownership, and operational settings
Pool Signer PDA (seeds: ["ccip_tokenpool_signer", mint]): Signing authority for token operations (burns, mints, transfers)
Chain Config PDAs (seeds: ["ccip_tokenpool_chainconfig", chain_selector, mint]): Per-destination chain configuration including rate limits and remote pool addresses

Mint Authority Management

Mint Authority Control:

The mint authority follows this lifecycle for BurnMint pools:

Required First: Pool Initialization

You must control the token's mint_authority to initialize the pool
The initialize instruction requires the mint authority as the signer
The pool stores you as the owner during initialization
Pool owner must create the Associated Token Account (ATA) for the Pool Signer PDA before pool operations can begin

Ongoing: Pool Management

As the pool owner, you can configure CCIP settings throughout the pool's lifetime:
- Set up chain configurations for new remote chains
- Configure or update rate limits for existing chains
- Manage allowlists and other pool settings
- Add or remove remote pool addresses

When Ready: Mint Authority Transfer

Transfer the mint_authority when you're ready to enable the pool for minting operations
This enables the pool to mint tokens on inbound flows when the SVM chain is the destination
Choose one of two transfer mechanisms (multisig approach strongly recommended for production):

Option 1: Direct Transfer (Simple)

Configuration:

Transfer the mint_authority directly to the Pool Signer PDA

Best suited for:

Development environments
Simple production deployments where the token exclusively integrates with CCIP
Scenarios with a single trusted actor interacting with the token

Limitations:

Only the token pool can mint tokens
Reduced flexibility for future integrations

Option 2: Multisig Configuration (Recommended for Production)

Configuration:

Set up a 1-of-N SPL token multisig account as the mint authority
Include the Pool Signer PDA as one of the authorized signers
Retain other signers under your exclusive control

Key benefits:

Enables multiple authorized parties to mint tokens
Maintains governance control through other multisig signers
Provides extensibility for future integrations
Enhanced security through distributed control

Requirements:

Must use SPL token multisig - other multisig implementations are not supported
The Pool Signer PDA must be included as one of the multisig signers
Multisig configuration must allow the pool to sign minting transactions independently

After this transfer, the pool can mint tokens when the SVM chain is the destination chain for cross-chain transfers.

Access Control

Understanding who can call which instructions is critical for secure pool operation and proper integration. This table shows the authorization model for all BurnMint token pool instructions, helping you understand the security boundaries and operational responsibilities.

Instruction Category	Instruction	Program Upgrade Authority	Pool Owner	Rate Limit Admin*	Router Authority
Global Config	`init_global_config`	✅	❌	❌	❌
	`update_self_served_allowed`	✅	❌	❌	❌
	`update_default_router`	✅	❌	❌	❌
	`update_default_rmn`	✅	❌	❌	❌
Pool Lifecycle	`initialize`	✅ OR Mint Authority	❌	❌	❌
Ownership	`transfer_ownership`	❌	✅	❌	❌
	`accept_ownership`	❌	✅**	❌	❌
Security	`transfer_mint_authority_to_multisig`	✅	❌	❌	❌
	`configure_allow_list`	❌	✅	❌	❌
	`remove_from_allow_list`	❌	✅	❌	❌
Chain Config	`init_chain_remote_config`	❌	✅	❌	❌
	`edit_chain_remote_config`	❌	✅	❌	❌
	`append_remote_pool_addresses`	❌	✅	❌	❌
	`set_chain_rate_limit`	❌	✅	✅	❌
	`delete_chain_config`	❌	✅	❌	❌
Cross-Chain	`lock_or_burn_tokens`	❌	❌	❌	✅
	`release_or_mint_tokens`	❌	❌	❌	✅

Notes:

* Rate Limit Admin: Optional role. Only useful if pool owner wants another address to manage rate limits
** accept_ownership: Must be the proposed_owner from transfer_ownership
Critical: Pool Signer PDA MUST have mint capability (direct or via multisig) for minting operations
Critical: Pool owner must create the Associated Token Account (ATA) for the Pool Signer PDA before pool operations can begin

When to Use

Key Characteristics:

Requires mint authority control for initialization, then transfer to pool for operations
Total supply can vary across chains during transfers
No liquidity management needed
Suitable for tokens designed to expand/contract supply

Choose BurnMint When:

You control the mint_authority for your token (required for initialization)
You are willing to transfer mint authority to the pool after CCIP registration
Your token is designed to have variable supply across chains
You want to avoid liquidity management complexity
Your token participates in Burn and Mint or Lock and Mint/Burn and Unlock token handling mechanisms

For detailed mint authority configuration options, see Mint Authority for BurnMint.

LockRelease Token Pool

The LockRelease token pool implements a lock-and-release strategy for cross-chain token transfers:

How It Works

Outbound token transfer (when the SVM chain is the source chain):

User transfers tokens to the pool's Associated Token Account (ATA)
Pool program "locks" tokens by holding them in its account
Tokens remain in circulation but are held by the pool as escrow
No tokens are destroyed - total supply remains constant

Inbound token transfer (when the SVM chain is the destination chain):

Pool program transfers tokens from its ATA to the user's ATA
Pool must have sufficient token balance (liquidity) to fulfill transfers
No minting occurs - only transfers of existing tokens from the pool's reserves

Architecture Components

SVM Program Architecture Overview:

On SVM-based blockchains like Solana, applications consist of programs (executable code) and accounts (data storage). Programs are stateless and store their data in separate accounts.

CCIP Token Pool Architecture:

The LockRelease token pool program uses the same PDA structure as BurnMint pools, organizing data into two categories:

Global PDAs: Shared configuration for all pools deployed from this program
Pool-Specific PDAs: Individual configuration for each token's pool

Each token has its own independent pool (one pool per mint), with pool-specific PDAs derived using the mint address as a seed.

Program-Derived Addresses (PDAs):

Global Configuration:

Global Config PDA (seeds: ["config"]): Program-wide settings including self_served_allowed, default router, and RMN remote addresses

Pool-Specific Configuration (per mint):

Pool State PDA (seeds: ["ccip_tokenpool_config", mint]): Token-specific pool configuration, ownership, and operational settings
Pool Signer PDA (seeds: ["ccip_tokenpool_signer", mint]): Signing authority for token operations (transfers, liquidity management)
Chain Config PDAs (seeds: ["ccip_tokenpool_chainconfig", chain_selector, mint]): Per-destination chain configuration including rate limits and remote pool addresses

Liquidity Management

Pool Initialization:

Program upgrade authority can always initialize pools
When self-serve is enabled (self_served_allowed: true), the token's mint authority can also initialize pools
Pool is configured with liquidity acceptance settings during initialization
Pool owner must create the Associated Token Account (ATA) for the Pool Signer PDA before pool operations can begin

Ongoing Liquidity Operations:

Rebalancer Role: Designated address that can provide or withdraw pool liquidity
Liquidity Acceptance: Configurable setting (can_accept_liquidity) controls whether the pool accepts new liquidity
Liquidity Operations:
- provide_liquidity: Rebalancer adds tokens to pool reserves
- withdraw_liquidity: Rebalancer removes tokens from pool reserves (can transfer to other pools)

Liquidity Requirements:

Pool must maintain sufficient token balance to fulfill cross-chain transfers
Insufficient liquidity will cause transfer failures
Rebalancer responsible for maintaining adequate liquidity across all supported chains

Access Control

Understanding who can call which instructions is critical for secure pool operation and proper integration. This table shows the authorization model for all LockRelease token pool instructions, helping you understand the security boundaries and operational responsibilities.

Instruction Category	Instruction	Program Upgrade Authority	Pool Owner	Rate Limit Admin*	Router Authority	Rebalancer
Global Config	`init_global_config`	✅	❌	❌	❌	❌
	`update_self_served_allowed`	✅	❌	❌	❌	❌
	`update_default_router`	✅	❌	❌	❌	❌
	`update_default_rmn`	✅	❌	❌	❌	❌
Pool Lifecycle	`initialize`	✅ OR Mint Authority	❌	❌	❌	❌
Ownership	`transfer_ownership`	❌	✅	❌	❌	❌
	`accept_ownership`	❌	✅**	❌	❌	❌
Security	`configure_allow_list`	❌	✅	❌	❌	❌
	`remove_from_allow_list`	❌	✅	❌	❌	❌
Liquidity Mgmt	`set_rebalancer`	❌	✅	❌	❌	❌
	`set_can_accept_liquidity`	❌	✅	❌	❌	❌
	`provide_liquidity`	❌	❌	❌	❌	✅
	`withdraw_liquidity`	❌	❌	❌	❌	✅
Chain Config	`init_chain_remote_config`	❌	✅	❌	❌	❌
	`edit_chain_remote_config`	❌	✅	❌	❌	❌
	`append_remote_pool_addresses`	❌	✅	❌	❌	❌
	`set_chain_rate_limit`	❌	✅	✅	❌	❌
	`delete_chain_config`	❌	✅	❌	❌	❌
Cross-Chain	`lock_or_burn_tokens`	❌	❌	❌	✅	❌
	`release_or_mint_tokens`	❌	❌	❌	✅	❌

Notes:

* Rate Limit Admin: Optional role. Only useful if pool owner wants another address to manage rate limits
** accept_ownership: Must be the proposed_owner from transfer_ownership
Critical: Pool owner must create the Associated Token Account (ATA) for the Pool Signer PDA before pool operations can begin

When to Use

Key Characteristics:

Program upgrade authority can always initialize pools; mint authority can self-initialize when accessible
No mint authority required for ongoing operations (unlike BurnMint)
Fixed total supply per chain - tokens are only transferred, never created or destroyed
Requires active liquidity management and funding
Suitable for tokens where you want to retain mint authority control OR where mint authority is no longer accessible

Choose LockRelease When:

You want to retain control of the token's mint authority (not transfer it to the pool)
Your token's mint authority is disabled/revoked (e.g., to cap token supply) or otherwise inaccessible
You prefer not to delegate minting capabilities to the token pool
You want to maintain fixed total supply on each blockchain
You can manage liquidity requirements and rebalancing across chains
You have operational capacity to monitor and maintain pool liquidity levels
Your token participates in Lock and Mint/Burn and Unlock or Lock and Unlock token handling mechanisms

Both pool types are built on the shared base-token-pool foundation, which provides common functionality including rate limiting, allowlists, cross-chain configuration, and event handling.

Next Steps: Pool Configuration

After deploying your token pool using any of the approaches above, you'll need to configure it for cross-chain operations. This includes:

Setting up remote chain configurations
Configuring rate limits for cross-chain transfers
Managing allowlists and access controls
Setting up liquidity management (for LockRelease pools)

For detailed instructions on configuring your token pool parameters, see Token Pool Configuration.

Custom Token Pools

If the standard BurnMint and LockRelease token pool programs don't meet your requirements, you can create a custom token pool program that is compatible with CCIP. This advanced approach gives you complete control over token handling logic while maintaining CCIP compatibility.

When to Build Custom Token Pools

Consider building a custom token pool when:

Complex Token Mechanics: Your token has unique behavior like rebasing, fee-on-transfer, or complex reward mechanisms
Specialized Business Logic: You need custom validation, compliance checks, or integration with other protocols
Governance Requirements: You need custom access control patterns

Standard pools are sufficient for:

Basic SPL tokens with standard mint/burn/transfer functionality
Tokens that don't require custom logic during cross-chain transfers
SPL tokens and Token-2022 tokens

Technical Requirements

All custom token pools must implement the following requirements to be CCIP-compatible:

Required Program-Derived Addresses (PDAs)

Your custom token pool must use these exact PDA seeds so the CCIP Router can correctly derive and interact with your pool accounts:

Required PDAs and Their Seeds:

Global Config PDA
- Seeds: ["config"]
- Purpose: Program-wide settings including self_served_allowed, default router, and RMN addresses
- Used by: Program admin for deployment configuration
Pool State PDA
- Seeds: ["ccip_tokenpool_config", mint_address]
- Purpose: Token-specific pool configuration, ownership, and operational settings
- Used by: Pool management and cross-chain operations
Pool Signer PDA
- Seeds: ["ccip_tokenpool_signer", mint_address]
- Purpose: Signing authority for token operations (burns, mints, transfers)
- Used by: Token transfer operations and mint authority control
Chain Config PDAs
- Seeds: ["ccip_tokenpool_chainconfig", chain_selector, mint_address]
- Purpose: Per-destination chain configuration including rate limits and remote pool addresses
- Used by: Cross-chain transfer validation and routing

Mandatory Instructions

When CCIP interacts with your custom token pools, it expects the presence of the following functions with exact signatures:

For source chain operations (locking or burning tokens):
- lock_or_burn_tokens(ctx: Context<TokenOnramp>, lock_or_burn: LockOrBurnInV1,) -> Result<LockOrBurnOutV1>
- This function handles token operations when your chain is the source of a cross-chain transfer
- Read the API reference to learn more about the parameters
For destination chain operations (releasing or minting tokens):
- release_or_mint_tokens(ctx: Context<TokenOfframp>, release_or_mint: ReleaseOrMintInV1,) -> Result<ReleaseOrMintOutV1>
- This function handles token operations when your chain is the destination of a cross-chain transfer
- Read the API reference to learn more about the parameters

Integration with Base Token Pool

All custom token pools should integrate the base-token-pool library for core functionality:

Ownership management: Pool ownership and proposed ownership transfers
Rate limiting: Inbound and outbound rate limit controls per destination chain
Cross-chain configuration: Remote pool addresses and chain-specific settings
Access control: Allowlists and permission management
Event handling: Standardized event emissions for monitoring
Decimal conversion: Use to_svm_token_amount for proper decimal handling between chains

Decimal Implementation Requirements

All custom token pools must implement proper decimal conversion to handle tokens with different decimal configurations across blockchains. For strategic guidance on decimal compatibility decisions, see Decimal Compatibility Considerations.

Required Implementation:

All standard token pools (BurnMint, LockRelease) automatically call to_svm_token_amount during the release_or_mint_tokens flow. If you build a custom token pool, you must use to_svm_token_amount from the base token pool library.

How to_svm_token_amount Works:

Reads the incoming amount from the source chain
Converts it from the source token decimals to the local token decimals
Returns a u64 amount or an error if the conversion exceeds u64::Max (maximum token supply on SVM-based blockchains)

Implementation Examples

Example 1: Rebasing Token Pool

Use Case: Rebasing tokens adjust their supply periodically based on external parameters (e.g., price, yield). These tokens require custom logic to handle rebasing events during cross-chain transfers.

Implementation Approach:

Source Blockchain: Instead of burning or locking a specific amount of tokens, track "underlying shares" that represent proportional ownership. In lock_or_burn_tokens, convert the user's tokens into an internal share count and store that in LockOrBurnOutV1.dest_pool_data for the destination token pool.
Destination Blockchain: In release_or_mint_tokens, parse the share count from ReleaseOrMintInV1.source_pool_data and convert those shares back into the current token amount based on the latest rebase. If your token supply has been rebased upward/downward since the transfer initiated, recalculate the final amount before minting or transferring to the user's ATA.

Example 2: Fee-on-Transfer Token Pool

Use Case: Tokens that deduct fees during transfers need custom logic to ensure cross-chain transfer amounts are accurate.

Implementation Approach:

Source Blockchain: In lock_or_burn_tokens, calculate the net amount after fees and ensure the correct amount is locked/burned. Store the original intended amount in dest_pool_data.
Destination Blockchain: In release_or_mint_tokens, use the original intended amount from source_pool_data to mint/release the correct amount, accounting for any destination-side fees.

Development Resources

Implementation References:

BurnMint Token Pool - Standard burn/mint implementation
LockRelease Token Pool - Standard lock/release implementation
Base Token Pool Library - Shared functionality foundation

Testing and Validation:

Test with CCIP Router integration to ensure proper PDA derivation
Validate decimal conversion handling for cross-chain transfers
Ensure rate limiting and access control functions work correctly
Test both source and destination chain operations thoroughly

Cross-Chain Token Standard - Token Pools (SVM)

Get the latest Chainlink content straight to your inbox.