cToken Contract Interface and Integration Guide

The Compound II cToken contract is an ERC-20 compliant wrapper that represents a user's supplied balance in a specific market. Unlike a simple rebasing token, the cToken's exchange rate against the underlying asset increases with each block as interest accrues, meaning a user's cToken balance remains static while its redeemable value grows. Integrators must track the exchangeRateStored and exchangeRateCurrent functions to calculate the precise underlying value of a position, rather than relying on the token balance alone. This interface is the canonical integration surface for all legacy Compound markets and remains active, though it has been superseded by the Compound III Comet architecture.

The core operational methods for integrators are mint, redeem, redeemUnderlying, borrow, repayBorrow, repayBorrowBehalf, liquidateBorrow, and transfer. A critical operational detail is that mint is a payable function for ETH markets but requires a prior ERC-20 approve call for token markets. The redeem function accepts a cToken amount, while redeemUnderlying accepts an underlying asset amount, requiring the caller to calculate the required cToken quantity off-chain using the current exchange rate. Failure to account for accrual between transaction simulation and confirmation can lead to failed redemptions. For borrowing, the borrow function's success depends on the account's liquidity, calculated by the Comptroller across all entered markets, not just the target market's collateral.

Governance and risk parameters are enforced by the Comptroller, not the cToken itself. The Comptroller's enterMarkets, exitMarket, getAccountLiquidity, and getHypotheticalAccountLiquidity functions are essential for any integration that assesses borrowing capacity or liquidation risk. The liquidateBorrow function's closeFactor and the Comptroller's liquidationIncentive are set via governance and directly impact liquidation bot profitability. Integrators must monitor AccrueInterest events to update their off-chain position ledgers and listen for PauseGuardian events that can halt mint, redeem, borrow, or liquidateBorrow operations, requiring graceful degradation in user interfaces and automated systems.

Teams maintaining wallets, custodians, or aggregators that interact with cToken markets should audit their integration against the precise mechanics of the exchange rate, the Comptroller's liquidity checks, and the error codes returned by the ErrorReporter contract. Chainscore can perform a targeted review of an existing cToken integration to validate accurate balance tracking, correct transaction construction for all core operations, and robust handling of governance-imposed pauses and parameter changes.

Compound's cToken contract uses a non-rebasing ERC-20 wrapper to represent a user's share of a lending pool. When a user supplies an underlying asset, the cToken contract mints a quantity of cTokens determined by the current exchangeRate, which is the ratio of cTokens to the underlying asset. This rate starts at 0.020000 and increases with every state-changing transaction as interest accrues to the pool. The user's cToken balance remains static, but its value in the underlying asset grows over time. This design is the inverse of a rebasing token like stETH; integrators must multiply the static cToken balance by the dynamic exchange rate to display a user's current position, not simply query balanceOf.

The exchangeRate is calculated as (totalCash + totalBorrows - totalReserves) / totalSupply. Interest accrual is triggered by any interaction with the market, which calls accrueInterest to update borrowIndex and allocate reserves. The borrowIndex tracks the accumulated interest for all borrowers since market inception, and each borrower's debt is calculated as their stored accountBorrowIndex principal multiplied by the current borrowIndex. This means a user's debt grows automatically without any per-block updates to their account storage. For integrators, the critical operational implication is that a user's health factor can deteriorate silently between transactions, and accurate off-chain position tracking requires maintaining a local copy of the borrowIndex and exchangeRate to compute real-time values without making an RPC call for every block.

A common integration failure is treating cTokens as 1:1 wrappers or using balanceOf directly for portfolio valuation. Wallets, custodians, and aggregators that display a user's cToken balance without multiplying by the exchange rate will under-report positions, potentially by a significant margin for long-held deposits. Chainscore Labs can audit an existing integration's balance calculation and position-tracking logic to ensure it correctly models the non-rebasing exchange rate and interest accrual mechanics, preventing valuation errors that could lead to incorrect liquidations or financial reporting discrepancies.