Как работают prediction markets в DeFi простыми словами: от Polymarket и UMA до MVP с automation layer

Prediction markets часто обсуждают как медийный феномен: кто точнее угадал выборы, цену ETF или решение регулятора. Но с инженерной точки зрения это очень интересный класс DeFi-протоколов, потому что он соединяет liquidity layer, pricing, oracle-resolution и settlement в один продукт.

Если убрать шум, prediction market — это протокол, в котором пользователи покупают и продают вероятности исхода. Цена токена “YES” или “NO” становится приблизительной оценкой шанса события. Дальше протокол должен сделать три вещи: удержать ликвидность, дождаться исхода и корректно рассчитать выплату.

Именно поэтому prediction markets полезно разбирать не как азартную витрину, а как инфраструктуру. Здесь хорошо видно, как onchain-система обращается с информацией из внешнего мира, как деньги двигаются между трейдерами, LP и арбитрами, и почему automation layer вокруг resolution, monitoring и risk controls часто важен не меньше, чем сами контракты.

Ниже — практический разбор: какие prediction market-протоколы и модели есть на рынке, как они работают простыми словами, какие компоненты нужны в архитектуре, где сидят основные риски и как собрать похожий MVP без лишней магии.

Что это за класс протоколов и кто есть на рынке

Prediction market-протоколы можно понимать как рынки для торговли условными выплатами. Пользователь не покупает сам актив, а покупает позицию, которая принесёт payout, если событие случится.

На рынке можно выделить несколько заметных подходов.

1. Orderbook или exchange-подход

Это модель, где пользователи выставляют bid/ask по конкретному исходу, а платформа сводит сделки между ними.

Самый известный пример последних лет — Polymarket. С продуктовой стороны идея проста:

есть рынок с чёткой формулировкой события;
есть токены или доли исходов;
пользователи покупают и продают их по рыночной цене;
после наступления дедлайна рынок резолвится, и победивший исход погашается по 1 доллару, проигравший — по 0.

Плюс такого подхода — хорошая ценовая сигнализация и привычная биржевая механика. Минус — надо решать проблему ликвидности и отдельным слоем продумывать resolution.

2. AMM-based conditional token markets

Другой путь — строить prediction market как пул ликвидности, где цена исходов меняется по формуле.

Исторически вокруг Gnosis, Omen и похожих систем обсуждали conditional tokens и AMM-модели. Здесь важная идея такая:

базовый collateral, например USDC, блокируется в market contract;
из него создаются условные токены разных исходов;
AMM позволяет покупать и продавать эти исходы без обязательного поиска контрагента;
после resolution победивший outcome redeemится обратно в collateral.

Это ближе к классическому DeFi-мышлению: есть liquidity pool, pricing function и redemption flow.

3. Oracle-driven resolution layer

Во многих prediction markets главный продуктовый риск — не матчинг ордеров, а ответ на вопрос: кто и как определяет, что событие действительно произошло.

Здесь важны такие модели, как:

optimistic resolution;
арбитраж/диспуты;
репутационные стейкеры;
внешние adjudication rules;
oracle-слой вроде UMA Optimistic Oracle для подтверждения исхода.

На практике рынок часто живёт не только за счёт торговой логики, а за счёт того, насколько внятно и дешево протокол умеет дойти до финального ответа.

4. Vertical prediction products

Есть и продуктовый слой поверх базовых рынков исходов:

sports/event markets;
election markets;
macro/ETF/crypto-event рынки;
B2B API для embedded forecast widgets;
internal decision markets для компаний или DAO.

Здесь prediction market становится не просто торговой площадкой, а reusable infrastructure для вероятностных рынков и event-linked settlement.

Как это работает простыми словами

Самая полезная отправная точка — не «ставка на событие», а торговля вероятностью.

Базовая логика YES/NO рынка

Представим рынок с вопросом:

“Будет ли ETH выше 4 000 долларов на 30 июня?”

Протокол создаёт два исхода:

Если рынок сейчас оценивает YES в 0.37, это значит, что коллективная цена участников примерно закладывает 37% вероятность события.

Что может сделать пользователь:

купить YES, если считает вероятность выше 37%;
продать YES или купить NO, если считает вероятность ниже;
обеспечить ликвидность и зарабатывать на fee, если уверен, что объём торгов это окупит.

После дедлайна рынок проходит resolution:

если событие случилось, YES redeemится по 1, NO по 0;
если не случилось, наоборот.

Откуда берётся цена

В prediction market цена — это не официальный truth-feed, а рыночная оценка.

Она появляется из комбинации:

убеждений трейдеров;
новой информации;
liquidity depth;
арбитража между связанными рынками;
поведения market makers или AMM.

То есть токен YES по 0.62 — это не «истина», а цена, по которой рынок сейчас готов обменять вероятность на деньги.

Как двигаются деньги

Упрощённо денежный поток выглядит так:

Пользователь или LP вносит collateral, чаще всего stablecoin.
Протокол выпускает conditional positions или открывает доступ к торгам по market shares.
Участники покупают и продают исходы, двигая цену.
Протокол или market makers собирают комиссии.
После deadline рынок закрывается для новых трейдов.
Oracle/resolution layer подтверждает итог.
Победивший исход обменивается обратно в collateral по фиксированному payout.

Это важный момент: prediction market — это не просто «ставка», а система, где деньги лежат под условной выплатой до тех пор, пока внешний факт не будет однозначно зафиксирован.

Какие модели prediction markets чаще всего встречаются

1. Binary markets

Самый понятный и ликвидный формат: событие произошло или нет.

Примеры:

будет ли протокол A запущен до даты X;
одобрит ли SEC конкретный ETF до дедлайна;
будет ли BTC выше уровня Y на дату Z.

Плюсы:

понятный UX;
простая payout-логика;
меньше споров в settlement.

Минусы:

формулировка вопроса должна быть очень точной;
даже небольшой ambiguity бьёт по доверию к resolution.

2. Categorical markets

Здесь исходов больше двух.

Примеры:

какая L2 станет лидером по TVL к концу квартала;
кто выиграет конкретные выборы;
какой актив покажет лучший performance за период.

Это удобнее для richer information markets, но сложнее для ликвидности: объём распыляется между несколькими outcomes.

3. Scalar markets

Здесь торгуется не просто событие, а диапазон численного значения.

Примеры:

где окажется цена ETH в диапазоне 2 000–5 000;
какой будет inflation print;
сколько revenue соберёт конкретный протокол.

Такие рынки ближе к производным и forecast-инструментам. Они полезны для data-rich сценариев, но сильно сложнее по UX и settlement rules.

4. Conditional token markets

Это очень DeFi-подход. Один базовый collateral расщепляется на условные доли разных исходов.

Плюсы:

удобно строить composable contracts;
можно делать mint/split/merge позиций;
хорошо ложится на onchain accounting.

Минусы:

пользователю сложнее понять механику с первого взгляда;
нужен аккуратный redemption flow и нормальная индексация.

Основные компоненты архитектуры

Если смотреть на prediction market как на инженерную систему, почти всегда появляются следующие слои.

1. MarketFactory

Модуль, который создаёт рынок по строгим правилам.

Он должен хранить:

текст вопроса;
категорию рынка;
deadline для торгов;
resolution source;
список outcomes;
collateral asset;
fee config;
dispute window.

Для MVP лучше не давать полную свободу и сразу вводить шаблоны рынка. Чем меньше произвольности в формулировке и settlement rules, тем меньше будущих споров.

2. CollateralVault

Хранит базовый collateral и отвечает за погашение победивших позиций.

Функции:

приём депозита;
mint условных позиций;
redemption после resolution;
блокировка выводов в некорректных состояниях;
учёт комиссий.

3. Matching или AMM layer

Нужен слой, который даёт цене двигаться.

Это может быть:

orderbook;
RFQ/solver flow;
constant function market maker;
гибрид, где quote строится offchain, а settlement остаётся onchain.

Для MVP AMM чаще проще, потому что не требует сразу строить полноценную matching engine.

4. Oracle / Resolution engine

Это ключевой слой prediction market-протокола.

Он должен уметь:

принимать proposed outcome;
выдерживать dispute window;
подтверждать финальный результат;
логировать justification и source;
переводить рынок в final state.

Если этот слой слабый, весь продукт начинает напоминать не рынок вероятностей, а просто UI над неясным ручным решением.

5. Redemption engine

После resolution система должна корректно раздать деньги:

победивший исход redeemится по номиналу;
проигравшие позиции гасятся;
комиссия списывается прозрачно;
treasury и LP accounting обновляются без ручных правок.

6. RiskConfig / Policy engine

Здесь лежат продуктовые лимиты и guardrails:

allowed categories;
max open interest на рынок;
min liquidity depth;
max unresolved markets per operator;
stale resolution thresholds;
pause / emergency flags;
требования к phrasing question templates.

Где основные риски и trade-offs

Prediction markets выглядят просто снаружи, но ломаются они обычно в довольно предсказуемых местах.

1. Resolution ambiguity risk

Главный риск — плохо сформулированный вопрос.

Если событие можно трактовать по-разному, начинается конфликт:

какой источник считать главным;
как трактовать форс-мажор;
какой timestamp использовать;
что делать, если событие частично произошло.

Поэтому хорошая формулировка рынка — это не копирайтинг, а часть risk engine.

2. Oracle governance risk

Даже если вопрос хороший, кто-то всё равно должен зафиксировать финальный outcome.

Риски здесь такие:

централизованный оператор ошибся;
optimistic proposal не был оспорен вовремя;
dispute-cost слишком высокий;
арбитры имеют конфликт интересов;
внешний источник данных пропал или изменил формат.

3. Liquidity fragmentation risk

Если рынков слишком много, объём распадается на множество тонких стаканов или мелких пулов.

Последствия:

спреды растут;
цена становится шумной;
крупному пользователю тяжело зайти или выйти;
вероятностный сигнал хуже отражает коллективное мнение.

4. Manipulation before resolution

Особенно опасны тонкие рынки рядом с дедлайном.

Там возможны:

price painting ради красивого медийного графика;
искусственный сдвиг вероятности под соцсети;
атаки на тонкий AMM;
давление на market makers перед закрытием.

Это не всегда ломает payout напрямую, но может портить репутацию и usefulness цены как сигнала.

5. Smart contract and redemption risk

Стандартный DeFi-набор тоже никуда не девается:

баг в split/merge conditional positions;
неправильный redemption расчёт;
утечка collateral;
админские права слишком широкие;
неверный state machine вокруг unresolved/paused/finalized markets.

6. Regulatory and product boundary risk

Prediction markets часто находятся на границе между information markets, derivatives и betting products.

Даже если не уходить в юридические детали, для продуктовой команды это значит одно: нельзя проектировать систему так, будто resolution, geographic restrictions и disclosure — это второстепенные мелочи.

Как сделать похожий прототип или MVP

Если цель — показать механику, не нужно строить огромную универсальную биржу исходов. Лучше собрать узкий MVP, который докажет базовые свойства системы.

Хороший MVP должен доказать семь вещей:

можно создать рынок из шаблона с корректной формулировкой;
пользователь может внести collateral и купить outcome;
цена действительно двигается после сделок;
дедлайн закрывает рынок предсказуемо;
resolution проходит через явный proposal/dispute/finalize flow;
redemption корректно отдаёт payout победителям;
automation layer отслеживает зависшие или спорные рынки.

Разумные границы MVP

Для demo достаточно:

одна EVM-сеть;
только binary markets;
collateral в USDC;
ограниченный набор market templates;
один oracle/resolution provider;
AMM вместо полноценного orderbook;
operator dashboard для review unresolved markets.

Такой MVP уже позволит показать механику без боли от полной биржевой инфраструктуры.

Какие контракты нужны

1. MarketFactory

Создаёт новые рынки из whitelist-шаблонов.

Функции:

create market;
validate template;
register outcomes;
set market deadlines;
bind resolution policy.

2. ConditionalTokenManager

Управляет выпуском и погашением outcome tokens.

Функции:

split collateral into YES/NO;
merge opposite positions;
transfer outcome balances;
redeem winning shares after finalize.

3. AMMPool

Обеспечивает базовую ликвидность и price discovery.

Функции:

add/remove liquidity;
buy outcome;
sell outcome;
calculate quote;
collect trading fees.

4. ResolutionController

Оркестрирует proposal, dispute и finalize.

Функции:

propose outcome;
post bond;
dispute outcome;
finalize after window;
expose audit trail по каждому рынку.

5. RedemptionController

Закрывает рынок и распределяет collateral.

Функции:

freeze trading after deadline;
accept final outcome;
redeem winner balances;
mark losing shares worthless;
update treasury accounting.

6. RiskConfig

Хранит лимиты и аварийные переключатели.

Примеры параметров:

max open interest per market;
max market duration;
min initial liquidity;
dispute window duration;
resolution SLA threshold;
emergency pause;
allowed source templates.

Индексация и data layer

Prediction market без индексации быстро становится непрозрачным.

Минимальный набор сущностей:

markets
outcomes
trades
lp_positions
resolution_proposals
disputes
finalizations
redemptions
operator_actions
alerts

Практичный стек для MVP:

Postgres;
indexer на Node/TypeScript или Go;
job queue для deadlines и resolution windows;
admin UI для review и finalize;
отдельный service для oracle adapters.

Бэкенд-джобы, без которых MVP будет хрупким

Минимально полезный набор такой:

market_close_job — закрывает торги по дедлайну;
resolution_prompt_job — создаёт задачу на proposal outcome;
dispute_window_job — отслеживает окончание окна спора;
finalize_job — завершает рынок после успешного resolution;
redemption_reconciliation_job — сверяет collateral и redeemed balances;
liquidity_health_job — смотрит на глубину и перекос цены;
alert_job — шлёт сигналы по зависшим, спорным или плохо ликвидным рынкам.

Как упростить pricing в MVP

Не нужно сразу строить сложную matching engine с продвинутыми маркет-мейкерами.

Для demo практичнее:

взять простой AMM для YES/NO;
ограничить размер сделок;
хранить reference price path в индексе;
считать implied probability прямо из pool state;
добавить guardrails на extreme slippage.

То есть сначала показать честный price-discovery и settlement loop, а не пытаться эмулировать full-featured биржу.

UI для демо

Для MVP хватит семи блоков:

список активных рынков;
карточка рынка с вопросом, probability и deadline;
buy/sell pane для YES/NO;
LP view с fee и liquidity share;
resolution timeline;
redemption history;
operator dashboard с unresolved/disputed markets.

Что можно автоматизировать поверх такого протокола

Prediction markets очень выигрывают от automation layer, потому что значительная часть риска лежит не в swap-функции, а в операционном цикле рынка.

1. Market creation policy

Automation может не пускать в прод новый рынок, пока он не проходит простые checks:

вопрос соответствует шаблону;
указан допустимый source of truth;
дедлайн не конфликтует с resolution SLA;
нет дубликата почти такого же рынка;
initial liquidity выше минимального порога.

2. Resolution monitoring

Самый ценный слой automation — не дать рынку зависнуть в unresolved state.

Нужно автоматически отслеживать:

рынки, где дедлайн уже прошёл;
задержанные oracle-updates;
отсутствие proposal outcome;
истечение dispute window;
рынки, где finalize не случился вовремя.

3. Risk controls и circuit breakers

Automation layer может:

ставить рынок на паузу при спорной формулировке;
ограничивать объём при слишком тонкой ликвидности;
выключать новые market listings при проблемах с oracle provider;
требовать ручного approval для high-visibility рынков;
поднимать инцидент при аномальном росте open interest.

4. Liquidity management

Если у протокола есть собственные market making или LP incentives, automation полезен и здесь:

перераспределять liquidity budget;
снимать стимулы с мёртвых рынков;
добавлять fee multipliers в тонких рынках;
следить за inventory imbalance по исходам.

5. Treasury и fee accounting

Автоматизация нужна и для финансового слоя:

считать fee revenue по рынкам;
сверять locked collateral;
отслеживать outstanding redemption obligations;
строить PnL по incentive programs;
фиксировать operator overrides.

6. Alerting для операторов и интеграторов

Самые полезные сигналы обычно такие:

market unresolved дольше SLA;
dispute opened;
oracle source unavailable;
liquidity below threshold;
redemption mismatch;
duplicate market detected;
abnormal volume spike перед дедлайном.

Практическая архитектура automation layer

Если собрать рабочую схему, получится примерно такой набор:

Market policy service — валидирует новые рынки и question templates.
Oracle adapter service — подтягивает источники данных и готовит resolution payload.
Resolution orchestrator — ведёт proposal/dispute/finalize lifecycle.
Execution gateway — единая точка для close market, finalize и redeem flows.
Treasury accountant — считает locked collateral, fees и redemption liabilities.
Risk monitor — следит за unresolved markets, thin liquidity и open interest spikes.
Alerting layer — шлёт сигналы в Telegram/Slack по спорным и зависшим состояниям.
Operator dashboard — показывает status рынков, audit trail и ручные overrides.

Для команды это важно по очень практичной причине: prediction market быстро превращается в операционный хаос, если resolution живёт в заметках оператора, дедлайны закрываются руками, а спорные рынки обнаруживаются только после жалоб пользователей.

Где такой MVP реально полезен

Даже без запуска массовой consumer-платформы такой MVP полезен как:

demo для event-linked DeFi settlement;
B2B слой для embedded forecast markets;
internal market для DAO governance signals;
исследовательский стенд для oracle/dispute-механик;
шаблон для продуктов, где важен payout по внешнему событию.

Главное, что стоит запомнить

Prediction markets в DeFi — это не просто красивая торговля мнениями. Это протоколы, где вероятность превращается в актив, а внешний факт — в условие для final settlement.

Если упростить механику до сути, получается следующее:

рынок выпускает условные позиции на исход события;
цена этих позиций отражает текущую коллективную вероятность;
после дедлайна нужен надёжный resolution layer, иначе весь продукт перестаёт быть доверяемым;
ключевые риски лежат в формулировке рынка, oracle governance, liquidity fragmentation и redemption logic;
MVP проще всего строить как binary market на USDC с шаблонными вопросами, AMM-ликвидностью и явным proposal/dispute/finalize flow;
automation layer особенно важен вокруг market creation policy, resolution monitoring, alerts и treasury reconciliation.

Именно поэтому prediction markets — один из самых показательных DeFi-классов для инженерного разбора. Здесь особенно хорошо видно, как протоколу приходится работать не только с токенами и ликвидностью, но и с неоднозначностью внешнего мира — а это почти всегда и есть самое сложное место в системе.