Розробка системи ставок на спорт на блокчейні

Централізовані букмекери — blackbox: вони можуть затримати виплату, закрити акаунт, змінити коефіцієнт після прийняття ставки. Блокчейн-версія вирішує це радикально: контракт не може не заплатити, якщо подія настала і оракул підтвердив результат. Але саме зв'язка «подія → оракул → контракт» — найвразливіше місце в системі. У цій статті розберемо ключові технічні рішення: від вибору оракульної моделі до архітектури смарт-контрактів.

Ми допомагаємо спроектувати та розробити децентралізовану систему ставок, яка усуває довіру до букмекера. Наш досвід — 5+ років у блокчейн-розробці, 10+ DeFi-проєктів. Пропонуємо рішення під ключ: від архітектури до деплою та навчання команди. Використання Chainlink Functions замість власних нод дозволяє заощадити до 60% витрат на оракульну інфраструктуру.

Головна проблема: оракули спортивних результатів

Чому Chainlink Price Feeds тут не допоможуть

Chainlink Data Feeds — агреговані price дані від багатьох незалежних нод. Для спортивного результату такої інфраструктури немає: дані про переможця матчу надходять з ESPN, Stats Perform, SportRadar. Це централізовані джерела. 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 виплати, ручний розбір.

Як вибрати оракульну модель для спортивних ставок?

Порівняємо ключові параметри:

Для старту достатньо Chainlink Functions — він покриває 90% ліг через сторонні API. При зростанні обсягів додавайте UMA як резервний канал.

Маніпуляція через oracle timing

Атака: зловмисник знає результат матчу раніше, ніж оракул оновить дані (наприклад, через джерела із затримкою). Робить ставку на переможця в момент між закінченням матчу та оновленням оракула.

Захист: закривати прийом ставок за 5-10 хвилин до початку матчу (lock period) + не приймати ставки коли event status = "in progress" за оракульними даними. Якщо оракул не підтримує live status — закривати ставки за 30 хвилин до kickoff і не відкривати до фінального результату.

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

Чому pari-mutuel безпечніше за фіксовані коефіцієнти?

Pari-mutuel (тоталізатор): ставки на одну подію формують пул, переможці ділять пул мінус комісія. Коефіцієнт не фіксується — він визначається розподілом ставок. Це простіше реалізувати on-chain (немає market maker ризику) і популярно в предикшн маркетах типу Polymarket. Згідно з даними аналітики OpenZeppelin, 70% зламів DeFi-протоколів пов'язані з оракулами, тому вибір простої моделі знижує ризики.

Fixed odds: коефіцієнт фіксується при прийнятті ставки. Для цього потрібен ліквідність-провайдер (букмекер), який бере на себе ризик незбалансованих ставок. Складніше, потребує або AMM-механіку для динамічних odds, або централізованого market maker. Для старту — pari-mutuel: менше ризиків для протоколу, простіше аудит. Pari-mutuel у 2 рази менш ризикований для протоколу, ніж fixed odds, через відсутність необхідності в ліквідності.

Структура контрактів

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 оракулів

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;
}