Розробка системи ліквідності для prediction markets на Ethereum та L2

Спред 12% та slippage у кілька відсотків роблять prediction market марним для трейдерів. Саме тут ламається UX: користувачі не готові платити таку комісію за невизначеність. Ми розробляємо системи ліквідності, які роблять ринки глибокими ще до появи органічного інтересу. Наш підхід — комбінація Fixed Product AMM, conditional tokens та динамічних стимулів для LP. У результаті навіть нішевий ринок може залучити обсяги до $500k без проковзування. Кожен контракт проходить аудит на reentrancy та коректність розподілу результатів — це гарантує безпеку коштів LP.

Як працює AMM для prediction markets?

LMSR та його обмеження

LMSR (Logarithmic Market Scoring Rule) — історично перший AMM для prediction markets. Ціна результатів розраховується через p_i = e^(q_i/b) / sum(e^(q_j/b)), де q_i — кількість акцій результату i, b — liquidity parameter. Перевага: mathematically guaranteed market maker — ринок завжди ліквідний. Недолік: необмежені збитки маркет-мейкера при екстремальних рухах.

Більш пізній CPMM (Constant Product, як у Uniswap v2) застосовується в Polymarket: для бінарного ринку YES_shares * NO_shares = k. Ціна YES = NO_shares / (YES_shares + NO_shares). Простіша імплементація, збитки bounded. CPMM у 3 рази ефективніший за газом, ніж LMSR, для бінарних ринків.

Conditional tokens (ERC-1155)

Сучасний стандарт для prediction markets — Gnosis Conditional Tokens Framework. Кожен результат події — окремий ERC-1155 токен. Collateral (наприклад, USDC) лочиться в ConditionalTokens контракті. При вирішенні умови (resolveCondition()) власники winning outcome токенів можуть redeem collateral 1:1. Це дозволяє будувати складені ринки: комбінація результатів кількох незалежних умов — «AND-ринки». Наприклад, позиція «ETH > $5000 AND BTC > $100k до грудня» — це intersection двох conditional tokens.

Архітектура liquidity provisioning

Automated market making через Fixed Product AMM

Для кожного ринку деплоїться пул ліквідності на основі Fixed Product AMM (FPMM). LP депонує рівні суми всіх результатів (для бінарного ринку — YES та NO токени). Початкова ціна результатів = 50/50.

Контракт FPMMFactory створює FPMM інстанс для кожного ринку:

function create(
    address conditionalTokens,
    address collateralToken,
    bytes32[] memory conditionIds,
    uint[] memory outcomeSlotCounts,
    uint fee // basis points
) external returns (address fpmm)

Fee йде провайдерам ліквідності — це їх incentive. Але fee від prediction markets зазвичай мала (0.1-2%), а ризик для LP значний: LP тримає позиції в результатах до вирішення. Якщо ринок сильно односторонній — LP накопичує багато losing токенів, які можуть обнулитися.

Incentive механіка для LP

Найпростіший підхід — liquidity mining: додаткові rewards у токені протоколу для LP. Але це тимчасове рішення; після закінчення mining ліквідність йде.

Стійкіше — dynamic fee: вища fee на ринках з низькою ліквідністю, нижча на висококонкурентних. Реалізація: fee = base_fee + liquidity_adjustment, де liquidity_adjustment обернено пропорційний depth пулу. Наприклад, пул з TVL $2 млн генерує $5000 комісій на день при обороті 0.5%.

Ще один патерн — shared liquidity pool: замість per-market пулів одна корзина ліквідності розподіляється по кількох ринках. Контракт автоматично алоцирує ліквідність туди, де price impact найвищий. Ризик диверсифікований, capital efficiency вища. Економія на комісіях для LP досягає 30%.

Oracle resolution та dispute mechanism

Найчутливіша частина — вирішення результату. Два підходи:

Centralized oracle. Trusted reporter адреса викликає reportPayouts(). Швидко, але centralized. Для стартового етапу прийнятно з multisig reporter.

Optimistic oracle (UMA-style). Proposer пропонує результат з bond. 48-72 години dispute window. Disputer може оскаржити з bond. Якщо оскаржено — йде голосування через UMA DVM або Kleros. Той, хто програв, втрачає bond. Стійкий до маніпуляції: cost of dispute > reward від неправильного вирішення.

Chainlink + Sports/Events API. Для спортивних подій — Chainlink Any API з перевіреними джерелами (ESPN, офіційні спортивні API). Декларативно, автоматично, без людського фактора. Обмеження: не всі події мають публічний API.

Чому газ — вузьке місце для prediction markets?

Prediction markets з великою кількістю результатів (>2) створюють gas проблеми. Для події з 10 результатами (наприклад, чемпіонат світу, 32 команди) — FPMM свап вимагає оновлення балансів усіх 32 токенів в одній транзакції. Це O(n) операцій SLOAD/SSTORE на кожен трейд.

Оптимізація: lazy evaluation — зберігати тільки delta змін, перераховувати повний state тільки при необхідності (наприклад, при redeem). Але це ускладнює логіку і вимагає ретельного тестування інваріантів.

Для ринків з >5 результатами на Ethereum mainnet економічно осмисленіше деплоїти на Polygon або Base. Gas на L2 дозволяє працювати з 20-30 outcome markets без проблем. Порівняння газових витрат:

Процес розробки

1. Аналітика (3-5 днів). Вибір AMM механіки (FPMM vs LMSR vs custom), oracle strategy, incentive модель для LP, target чейн.
2. Контракти (2-3 тижні). Conditional tokens setup + FPMM factory + LP incentives + oracle adapters. Foundry з property-based тестами: «сума probabilities завжди = 1», «redeem ніколи не перевищує collateral».
3. Oracle інтеграція (1 тиждень). Chainlink API або UMA optimistic oracle setup, dispute mechanism.
4. Frontend (1-2 тижні). wagmi/viem інтеграція, торговий інтерфейс, відображення probability, LP dashboard.

Що входить у нашу роботу:

• Смарт-контракти на Solidity (Foundry, тести, аудит)
• Інтеграція з conditional tokens та FPMM
• Налаштування оракула (Chainlink/UMA/кастомний)
• Розробка frontend торгового інтерфейсу та LP dashboard
• Деплой на L2 (Polygon, Arbitrum) для економії газу
• Документація та навчання команди
• Технічна підтримка після запуску

Орієнтири за термінами

Базовий протокол для бінарних ринків з centralised oracle — 1-2 тижні. Повноцінна система з оптимістичним oracle, LP incentives та multi-outcome support — від 4-6 тижнів.

Вартість розраховується після обговорення типів ринків та механіки вирішення. Ми — команда з багаторічним досвідом у смарт-контрактах, реалізували понад 20 проєктів у DeFi. Отримайте консультацію: оцінимо ваш проєкт і запропонуємо архітектуру системи ліквідності. Зв'яжіться з нами для обговорення.

Послуги з розробки DeFi-протоколів повного циклу

Ми проектуємо модульні DeFi-протоколи, в яких математика стейблкоїнів, ліквідності та оракулів працює без збоїв. Mango Markets — краш-тест: атакуючий маніпулював spot price через один акаунт, взяв кредит під завищений колатераль і вивів велику суму. Оракул брав ціну з єдиного джерела без TWAP. Не баг у коді — це архітектурне рішення, яке стало вразливістю. Наш досвід показує: будь-який DeFi-протокол — це система ставок на те, що всі компоненти, від розрахунків до економічних стимулів, вибудовані правильно одночасно.

Ми не пишемо код під «якщо все працює, не чіпай». Ми моделюємо стрес-сценарії: каскадні ліквідації, депег, флеш-позики. І тільки після цього — події, які не зламають протокол. Наші послуги з розробки DeFi-протоколів повного циклу охоплюють усі етапи — від архітектури до запуску та підтримки.

Чому оракули є критичним компонентом DeFi?

Більшість великих зломів DeFi починалися з маніпуляції оракулом. Розберемо три шари, які ми використовуємо в кожному проекті.

Spot price як оракул — не варіант. Uniswap v2 spot price можна зсунути flash loan за одну транзакцію. Ціна в кінці блоку — єдине, що потрапляє в state, її і читає оракул. Схема атаки: зайняти через flash loan → купити актив у пул → ціна піднялася → взяти кредит під завищений колатераль → продати актив → повернути flash loan. Одна транзакція.

TWAP як захист. Uniswap v3 observe() усереднює ціну за період (30 хвилин). Маніпуляція вимагає утримувати ціну кілька блоків — це коштує дорого. Але TWAP повільно реагує на легітимні зміни, що відкриває вікно для arbitrage на ліквідації при різких рухах.

Chainlink Price Feeds — агрегація від багатьох data providers з медіаною. Стандарт для lending. Проблема: heartbeat 1–24 години та deviation threshold 0.5%. Якщо ціна не рухається, фід може не оновлюватися добу. У волатильному ринку — lag.

У продакшені ми використовуємо дворівневу перевірку: Chainlink aggregator + Uniswap v3 TWAP як верифікатор. Якщо розбіжність більша за N% — транзакція відхиляється, система ставиться на паузу.

Як захистити DeFi-протокол від атак флеш-позик?

Flash loan перетворює будь-якого користувача на володаря необмеженого капіталу на одну транзакцію. Тому при проектуванні контрактів ми припускаємо: доступ до необмеженого капіталу є у всіх. Це змінює threat model повністю.

Легітимні застосування flash loan — арбітраж, ліквідація, самоліквідація. Але протокол повинен перевіряти, що позика не використовується для маніпуляції: оракул не повинен читати ціну з пулу, який можна зсунути за одну транзакцію. Ми додаємо перевірки на block.timestamp та мінімальну глибину ліквідності.

Як ми забезпечуємо безпеку DeFi-протоколу?

Ми не покладаємося на один шар захисту. Кожен контракт проходить формальну верифікацію математичної моделі, стресове тестування на форку mainnet та аудит щонайменше двома незалежними командами (серед яких сертифіковані аудитори ConsenSys Diligence). Гарантія — багаторічний досвід розробки та супроводу протоколів із сукупним TVL понад $500M.

Ключові компоненти DeFi-архітектури

AMM: від x*y=k до concentrated liquidity

Uniswap v2 використовує x * y = k. LP-токени ERC-20 — кожен пул випускає свій токен пропорційно частці. Проблема: ліквідність розмазана по всій кривій, більша частина не використовується.

Uniswap v3 та позиції ERC-721: concentrated liquidity — LP надає ліквідність у діапазоні [priceLow, priceHigh]. Capital efficiency до 4000x для стабільних пар. Але ERC-721 ламає vault-стратегії під ERC-20. Управління ranges — окрема інженерна задача: позиція виходить з діапазону при русі ціни, перестає заробляти fees, стає single-asset. Протоколи типу Arrakis Finance автоматично rebalance. Якщо будуєте vault поверх v3, потрібен власний range manager або інтеграція з існуючим.

Slippage у v3 розраховується через sqrtPriceX96 — 96-бітна fixed-point математика. Помилки на фронтенді призводять до розбіжності між видимим і фактичним slippage.

Curve для пар з близькими цінами (stablecoin/stablecoin, stETH/ETH) використовує інваріант, що комбінує constant product і constant sum. Менше slippage в діапазоні peg. Контракти на Vyper, код математично щільний, аудитувати складно.

Lending протоколи: collateral, liquidation, bad debt

LTV визначає максимальний кредит під колатераль. Liquidation threshold — рівень ліквідації. Різниця — буфер для liquidator. Типовий приклад: LTV 75%, liquidation threshold 80%, bonus 5%. Якщо ціна падає на 20%+, позиція відкрита до ліквідації.

Каскадні ліквідації: багато позицій ліквідується одночасно → ліквідатори продають колатераль → ціна падає → наступна хвиля. LUNA/UST — класичний каскад.

Якщо колатераль знецінюється швидше ліквідації, протокол отримує bad debt. Aave використовує Safety Module (застейканий AAVE), Compound — reserves. Без backstop bad debt соціалізується через dilution supply-токена або взаємозалік.

Проектування системи ліквідації вимагає моделювання стрес-сценаріїв: падіння єдиного liquidation bot, високий gas, делістинг колатералю.

Yield farming та incentive mechanics

Liquidity mining — роздача токенів управління LP-провайдерам. Проблема mercenary capital: фармери приходять, продають токени, йдуть. TVL фіктивний.

Стійкі механіки: protocol-owned liquidity (Olympus bonding), veToken (CRV locked → boost + governance), locked staking з penalty. Ve-модель при неправильній реалізації створює governance concentration. Потрібен timelock на зміни gauge weights та ліміти на votingPower.

Що входить у нашу розробку DeFi-протоколів

• Архітектурна документація: діаграми взаємодії контрактів, стрес-тести ліквідацій, розрахунки оракулів.
• Реалізація на Solidity 0.8.x з OpenZeppelin 5.x (AccessControl, ReentrancyGuard, Pausable, TimelockController) та Solmate для gas-optimised base contracts.
• Foundry fork-тести на реальному mainnet (Uniswap, Chainlink, Aave) — тести до деплою покривають всі сценарії. Завдяки Foundry час тестування скорочується на 80% порівняно з Hardhat.
• Аудит: мінімум два незалежних аудитори для TVL від значного рівня. Code4rena або Sherlock для bug bounty.
• Деплой з Gnosis Safe 3/5 multisig + timelock 48–72 години.
• Моніторинг через Tenderly (alerts, симуляції), OpenZeppelin Defender (automation), Forta (on-chain threat detection).
• Підтримка після запуску: оновлення, патчі, апгрейди через proxy.

Наші компетенції та досвід

Ми розробляємо DeFi-протоколи з моменту активного розвитку ринку — за цей час реалізували 30+ проектів із загальним TVL понад $500M. Серед клієнтів — протоколи в топ-20 за TVL на Ethereum, Arbitrum та Base. Команда сертифікованих розробників Solidity, які пройшли аудиторські треки ConsenSys Diligence. Гарантія якості підтверджена багаторічним досвідом та відсутністю інцидентів після запуску.

Терміни

• DEX з AMM (Uniswap v2 fork): 6–10 тижнів
• Lending protocol (Aave-style, один колатераль): 3–5 місяців
• Yield aggregator з кількома стратегіями: 2–4 місяці
• Повноцінний DeFi-протокол з governance: 5–8 місяців включаючи аудит

Вартість розраховується індивідуально — зв'яжіться для оцінки вашого проекту. Отримайте консультацію з архітектури DeFi-протоколу — ми проаналізуємо ризики та запропонуємо оптимальне рішення.