Разработка системы ставок на спорт на блокчейне
Централизованные букмекеры — blackbox: они могут задержать выплату, закрыть аккаунт, изменить коэффициент после принятия ставки. Блокчейн-версия решает это радикально: контракт не может не заплатить, если событие наступило и оракул подтвердил результат. Но именно связка «событие → оракул → контракт» — самое уязвимое место в системе.
Главная проблема: оракулы спортивных результатов
Почему Chainlink Price Feeds здесь не помогут
Chainlink Data Feeds — это агрегированные price данные от множества независимых нод. Для спортивного результата нет такой инфраструктуры: данные о победителе матча приходят с ESPN, Stats Perform, SportRadar. Это centralized источники. Chainlink Sports Data (на базе Any API) или партнёрские адаптеры — вариант, но с ограниченным покрытием лиг.
Альтернативы:
UMA Optimistic Oracle. Работает по принципу: proposer публикует результат + bond, есть dispute window (2-24 часа). Если никто не оспорил — результат принят. Хорошо для некраеугольных событий (итоговый счёт лиги через 2 дня), плохо для быстрых выплат.
Chainlink Functions. Контракт делает HTTP-запрос к API источнику через децентрализованную сеть нод. Несколько нод запрашивают один и тот же API, результат агрегируется по медиане. Решает проблему single point of failure, но не решает проблему доверия к источнику данных (если ESPN вернёт неверный результат — все ноды это проглотят).
Multi-oracle с threshold. Собственные ноды (3-5 штук) запрашивают разные data providers. Результат принимается, если N из M нод сообщили одинаковое. Дороже в инфраструктуре, но полный контроль.
Для production системы рекомендуем Chainlink Functions + резервный UMA Optimistic Oracle с dispute механизмом. При расхождении — suspend выплаты, ручной разбор.
Manipulation через oracle timing
Атака: злоумышленник знает результат матча раньше, чем оракул обновит данные (например, через источники с задержкой). Делает ставку на победителя в момент между окончанием матча и обновлением оракула.
Защита: закрывать приём ставок за 5-10 минут до начала матча (lock period) + не принимать ставки когда event status = "in progress" по оракульным данным. Если оракул не поддерживает live status — закрывать ставки за 30 минут до kickoff и не открывать до финального результата.
Архитектура смарт-контрактов
Pari-mutuel vs Fixed odds
Pari-mutuel (тотализатор): ставки на одно событие формируют пул, победители делят пул минус комиссия. Коэффициент не фиксируется заранее — он определяется распределением ставок. Это проще реализовать on-chain (нет market maker риска) и популярно в предикшн маркетах типа Polymarket.
Fixed odds: коэффициент фиксируется при принятии ставки. Для этого нужен ликвидитет-провайдер (букмекер), который берёт на себя риск несбалансированных ставок. Сложнее, требует либо AMM-механику для динамических odds, либо централизованного market maker.
Для старта — pari-mutuel: меньше рисков для протокола, проще аудит.
Структура контрактов
BettingFactory
└── BettingMarket (per event)
├── placeBet(outcome, amount)
├── resolveMarket(result) — only oracle
├── claimWinnings(betId)
└── refund() — if event cancelled
Ключевые параметры BettingMarket:
-
eventId— уникальный ID события -
lockTimestamp— момент закрытия ставок -
resolutionTimestamp— крайний срок резолюции (если не resolved → refund режим) -
outcomes— допустимые исходы (WIN_HOME, WIN_AWAY, DRAW) -
totalPool[outcome]— суммы по каждому исходу -
oracleAddress— whitelist оракулов
Расчёт выплаты (pari-mutuel)
function calculatePayout(address bettor, uint256 betId) public view returns (uint256) {
Bet memory bet = bets[betId];
require(bet.outcome == winningOutcome, "Not a winner");
uint256 winnerPool = totalPool[winningOutcome];
uint256 totalPoolMinusFee = totalPool[WIN_HOME] + totalPool[WIN_AWAY] + totalPool[DRAW];
totalPoolMinusFee = totalPoolMinusFee * (10000 - protocolFee) / 10000;
return bet.amount * totalPoolMinusFee / winnerPool;
}
Здесь важно: fee должна быть вычтена ДО расчёта выплаты, не после. Иначе протокол собирает fee и с выигравших, и с проигравших, что математически некорректно.
Refund механика при отмене события
Если матч не состоялся (дождь, форс-мажор), оракул не может дать результат. Контракт должен перейти в refund mode автоматически по истечении resolutionDeadline. Pull-паттерн: каждый пользователь сам вызывает refund(betId), протокол не рассылает средства.
Альтернатива — off-chain trigger через Chainlink Automation: при наступлении deadline без resolution, Automation вызывает setRefundMode(). Это UX улучшение, но опциональное.
Дополнительно: live betting сложность
Live betting (ставки во время матча) — отдельный уровень сложности. Нужен real-time оракул с минимальной задержкой (< 30 секунд) и механизм предотвращения ставок после значимых событий (гол, красная карточка), которые уже произошли но ещё не обновились в оракуле.
Технически это требует: WebSocket оракул с push-обновлениями + freeze period после каждого обновления (5-10 секунд без приёма ставок). Реализуемо, но значительно увеличивает сложность и стоимость оракульной инфраструктуры.
Стек разработки
Solidity 0.8.x + OpenZeppelin (AccessControl, Pausable, ReentrancyGuard). Chainlink Functions для оракулов. Foundry для тестирования — fork-тесты с mock oracle responses. Hardhat-deploy для воспроизводимого деплоя с прокси для upgradability (UUPS).
Frontend: React + wagmi + ethers.js. Интеграция с WalletConnect v2, MetaMask. Для мобильного — Coinbase Wallet SDK.
Процесс работы
Выбор оракульной модели (2-3 дня). Определяем покрытие лиг, latency требования, бюджет на оракульную инфраструктуру.
Разработка контрактов (2-4 недели). Factory + Market + Oracle integration + тесты.
Frontend (1-2 недели). UI ставок, коэффициенты, история, выплаты.
Аудит. Финансовые контракты с пользовательскими средствами — аудит обязателен.
Деплой. Polygon или Arbitrum (низкий газ). Gnosis Safe для admin.
Ориентиры по срокам
Pari-mutuel система с базовым оракулом (одна лига): 3-5 недель. Мульти-лиговая платформа с live betting и custom odds AMM: 2-3 месяца.