Розробка пулів ліквідності
Команда принесла контракт пулу з класичною механікою x*y=k. На тестнеті все працювало. На mainnet через три дні після запуску sandwich-бот витягнув з пулу $180k — ціна входу на 12% вище реальної, ціна виходу на 11% нижче. Жодного slippage-контролю на рівні контракту не було, тільки frontend перевіряв. Це типова історія, коли розробники копіюють механіку AMM, не розбираючись як працює MEV-інфраструктура Ethereum.
Де AMM-контракт ломається при розгортанні
Impermanent loss як архітектурне рішення, а не баг
IL — це не помилка, це математична наслідок постійного перебалансування. Але протоколи, які не пояснюють LP-провайдерам реальну математику, втрачають ліквідність: люди бачать APY 40%, забирають позицію через місяць та не розуміють, чому в USD вони в мінусі. Завдання контракту — надавати точні дані про позицію: поточну вартість, накопичені комісії, розраховану IL.
У Uniswap v3 це ускладнюється концентрованою ліквідністю: позиція активна тільки в діапазоні [tickLower, tickUpper]. Коли ціна виходить з діапазону, позиція перестає заробляти комісії та повністю конвертується в один токен. LP-провайдер без моніторингу може тижнями тримати "мертву" позицію.
Price manipulation через flash loan в одноосторонніх оракулах
AMM-пул, який сам є оракулом ціни — точка атаки. Flash loan на $50M USDC, одна транзакція на swap — spot-ціна в пулі зсувається в 10 раз. Якщо ваш лендинговий протокол читає ціну з цього пулу — він видає кредити під маніпульовану collateral. Саме так працював вектор атаки на Mango Markets ($114M у 2022).
Рішення: TWAP (Time-Weighted Average Price) через Uniswap v3 oracle — IUniswapV3Pool.observe() з вікном спостереження мінімум 30 хвилин. Або Chainlink як зовнішній оракул з circuit breaker: якщо spot та Chainlink розходяться більше ніж на 5% — транзакція скасується.
Reentrancy у callback-механіці
Uniswap v2/v3 використовує callback-паттерн: uniswapV2Call та uniswapV3SwapCallback. Якщо ваш пул реалізує подібну механіку та не ставить nonReentrant на функцію, яка викликає callback — класичний вектор. Атакуючий через callback повторно входить у пул до оновлення резервів.
У практиці зустрічали контракт пулу з функцією swap, яка оновлювала reserve0 та reserve1 після виклику _callback. Reentrancy дозволяла отримати токени двічі при одному вході. OpenZeppelin ReentrancyGuard потрібен на swap, addLiquidity, removeLiquidity — всі три.
Як ми будуємо пули ліквідності
Архітектурні рішення
Для більшості задач не потрібно писати AMM з нуля. Протоколи Uniswap v2/v3, Balancer, Curve — battle-tested код з мільярдами TVL. Завдання — правильно вибрати механіку під вашу токеноміку:
| Механіка | Підходить для | Приклад |
|---|---|---|
| x*y=k (Uniswap v2) | Загальний випадок, два токена | Будь-яка пара ERC-20 |
| Concentrated liquidity (Uniswap v3) | Стейблкоїни, корельовані активи | USDC/USDT, ETH/stETH |
| StableSwap (Curve) | Стейблкоїни з мінімальним slippage | 3pool, FRAX |
| Weighted pools (Balancer) | 2-8 токенів з кастомними вагами | 80/20 WETH/TOKEN |
| CPMM з кастомними fees | Протокольні пули з fee-sharing | Власний DEX |
Якщо завдання — кастомний пул під конкретний протокол, за основу беремо Uniswap v4 Hooks (якщо чейн підтримує) або Balancer v2 Vault архітектуру, де загальний vault зберігає токени, а пули — тільки логіку.
LP-токени та облік позицій
Стандарт ERC-20 для LP-токенів у Uniswap v2 — найпростіший випадок. Доля в пулі = lpBalance / lpTotalSupply. Проблема: при великій кількості LP-провайдерів кожен transfer LP-токена змінює відносні долі без знання інших учасників.
Для Uniswap v3-style позицій використовуємо NFT (ERC-721) — кожна позиція унікальна за тиками та розміром. Це ускладнює інтеграцію з іншими протоколами (не можна просто застейкати в ферму), але дає точний облік концентрованої ліквідності.
Fee accumulation: у Uniswap v3 комісії накопичуються через feeGrowthInside0LastX128 та feeGrowthInside1LastX128 — глобальний лічильник мінус лічильник на момент відкриття позиції. При collect() відбувається перерахунок. Якщо реалізуєте подібну механіку — overflow у uint128 при довгих періодах без збору комісій даст неправильні цифри; використовуйте unchecked arithmetic з явним коментарем.
Захист від MEV на рівні контракту
Кілька механік, що знижують прибуток sandwich-ботів:
Commit-reveal для крупних свапів. Користувач спочатку публікує хеш транзакції, через N блоків — саму транзакцію. Боти не знають параметри заздалегідь. Тертя для користувача високе, підходить тільки для крупних свапів.
Dynamic fees. Fee зростає при високій волатильності (детектується через відхилення від TWAP). Це робить сандвіч менш прибутковим. Реалізується через Uniswap v4 Hook або custom fee tier.
Private mempool. На рівні контракту не вирішується — це інфраструктурне питання (Flashbots Protect, MEV Blocker). Але важливо попередити клієнта до розгортання.
Процес розробки
Специфікація (2-3 дні). Визначаємо механіку пулу, токеноміку LP-токенів, fee structure, ролі (owner, fee collector, pause guardian). Малюємо state diagram: всі переходи станів пулу, включаючи emergency pause.
Розробка (1-2 тижні). Контракти на Solidity 0.8.x з Foundry. Fuzz-тести на інваріанти: reserve0 * reserve1 >= k ніколи не порушується, сума всіх LP-долей = totalSupply, комісії не перевищують обсяг свапу.
Fork-тестування. Тести на форку mainnet/Arbitrum — реальні ціни, реальні токени, реальні MEV-боти в mempool. Використовуємо vm.createFork у Foundry.
Внутрішній аудит + Slither. Мінімум за тиждень до розгортання. Для TVL > $500k рекомендуємо зовнішній аудит (Code4rena, Sherlock, Spearbit).
Розгортання. forge script з верифікацією, multisig Gnosis Safe на owner-функції, timelock на зміну fee параметрів (мінімум 48 годин).
Орієнтири за часовими рамками
Базовий пул з механікою x*y=k та LP-токенами ERC-20 — від 2 тижнів з тестами. Пул з концентрованою ліквідністю у стилі Uniswap v3 — від 6 тижнів. Кастомна механіка з кількома токенами, інтеграцією з зовнішніми оракулами та fee-sharing — 2-3 місяці. Терміни аудиту не включені.