Detailed Instructions

Before migrating, users must audit their Compound v1 positions to understand their exposure. The primary change in v2 is the introduction of cTokens as interest-bearing assets, replacing v1's separate balance tracking. In v1, interest accrued directly to your wallet balance; in v2, your balance of cTokens increases over time.

• Sub-step 1: Check your v1 balances. Use the getAccountLiquidity function on the v1 Comptroller (0x3d9819210A31b4961b30EF54bE2aeD79B9c9Cd3B) for your Ethereum address to see supplied/borrowed amounts.
• Sub-step 2: Calculate potential cToken exchange rates. Understand that 1 cDAI in v2 will represent a growing share of the underlying DAI pool.
• Sub-step 3: Review new risk parameters. V2 introduces collateral factors per asset, affecting borrowing power. For example, DAI might have a 75% factor, meaning you can borrow up to 75% of your supplied DAI value.

Tip: Use a block explorer to query your historical interactions with the v1 contracts to ensure all positions are accounted for.

Detailed Instructions

This step involves calling the repay and redeem functions on the v1 contracts. You must first repay any outstanding borrows, as you cannot migrate a leveraged position directly. The order of operations is critical to avoid liquidation risk in v1 during the process.

• Sub-step 1: Repay all borrowed assets. For each borrowed asset (e.g., ETH, DAI), call the repayBorrow function on the respective v1 cToken contract. For example, to repay DAI, interact with cDAI v1 (0x5d3a536E4D6DbD6114cc1Ead35777bAB948E3643). Ensure you approve the contract to spend your DAI first.
• Sub-step 2: Redeem underlying assets. After repaying, call redeem or redeemUnderlying on each v1 cToken contract to convert your cTokens back to the base asset. For cETH v1 (0x4Ddc2D193948926D02f9B1fE9e1daa0718270ED5), this returns ETH.
• Sub-step 3: Verify wallet balances. Confirm your wallet now holds the raw assets (e.g., 100 DAI, 5 ETH) and your v1 account liquidity is zero.

Tip: Batch these transactions using a smart wallet or delegate contract to save on gas costs during this multi-step exit.

Detailed Instructions

With raw assets in your wallet, you now interact with the Compound v2 protocol, whose core Comptroller is at 0x3d9819210A31b4961b30EF54bE2aeD79B9c9Cd3B. The first action is to mint cTokens by supplying an asset. This action grants you interest-bearing tokens and enables borrowing.

• Sub-step 1: Approve v2 cToken contracts. For each asset, approve the corresponding v2 cToken contract to spend your tokens. For DAI, approve cDAI v2 (0x5d3a536E4D6DbD6114cc1Ead35777bAB948E3643—note the same address as v1 cDAI, as it was upgraded in-place). Use an approval amount of 2^256 - 1 for unlimited allowance.

codeCopy
// Example: Approving cDAI v2 to spend DAI
daiContract.approve(cDAIv2Address, "115792089237316195423570985008687907853269984665640564039457584007913129639935");

• Sub-step 2: Call the mint function. Supply your asset by calling mint() on the cToken contract. For ETH, use mint() on cETH v2 (0x4Ddc2D193948926D02f9B1fE9e1daa0718270ED5) while sending ETH in the transaction.
• Sub-step 3: Verify cToken balance. Your wallet balance of cDAI or cETH will now reflect your deposit, accruing interest every block.

Tip: Monitor the exchangeRateCurrent() for your cToken to see how many underlying assets one cToken represents, which increases over time.

Detailed Instructions

In v2, supplied assets are not automatically used as collateral. You must explicitly enter markets via the Comptroller. This allows your cTokens to secure borrows based on their collateral factor. This step finalizes your active participation in the v2 lending market.

• Sub-step 1: Enter the market. Call enterMarkets() on the Comptroller with an array of cToken addresses you've supplied. This enables them as collateral.

codeCopy
// Entering both cDAI and cETH markets
comptroller.enterMarkets(["0x5d3a536E4D6DbD6114cc1Ead35777bAB948E3643", "0x4Ddc2D193948926D02f9B1fE9e1daa0718270ED5"]);

• Sub-step 2: Check borrowing capacity. Call getAccountLiquidity() on the Comptroller with your address. It returns a tuple: (error, liquidity, shortfall). A positive liquidity value in USD (scaled by 1e18) is your available borrowing power.
• Sub-step 3: Execute a borrow. If desired, call borrow() on a cToken contract for an available asset (e.g., borrow USDC using cDAI as collateral). Ensure you stay within safe limits to avoid liquidation, which is more efficient in v2 with a dedicated Liquidator contract.

Tip: Use a front-end like Compound's App or a dashboard to monitor your health factor, which is your collateral value divided by your borrow value. Keep it well above 1 to avoid risk.

Detailed Instructions

In Compound v1, risk management was introduced through a set of static, governance-controlled parameters for each supported asset. The primary mechanism was the collateral factor, which determined the maximum borrowing power against deposited assets. For example, if ETH had a collateral factor of 75%, a user depositing 100 ETH could borrow up to 75 ETH worth of another asset. The system relied on a single, global interest rate model per asset, typically a jump-rate model, which adjusted rates based on utilization.

• Sub-step 1: Define Collateral Factors: Governance must propose and vote on a collateral factor (e.g., 0.75 for ETH) for each cToken market via a proposal.
• Sub-step 2: Set Interest Rate Models: Deploy and configure a JumpRateModel contract for each asset, setting baseRate, multiplier, and kink parameters.
• Sub-step 3: Monitor Oracle Prices: Ensure the price oracle (initially a simple medianizer) is updating prices for all assets to calculate collateral values and liquidate undercollateralized positions.

Tip: The static nature meant parameters couldn't adapt to volatile market conditions, creating systemic risk during black swan events.

Detailed Instructions

Compound v2 introduced a more granular risk framework managed by a central Comptroller contract. Key innovations were the collateral factor and borrow cap per asset. The collateral factor continued to limit borrowing, while the borrow cap (e.g., 1,000,000 DAI) restricted the total borrowable amount of an asset to mitigate over-concentration. The close factor was introduced, allowing liquidators to repay only a portion (e.g., 50%) of an underwater borrow in a single transaction. Risk assessment now required monitoring the Collateral Factor and the Reserve Factor, which siphoned a portion of interest to a reserve for insolvency protection.

• Sub-step 1: Configure Market via Comptroller: Call _supportMarket(CToken cToken) and then _setCollateralFactor(CToken cToken, uint newCollateralFactorMantissa).
• Sub-step 2: Set Borrow Caps: Execute _setMarketBorrowCaps(CToken[] calldata cTokens, uint[] calldata newBorrowCaps) to limit total borrowing per asset.
• Sub-step 3: Adjust Reserve Factors: Use _setReserveFactor(uint newReserveFactorMantissa) on each cToken to set the percentage of interest directed to reserves (e.g., 0.10 for 10%).

Tip: The Comptroller's centralized logic became a single point of failure and upgrade complexity.

Detailed Instructions

This evolutionary phase, preceding v3, focused on containing risk through isolated markets and decentralized oracle networks. The concept allowed new assets to be listed without exposing the entire protocol to their risk; they could only be used as collateral within their own isolated pool. The Open Price Feed was introduced, aggregating prices from multiple sources (e.g., Coinbase, Binance) via a decentralized network of reporters. This reduced oracle manipulation risk. Risk managers now had to evaluate assets for isolated listing versus cross-collateralization, and rigorously audit oracle security.

• Sub-step 1: Deploy Isolated Market: Create a new Comptroller and cToken for the asset, isolating its risk from the main pool.
• Sub-step 2: Integrate Open Price Feed: Configure the cToken's priceOracle to point to the Chainlink aggregator contract (e.g., 0x5f4eC3Df9cbd43714FE2740f5E3616155c5b8419 for ETH/USD).
• Sub-step 3: Set Strict Parameters for Isolated Assets: Apply conservative collateral factors (e.g., 0.50) and low borrow caps initially, as there is no shared safety net.

Tip: Isolation protected the main protocol but reduced capital efficiency for new assets.

Detailed Instructions

Compound v3 represents a paradigm shift with asset-specific, configurable risk parameters set directly per market, eliminating the global Comptroller. The core risk levers are the Collateral Factor (now called Liquidation Threshold) and the Borrow Cap. Crucially, each asset has a Base Asset (e.g., USDC for the USDC market), which is the only borrowable asset, simplifying risk. The Price Feed is integrated directly, and a Liquidation Bonus incentivizes keepers. The Comet contract holds all logic, and configuration is done at deployment via constructor arguments.

• Sub-step 1: Deploy Comet with Config: Deploy the Comet contract with a detailed configuration struct specifying baseToken, priceFeed, storeFrontPriceFactor (liquidation bonus), and supplyCaps.
• Sub-step 2: Set Asset-Specific Collateral Details: For each collateral asset, configure assetInfo including offset (for scaling), priceFeed, borrowCollateralFactor, and liquidateCollateralFactor.

codeCopy
// Example config for WETH as collateral
assetConfigs.push(CometConfiguration.AssetConfig({
    asset: 0xC02aaA39b223FE8D0A0e5C4F27eAD9083C756Cc2,
    priceFeed: 0x5f4eC3Df9cbd43714FE2740f5E3616155c5b8419,
    decimals: 18,
    borrowCollateralFactor: 0.825e18, // 82.5%
    liquidateCollateralFactor: 0.89e18 // 89%
}));

• Sub-step 3: Monitor Utilization and Caps: Continuously track getBorrowRate() and totalBorrow() against the borrow cap to manage systemic risk.

Tip: This architecture maximizes capital efficiency and safety by tailoring risk parameters to each asset's volatility and liquidity profile.