Кастомізація форку DeFi-протоколу
Uniswap v2 був форкнутий більше 200 разів. Більшість форків померли не тому що код поганий — він достатньо добре перевірений. Померли тому що форк скопіювали як є, не розібравшись у механіці, та ломануло при першій спробі щось змінити. Storage collision при апгрейді, неправильно відкалібровані параметри fee, сломаний механізм ціноутворення з-за неправильної ініціалізації пулів — ось чому «просто форкнути Uniswap» не працює без розуміння внутрішностей.
Що значить кастомізація на практиці
Аудит вихідного протоколу перед змінами
Перший крок — розібратися, що саме ми форкуємо. Uniswap v2, Uniswap v3, Curve, Aave v3, Compound v3, Balancer v2 — кожен має свою архітектуру та обмеження на кастомізацію.
Uniswap v2 форк — найпростіший. AMM-логіка в UniswapV2Pair, роутер окремо. Кастомізуємо: fee структуру (v2 фіксовані 0.3%), токеноміку LP-токенів, whitelist торговельних пар. Додаємо: buyback механіку з protocol fee, staking rewards для LP.
Aave v3 форк — складніше. Протокол модульний, 20+ контрактів. Кастомізуємо: список поддерживаемых активів, LTV/liquidation threshold параметри, interest rate strategy, включення/виключення isolation mode для нових активів. Не варто трогати: core математику InterestRateModel без глибокого розуміння, механіку aToken.
Curve форк — нішева задача для stable swap. Параметр A (amplification) критичний: занадто високий — пул не ребалансується при depeg, занадто низький — високий slippage. Значення A для існуючих пулів Curve підбиралося експериментально місяцями.
Розповсюджені помилки при форках
Неправильний fee розрахунок. У Uniswap v2 fee знімається через amountIn * 997 / 1000 (0.3%). Змінити fee без перерахунку константи — ломається інвариант k = x * y. Транзакції проходять, баланс пулу некорректний, LP гублює гроші.
Storage layout при апгрейді форка. Якщо взяли Aave v3 з proxy архітектурою та додали змінну в середину storage — наступний апгрейд ломає storage. Aave v3 використовує свій struct ReserveData у storage slot N. Додання поля до нього сдвигає всі наступні дані.
Oracle конфігурація. Aave v3 використовує Chainlink агрегатори з конкретними heartbeat та deviation threshold параметрами під кожен актив. Форк на новому чейні потребує або Chainlink підтримки на цьому чейні, або заміни на інший оракул. Використання оракула без anti-manipulation захисту (TWAP, circuit breaker) — прямий вектор до oracle manipulation атаки.
Технічний процес кастомізації
Diff-based аналіз
Беремо оригінальний протокол з офіційного GitHub, робимо fork у приватний репозиторій. Всі зміни — тільки через pull request з описанням причини та impact. Це дозволяє в будь-який момент зробити git diff проти оригіналу та розібратися, що повністю змінилося.
Типовий розмір diff для «легкої» кастомізації Uniswap v2 з додатковим fee механізмом — 200–400 строк. Якщо diff >1000 строк — це вже не кастомізація, це новий протокол.
Параметризація через конфіги
Хороші форки виносять змінюємі параметри в admin-controlled конфіги, а не хардкодять у контракти. Uniswap v2 з змінюємим fee: uint256 public swapFee = 30; // basis points з onlyOwner сеттером та timelock. Це дозволяє калібрувати параметри після деплоя без апгрейду контракту.
Тестування змінено логіки
Fork-тесты у Foundry — основний інструмент перевірки. Беремо реальні історичні транзакції оригінального протоколу, відтворюємо їх проти нашого форку, порівнюємо результати. Розбіжність у балансах — індикатор помилки у математиці.
Invariant тесты: для AMM — k повинен тільки расти (не зменшуватися) з кожним свапом. Для lending — totalDebt ніколи не перевищує totalSupply. Запускаємо Echidna на 100k+ ітерацій.
| Протокол | Складність форка | Типова час кастомізації | Основні ризики |
|---|---|---|---|
| Uniswap v2 | Низька | 3–7 днів | Fee math, oracle |
| Uniswap v3 | Висока | 2–4 тижні | Tick math, concentrated liquidity |
| Aave v3 | Висока | 2–4 тижні | Oracle setup, risk parameters |
| Curve StableSwap | Середня | 1–2 тижні | Параметр A, pool init |
| Balancer v2 | Середня | 1–2 тижні | Vault архітектура, pool math |
Процес роботи
Аналіз вихідного протоколу (2–3 дня). Вивчаємо архітектуру, складаємо список компонентів для зміни. Оцінюємо ризики кожної зміни.
Розробка та тестування (5–10 днів). Всі зміни у ізольованих PR. Fork-тесты + invariant тесты на кожну зміну. Документування diff.
Деплой скрипти. Форки крупних протоколів потребують складної ініціалізації: правильний порядок деплоя контрактів, налаштування параметрів, ініціалізація оракулів. Скрипти через forge script з воспроизводими результатами.
Внутрішній аудит. Особливий фокус на змінено частини. Оригінальний код вважаємо відносно безпечним (вже пройшов аудити), новий код — перевіряємо як новий контракт.
Ориентири по строкам
Легка кастомізація Uniswap v2 (fee механіка, whitelist) — 1–2 тижні. Кастомізація Aave v3 з новими ринками та параметрами — 2–4 тижні. Строки залежать від обсягу змін та складності цільового протоколу.
Вартість розраховується після review вихідного протоколу та технічного завдання на зміни.