Мы разрабатываем протоколы предсказаний в стиле Azuro — децентрализованные системы ставок на спортивные события, где пулы ликвидности выступают контрагентом, а смарт-контракты заменяют букмекера. Вы получаете on-chain решение с прозрачной математикой и защитой от манипуляций. Наш опыт — 5+ лет в Web3 и 10+ реализованных протоколов. Свяжитесь с нами, чтобы оценить проект под ключ.
Как работает 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 с метаданными события.
Математика маржи
Azuro закладывает маржу в коэффициенты — не явный 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.
Почему Azuro-модель лучше peer-to-peer?
В P2P-протоколах (Augur, PolyMarket) ликвидность распределена между исходами, что приводит к большому спреду и недостаточной глубине для крупных ставок. Azuro с pool-based моделью концентрирует ликвидность: один пул обслуживает все события, а reinforcement перераспределяет её динамически. Сравнение:
| Параметр | P2P (Augur) | Pool-based (Azuro) |
|---|---|---|
| Глубина рынка | Зависит от числа трейдеров | Единый пул |
| Спред | Высокий при низкой активности | Низкий, регулируется reinforcement |
| Время исполнения | Может быть долгим | Мгновенное |
| Риск LP | Нет прямого LP | Требуется управление рисками |
Azuro protocol documentation
Как защитить пул ликвидности от одностороннего риска?
Ключевая задача — не допустить, чтобы pool покрывал все ставки на один исход. Azuro использует reinforcement, но этого недостаточно. Дополнительные меры:
- Max exposure per event — лимит на сумму ставок на одно событие. При превышении ставки отклоняются.
- Global lock fraction — максимальный процент locked средств от всего пула (обычно 80-90%). Превышение блокирует приём ставок.
- LP lock period — 7 дней, чтобы предотвратить pump-and-dump ликвидности.
- Dispute period — защита от неверного результата.
Типичные ошибки при разработке
- Отсутствие
minOdds— ставки проходят с невыгодными коэффициентами после изменения. - Некорректная калибровка
k— reinforcement слишком агрессивен или слишком слаб. - Игнорирование cancelled event — средства застревают навсегда.
- Централизованный oracle без защиты — одна уязвимость ломает весь протокол.
Процесс работы
Аналитика (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.
Что входит в работу
- Архитектурная документация и диаграммы потоков
- Исходный код смарт-контрактов (Solidity) с юнит-тестами
- Интеграция оракула (Data Provider или Chainlink)
- Subgraph для истории ставок (The Graph)
- Deploy-скрипты и документация по деплою
- Обучение вашей команды (2-3 дня)
- Поддержка после запуска (1 месяц)
Ориентиры по срокам
Базовый протокол с prematch ставками и централизованным DP — 2-3 месяца. Полный протокол с live betting, dispute resolution и DAO governance — 4-6 месяцев.
Стоимость рассчитывается после детальной оценки требований. Экономия на комиссиях по сравнению с централизованными решениями может достигать 40% за счёт устранения посредников. Закажите консультацию — оценим ваш проект.