## Introduction to Building a Cross-Chain Rebase Token Welcome to this section focused on constructing a sophisticated DeFi primitive: a cross-chain rebase token. We'll leverage the power of the Foundry development toolkit and Chainlink's Cross-Chain Interoperability Protocol (CCIP) to build, test, and deploy a token capable of operating across multiple blockchain networks while incorporating a dynamic supply mechanism. This lesson tackles complex concepts, including advanced Solidity patterns, intricate cross-chain interactions facilitated by CCIP, and robust testing methodologies essential for secure and reliable smart contract development. We will explore how to design a token whose supply adjusts based on accrued interest and how to enable seamless transfers of this token between different blockchains. ### Core Concepts Explored Before diving into the code, let's establish a clear understanding of the fundamental concepts underpinning this project: 1. **Cross-Chain Functionality:** This refers to the capability of smart contracts or digital assets, like our token, to interact or move between distinct blockchain networks. Our goal is to build a single token standard that can exist and be transferred across multiple chains. 2. **Rebase Token:** Unlike standard ERC20 tokens where a user's balance only changes via direct transfers, a rebase token features an automatically adjusting total supply. This adjustment, or "rebase," is typically driven by specific criteria. In our case, the supply will grow based on accrued linear interest. Consequently, a user's balance can increase over time simply by holding the token, reflecting their proportional share of the expanding total supply. 3. **Chainlink CCIP (Cross-Chain Interoperability Protocol):** This is the secure messaging and token transfer protocol we will utilize to enable the cross-chain capabilities of our rebase token. CCIP provides the infrastructure for sending messages and initiating token movements between supported networks. 4. **Foundry:** Our primary development environment. Foundry is a comprehensive toolkit for Solidity development, offering tools for compilation, deployment, and advanced testing strategies like fuzz testing and fork testing, which are crucial for this project's complexity. 5. **CCIP Token Pool:** A specific smart contract pattern used in conjunction with Chainlink CCIP for facilitating cross-chain token transfers. It manages the locking or burning of tokens on the source chain and the corresponding releasing or minting on the destination chain. 6. **Burn and Mint Mechanism:** The chosen strategy for cross-chain token transfers. When a user initiates a cross-chain transfer, their tokens are destroyed (burned) on the origin chain. Following confirmation via CCIP, an equivalent amount of new tokens is created (minted) for them on the destination chain, managed by the respective Token Pool contracts. 7. **Linear Interest:** The mechanism driving our token's rebase functionality. Interest accrues proportionally over time, causing the total supply (and thus individual balances, proportionally) to increase predictably. 8. **Vault Contract:** A user-facing smart contract that serves as the primary interaction point. Users can deposit a base asset (e.g., ETH) into the Vault, which then mints the corresponding amount of rebase tokens. Conversely, users can redeem their rebase tokens through the Vault, which burns the tokens and returns the underlying base asset. This contract effectively links the rebase token to the yield generated (represented by the rebase). 9. **Fork Testing:** A powerful testing technique provided by Foundry. It allows us to create a local copy of a live blockchain's state (e.g., Sepolia testnet). Tests can then interact with deployed contracts and real-world state in a controlled, local environment, enabling realistic end-to-end testing of cross-chain interactions without repeated testnet deployments. 10. **Precision and Truncation:** Inherent challenges when working with fixed-point arithmetic in Solidity, particularly for calculations involving rates and time, like our interest accrual. Careful implementation and specialized testing assertions are required to handle potential rounding errors or loss of precision. 11. **Token Dust:** Very small residual amounts of tokens that can sometimes result from complex calculations or distribution mechanisms. While often negligible, they may need consideration in contract logic or when writing precise test assertions. 12. **`super` Keyword (Solidity):** A keyword used within inheriting contracts to explicitly call functions defined in their parent contract(s). This is particularly relevant when overriding standard functions like `balanceOf` or `transfer`, allowing us to extend or modify the base functionality while still leveraging it. ### Project Code Structure and Implementation Details The project repository contains several key components organized logically: **`src/` Directory (Smart Contracts):** * **`RebaseToken.sol`:** This is the heart of our project – the custom ERC20-like token contract implementing the rebase logic. * **Overridden Functions:** Key functions like `balanceOf` are overridden. Instead of returning a static value from a mapping, `balanceOf` dynamically calculates the user's current share. * **`balanceOf(address _user)` Logic:** This function retrieves the user's last recorded principal balance (using `super.balanceOf(_user)` to access the underlying ERC20 storage) and then calculates the interest accrued since the user's last interaction or balance update. The final balance returned is the sum of the principal and the calculated accrued interest, adjusted for precision. * **`_calculateUserAccumulatedInterestSinceLastUpdate(address _user)`:** An internal function responsible for computing the interest earned by a specific user based on their principal balance, their applicable interest rate (`s_userInterestRate[user]`), and the time elapsed (`block.timestamp - s_userLastUpdateTimestamp[user]`) since their balance was last updated. Precision factors (`PRECISION_FACTOR`) are used for fixed-point math. * **`mint()` and `burn()` Functions:** These functions have unique considerations. Before executing the core minting or burning logic (often calling the parent's implementation via `super`), they must first trigger an update (`_mintAccruedInterest`) to account for any interest accrued up to the current block timestamp, ensuring calculations are based on the most up-to-date balances. * **`RebaseTokenPool.sol`:** This contract is a specialized version of a Chainlink CCIP Token Pool, specifically designed to handle our `RebaseToken`. * **Inheritance:** It inherits from CCIP's base `TokenPool` contract. * **Functionality:** Implements the `_lockOrBurn` and `_releaseOrMint` internal functions required by CCIP's burn-and-mint flow. On the source chain, it interacts with `RebaseToken.burn()`. On the destination chain, it interacts with `RebaseToken.mint()`, effectively managing the token's destruction and creation across chains as orchestrated by CCIP messages. * **`Vault.sol`:** The primary interface for users. * **`deposit()` Function:** A `payable` function accepting the base asset (e.g., ETH). It calculates the equivalent amount of rebase tokens to issue based on the current state and calls `_rebaseToken.mint()` to credit the user. * **`redeem()` Function:** Allows users to exchange their rebase tokens back for the base asset. It takes the amount of rebase tokens to redeem, calls `_rebaseToken.burn()` to destroy them, and then transfers the corresponding amount of the base asset back to the user. **`script/` Directory (Foundry Scripts):** * Contains automation scripts written for Foundry's scripting capabilities. * **`Deployer.s.sol`:** Deploys the core contracts (`RebaseToken`, `Vault`, `RebaseTokenPool`) to the target chains. * **`ConfigurePools.s.sol`:** Configures the deployed `RebaseTokenPool` contracts on each chain, linking them together via CCIP settings. * **`BridgeTokens.s.sol`:** Executes a cross-chain token transfer using the configured CCIP setup and token pools. **`test/` Directory (Foundry Tests):** * **`RebaseToken.t.sol`:** Contains unit tests and fuzz tests specifically for the `RebaseToken` contract. * **Testing Focus:** Verifies the correctness of the rebase logic, interest accrual calculations, and overridden functions under various scenarios. * **Handling Precision:** Likely employs assertions like `assertApproxEqAbs` (Assert Approximate Equals Absolute) to gracefully handle minor discrepancies that can arise from fixed-point arithmetic and time-dependent calculations during fuzzing, preventing failures due to insignificant "token dust." * **`CrossChain.t.sol`:** Contains integration tests focusing on the end-to-end cross-chain functionality. * **Fork Testing:** Utilizes Foundry's fork testing (`vm.createSelectFork`) to simulate interactions on live testnet environments (like Sepolia) locally. * **CCIP Simulation:** Leverages helper tools like `Chainlink Local` and `CCIPLocalSimulatorFork` to mimic the behavior of the CCIP network locally. This allows developers to test the full message-passing and token transfer flow (deposit -> bridge -> check balance on destination) without the delays and costs of constant testnet deployments. **Automation (`bridgeToZkSync.sh`):** * A bash script is provided to demonstrate and automate the entire workflow: 1. Deploying contracts to multiple chains (e.g., Sepolia and zkSync Sepolia). 2. Configuring the CCIP lanes between the deployed token pools using Foundry scripts. 3. Interacting with the `Vault` to deposit ETH and mint rebase tokens. 4. Initiating and completing a cross-chain transfer using the `BridgeTokens.s.sol` script. * This showcases how scripting can orchestrate complex, multi-step, multi-chain operations efficiently. ### Key Takeaways and Learning Objectives By working through this section, you will gain practical experience and understanding in: * Implementing Chainlink CCIP for cross-chain token transfers. * Adapting existing or custom tokens (like our rebase token) for use with CCIP. * Designing and coding a rebase token with time-based interest accrual. * Utilizing advanced Solidity features like the `super` keyword in inheritance hierarchies. * Mastering advanced Foundry testing techniques: * Fuzz testing stateful contracts with time-dependent logic. * Addressing precision issues in tests using approximate assertions. * Setting up and executing fork tests for cross-chain scenarios. * Employing local simulation tools like Chainlink Local for CCIP testing. * Applying cross-chain design patterns like burn-and-mint bridging. * Automating deployment and interaction workflows using bash and Foundry scripting. Remember, the dynamic nature of rebase token balances and the complexities of cross-chain interactions necessitate rigorous testing. Fork testing and tools that simulate the cross-chain environment locally are invaluable for ensuring the correctness and security of such systems.