Розробка форку Compound для кастомного lending

Розробка форку Compound для кастомного lending

Compound V2 — один з найдокументованіших DeFi-протоколів з відкритим вихідним кодом, документованими уразливостями та сотнями форків у production. На перший погляд, «зробити форк» звучить просто: скопійована репозиторій, поміняв параметри, задеплоїв. На практиці — це джерело більшості хаків у категорії lending: неправильний розрахунок exchange rate, сломана логіка liquidation incentive, оракул з одним джерелом ціни.

Розбираємо, що реально потрібно зробити, щоб форк Compound працював правильно.

Що зазвичай ломають при форку Compound

Exchange rate та накопленні відсотки

Compound використовує концепцію cToken: користувач депонує DAI, отримує cDAI. Зі часом exchange rate росте — за рахунок накопленних відсотків від позичальників. Розрахунок rate йде через accrueInterest(), яка повинна викликатися перед будь-якою операцією з балансами.

Розповсюджена помилка у форках: accrueInterest() викликається не везде, де потрібно — наприклад, пропускають у кастомній функції liquidation. Итог: exchange rate застаріває, користувачі бачать некорректний баланс або, гірше, ліквідатор отримує менше collateral, ніж повинен. У одному відомому форку 2023 року це привело до того, що bad debt накопивалася непомітно кілька тижнів.

Перевірка: у тестах явно викликаємо vm.roll(block + N) та перевіряємо, що exchangeRateCurrent() коректно збільшується пропорційно borrowRate та часу.

Collateral factor vs liquidation threshold

У Compound V2 collateralFactor виконує дві ролі: визначає, скільки можна позичити, та задає поріг ліквідації. Це означає, що позиція переходить у ліквідацію майже одразу при перетині borrow limit — немає буфера між "максимальним займом" та "ліквідацією". Aave V3 розв'язав це розділенням на LTV (loan-to-value, скільки можна позичити) та liquidationThreshold (коли ліквідують). Буфер — 10–15% — дає позичальникам час довнести колатераль.

Якщо робимо форк під production з реальними користувачами — рекомендуємо додати це розділення. Це не мінює core математику Compound, але значно покращує UX та знижує кількість ненужних ліквідацій при краткосрочній волатильності.

Оракул: одного Chainlink недостатньо

Compound V2 використовує Chainlink як єдиний джерело ціни. Якщо Chainlink feed з якої-то причини зависає (а такое бывает — feed для менш ліквідних активів може не оновлюватися годинами), протокол працює з застарілою ціною. В періоди високої волатильності це створює або можливість арбітражу, або ризик bad debt.

Мінімальний захист: перевіряти updatedAt timestamp від Chainlink та блокувати операції, якщо дані старші за N секунд. Розширений захист: secondary oracle (наприклад, Uniswap V3 TWAP як fallback) з circuit breaker — якщо ціни двох оракулів розходяться більше ніж на X%, операції приостановлюються.

Що кастомизуємо у форку

Типові кастомізації під конкретний проект:

Список поддерживаемых активів. Compound підтримує великі активи — ETH, WBTC, USDC, DAI. Якщо потрібен lending для нішевих токенів (LST, LP-токени, RWA) — додаємо нові markets з індивідуальними параметрами ризику. LP-токени як collateral потребують окремої логіки оцінки через underlying активи.

Interest rate model. Compound використовує JumpRateModel: низька ставка при низькій утилізації, різкий ріст після kink-point (зазвичай 80%). Для stablecoin-пулів kink зазвичай вищий, для волатильних активів — нижчий. Параметри (baseRate, multiplier, jumpMultiplier, kink) виставляємо під конкретну токеноміку.

Governance та admin функції. Compound V2 має єдину admin-адресу з широкими правами. Для production-протоколу мінімум: Gnosis Safe multisig на admin, timelock на критичних змінах (параметри risk, oracle, pause guardian). Decentralized governance через Governor Bravo можна додати пізніше.

Isolation mode. Compound V2 не розділяє ризики між активами — проблема з одним токеном може впливати на весь протокол. Compound V3 (Comet) розв'язав це радикально, ввівши single-collateral markets. Для форку рекомендуємо хоча б базову ізоляцію: раздельні пулы для high-risk активов.

Stack та процес

Базис — репозиторій compound-protocol або compound-v2-subgraph для The Graph індексації. Розробка в Foundry: unit тести для кожного market, integration тести з fork mainnet для перевірки oracle інтеграції.

Аудит обов'язковий. Форк Compound не означає «безпечний автоматично» — кастомізації створюють нові вектори. Рекомендуємо Code4rena або Sherlock contest: широке покриття аудиторами за фіксований бюджет.

Ориентири по строкам

Базовий форк з мінімальними змінами параметрів — 4–6 тижнів розробки. Форк зі значними кастомізаціями (новий interest rate model, isolation pools, кастомний оракул) — 8–12 тижнів. Аудит йде паралельно останнім тижням розробки, але фінальна версія коду повинна бути заморожена за 2 тижні до початку аудиту.