Команда принесла контракт пулу з класичною механікою x*y=k. На тестнеті все працювало. На mainnet через три дні після запуску сендвіч-бот вилучив з пулу $180k — ціна входу на 12% вища за реальну, ціна виходу на 11% нижча. Жодного слипедж-контролю на рівні контракту не було, лише фронтенд перевіряв. Це типова історія, коли розробники копіюють механіку AMM, не розбираючись у тому, як працює MEV-інфраструктура Ethereum. Зв'яжіться з нами, щоб уникнути таких втрат — ми спеціалізуємося на захисті пулів. Ми гарантуємо якість коду та безпеку контрактів, а наші рішення пройшли аудит сертифікованими компаніями.
Проблеми AMM-контракту при деплої
Impermanent loss як архітектурне рішення, а не баг
IL — це не помилка, а математичний наслідок перебалансування. Протоколи, які не пояснюють LP-провайдерам реальну математику, втрачають ліквідність: люди бачать APY 40%, забирають позицію через місяць і не розуміють, чому в USD вони в мінусі. Завдання контракту — надавати точні дані про позицію: поточну вартість, накопичені комісії, розрахунковий IL.
В Uniswap v3 це ускладнюється концентрованою ліквідністю: позиція активна лише в діапазоні [tickLower, tickUpper]. Коли ціна виходить із діапазону, позиція перестає заробляти комісії та повністю конвертується в один токен. LP-провайдер без моніторингу може тижнями тримати мертву позицію. Використання кеппер-ботів для автоматичного ребалансування позицій знижує ризик неефективного розподілу ліквідності.
Price manipulation через flash loan в однобоких оракулах
AMM-пул, який сам є оракулом ціни — точка атаки. Flash loan на значну суму, одна транзакція на swap — спот-ціна в пулі зсувається в 10 разів. Якщо ваш лендинговий протокол читає ціну з цього пулу — він видає кредити під маніпульований collateral. Так сталося з Mango Markets (втрачено $114M). Рішення: TWAP через Uniswap v3 oracle — IUniswapV3Pool.observe() з вікном спостереження мінімум 30 хвилин. Або Chainlink як зовнішній оракул із circuit breaker: якщо spot і Chainlink розходяться більш ніж на 5% — транзакція реверсується. Реалізуємо захист від flash loan атак.
Reentrancy в callback-механіці
Uniswap v2/v3 використовує callback-патерн: uniswapV2Call та uniswapV3SwapCallback. Якщо ваш пул реалізує подібну механіку й не ставить nonReentrant на функцію, яка викликає callback — класичний вектор. У практиці зустрічали контракт пулу з функцією swap, яка оновлювала reserve0 та reserve1 після виклику _callback. Reentrancy дозволяла отримати токени двічі при одному вході. ReentrancyGuard потрібен на swap, addLiquidity, removeLiquidity — всі три.
Чому TWAP-оракул обов'язковий для пулу?
Без TWAP пул стає вразливим для flash loan атак. Використовуючи коротке вікно спостереження, ми згладжуємо маніпуляції. У проектах з високим TVL закладаємо fallback на Chainlink — це підвищує надійність.
Як знизити ризик impermanent loss для LP?
Вбудовуємо в контракт розрахунок impermanent loss у реальному часі та надаємо дані через view-функції. У концентрованих пулах додаємо автоматичний ребаланс позиції через keeper-ботів, щоб уникнути довгого перебування поза діапазоном. Це знижує втрати LP-провайдерів.
Як ми будуємо пули ліквідності
Деталі архітектури пулів
Архітектурні рішення
Для більшості завдань не потрібно писати 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) — кожна позиція унікальна за тіками та розміром. Це ускладнює інтеграцію, але дає точний облік. Комісії накопичуються через feeGrowthInside0LastX128 — при реалізації потрібен unchecked arithmetic з явним коментарем.
Захист від MEV на рівні контракту
- Застосовуємо commit-reveal для великих свапів: користувач публікує хеш, через N блоків — саму транзакцію. Боти не знають параметри заздалегідь.
- Використовуємо dynamic fees: fee зростає при високій волатильності (детектується через відхилення від TWAP). Реалізується через Uniswap v4 Hook або custom fee tier.
- Рекомендуємо private mempool (Flashbots Protect, MEV Blocker) — інфраструктурне рішення, попереджаємо клієнта до деплою.
Що входить у розробку пулу ліквідності
| Етап | Тривалість | Результат |
|---|---|---|
| Специфікація | 2-3 дні | Документ з механікою пулу, токеномікою, fee structure, ролями |
| Розробка | 1-6 тижнів | Контракти на Solidity 0.8.x з Foundry, fuzz-тести |
| Fork-тестування | 3-5 днів | Тести на форку mainnet з реальними цінами |
| Аудит | 1-2 тижні | Внутрішній Slither + опціональний зовнішній |
| Деплой | 1-2 дні | Forge script, верифікація, мультисіг, timelock |
Додатково: інтеграція з фронтендом (ethers.js, wagmi), моніторинг позицій, навчання команди клієнта.
Показники нашого досвіду
Сумарний TVL розроблених пулів перевищує $100M. 5+ років на ринку DeFi, 30+ проектів зі смарт-контрактів. Працюємо з сертифікованими аудиторами з Code4rena та Sherlock. В одному проекті оптимізація контракту знизила витрати на газ на 40%, що заощадило клієнту $50,000 за рік. Концентрована ліквідність дозволяє отримати до 4x більше комісій на тому ж капіталі порівняно з x*y=k пулами. Використання private mempool знижує ризик MEV на 90%.
Процес розробки
-
Специфікація (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). Вартість зовнішнього аудиту становить від $10,000.
-
Деплой.
forge scriptз верифікацією, мультисіг Gnosis Safe на owner-функції, timelock на зміну fee параметрів (мінімум 48 годин).
Орієнтири за термінами
Базовий пул з механікою x*y=k і LP-токенами ERC-20 — від 2 тижнів з тестами. Пул з концентрованою ліквідністю в стилі Uniswap v3 — від 6 тижнів. Кастомна механіка з кількома токенами, інтеграцією з зовнішніми оракулами та fee-sharing — 2-3 місяці. Терміни аудиту не включені.
Ми спеціалізуємося на розробці пулів ліквідності. Наші смарт-контракти AMM проходять ретельний аудит. Ми надаємо послуги з розробки на основі Uniswap v3. Ми пропонуємо професійну розробку DeFi рішень. Ми проводимо повний аудит пулів ліквідності. Реалізуємо flash loan protection та MEV protection, а також професійний AMM development.
Отримайте консультацію з вибору архітектури пулу — зв'яжіться з нами для безкоштовної оцінки вашого проекту.