## Configuring Your CCIP Token Pools for Cross-Chain Transfers Before you can mint tokens and execute cross-chain transfers using Chainlink CCIP (Cross-Chain Interoperability Protocol) with a Burn & Mint token mechanism, a critical prerequisite is the configuration of your deployed Token Pools. This configuration step establishes the necessary permissions and connections, enabling the pools on different chains to interact seamlessly. This lesson guides you through understanding and implementing this configuration. ## Understanding `applyChainUpdates` for Pool Configuration The core of token pool configuration lies in the `applyChainUpdates` function. This function is part of the `TokenPool` contract provided by Chainlink CCIP. If you are using a custom token pool, such as a `RebaseTokenPool` that inherits from Chainlink's base `TokenPool`, this function will be available through inheritance. You can find detailed information about this function in the official Chainlink CCIP documentation, specifically within the TokenPool API reference for `applyChainUpdates`. **Purpose:** The primary purpose of `applyChainUpdates` is to update the chain-specific permissions and configurations for the token pool contract on which it is called. Essentially, it tells a local pool which remote chains it is allowed to interact with. **Arguments:** The `applyChainUpdates` function accepts two main arguments: 1. `uint64[] calldata remoteChainSelectorsToRemove`: This is an array of CCIP chain selectors (type `uint64`) for chains whose configurations you wish to *remove* from the pool's allowed list. If you are only adding or updating configurations, this array will typically be empty. 2. `ChainUpdate[] calldata chainsToAdd`: This is an array of `ChainUpdate` structs. Each struct in this array contains the configuration details for a new chain to be *added* or an existing chain's configuration to be *updated*. **Enabling Chains:** When you configure a local token pool to add a remote chain via the `chainsToAdd` parameter, you are effectively "enabling" that remote chain for interaction. This means the local pool (the one on which `applyChainUpdates` is being called) will be permitted to: * Receive tokens *from* the specified remote chain. * Send tokens *to* the specified remote chain. For example, if you are configuring the Token Pool deployed on Sepolia, and you add the Arbitrum Sepolia chain configuration to `chainsToAdd`, the Sepolia pool will then be authorized to send tokens to the Arbitrum Sepolia pool and receive tokens from it. ## Implementing Pool Configuration in a Foundry Test To manage pool configurations effectively, especially within a testing environment like Foundry, it's practical to create a reusable helper function. We'll walk through creating such a function, `configureTokenPool`, within a Solidity test file (e.g., `CrossChain.t.sol`). **Conceptualizing Local vs. Remote:** Within the context of our `configureTokenPool` helper function, it's crucial to distinguish between: * **Local Chain:** The blockchain whose Token Pool is currently being configured (i.e., the chain where `applyChainUpdates` is being called). * **Remote Chain:** The *other* blockchain that is being enabled for interaction with the local chain's pool. Our helper function will need parameters to represent components from both the local and remote chains. **`configureTokenPool` Helper Function Implementation:** This function will encapsulate the logic for calling `applyChainUpdates` on a specified local pool. ```solidity // Import necessary contracts and libraries // import {TokenPool} from "@ccip/contracts/src/v0.8/ccip/pools/TokenPool.sol"; // Assuming RebaseTokenPool inherits TokenPool import {RateLimiter} from "@ccip/contracts/src/v0.8/ccip/libraries/RateLimiter.sol"; // ... inside your test contract ... // owner, sepoliaFork, arbSepoliaFork, sepoliaPool, arbSepoliaPool, // sepoliaToken, arbSepoliaToken, sepoliaNetworkDetails, arbSepoliaNetworkDetails // are assumed to be defined elsewhere in your test setup. function configureTokenPool( uint256 forkId, // The fork ID of the local chain address localPoolAddress, // Address of the pool being configured uint64 remoteChainSelector, // Chain selector of the remote chain address remotePoolAddress, // Address of the pool on the remote chain address remoteTokenAddress // Address of the token on the remote chain ) public { // 1. Select the correct fork (local chain context) vm.selectFork(forkId); // 2. Prepare arguments for applyChainUpdates // An empty array as we are only adding, not removing. uint64[] memory remoteChainSelectorsToRemove = new uint64[](0); // Construct the chainsToAdd array (with one ChainUpdate struct) TokenPool.ChainUpdate[] memory chainsToAdd = new TokenPool.ChainUpdate[](1); // The remote pool address needs to be ABI-encoded as bytes. // CCIP expects an array of remote pool addresses, even if there's just one primary. bytes[] memory remotePoolAddressesBytesArray = new bytes[](1); remotePoolAddressesBytesArray[0] = abi.encode(remotePoolAddress); // Populate the ChainUpdate struct // Refer to TokenPool.sol for the ChainUpdate struct definition: // struct ChainUpdate { // uint64 remoteChainSelector; // bytes remotePoolAddresses; // ABI-encoded array of remote pool addresses // bytes remoteTokenAddress; // ABI-encoded remote token address // RateLimiter.Config outboundRateLimiterConfig; // RateLimiter.Config inboundRateLimiterConfig; // } chainsToAdd[0] = TokenPool.ChainUpdate({ remoteChainSelector: remoteChainSelector, remotePoolAddresses: abi.encode(remotePoolAddressesBytesArray), // ABI-encode the array of bytes remoteTokenAddress: abi.encode(remoteTokenAddress), // For this example, rate limits are disabled. // Consult CCIP documentation for production rate limit configurations. outboundRateLimiterConfig: RateLimiter.Config({ isEnabled: false, capacity: 0, rate: 0 }), inboundRateLimiterConfig: RateLimiter.Config({ isEnabled: false, capacity: 0, rate: 0 }) }); // 3. Execute applyChainUpdates as the owner // applyChainUpdates is typically an owner-restricted function. vm.prank(owner); // The 'owner' variable should be the deployer/owner of the localPoolAddress TokenPool(localPoolAddress).applyChainUpdates( remoteChainSelectorsToRemove, chainsToAdd ); } ``` **Key Steps in `configureTokenPool`:** 1. **Select Fork (`vm.selectFork`):** Foundry's `vm.selectFork(forkId)` cheatcode is used to switch the execution context of the test to the *local chain* whose pool is being configured. The `forkId` (e.g., `sepoliaFork` or `arbSepoliaFork`) is passed as an argument. 2. **Prepare `applyChainUpdates` Arguments:** * `remoteChainSelectorsToRemove`: Initialized as an empty `uint64` array (`new uint64[](0)`) because we are only adding a new chain configuration in this scenario. * `chainsToAdd`: This array will contain `TokenPool.ChainUpdate` structs. For enabling a single remote chain, it's an array with one element. * **`remotePoolAddresses`:** The `ChainUpdate` struct expects `bytes` for `remotePoolAddresses`. This field should contain an ABI-encoded array of `bytes`, where each `bytes` element is an ABI-encoded remote pool address. Even if you have only one corresponding remote pool, it must be wrapped in an array and then the array itself ABI-encoded. * **`remoteTokenAddress`:** The address of the token contract on the *remote* chain, ABI-encoded into `bytes`. * **Rate Limiter Configuration:** The `ChainUpdate` struct includes `outboundRateLimiterConfig` and `inboundRateLimiterConfig`. These use the `RateLimiter.Config` struct (requiring an import of `RateLimiter.sol`). In this test setup, rate limiting is explicitly disabled by setting `isEnabled` to `false` and other parameters to `0`. For production, these should be configured according to your application's needs. 3. **Prank Owner and Call (`vm.prank`):** The `applyChainUpdates` function on the `TokenPool` contract is typically restricted to be callable only by the owner of the pool. Foundry's `vm.prank(owner)` cheatcode makes the *next single call* execute as if it were initiated by the specified `owner` address. The `localPoolAddress` is cast to the `TokenPool` interface type to call the function. (If multiple subsequent calls needed owner permissions, `vm.startPrank(owner)` and `vm.stopPrank()` would be used.) ## Activating Cross-Chain Communication in `setUp` Once your tokens (e.g., `sepoliaToken`, `arbSepoliaToken`) and token pools (e.g., `sepoliaPool`, `arbSepoliaPool`) are deployed on their respective chains, you call the `configureTokenPool` helper function within your test's `setUp` function. This must be done for each direction of interaction. **Example: Configuring Sepolia Pool for Arbitrum Sepolia, and vice-versa:** ```solidity // ... inside your setUp function, after deploying tokens and pools ... // Configure Sepolia Pool to interact with Arbitrum Sepolia Pool configureTokenPool( sepoliaFork, // Local chain: Sepolia address(sepoliaPool), // Local pool: Sepolia's TokenPool arbSepoliaNetworkDetails.chainSelector, // Remote chain selector: Arbitrum Sepolia's address(arbSepoliaPool), // Remote pool address: Arbitrum Sepolia's TokenPool address(arbSepoliaToken) // Remote token address: Arbitrum Sepolia's Token ); // Configure Arbitrum Sepolia Pool to interact with Sepolia Pool configureTokenPool( arbSepoliaFork, // Local chain: Arbitrum Sepolia address(arbSepoliaPool), // Local pool: Arbitrum Sepolia's TokenPool sepoliaNetworkDetails.chainSelector, // Remote chain selector: Sepolia's address(sepoliaPool), // Remote pool address: Sepolia's TokenPool address(sepoliaToken) // Remote token address: Sepolia's Token ); // ... rest of your setUp ... ``` Notice the explicit type casting (e.g., `address(sepoliaPool)`). This is because variables like `sepoliaPool` might be of a specific contract type (e.g., `RebaseTokenPool`), but the `configureTokenPool` function expects generic `address` types for pool and token addresses. After implementing these configurations, running `forge build` or your specific compilation command will help verify that the code, including the struct definitions and function calls, is syntactically correct. With the pools configured, you are now ready to proceed with writing tests that perform actual cross-chain token transfers. ## Key Considerations for Pool Configuration * **Timing is Crucial:** Pool configuration via `applyChainUpdates` must be performed *after* deploying your token pool contracts on all relevant chains but *before* attempting any cross-chain minting or transfer operations. * **Chain Selector Type:** Remember that `remoteChainSelectorsToRemove` in `applyChainUpdates` expects an array of `uint64`, not `uint256`. * **ABI Encoding:** Addresses passed as `bytes` within the `ChainUpdate` struct (specifically `remotePoolAddresses` and `remoteTokenAddress`) must be correctly ABI-encoded. The `remotePoolAddresses` field itself expects ABI-encoded `bytes[]`. * **Foundry Cheats:** Utilize `vm.selectFork` to manage chain context and `vm.prank` (or `vm.startPrank`/`vm.stopPrank`) to simulate transactions from privileged accounts like the pool owner. * **Rate Limiting:** While disabled in this test scenario (`isEnabled: false`), CCIP offers robust rate-limiting features. For production deployments, carefully configure the `outboundRateLimiterConfig` and `inboundRateLimiterConfig` fields in the `ChainUpdate` struct to manage token flow and enhance security. Refer to the Chainlink `RateLimiter.sol` library and CCIP documentation for details. * **Clarity in Direction:** When configuring pools for bidirectional communication (e.g., Chain A <-> Chain B), ensure you call `applyChainUpdates` on Chain A's pool (listing Chain B as remote) AND on Chain B's pool (listing Chain A as remote). By following these steps and considerations, you can successfully configure your Chainlink CCIP Token Pools, paving the way for secure and reliable cross-chain token functionality.