Розробка форку Uniswap для кастомного DEX
Форк Uniswap — це не «скопіювати репозиторій та поміняти назву». Це серйозна інженерна робота: розібратися в інваріантах AMM, вирішити які параметри мінювати та чому, написати нові тести для змінено математики, пройти аудит. Команди, які просто клонували Uniswap v2 у 2021 році без розуміння механік, отримали протоколи з price manipulation уразливостями через flash loan та дренованими пулами.
Uniswap v2 vs v3: що саме форкувати
Вибір версії визначає складність та можливості:
| Параметр | Uniswap v2 | Uniswap v3 |
|---|---|---|
| Архітектура | Проста, x*y=k | Concentrated liquidity, ticks |
| Кастомізація | Легко змінити fee | Складно, багато математики |
| Аудит форку | 2–4 тижні | 4–12 тижнів |
| Готових форків | Сотні (PancakeSwap, SushiSwap) | Менше (Pancake v3, Camelot) |
| Газ на swap | ~120k | ~150–200k |
| Capital efficiency | Низька | Висока |
Для більшості нових DEX рекомендуємо стартувати з v2-архітектури з кастомними fee tiers. Concentrated liquidity (v3) оправдана, якщо є розуміння того, як LP-провайдери будуть управляти позиціями, та готовність до більш складного аудиту.
Що зазвичай мінюють у форку
Структура комісій
У Uniswap v2 fee зафіксовано на 0.3%, з них 0.05% йде в протокол (якщо включен). У форку можна:
- Змінити базовий fee (наприклад, 0.1% для stablecoin-пар, 1% для екзотичних токенів)
- Додати динамічний fee залежно від волатильності (потребує оракул або TWAP)
- Спрямувати protocol fee у казну DAO, staking, або на buyback токена
- Додати реферальні fee: частина комісії йде реферу (потрібне маппінг referrer → адреса)
Токен-специфічні обмеження
Часто потрібні пари тільки між затвердженими токенами (permissioned factory), або обмеження на створення пулів без multisig-підтвердження. Додається через mapping(address => bool) public allowedTokens та модифікатор у createPair.
Ціновые оракули та TWAP
Uniswap v2 зберігає кумулятивні ціни для TWAP — це вбудовано у _update(). Форк може додати більш часті snapshots або інтеграцію з Chainlink для захисту від маніпуляції. Проблема оригінального TWAP: при малій ліквідності пула коротері періоди TWAP (~5 хвилин) уразливі до price manipulation через крупні своп.
Головна небезпека форків: математика інваріанта
Flash loan атаки через нарушення інваріанта
Uniswap v2 перевіряє інвариант після всіх операцій у транзакції:
require(balance0Adjusted * balance1Adjusted >= uint(_reserve0) * uint(_reserve1) * 1000**2);
Помилка у форках: зміна логіки fee ломає цей розрахунок. Якщо balance0Adjusted розраховується неправильно при нестандартному fee — атакуючий може дренувати пул через серію flash swap → swap back транзакцій, кожна з яких проходить перевірку, але сумарно забирає ліквідність.
Ми бачили цей баг у трьох форках на BSC у 2022–2023 роках. Втрати: $1.2M, $800k, $3.5M.
При будь-якій зміні fee-логіки обов'язкові invariant-based fuzz тести в Foundry: Echidna або Foundry's vm.assume з сотнями тисяч випадкових параметрів. Інвариант: k_after >= k_before * (1 - fee).
Fee-on-transfer токени
Якщо DEX орієнтований на токени з tax (fee-on-transfer), стандартний Uniswap v2 не працює коректно: контракт очікує отримати amountIn токенів, але отримує amountIn * (1 - tax). Потрібна версія функцій swapExactTokensForTokensSupportingFeeOnTransferTokens — вона у Uniswap вже є, але у мінімалістичних форках її часто виключають, що ломає сумісність з популярними BSC-токенами.
Stack та процес
Розробка контрактів — Foundry для всього: тести, деплой, fuzzing. Базуємося на офіційному репозиторії Uniswap v2-core + v2-periphery як submodule, щоб ясно бачити diff. Зміни мінімальні та сфокусовані — не переписуємо те, що працює.
Тести. Для форку мінімальний набір:
- Створення пари, додавання/видалення ліквідності
- Своп у обидва боки з перевіркою інваріанта
- Flash swap з коректним та неправильним поверненням
- Розрахунок fee для нестандартних значень
- Fuzz тести на інвариант з 100k+ ітерацій
- Fork тест на mainnet: реальні токени, реальні балансы через
vm.createFork
Frontend. Адаптуємо Uniswap Interface (open-source) або будуємо з нуля на React + wagmi + viem. Uniswap SDK v3 сумісний з v2-форками при правильній конфігурації chain та factory address.
Роутер агрегації. Якщо потрібен мультихоп routing через власні пули + зовнішні DEX — інтегруємо 1inch Aggregation Protocol або пишемо власний роутер. Важливо для UX: користувач не повинен вручну шукати маршрут.
Деплой та запуск
Спочатку testnet (Sepolia, опціонально власна dev-мережа через Anvil). Потім аудит — обов'язково перед mainnet деплоем з реальним TVL. Після аудиту: mainnet deploy через forge script з multisig (Gnosis Safe) для ownership factory-контракту.
Строки залежать від складності кастомізації: v2-форк з змінено fee tiers — 1–2 тижні розробки + 2–4 тижні аудит. Повноцінний v3-форк з кастомним UI — від 2 місяців. Для production-протоколу аудит зовнішньої командою не опціональний.
Вартість обговорюється після аналізу вимог та вибраної версії.