Розробка системи ліквідності для prediction markets
Polymarket у 2024 році — $1.5 мільярда торгового обсягу на президентських виборах. Але подивись на будь-який «нішевий» ринок того ж Polymarket — bid-ask spread 10-15%, загальна ліквідність $50k. Саме тут ломається користувальницький досвід: користувач хоче поставити $5000 на результат футбольного матчу, але slippage з'їдає 8% ще до початку події. Задача системи управління ліквідністю — зробити ринки ліквідними до й незалежно від органічного інтересу трейдерів.
Як працює AMM для prediction markets
LMSR та його обмеження
Logarithmic Market Scoring Rule (LMSR) — історично перший AMM для prediction markets. Ціна результатів розраховується через p_i = e^(q_i/b) / sum(e^(q_j/b)), де q_i — кількість акцій результату i, b — параметр ліквідності. Перевага: математично гарантований market maker — ринок завжди ліквідний. Недостаток: неограничені убитки маркет-мейкера при екстремальних рухах.
Пізніше CPMM (Constant Product, як у Uniswap v2) застосовується у Polymarket: для бінарного ринку YES_shares * NO_shares = k. Ціна YES = NO_shares / (YES_shares + NO_shares). Простіше для розуміння й імплементації, убитки обмежені.
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 до грудня» — це перетин двох 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. Проблема: комісії від prediction markets зазвичай малі (0.1-2%), а ризик для LP — значний. LP тримає позиції в результатах до розв'язання. Якщо ринок сильно односторонній (всі ставлять на YES) — LP по суті накопичує багато NO, які можуть обнулитися.
Механіка LP incentive
Найпростіший підхід: liquidity mining — додаткові награди в токені протоколу для LP. Але це тимчасове рішення; як тільки mining закінчується, ліквідність йде.
Стійкіше: dynamic fee — вища комісія на ринках з низькою ліквідністю, нижча на висококонкурентних. Реалізація: fee = base_fee + liquidity_adjustment, де liquidity_adjustment обернено пропорційна глибині пулу.
Ще один паттерн: shared liquidity pool — замість per-market пулів одна корзина ліквідності розподіляється по кількох ринках. Контракт автоматично алокує ліквідність туди, де price impact найвищий. Ризик диверсифіцирован, capital efficiency вища.
Oracle resolution та dispute mechanism
Найчутливіша частина — розв'язання результату. Два підходи:
Централізований оракул. Trusted reporter адреса викликає reportPayouts(). Швидко, але централізовано. Для стартового етапу — прийнятно з multisig reporter.
Оптимістичний оракул (UMA-стиль). Proposer пропонує результат з bond. 48-72 години dispute window. Disputer може оспорити з bond. Якщо оспорено — голосування через UMA DVM або Kleros. Проигравший втрачає bond. Стійкий до маніпуляції: вартість dispute > reward від неправильного розв'язання.
Chainlink + Sports/Events API. Для спортивних подій — Chainlink Any API з перевіреними джерелами (ESPN, офіційні спортивні API). Декларативно, автоматично, без людського фактора. Обмеження: не всі події мають публічний API.
Проблеми продуктивності та газу
Prediction markets з великою кількістю результатів (>2) створюють проблеми газу. Для події з 10 результатами (наприклад, чемпіонат світу, 32 команди) — FPMM своп потребує оновлення балансів всіх 32 токенів в одній транзакції. Це O(n) операцій SLOAD/SSTORE на кожен трейд.
Оптимізація: lazy evaluation — зберігати тільки delta змін, пересчитувати повний стан тільки при необхідності (наприклад, при redeem). Але це ускладнює логіку й потребує ретельного тестування інваріантів.
Для ринків з >5 результатів на Ethereum mainnet — економічно розумніше деплоювати на Polygon або Base. Газ на L2 дозволяє працювати з 20-30 outcome ринками без проблем.
Процес розробки
Аналітика (3-5 днів). Виберіть AMM механіку (FPMM vs LMSR vs кастомна), oracle стратегія, LP incentive модель, target чейн.
Контракти (2-3 тижні). Setup conditional tokens + FPMM factory + LP incentives + oracle adapters. Foundry з property-based тестами: «сума probabilities завжди = 1», «redeem ніколи не перевищує collateral».
Oracle інтеграція (1 тиждень). Setup Chainlink API або UMA optimistic oracle, dispute механізм.
Frontend (1-2 тижні). wagmi/viem інтеграція, торговий інтерфейс, відображення probability, LP дашборд.
Ориєнтири по термінах
Базовий протокол для бінарних ринків з централізованим оракулом — 1-2 тижні. Повна система з оптимістичним оракулом, LP incentives та multi-outcome підтримкою — 4-6 тижнів.
Вартість розраховується після обговорення типів ринків та механіки розв'язання.