Система оракулів для prediction markets
Prediction market покладається на довіру до оракула: якщо оракул брехає чи помиляється — весь ринок втрачає сенс. Система оракулів для prediction market складніша ніж ціновий feed — повинна обробляти субективні питання, спірні результати, форс-мажор, события, які не сталися.
Класифікація ринків за вимогами до оракула
Binary markets (так/ні): найпростіший резолвинг. "Ціна BTC > $100K на 31 грудня?" → 0 або 1.
Scalar markets: "Яка буде ціна ETH 31 грудня?" → числове значення в діапазоні.
Categorical markets: "Хто виграє чемпіонат?" → вибір з кількох варіантів.
Conditional markets: "Якщо подія X сталася — що з Y?" — складна залежність.
Многошарова система оракулів
Платформа типу Polymarket використовує UMA Optimistic Oracle для більшості ринків плюс USDC на Polygon.
Система з трьома рівнями
Рівень 1: Automatic Resolution
├── Price feeds (Chainlink/Pyth) для price-based
└── Verifiable external data (sports, election APIs)
Рівень 2: Optimistic Resolution (UMA/Reality.eth)
├── Proposer → пропонує результат + bond
├── Dispute window (2h - 24h)
└── Без dispute → прийнято
Рівень 3: Human Escalation
├── UMA DVM (token voter court)
├── Kleros arbitration
└── DAO governance vote
Роль創者Ринку
Кожний ринок створюється з:
- Resolution criteria: точні умови, що визначають результат
- Resolution oracle: який оракул/процес використовується
- Resolution timestamp: коли або як триггер
- Invalid conditions: коли ринок визначається invalid
Trusted Reporters / Верифіковані джерела
Для sports та news подій — модель trusted reporter:
News Feed Integration: офіційні API (AP, Reuters, ESPN) надають machine-readable дані. Договірні угоди забезпечують надійність джерела.
Multi-reporter consensus: кілька незалежних reporters повинні погодитися. 3-з-5 threshold.
Reporter staking: reporters стейкають токени. Неправильний або маніпульований звіт → slashing. Економічний стимул до честі.
Обробка edge cases
Event cancelled: матч перенесений, вибори скасовані. Ринок повинен повернути ставки (void).
Ambiguous outcome: результати можуть інтерпретуватись по-різному. Потреба механізму escalation.
Late oracle data: оракул повернув дані через 2 години після дедлайну — приймати або ні? Критерії встановити заздалегіді.
Oracle manipulation: високий UMA bond означає, що маніпуляція неекономічна. Потреба мониторингової системи.
Resolution аналітика
Платформа повинна трекити якість резолвингу:
- Час від resolution timestamp до фактичного resolve
- % ринків auto-resolved vs disputed
- Історія disputes та їх результати
- Reputation scores reporters
Добре налаштована система оракулів — конкурентна перевага для prediction market. Користувачі довіряють платформі з прозорою історією резолвингів. Розробка: 6-10 тижнів.