Розробка протоколу стабільного обміну (stable swap) для LST та стейблкоїнів
Один із наших клієнтів хотів запустити DEX для торгівлі LST-токенами. Curve Finance тримає $3-5 млрд TVL не тому, що вона перша DEX, а тому що вирішила конкретну математичну проблему: Uniswap V2 з x*y=k кривою дає 1% slippage вже при обміні 0.1% від пулу. Для активів, які мають коштувати однаково (USDC/USDT, stETH/ETH, WBTC/renBTC), це неприйнятно. Stable swap інваріант концентрує ліквідність навколо паритету та знижує slippage на порядки. Ми беремо цю математику та адаптуємо під ваш проект, спираючись на 5+ років досвіду розробки DeFi-протоколів.
Якщо ваш проект працює з pegged активами — LST (liquid staking tokens), стейблкоїнами, wrapped assets — вам потрібна саме ця математика. За 5+ років ми розробили 15+ DeFi-протоколів, включаючи інтеграції з Curve, Uniswap та Balancer. Ми гарантуємо коректну реалізацію інваріанту та ретельне тестування.
Чому stable swap кращий за Uniswap для стейблкоїнів?
Stable swap знижує slippage в 100-1000 разів порівняно з Uniswap V2 для стейблкоїнів. Далі — деталі математики.
StableSwap інваріант Curve
Curve використовує гібридний інваріант, що комбінує constant sum (x+y=k, нульовий slippage) та constant product (x*y=k, нескінченна ліквідність). Формула для двох активів:
A * n^n * sum(x_i) + D = A * D * n^n + D^(n+1) / (n^n * prod(x_i)) де A — amplification coefficient, D — інваріант, n — кількість активів.
Amplification coefficient — ключовий параметр. При A=0 система поводиться як Uniswap (constant product). При A→∞ — як constant sum. Curve використовує A=100-2000 залежно від пулу. Для пар типу USDC/USDT — високий A (100-200), тому що активи рідко відхиляються від паритету. Для stETH/ETH на старті — нижчий, тому що stETH торгувався з дисконтом і високий A призвів би до дисбалансу пулу.
Важливо: A можна змінювати. Але зміна A має бути градуальною — Curve реалізує ramp_A/stop_ramp_A з таймлоком мінімум 7 днів та обмеженням зміни не більше ніж у 10x за раз. Різка зміна A при незбалансованому пулі — це фактично зміна ціни активів, що еквівалентно маніпуляції.
Розв'язок D через ітерації Ньютона
Рівняння інваріанту не має аналітичного розв'язку відносно D — використовується метод Ньютона-Рафсона. Типова імплементація сходиться за 4-8 ітерацій при нормальних балансах. Проблема: при сильно незбалансованому пулі або екстремальних значеннях ітерації можуть не сходитися.
У Solidity це виглядає як цикл з обмеженням на 255 ітерацій та перевіркою |D_new - D_prev| <= 1. Якщо не зійшлося — revert. Це рідкісний кейс, але без нього контракт може зависнути в infinite loop при атаці спеціально підібраними параметрами.
Точність обчислень та PRECISION_MUL
Різні стейблкоїни мають різні decimals: USDC — 6, DAI — 18, USDT — 6. Всередині контракту всі баланси нормалізуються до 18 decimals через PRECISION_MUL = [1e12, 1e12, 1] (для пулу USDC/USDT/DAI). Забути цю нормалізацію — означає отримати арифметичну вразливість, яка дозволяє витягти з пулу несправедливу частку активів через remove_liquidity_one_coin.
Реальний кейс: саме помилка в нормалізації decimals стала одним із векторів у кількох форках Curve, де атакуючий міг витягти більше токенів із 18 decimals, ніж вносив токенів із 6 decimals.
Як уникнути помилок при розгортанні?
Що входить у роботу (під ключ)
- Повна архітектура пулу: базовий або meta-pool
- Імплементація контрактів: ядро StableSwap, LP-токен, admin з timelock
- Інтеграція rate providers (якщо потрібні)
- Набір тестів: unit, fork-mainnet, fuzz-тести інваріантів
- Аудит безпеки (зовнішній або внутрішній за домовленістю)
- Документація: опис математики, конфігурації та інструкції з розгортання
- Підтримка після розгортання: 1 місяць консультування
Типові ризики та їх запобігання
Форкнути Curve — спокусливо, код відкритий. Але:
Vyper→Solidity трансляція містить пастки. У Vyper @view функції не можуть змінювати стан на рівні компілятора. У Solidity за цим стежить лише view модифікатор, який не завжди застосовується коректно при трансляції.
Reentrancy у read-only контексті: атака read-only reentrancy на Curve дозволила маніпулювати ціною в LP-токені через виклик під час remove_liquidity. Протоколи, що використовують ціну LP-токена Curve як oracle, були вразливі. Якщо ваш пул планується як oracle для інших протоколів — реалізуйте reentrancy lock на всі state-changing функції та окремий view-safe price feed.
Порівняння: Stable swap vs Uniswap V2
| Параметр | Stable swap (Curve-style) | Uniswap V2 |
|---|---|---|
| Slippage для стейблкоїнів | <0.01% для угод до 20% пулу | ~1% для 0.1% пулу |
| Концентрація ліквідності | Навколо паритету | Рівномірно |
| Amplification coefficient | Налаштовуваний (100-2000) | Немає |
| Ризики | Складність математики, трансляція | Простота, але високий slippage |
Порівняння показує, що stable swap кращий за Uniswap V2 у 10-100 разів для pegged активів.
Стек та інструменти
Solidity 0.8.x для основних контрактів. Для математики з високою точністю використовуємо mulDiv із OpenZeppelin Math — уникаємо переповнення при проміжних обчисленнях типу a * b / c де a * b може перевищити uint256.
Foundry для тестування: fork-тести на Ethereum mainnet дозволяють відтворити реальні баланси Curve пулів і порівнювати output нашого контракту з оригіналом. Розходження більше 1 wei на тих самих вхідних даних — червоний прапор.
Vyper (як Curve) vs Solidity: оригінальний Curve написаний на Vyper. Ми пишемо на Solidity для кращої сумісності з toolchain (Foundry, Slither, Hardhat-екосистема). Математика — ідентична при правильній імплементації.
| Компонент | Інструмент | Причина |
|---|---|---|
| Контракти | Solidity 0.8.x | Toolchain сумісність |
| Математика | OpenZeppelin Math.mulDiv | Overflow-safe |
| Тести | Foundry + fork mainnet | Порівняння з Curve оригіналом |
| Статичний аналіз | Slither + Aderyn | Виявлення арифметичних проблем |
| Фаззинг | Echidna | Інваріанти D-константи |
Процес роботи (під ключ)
- Специфікація (1 тиждень). Визначаємо: кількість активів, чи потрібні rate providers, архітектура (базовий пул vs meta-pool), модель зборів, governance параметри (хто може змінювати A та комісію).
- Розробка математичного ядра (1-2 тижні). Інваріант, Newton's method для D,
get_y()для розрахунку виходу. Покриття тестами: порівняння з Python reference implementation Curve. - Контракти пулу та LP-токену (1-2 тижні). exchange, add/remove liquidity, admin functions з timelock.
- Інтеграційні тести (1 тиждень). Fork-тести, fuzzing інваріантів, stress testing extreme imbalance сценаріїв.
- Аудит. Для пулів із реальними коштами — обов'язковий зовнішній аудит. Математика stable swap нетривіальна та містить неочевидні edge cases.
Терміни: від 2 до 4 місяців від специфікації до готовності до аудиту, залежить від складності архітектури. Вартість розраховується після фіналізації вимог — зв'яжіться з нами для безкоштовної оцінки вашого проекту.
Примітка: Ми гарантуємо якість реалізації та надаємо сертифікованих аудиторів. Наш досвід 5+ років у DeFi та 15+ реалізованих протоколів — ваша гарантія успішного запуску. Докладніше про математику StableSwap можна прочитати в оригінальній статті Curve або на Wikipedia.
Пропонуємо розробку stable swap під ключ за 2-4 місяці. Напишіть нам для оцінки вашого проекту — ми безкоштовно проаналізуємо вимоги та запропонуємо рішення.