## Building a Cross-Chain Rebase Token: The Foundation Welcome! Our ultimate objective is to construct a sophisticated cross-chain rebase token leveraging Chainlink's Cross-Chain Interoperability Protocol (CCIP). However, given the inherent complexities of both rebase mechanics and cross-chain communication, we'll adopt a phased approach. Our first critical step is to build and thoroughly understand a standard, single-chain rebase token. This foundational knowledge will be indispensable before we introduce the additional layer of CCIP functionality. Rebase tokens themselves are non-trivial, so a methodical, step-by-step process is key to success. ## Preparing Your Foundry Development Environment To begin, we need to set up our development environment using Foundry, a powerful and fast toolkit for Ethereum application development. 1. **Create Project Directory:** Open your terminal and create a new directory for our project. You can name it descriptively; for this lesson, we'll use `ccip-rebase-token`. ```bash mkdir ccip-rebase-token cd ccip-rebase-token ``` 2. **Initialize Foundry Project:** Within your new project directory, initialize a Foundry project. ```bash forge init ``` This command scaffolds a standard Foundry project structure, creating `src` (for contracts), `script` (for deployment/interaction scripts), `test` (for tests), and `lib` (for dependencies) folders. It also sets up configuration files and automatically installs `forge-std`, Foundry's standard library. 3. **Open in VS Code:** Open the newly created project in your preferred code editor, such as Visual Studio Code. ```bash code . ``` 4. **Clean Up Default Files:** To start with a clean slate, we'll remove the default example files generated by `forge init`. Delete the following files: * `src/Counter.sol` * `script/Counter.s.sol` * `test/Counter.t.sol` Additionally, clear the contents of the `README.md` file. We'll populate this with our own design specifications. ## Core Design of the Single-Chain Rebase Token With our environment ready, let's outline the core design principles and functionality of our rebase token, as we would typically document in a `README.md` file. ### Protocol Overview The fundamental idea is to create a system where users can deposit an underlying asset (for example, ETH or a stablecoin like WETH) into a central smart contract, which we'll refer to as the `Vault`. In exchange for their deposit, users receive `rebase tokens`. These `rebase tokens` are special; they represent the user's proportional share of the total underlying assets held within the `Vault`, including any interest or rewards that accrue over time. ### Understanding Rebase Token Mechanics The defining characteristic of a rebase token is how its supply adjusts, directly impacting a holder's balance. * **Dynamic Balances:** The `balanceOf(address user)` function, a standard ERC20 view function, will be designed to return a *dynamic* value. This means that when a user queries their balance, it will appear to increase over time, reflecting their share of accrued interest or rewards. In our specific implementation, this increase will be calculated *linearly* with time. * **`balanceOf` is a View Function (Gas Efficiency):** It's crucial to understand that the `balanceOf` function *shows* the user's current theoretical balance, including dynamically calculated interest. However, calling `balanceOf` itself does *not* execute a state-changing transaction on the blockchain. It doesn't mint new tokens with every call, as that would incur gas costs for simply viewing a balance. This design is critical for gas efficiency. * **State Update on Interaction:** The actual *minting* of the accrued interest (i.e., updating the user's on-chain token amount) will occur strategically *before* a user performs any state-changing action with their tokens. These actions include: * Depositing more underlying assets (minting more rebase tokens). * Withdrawing/redeeming their underlying assets (burning rebase tokens). * Transferring their rebase tokens to another address. * (In the future) Bridging their tokens to another chain. The mechanism works as follows: When a user initiates one of these actions, the contract will first check the time elapsed since their last interaction. It then calculates the interest accrued to that user during this period, based on their specific interest rate (more on this below). These newly calculated interest tokens are then *minted* to the user's recorded balance *on-chain*. Only *after* this balance update does the contract proceed to execute the user's original requested action (e.g., transfer, burn) with their now up-to-date balance. ### The Interest Rate Model: Rewarding Early Adopters Our interest rate mechanism is designed to incentivize early participation in the protocol. * **Global Interest Rate:** The protocol will feature a `global interest rate`. This rate, potentially managed by an `owner` or a governance mechanism, determines the base rate at which interest accrues for the entire protocol at any given moment. * **Decreasing Global Rate (Key Feature):** A critical design choice is that this `global interest rate` can *only decrease* over time. It cannot be increased by the owner once set or lowered. * **User-Specific Interest Rate Snapshot:** When a user makes their *first* deposit into the `Vault`, the `Rebase Token` contract takes a *snapshot* of the *current* `global interest rate`. This snapshot becomes the user's *individual, fixed interest rate* for that specific deposit. * **Incentivizing Early Adopters:** This design directly rewards early users. Because the global interest rate can only decrease, users who deposit earlier effectively lock in a higher interest rate for their initial capital compared to users who deposit later, when the global rate might have been reduced. * **Handling Subsequent Deposits:** If an existing user makes *additional* deposits at a later time, those new deposits would likely accrue interest based on the (potentially lower) `global interest rate` prevailing *at the time of the new deposit*. The exact mechanics for handling multiple deposits from the same user and their associated rates will be detailed during contract implementation. * **Conceptual Source of Yield:** While the underlying assets in the `Vault` could theoretically be deployed in various DeFi strategies (e.g., staking, lending, liquidity provision) to generate yield, for this initial version, the "interest" is primarily a function of the rebase mechanism itself, designed to increase token adoption by directly rewarding token holders with more tokens. ## Illustrating the Interest Rate Flow Let's visualize how this interest rate mechanism plays out for different users at different times: 1. **Initial User Deposit (User 1):** * `User 1` deposits ETH into the `Vault Contract`. * The `Vault Contract` communicates with the `Rebase Token` contract. * Let's assume the `Rebase Token` contract currently has its `globalInterestRate` set to 0.05 (or 5%). * The `Rebase Token` contract records that `User 1's Interest Rate` is 0.05. This rate is now locked in for User 1's initial deposit. * The `Vault Contract` mints and sends the corresponding amount of `rebase tokens` to `User 1`. 2. **Owner Adjusts Global Rate:** * Sometime later, an `Owner` (or governance) interacts with the `Rebase Token` contract. * The `Owner` decides to *decrease* the `globalInterestRate`, for example, from 0.05 down to 0.04 (4%). 3. **New User Deposit (User 2):** * Now, `User 2` decides to deposit ETH into the `Vault Contract`. * The `Vault Contract` again communicates with the `Rebase Token` contract. * The `Rebase Token` contract's `globalInterestRate` is now 0.04. * The `Rebase Token` contract records that `User 2's Interest Rate` is 0.04. This is User 2's locked-in rate. * The `Vault Contract` mints and sends `rebase tokens` to `User 2`. 4. **Outcome and Further Rate Adjustments:** * As time progresses, `User 1` will continue to accrue interest based on their higher, locked-in rate of 0.05. * `User 2`, having deposited later, will accrue interest based on their lower, locked-in rate of 0.04. This clearly demonstrates the early adopter incentive. * If the `Owner` were to decrease the `globalInterestRate` again, say to 0.02, it would not affect the already locked-in rates for `User 1` (still 0.05) or `User 2` (still 0.04). Any new depositors after this change would receive the 0.02 rate. This step-by-step approach—starting with a single-chain rebase token and carefully considering its mechanics—will provide a solid foundation before we embark on the more complex journey of adding cross-chain capabilities. The dynamic balance calculation versus actual state updates might seem intricate at first, but it will become clearer as we translate these concepts into smart contract code.