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

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

Мы не раз сталкивались с ситуацией: клиент приходит с идеей децентрализованной букмекерской платформы, но не понимает, как распределить риски между провайдерами ликвидности. В централизованных системах дом принимает всё на себя — в 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 недель. Стоимость рассчитывается индивидуально после обсуждения архитектуры и источников данных.