cToken

A cToken is an ERC-20 token that represents a user's share of a pooled-liquidity lending market in Compound V2. Every Compound V2 market has exactly one cToken contract — cUSDC for the USDC market, cDAI for the DAI market, cETH for the ETH market, and so on.

How cTokens Work

When you supply USDC to Compound, the protocol:

1. Transfers USDC from you to the cUSDC contract.
2. Mints cUSDC tokens to you at the current exchangeRate.
3. The USDC sits in the cUSDC contract, available for borrowers to borrow.

As time passes and borrowers pay interest, the cUSDC contract accumulates more USDC. The exchangeRate between cUSDC and USDC grows accordingly. Your cUSDC balance stays constant, but each cUSDC now represents more USDC.

When you redeem, you burn cUSDC and receive USDC at the new, higher exchange rate. The difference is your earned interest.

The Exchange Rate Math

The exchange rate at any moment is:

1exchangeRate = (cash + totalBorrows - totalReserves) / totalSupply

Where cash is USDC currently in the contract, totalBorrows is USDC out on loan (with accumulated interest), totalReserves is the protocol's fee, and totalSupply is the cUSDC in circulation.

As totalBorrows grows with accrued interest, the numerator grows, which grows the exchange rate. That is mechanically how cToken holders earn.

Supply and Borrow from the Same cToken

In Compound V2, the same cToken handles both supply and borrow flows. The difference is:

• Suppliers hold cTokens (a share of the pool's assets).
• Borrowers owe the cToken an amount of the underlying asset (tracked as a borrow balance, not a token).

Borrowers pay interest on what they owe. Suppliers earn interest via the growing exchange rate.

Key cToken Functions

• mint(amount) — supply the underlying, receive cTokens.
• redeem(cTokens) — burn cTokens, receive the underlying plus interest.
• redeemUnderlying(amount) — specify the underlying amount to redeem (protocol computes cTokens to burn).
• borrow(amount) — borrow the underlying against collateral held in other cTokens.
• repayBorrow(amount) — repay borrowed underlying, reducing borrow balance.
• liquidateBorrow(borrower, amount, cTokenCollateral) — if borrower is underwater, liquidate them.

Common Implementation Traps

When rebuilding Compound V2 from scratch, several traps around cTokens are easy to miss:

Exchange rate computation order matters. The exchange rate must be read before the mint's state changes are committed. Otherwise, the supplier receives fewer cTokens than they should.

Accrual before any operation. Every cToken function must call accrueInterest() first to bring the market's state up to the current block. Forgetting this in any path means stale interest accounting.

Borrow index math. Stored borrow balances are in "principal" units — they must be scaled by the current borrow index to get the actual debt. The index grows as interest accrues. A fork that skips the index scaling has a systematic underflow in debts.

Reentrancy on transfer callbacks. Tokens that call back into the cToken during transfer (e.g., ERC-777 style tokens, or rebasing tokens that adjust balances) can create reentrancy surfaces. Compound V2 guards against this with checks-effects-interactions, but forks that introduce new token types need to be careful.

cTokens in Forks

Because Compound V2 is the most-forked lending protocol, variants of cTokens appear on many chains:

• iToken (Iron Bank) — a credit-line variant.
• cNote (Canto v2) — the lending-market token for Canto's algorithmic stablecoin.
• qToken (Benqi on Avalanche) — a naming variant of the same pattern.
• hToken (Hundred Finance) — multi-chain variant.

Each fork modifies some aspect of the cToken implementation, and those modifications are where most fork-specific bugs live. The Shadow Arena in Zealynx Academy has Flux Finance and Canto v2 as live targets — both Compound V2 forks with specific bugs in their modifications.