Cross-Chain Token Standard - Upgradability (SVM)

Token pool upgradability on SVM-based blockchains (e.g., Solana) depends entirely on which deployment approach you choose. Your upgrade responsibilities and capabilities vary significantly based on whether you use self-serve mode, deploy standard pools yourself, or build custom pools.

Upgrade Approaches by Deployment Type

Your upgrade experience depends entirely on which deployment approach you chose when setting up your token pool:

Approach 1: Self-Serve Mode (Recommended - No Action Required)

How it works:

This approach follows the same pattern as SPL Token programs on Solana: you create and manage your own token pools (like creating your own mints), but the underlying token pool programs are maintained by the program authority through established governance processes.

What it means for upgrades:

• Governance-controlled upgrades: The standard BurnMint and LockRelease programs are upgraded through CCIP's governance process involving multisig approvals, timelock reviews, and node operator oversight
• Seamless updates: Security fixes and feature updates are deployed through the governance process without breaking your pool configuration or mint authority
• No action required: You don't manage program upgrades, similar to how you don't upgrade the SPL Token program when using standard Solana tokens
• Preserved functionality: Updates happen at the program level while your individual pool state and configuration remain intact

Your responsibilities:

• None - program upgrades are handled through CCIP governance
• Monitor CCIP announcements for new features or breaking changes
• Test your integration after major protocol updates

Benefits:

• Always up-to-date with latest security patches through proven governance
• No operational overhead for program upgrade management
• Professional maintenance through decentralized governance
• Immediate access to new CCIP features

Approach 2: Self-Deployed Standard Pools (User-Controlled Upgrades)

What it means for upgrades:

• You control the upgrade authority for your deployed standard pool programs
• Manual upgrades: You decide when to apply updates from the Chainlink repository
• Full control: You can customize timing, test extensively, and coordinate with your governance

Your responsibilities:

• Monitor Chainlink repository for new releases
• Test upgrades in development environments
• Execute upgrade transactions using Solana CLI or Anchor tooling
• Coordinate upgrades with your governance/operational processes

Approach 3: Custom Token Pools (User-Controlled Upgrades)

What it means for upgrades:

• You control the upgrade authority for your custom pool program
• Custom development: You develop your own upgrades and improvements
• Complete responsibility: All upgrade planning, development, and execution is your responsibility

Your responsibilities:

• Develop custom upgrade code
• Ensure CCIP compatibility after upgrades
• Test thoroughly with CCIP Router integration
• Execute upgrade transactions
• Monitor for breaking changes in CCIP protocol updates

In-Place Upgrades (Approaches 2 & 3 Only)

When you control the upgrade authority, in-place upgrades provide significant benefits:

Benefits of In-Place Upgrades

1. Retain Mint Authority (Burn and Mint Pools): SPL tokens have a single mint_authority. When you delegate this authority to a Burn and Mint token pool program, that program holds the exclusive rights to mint tokens. As detailed in the Mint Authority for BurnMint section, in-place upgrades allow you to:

   • Maintain Control: Upgrade the pool code without reassigning the mint authority, which avoids the complexity of modifying the multisig membership or reconfiguring authorities.
   • Reduce Overhead: Avoid manual reassignments, such as adding a new pool to the multisig and removing the old one, thereby simplifying maintenance and reducing the risk of errors.

2. Preserve User Workflow (All Pools): On SVM-based blockchains, instructions require specifying all involved accounts, including the token pool program ID. If you redeploy your pool to a new Program ID, users and integrators must update their transaction code to reference it. In-place upgrades keep the original ID so that existing references and account parameters remain valid.

Best Practices for User-Controlled Upgrades

Governance and Security

1. Secure Upgrade Authority Management

   • Configure the upgrade authority to a trusted multisig or governance program
   • Never use single-key control for production pools
   • Implement time delays and approval processes for critical upgrades

2. Plan Governance Processes

   • Establish clear governance rules for when and how upgrades are approved
   • Consider community input for significant changes
   • Document upgrade procedures and emergency response plans

Development and Testing

3. Comprehensive Testing

   • Develop and validate pool updates in test environments first
   • Test integration with CCIP Router and cross-chain operations
   • Verify all existing functionality works after upgrade
   • Test edge cases and error conditions

4. Backward Compatibility

   • Design upgrades to maintain compatibility with existing state accounts and PDAs
   • Ensure existing user configurations remain valid
   • Plan migration strategies for breaking changes

Execution

5. Upgrade Execution

   • Use Solana CLI or Anchor tooling to execute upgrade transactions
   • Perform upgrades during low-traffic periods when possible
   • Have rollback plans ready in case of issues
   • Monitor system behavior immediately after upgrades

6. Prefer Upgrades Over Redeployment

   • In-place upgrades preserve all existing references and authorities
   • Redeployment forces re-registration, mint authority reassignment, and user workflow updates
   • Only redeploy when absolutely necessary (e.g., fundamental architecture changes)