Разработка системы ликвидности для prediction markets
Polymarket в 2024 году — $1.5 миллиарда торгового объёма на президентских выборах. Но посмотри на любой «нишевый» рынок того же Polymarket — bid-ask spread 10-15%, ликвидность $50k total. Именно здесь ломается пользовательский опыт: пользователь хочет поставить $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 — 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.
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 держит позиции в исходах до разрешения. Если рынок сильно односторонний (все ставят на YES) — LP по сути накапливает много NO, которые могут обнулиться.
Incentive механика для LP
Простейший подход: liquidity mining — дополнительные rewards в токене протокола для LP. Но это временное решение; как только mining заканчивается, ликвидность уходит.
Устойчивее: dynamic fee — выше fee на рынках с низкой ликвидностью, ниже на высококонкурентных. Реализация: fee = base_fee + liquidity_adjustment, где liquidity_adjustment обратно пропорционален depth пула.
Ещё один паттерн: shared liquidity pool — вместо per-market пулов одна корзина ликвидности распределяется по нескольким рынкам. Контракт автоматически аллоцирует ликвидность туда, где price impact наиболее высок. Риск диверсифицирован, capital efficiency выше.
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.
Проблемы производительности и gas
Prediction markets с большим числом исходов (>2) создают gas проблемы. Для события с 10 исходами (например, чемпионат мира, 32 команды) — FPMM свап требует обновления балансов всех 32 токенов в одной транзакции. Это О(n) операций SLOAD/SSTORE на каждый трейд.
Оптимизация: lazy evaluation — хранить только delta изменений, пересчитывать полный state только при необходимости (например, при redeem). Но это усложняет логику и требует тщательного тестирования инвариантов.
Для рынков с >5 исходами на Ethereum mainnet — экономически осмысленнее деплоить на Polygon или Base. Gas на L2 позволяет работать с 20-30 outcome markets без проблем.
Процесс разработки
Аналитика (3-5 дней). Выбор AMM механики (FPMM vs LMSR vs custom), oracle strategy, incentive модель для LP, target чейн.
Контракты (2-3 недели). Conditional tokens setup + FPMM factory + LP incentives + oracle adapters. Foundry с property-based тестами: «сумма probabilities всегда = 1», «redeem никогда не превышает collateral».
Oracle интеграция (1 неделя). Chainlink API или UMA optimistic oracle setup, dispute mechanism.
Frontend (1-2 недели). wagmi/viem интеграция, торговый интерфейс, отображение probability, LP dashboard.
Ориентиры по срокам
Базовый протокол для бинарных рынков с centralised oracle — 1-2 недели. Полноценная система с оптимистичным oracle, LP incentives и multi-outcome support — от 4-6 недель.
Стоимость рассчитывается после обсуждения типов рынков и механики разрешения.