Розробка протоколу передсказань (Azuro-стиль)
Централізовані букмекери — це чорна скриня. Ліміти на ставки, заморозка аккаунтів, непрозоре змінення коефіцієнтів. Azuro вирішує це через on-chain протокол: пули ліквідності як контрагент, смарт-контракти як букмекер, оракули як джерело результатів. Розробка аналогічного протоколу — це не просто контракти, це система управління ризиками для LP, точна математика маржі та стійкість до маніпуляції оракулом.
Ядро протоколу: як працює Azuro-модель
Пул ліквідності як контрагент
На відміну від peer-to-peer ставок (протоколи типу Augur), Azuro використовує pool-based модель. Провайдери ліквідності вносять активи в пул, який автоматично виступає контрагентом для всіх ставок. LP отримують долю комісій пропорційно внеску.
Ключовий ризик LP: якщо одна сторона події перевантажена ставками, пул несе одностороннє експозицію. Azuro балансує через reinforcement — динамічне змінення коефіцієнтів при дисбалансі. Чим більше ставок на один результат, тим нижче коефіцієнт на нього та вищий на протилежний. Математика:
newOdds = initialOdds * (1 - k * imbalanceFactor)
де imbalanceFactor — відношення ставок на кожну сторону. Правильна калібровка k — критична. Занадто агресивна — коефіцієнти падають до неінтересних. Занадто м'яка — пул накопичує односторонній ризик.
Core/Express: структура ставок
Azuro розрізняє Core (одиночні ставки) та Express (експресс/аккумулятор). В Express добуток коефіцієнтів створює великий потенційний виграш, але виплата відбувається тільки при вгадуванні всіх результатів. Логіка контракту Express: перевіряємо кожну подію послідовно, якщо одна програла — весь Express програв, всі заблоковані кошти повертаються в пул.
LP lockup — складна частина. При прийнятті ставки пул резервує потенційну виплату (maxPayout = betAmount * odds). Ці кошти недоступні для нових ставок поки подія не розв'язана. При великій кількості одночасних подій locked/available ratio може впасти до 0.2 — пул фізично не може прийняти нові ставки. Потрібна механіка maxExposure per event та глобальна maxLockFraction.
Оракул і розв'язання: де ломаються протоколи
Розв'язання результатів — найбільш уразливе місце. Централізований оракул — single point of failure та маніпуляція. Azuro використовує Data Providers (DP) — авторизовані адреси, які можуть підтверджувати результати. Кілька DP, консенсус-механізм для спірних випадків.
Типові проблеми:
Затримане розв'язання. DP не підтверджує результат вчасно. Ставки заблоковані, LP не можуть вийти. Потрібен timeout: якщо результат не прийшов за N годин після запланованого часу події — ставки автоматично рефундяться.
Неправильний результат. DP підтвердив неправильний результат. Потрібен период оскарження (24-48 годин) + governance overrule через DAO або multisig. Після периода оскарження результат фіналізується.
Скасована подія. Матч скасований (дощ, VAR, дискваліфікація). Протокол повинен підтримувати CANCELED статус → повний рефанд всіх ставок.
Архітектура контрактів
Ключові компоненти
LP контракт — управління ліквідністю. ERC-20 LP токени, addLiquidity, removeLiquidity з lock period (стандартно 7 днів — захист від flash liquidity атак). Облік locked/available коштів.
Core контракт — прийом ставок. 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 ставки потребують частішого оновлення коефіцієнтів (кожну хвилину) та іншої логіки оракула.
| Компонент | Відповідальність |
|---|---|
| LiquidityTree | Зберігання LP позицій, розрахунок withdrawable |
| OddsLib | Математика коефіцієнтів, reinforcement |
| AzuroBet (ERC-721) | NFT-токен ставки |
| BettingEngine | Основна логіка ставок та виплат |
| DataProvider | Оракул для результатів |
| ProxyFront | Entry point з permit2 підтримкою |
Ставка як NFT
Кожна ставка — ERC-721 токен. Це дозволяє: трансфер ставок між адресами, вторинний ринок (продаж очікуючої ставки), агрегацію в гаманці. tokenURI генерується on-chain або зберігається на IPFS з метаданнями події.
Математика маржі
Azuro закладає маржу в коефіцієнти — не явну комісію, а 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)
При правильній калібровці маржа покриває: операційні витрати DP, резерв для поганих результатів, прибуток протоколу treasury.
Процес розробки
Аналітика (1 тиждень). Визначаємо: які спорти/події, тільки prematch або + live, модель оракула (централізований DP або Chainlink Functions), tokenomics LP.
Проектування (1-2 тижні). Архітектура контрактів, схема LP lockup, flow dispute resolution, governance.
Розробка (6-10 тижнів). Smart contracts + інтеграція оракула + Data Provider backend + субграф для історії ставок + frontend. Паралельні треки.
Тестування (2 тижні). Симуляція екстремальних сценаріїв: 90% ставок на один результат, затримане розв'язання, одночасний redeem 1000 ставок.
Аудит. Обов'язковий — протокол утримує реальні кошти користувачів. Фокус аудиту: маніпуляція оракулом, LP drain через екзотичні event сценарії, reentrancy в payout.
Ориєнтири по термінах
Базовий протокол з prematch ставками та централізованим DP — 2-3 місяці. Повний протокол з live betting, dispute resolution та DAO governance — 4-6 місяців.
Вартість розраховується після детальної оцінки вимог.