Розробка платформи предсказань (prediction market) на блокчейні
Polymarket у 2024 році обробила понад $1.5 мільйарда обсягу торгів по президентським виборах у США. Механіка проста: користувачі купують shares в события, ціна share = implied probability. Якщо результат відбувається — share коштує $1. Якщо ні — $0. Ринок агрегує інформацію та «предсказує» вероятності краще більшості аналітиків. Побудова такої системи технічно складна: три незалежні задачі — створення ринків, підтримка ліквідності, автоматичне розрішення результатів — кожна з власними вразливостями.
Ключові технічні проблеми
Oracle manipulation при розрішенні спорів
Найвразливіше місце prediction market — механізм resolution. Хто вирішує, наступила якась подія? Три варіанти: довірений оракул (централізація), Chainlink / UMA (залежність від сторонніх протоколів), optimistic resolution з dispute period (децентралізація, але latency).
Chainlink підхід працює для чітко верифіцируемых событий: ціна активу, спортивний результат через офіційний API. Проблема: не всі события мають on-chain верифіцируемий джерело правди. «Виграє ли X вибори» — субєктивно інтерпретуємо события.
UMA Optimistic Oracle — гнучкіший підхід. Proposer пропонує результат, будь-хто може оспорити протягом dispute window (зазвичай 24-72 години), задепозивши collateral. Якщо оспорено — UMA token holders голосують. Перевага: працює для будь-якої события. Недолік: latency 2-3 дні на resolution.
Centralized multisig resolution — використовується більшістю протоколів на старту (включаючи ранній Polymarket). Швидко, але вимагає довіри до оператора. При спорних результатах — репутаційний ризик.
У нашій реалізації для кожного типу ринку вибираємо підходящий механізм. Для crypto price ринків — Chainlink. Для субєктивних событій — UMA Optimistic Oracle. Multisig — тільки як fallback при failure інших механізмів.
Ліквідність: AMM vs Order Book
Prediction markets традиційно використовують два підходи до ліквідності:
CLOB (Central Limit Order Book) — користувачі виставляють limit orders. Polymarket працює на CLOB через Polygon. Перевага: точні ціни, мінімальний slippage при наявності ліквідності. Недолік: нові ринки без учасників — немає ліквідності взагалі.
AMM (Automated Market Maker) — протокол сам підтримує ліквідність через математичну формулу. Augur V2 та Gnosis використовували LMSR (Logarithmic Market Scoring Rule). LMSR гарантує, що ринок завжди приймає сделки, але протокол несе potential loss (subsidizes liquidity).
Наш підхід: Hybrid — початкова ліквідність через protocol-seeded AMM, CLOB для крупних трейдерів. AMM використовує constant product формулу (адаптовану для бінарних результатів), LP positions виступають як automated market makers.
Токен стандарт для shares: ERC-1155
Кожен ринок має мінімум два outcome токени (YES/NO, або кілька для multi-outcome). ERC-1155 — правильний вибір: один контракт керує токенами всіх ринків, batch transfer знижує gas при торговлі кількома ринками одночасно.
При створенні ринку мінтяться conditional tokens: за кожні 1 USDC collateral створюється 1 YES + 1 NO токен. Суммарна вартість YES + NO = 1 USDC (до resolution). Після resolution один з токенів = 1 USDC, інший = 0.
Це паттерн Gnosis Conditional Tokens Framework (CTF) — battle-tested бібліотека для prediction markets. Ми будуємо поверх CTF, а не з нуля.
Архітектура системи
Контрактний шар
MarketFactory — створює нові ринки. Параметри: question, resolution source, expiry, initial liquidity. Розгортає AMM пул для кожного нового ринку.
ConditionalTokens (CTF) — Gnosis відкритий контракт для видачі conditional tokens. Перевірений кількома аудитами, має production історію на Polymarket.
FixedProductMarketMaker (FPMM) — AMM контракт для кожного ринку. Використовує constant product формулу адаптовану для N-результатів. LP providers додають ліквідність, отримують LP shares, заробляють на trading fees.
ResolutionModule — керує процесом resolution. Інтегрується з Chainlink / UMA, забезпечує dispute механізм.
TreasuryManager — протокол бере комісію (0.5-2%) від кожного трейду. Керує protocol reserves, які використовуються для першочергового seeding ліквідності нових ринків.
Створення ринку та initial liquidity
Bootstrapping ліквідності — одна з найскладніших задач. Стратегія:
-
Protocol-seeded markets. Популярні ринки (вибори, крипто события) — протокол додає початкову ліквідність з treasury. LP shares залишаються у протоколу.
-
User-created markets. Будь-хто може створити ринок, задепозивши initial liquidity. Це incentivizes market creators — вони отримують trading fees від свого ринку.
-
Conditional liquidity rewards. LPs в перші N днів після створення ринку отримують додаткові governance токени. Аналог Uniswap liquidity mining.
Gas оптимізація для Polygon / L2
Prediction markets працюють на L2 — газ на Ethereum mainnet робить мілкі сделки ($10-50) економічно невигідними. Polygon — історичний вибір Polymarket. Альтернативи: Base, Arbitrum.
На L2 gas коштує в 10-100x раз дешевше. ERC-1155 batch transfer знижує gas на 40-60% при торговлі кількома токенами одночасно. multicall паттерн для batch операцій.
Процес розробки
Аналітика (5-7 днів). Визначення типів ринків, resolution механізмів для кожного типу, токеноміки протоколу. Вивчення Polymarket, Augur, Metaculus як референсів.
Розробка контрактів (5-8 тижнів). CTF інтеграція або кастомна реалізація, FPMM логіка, resolution модулі. Тестування через Foundry: fork-тесты, fuzz-тесты на AMM інваріанти (sum of probabilities = 1).
Resolution інтеграції (2-3 тижні). Chainlink для верифіцируемих событій, UMA Optimistic Oracle для субєктивних.
Frontend (3-5 тижнів). Інтерфейс створення ринків, trading UI, portfolio, resolution tracking. wagmi + viem для контрактних взаємодій.
Аудит (обов'язковий). Складність conditional tokens логіки та потенційний обсяг коштів — обов'язковий зовнішній аудит.
Типові помилки в prediction market
Неправильний resolution без dispute механізму. Rogue оракул може розв'язати ринок на користь одного результату при спорній ситуації. Без dispute mechanism у користувачів немає recourse.
Infinite approval exploit. Якщо UI запитує infinite approve на CTF контракт та в ньому виявиться уразливість — атакуючий може дренувати весь approval. Обмежені approve або EIP-2612 permit.
Front-running при resolution. Між submission результату оракулом та його on-chain обробкою — window для front-running. Commit-reveal схема або VDF (Verifiable Delay Function) для критичних ринків.
Орієнтири по строкам
MVP (бінарні ринки, Chainlink resolution, базовий AMM, Polygon) — 6-8 тижнів. Повнофункціональна платформа з UMA, user-created markets, CLOB, governance — 2-4 місяці. Вартість розраховується індивідуально.