Разработка протокола предсказаний (Azuro-стиль)
Централизованные букмекеры — это black box. Лимиты на ставки, заморозка аккаунтов, непрозрачное изменение коэффициентов. Azuro решает это через on-chain протокол: пулы ликвидности как контрагент, смарт-контракты как букмекер, оракулы как источник результатов. Разработка аналогичного протокола — это не просто контракты, это система управления рисками для LP, точная математика маржи и устойчивость к manipulation через оракулы.
Ядро протокола: как работает Azuro-модель
Liquidity Pool как контрагент
В отличие от peer-to-peer ставок (протоколы типа Augur), Azuro использует pool-based модель. Провайдеры ликвидности вносят активы в pool, который автоматически выступает контрагентом для всех ставок. LP получают долю комиссий пропорционально внкладу.
Ключевой риск LP: если одна сторона события перегружена ставками, pool несёт одностороннее exposure. Azuro балансирует через reinforcement — динамическое изменение коэффициентов при дисбалансе. Чем больше ставок на один исход, тем ниже коэффициент на него и тем выше на противоположный. Математика:
newOdds = initialOdds * (1 - k * imbalanceFactor)
где imbalanceFactor — отношение ставок на каждую сторону. Правильная калибровка k — критична. Слишком агрессивная — коэффициенты падают до неинтересных. Слишком мягкая — pool накапливает односторонний риск.
Core/Express: структура ставок
Azuro различает Core (одиночные ставки) и Express (экспресс/аккумулятор). В Express произведение коэффициентов создаёт большой потенциальный выигрыш, но выплата происходит только при угадывании всех исходов. Контрактная логика Express: проверяем каждое событие последовательно, если одно проиграло — весь Express проигран, все заблокированные средства возвращаются в pool.
LP lockup — сложная часть. При принятии ставки pool резервирует потенциальную выплату (maxPayout = betAmount * odds). Эти средства недоступны для новых ставок пока событие не разрешено. При большом количестве одновременных событий locked/available ratio может упасть до 0.2 — pool физически не может принять новые ставки. Нужна механика maxExposure per event и global maxLockFraction.
Oracle и resolve: где ломаются протоколы
Разрешение результатов — наиболее уязвимое место. Централизованный oracle — single point of failure и manipulation. Azuro использует Data Providers (DP) — авторизованные адреса, которые могут подтверждать результаты. Несколько DP, консенсус-механизм для спорных случаев.
Типичные проблемы:
Delayed resolve. DP не подтверждает результат вовремя. Ставки заблокированы, LP не могут выйти. Нужен timeout: если результат не пришёл за N часов после scheduled event time — ставки автоматически рефандятся.
Wrong result. DP подтвердил неверный исход. Нужен dispute period (24-48 часов) + governance overrule через DAO или multisig. После dispute period результат финализируется.
Cancelled event. Матч отменён (дождь, VAR, disqualification). Протокол должен поддерживать CANCELED статус → полный рефанд всех ставок.
Архитектура контрактов
Ключевые компоненты
LP Contract — управление ликвидностью. ERC-20 LP-токены, addLiquidity, removeLiquidity с lock period (стандартно 7 дней — защита от flash liquidity attacks). Учёт locked/available funds.
Core Contract — приём ставок. bet(uint256 conditionId, uint256 outcomeId, uint256 amount, uint256 minOdds, uint256 deadline). Параметр minOdds — защита от odds slippage (аналог slippage protection в DEX). deadline — ставка отклоняется если блок > deadline.
Condition — одно событие. Структура: conditionId, gameId, outcomes[], reinforcement, margin, state, ipfsHash. ipfsHash содержит метаданные события (команды, время, тип). On-chain хранить строки — дорого.
PrematchCore / LiveCore — раздельные контракты для prematch и live ставок. Live ставки требуют более частого обновления коэффициентов (каждую минуту) и другой oracle-логики.
| Компонент | Ответственность |
|---|---|
| LiquidityTree | Хранение LP позиций, расчёт withdrawable |
| OddsLib | Математика коэффициентов, reinforcement |
| AzuroBet (ERC-721) | NFT-токен ставки |
| BettingEngine | Основная логика ставок и выплат |
| DataProvider | Oracle для результатов |
| ProxyFront | Entry point с permit2 поддержкой |
Ставка как NFT
Каждая ставка — ERC-721 токен. Это позволяет: трансфер ставок между адресами, вторичный рынок (sell pending bet), агрегацию в wallet. tokenURI генерируется on-chain или хранится на IPFS с метаданными события.
Математика маржи
Азуро закладывает маржу в коэффициенты — не явный fee, а built-in spread. При бинарном исходе с true probability 50%/50%, коэффициенты будут не 2.0/2.0, а например 1.9/1.9 при 5% марже. Математика:
margin = 1 - (1/odds1 + 1/odds2 + ...)
trueOdds = publishedOdds * (1 - margin)
При правильной калибровке margin покрывает: operational costs DP, резерв для плохих результатов, profit protocol treasury.
Процесс работы
Аналитика (1 неделя). Определяем: какие спорты/события, prematch only или + live, модель oracle (централизованный DP или Chainlink Functions), tokenomics LP.
Проектирование (1-2 недели). Контрактная архитектура, схема LP lockup, dispute resolution flow, governance.
Разработка (6-10 недель). Smart contracts + oracle integration + Data Provider backend + subgraph для истории ставок + frontend. Параллельные треки.
Тестирование (2 недели). Симуляция экстремальных сценариев: 90% ставок на один исход, delayed resolve, simultaneous 1000 bet redeem.
Аудит. Обязателен — протокол держит реальные средства пользователей. Фокус аудита: oracle manipulation, LP drain через экзотические event scenarios, reentrancy в payout.
Ориентиры по срокам
Базовый протокол с prematch ставками и централизованным DP — 2-3 месяца. Полный протокол с live betting, dispute resolution и DAO governance — 4-6 месяцев.
Стоимость рассчитывается после детальной оценки требований.