Разработка форка Compound для кастомного lending
Compound V2 — один из самых изученных DeFi-протоколов с открытым исходным кодом, задокументированными уязвимостями и сотнями форков в продакшне. На первый взгляд, «сделать форк» звучит просто: скопировал репозиторий, поменял параметры, задеплоил. На практике — это источник большинства хаков в категории lending: неправильный расчёт exchange rate, сломанная логика liquidation incentive, oracle с одним источником цены.
Разбираем, что реально нужно сделать, чтобы форк 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 и снижает количество ненужных ликвидаций при краткосрочной волатильности.
Oracle: одного 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%). Для стейблкоин-пулов 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 не разделяет риски между активами — проблема с одним токеном может affect весь протокол. Compound V3 (Comet) решил это радикально, введя single-collateral markets. Для форка рекомендуем хотя бы базовую изоляцию: раздельные пулы для high-risk assets.
Стек и процесс
Базис — репозиторий compound-protocol или compound-v2-subgraph для The Graph индексации. Разработка в Foundry: unit тесты для каждого market, integration тесты с fork mainnet для проверки oracle интеграции.
Аудит обязателен. Форк Compound не значит «безопасный автоматически» — кастомизации создают новые векторы. Рекомендуем Code4rena или Sherlock contest: широкое покрытие аудиторами за фиксированный бюджет.
| Этап | Срок | Содержание |
|---|---|---|
| Проектирование | 1-2 нед | Параметры рисков, список активов, governance модель |
| Разработка | 4-8 нед | Контракты, кастомизации, тесты |
| Внутренний аудит | 1-2 нед | Slither, Echidna, ручной review |
| Внешний аудит | 2-4 нед | Обязательно перед mainnet |
| Деплой и мониторинг | 1 нед | Gnosis Safe, subgraph, дашборд |
Ориентиры по срокам
Базовый форк с минимальными изменениями параметров — 4-6 недель разработки. Форк со значительными кастомизациями (новый interest rate model, isolation pools, кастомный oracle) — 8-12 недель. Аудит идёт параллельно последним неделям разработки, но финальная версия кода должна быть заморожена за 2 недели до начала аудита.