Розробка пулів ліквідності для ставок на блокчейні

Розробка пулів ліквідності для ставок на блокчейні

Ми не раз стикалися з ситуацією: клієнт приходить з ідеєю децентралізованої букмекерської платформи, але не розуміє, як розподілити ризики між провайдерами ліквідності. У централізованих системах дом приймає все на себе — в DeFi-беттингу відповідальність лягає на LP-пул. Наше завдання — спроектувати механізм, який збалансує stake та payout так, щоб пул не виявився порожнім після серії апсетів.

Протоколи типу Azuro будують інфраструктуру саме такого типу: провайдер додає USDC в пул, ставки йдуть проти цього пулу, odds коригуються динамічно залежно від обсягів та поточного exposure. За 5+ років ми розробили понад 30 блокчейн-рішень, включаючи беттинг-продукти для Polygon та Arbitrum.

Ключова проблема: управління exposure

Дисбаланс ставок

Якщо 90% ставок йде на одну сторону події (наприклад, на перемогу Реала в дербі), пул несе величезний directional risk. Один результат — провайдери ліквідності втрачають значну частину пулу, інший — заробляють.

Динамічні odds як рішення: при перевищенні exposure threshold на одну сторону odds на цю сторону автоматично знижуються, роблячи ставку менш привабливою, а на протилежну — зростають. Це балансувальний механізм без централізованого маркет-мейкера.

function calculateOdds( uint256 eventId, uint8 outcomeId ) public view returns (uint256 odds) { ExposureData memory data = exposures[eventId]; uint256 totalPool = data.lpLiquidity; uint256 sideExposure = data.outcomeExposure[outcomeId]; // Чим вище exposure на сторону, тим нижче odds uint256 adjustedPool = totalPool - sideExposure * MARGIN_FACTOR / 1e18; odds = (adjustedPool * 1e18) / (adjustedPool - sideExposure); } 

Реальні системи використовують більш складні моделі з урахуванням correlated events (кілька матчів в одному турнірі), liquidity depth та market maker oracle для початкових odds.

Як захистити пул від маніпуляцій? Оракул результатів

Це найуразливіша точка будь-якого беттинг-протоколу. Хто визначає результат матчу? Централізований оратор — єдина точка відмови. Компрометація оракула = дренаж всієї ліквідності. Ми використовуємо багаторівневий захист:

У продакшн-системах оптимальна комбінація: автоматичне вирішення через Chainlink для очевидних результатів, Kleros — для спірних. Такий підхід знижує ймовірність маніпуляції на 95%.

Архітектура контрактів

Структура пулу ліквідності

Пул нагадує Uniswap LP, але з відмінностями:

• LP-токен представляє частку (аналог LP-токену AMM)
• Ліквідність блокується на період активних подій
• При масовому виведенні — черга (withdrawal queue)

struct LiquidityPool { uint256 totalLiquidity; // USDC в пулі uint256 lockedLiquidity; // заблоковано для покриття відкритих ставок uint256 totalShares; // LP-токени mapping(address => uint256) shares; } function addLiquidity(uint256 amount) external { // shares розраховуються пропорційно поточній вартості пулу uint256 newShares = totalShares == 0 ? amount : amount * totalShares / totalLiquidity; // ... } 

lockedLiquidity — максимально можлива виплата за всіма відкритими ставками. LP не може вивести ліквідність нижче цього порогу. Це інваріант безпеки: пул завжди здатен розрахуватися за поточними ставками.

Ставки як NFT чи fungible?

Два підходи: ставка як ERC-721 NFT (унікальна, може торгуватися на вторинному ринку) або як запис у маппінгу контракту. ERC-721 відкриває можливість ставочного маркетплейсу — користувач може продати виграшну ставку до завершення події. Це додаткова ліквідність для користувачів та додатковий revenue для протоколу (комісія з вторинних угод). Azuro використовує саме цей підхід через betting ERC-721. Трейдоффи: трохи вищий gas на створення ставки (~50k gas vs ~30k для маппінгу), складніше аудитується.

Що входить в роботу

Кожен проєкт включає:

• Архітектурна документація (діаграми потоків, безпека)
• Розробка та аудит смарт-контрактів (Foundry + Slither)
• Інтеграція Chainlink або інших оракулів
• Налаштування та тестування liquidity pool логіки
• Розгортання на тестовій мережі та mainnet
• Документація для інтеграторів та користувачів
• Підтримка протягом 3 місяців після запуску

Економіка провайдерів ліквідності

Прибутковість LP = маржа платформи - виплати за виграшними ставками. При маржі 5% та збалансованих ставках — LP заробляє 5-8% річних плюс додатковий yield від невикористаної ліквідності (стейкінг USDC в Aave, поки події не закриті). Ризик: при серії великих upset-результатів — LP втрачає. Insurance fund з частини комісій частково буферизує втрати. Для зниження ризику ми рекомендуємо розділяти пули за видами спорту та лімітувати exposure на одну подію.

Чому обирають нас?

20+ інженерів в команді, 5 років на ринку блокчейн-розробки, 30+ запущених dApps. Надаємо гарантію на безпеку контрактів (formal verification за запитом). Пишіть — оцінимо ваш проєкт та запропонуємо архітектуру під ключ.

Орієнтовні терміни

Базовий пул з фіксованими odds та централізованим оракулом — від 1 до 2 тижнів. Повноцінний протокол з динамічними odds, Chainlink, LP-токенами та вторинним ринком ставок — від 6 до 10 тижнів. Вартість розраховується індивідуально після обговорення архітектури та джерел даних.