Compound Fork Development for Custom Lending

Development of a Compound Fork for Custom Lending

Compound V2 is one of the most studied open-source DeFi protocols with documented vulnerabilities and hundreds of production forks. At first glance, "making a fork" sounds simple: copy the repository, change parameters, deploy. In practice — this is the source of most hacks in the lending category: incorrect exchange rate calculation, broken liquidation incentive logic, oracle with single price source.

Let's break down what you actually need to do for a Compound fork to work correctly.

What Developers Usually Break When Forking Compound

Exchange Rate and Accumulated Interest

Compound uses the concept of cToken: a user deposits DAI, receives cDAI. Over time the exchange rate grows — from accumulated interest from borrowers. Rate calculation happens via accrueInterest(), which must be called before any balance operation.

Common fork error: accrueInterest() not called everywhere needed — e.g., skipped in a custom liquidation function. Result: exchange rate becomes stale, users see incorrect balance or, worse, liquidator gets less collateral than deserved. In one notable fork in 2023 this caused bad debt to accumulate quietly for weeks.

Check: in tests explicitly call vm.roll(block + N) and verify exchangeRateCurrent() increases correctly proportional to borrowRate and time.

Collateral Factor vs Liquidation Threshold

In Compound V2, collateralFactor serves two roles: determines how much you can borrow and sets the liquidation threshold. This means position goes into liquidation almost immediately when crossing borrow limit — no buffer between "maximum borrow" and "liquidation". Aave V3 solved this by splitting into LTV (loan-to-value, how much you can borrow) and liquidationThreshold (when you get liquidated). A 10–15% buffer gives borrowers time to add collateral.

If building a fork for production with real users — we recommend adding this split. It doesn't change Compound's core math, but significantly improves UX and reduces unnecessary liquidations during short-term volatility.

Oracle: Chainlink Alone Is Not Enough

Compound V2 uses Chainlink as the sole price source. If Chainlink feed freezes for some reason (and it happens — feeds for less liquid assets can fail to update for hours), the protocol works with stale prices. During high volatility this creates either arbitrage opportunity or bad debt risk.

Minimum protection: check updatedAt timestamp from Chainlink and block operations if data is older than N seconds. Extended protection: secondary oracle (e.g., Uniswap V3 TWAP as fallback) with circuit breaker — if two oracle prices diverge >X%, operations pause.

What We Customize in a Fork

Typical customizations for specific projects:

Supported Asset List. Compound supports large assets — ETH, WBTC, USDC, DAI. For niche token lending (LSTs, LP-tokens, RWA) — add new markets with individual risk parameters. LP-tokens as collateral require separate valuation logic through underlying assets.

Interest Rate Model. Compound uses JumpRateModel: low rate at low utilization, sharp rise after kink-point (usually 80%). For stablecoin pools kink is usually higher, for volatile assets — lower. Parameters (baseRate, multiplier, jumpMultiplier, kink) we set for specific tokenomics.

Governance and Admin Functions. Compound V2 has a single admin address with broad rights. For production protocol minimum: Gnosis Safe multisig on admin, timelock on critical changes (risk parameters, oracle, pause guardian). Decentralized governance via Governor Bravo can be added later.

Isolation Mode. Compound V2 doesn't separate risk between assets — one asset problem can affect entire protocol. Compound V3 (Comet) solved this radically with single-collateral markets. For a fork we recommend at least basic isolation: separate pools for high-risk assets.

Stack and Process

Basis — compound-protocol repository or compound-v2-subgraph for The Graph indexing. Development in Foundry: unit tests for each market, integration tests with mainnet fork for oracle integration verification.

Audit is mandatory. Forking Compound doesn't mean "automatically safe" — customizations create new vectors. We recommend Code4rena or Sherlock contest: broad auditor coverage at fixed budget.

Timeline Guidance

Basic fork with minimal parameter changes — 4–6 weeks development. Fork with significant customizations (new interest rate model, isolation pools, custom oracle) — 8–12 weeks. Audit runs parallel with final development weeks, but final code should be frozen 2 weeks before audit start.