Коли пул ліквідності приймає ставки лише на один результат, ризик для LP зростає в рази. Ми розробляємо протоколи передбачень у стилі Azuro — децентралізовані системи ставок на спортивні події, де пули ліквідності виступають контрагентом, а смарт-контракти замінюють букмекера. Ви отримуєте on-chain рішення з прозорою математикою та захистом від маніпуляцій. Наш досвід — десятки реалізованих протоколів Web3. Зв'яжіться з нами, щоб оцінити проєкт під ключ.
Як працює 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 атак). Облік 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
На одному з наших проєктів ми оптимізували reinforcement та налаштування maxLockFraction, що дозволило підтримувати locked/available ratio на рівні 0.4 навіть при пікових навантаженнях, тоді як стандартні реалізації падали до 0.7. Ставки виконувались за 2-3 секунди, а ризик для LP був мінімізований.
Як захистити пул ліквідності від одностороннього ризику?
Ключове завдання — не допустити, щоб 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, одночасний 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% за рахунок усунення посередників. Замовте консультацію — оцінимо ваш проєкт.