Розробка протоколу передбачень (Azuro-стиль)

Коли пул ліквідності приймає ставки лише на один результат, ризик для 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-логіки.

Ставка як 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 перерозподіляє її динамічно. Порівняння:

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 — захист від невірного результату.

Процес роботи

Аналітика (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% за рахунок усунення посередників. Замовте консультацію — оцінимо ваш проєкт.

Послуги з розробки DeFi-протоколів повного циклу

Ми проектуємо модульні DeFi-протоколи, в яких математика стейблкоїнів, ліквідності та оракулів працює без збоїв. Mango Markets — краш-тест: атакуючий маніпулював spot price через один акаунт, взяв кредит під завищений колатераль і вивів велику суму. Оракул брав ціну з єдиного джерела без TWAP. Не баг у коді — це архітектурне рішення, яке стало вразливістю. Наш досвід показує: будь-який DeFi-протокол — це система ставок на те, що всі компоненти, від розрахунків до економічних стимулів, вибудовані правильно одночасно.

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

Чому оракули є критичним компонентом DeFi?

Більшість великих зломів DeFi починалися з маніпуляції оракулом. Розберемо три шари, які ми використовуємо в кожному проекті.

Spot price як оракул — не варіант. Uniswap v2 spot price можна зсунути flash loan за одну транзакцію. Ціна в кінці блоку — єдине, що потрапляє в state, її і читає оракул. Схема атаки: зайняти через flash loan → купити актив у пул → ціна піднялася → взяти кредит під завищений колатераль → продати актив → повернути flash loan. Одна транзакція.

TWAP як захист. Uniswap v3 observe() усереднює ціну за період (30 хвилин). Маніпуляція вимагає утримувати ціну кілька блоків — це коштує дорого. Але TWAP повільно реагує на легітимні зміни, що відкриває вікно для arbitrage на ліквідації при різких рухах.

Chainlink Price Feeds — агрегація від багатьох data providers з медіаною. Стандарт для lending. Проблема: heartbeat 1–24 години та deviation threshold 0.5%. Якщо ціна не рухається, фід може не оновлюватися добу. У волатильному ринку — lag.

У продакшені ми використовуємо дворівневу перевірку: Chainlink aggregator + Uniswap v3 TWAP як верифікатор. Якщо розбіжність більша за N% — транзакція відхиляється, система ставиться на паузу.

Як захистити DeFi-протокол від атак флеш-позик?

Flash loan перетворює будь-якого користувача на володаря необмеженого капіталу на одну транзакцію. Тому при проектуванні контрактів ми припускаємо: доступ до необмеженого капіталу є у всіх. Це змінює threat model повністю.

Легітимні застосування flash loan — арбітраж, ліквідація, самоліквідація. Але протокол повинен перевіряти, що позика не використовується для маніпуляції: оракул не повинен читати ціну з пулу, який можна зсунути за одну транзакцію. Ми додаємо перевірки на block.timestamp та мінімальну глибину ліквідності.

Як ми забезпечуємо безпеку DeFi-протоколу?

Ми не покладаємося на один шар захисту. Кожен контракт проходить формальну верифікацію математичної моделі, стресове тестування на форку mainnet та аудит щонайменше двома незалежними командами (серед яких сертифіковані аудитори ConsenSys Diligence). Гарантія — багаторічний досвід розробки та супроводу протоколів із сукупним TVL понад $500M.

Ключові компоненти DeFi-архітектури

AMM: від x*y=k до concentrated liquidity

Uniswap v2 використовує x * y = k. LP-токени ERC-20 — кожен пул випускає свій токен пропорційно частці. Проблема: ліквідність розмазана по всій кривій, більша частина не використовується.

Uniswap v3 та позиції ERC-721: concentrated liquidity — LP надає ліквідність у діапазоні [priceLow, priceHigh]. Capital efficiency до 4000x для стабільних пар. Але ERC-721 ламає vault-стратегії під ERC-20. Управління ranges — окрема інженерна задача: позиція виходить з діапазону при русі ціни, перестає заробляти fees, стає single-asset. Протоколи типу Arrakis Finance автоматично rebalance. Якщо будуєте vault поверх v3, потрібен власний range manager або інтеграція з існуючим.

Slippage у v3 розраховується через sqrtPriceX96 — 96-бітна fixed-point математика. Помилки на фронтенді призводять до розбіжності між видимим і фактичним slippage.

Curve для пар з близькими цінами (stablecoin/stablecoin, stETH/ETH) використовує інваріант, що комбінує constant product і constant sum. Менше slippage в діапазоні peg. Контракти на Vyper, код математично щільний, аудитувати складно.

Lending протоколи: collateral, liquidation, bad debt

LTV визначає максимальний кредит під колатераль. Liquidation threshold — рівень ліквідації. Різниця — буфер для liquidator. Типовий приклад: LTV 75%, liquidation threshold 80%, bonus 5%. Якщо ціна падає на 20%+, позиція відкрита до ліквідації.

Каскадні ліквідації: багато позицій ліквідується одночасно → ліквідатори продають колатераль → ціна падає → наступна хвиля. LUNA/UST — класичний каскад.

Якщо колатераль знецінюється швидше ліквідації, протокол отримує bad debt. Aave використовує Safety Module (застейканий AAVE), Compound — reserves. Без backstop bad debt соціалізується через dilution supply-токена або взаємозалік.

Проектування системи ліквідації вимагає моделювання стрес-сценаріїв: падіння єдиного liquidation bot, високий gas, делістинг колатералю.

Yield farming та incentive mechanics

Liquidity mining — роздача токенів управління LP-провайдерам. Проблема mercenary capital: фармери приходять, продають токени, йдуть. TVL фіктивний.

Стійкі механіки: protocol-owned liquidity (Olympus bonding), veToken (CRV locked → boost + governance), locked staking з penalty. Ve-модель при неправильній реалізації створює governance concentration. Потрібен timelock на зміни gauge weights та ліміти на votingPower.

Що входить у нашу розробку DeFi-протоколів

• Архітектурна документація: діаграми взаємодії контрактів, стрес-тести ліквідацій, розрахунки оракулів.
• Реалізація на Solidity 0.8.x з OpenZeppelin 5.x (AccessControl, ReentrancyGuard, Pausable, TimelockController) та Solmate для gas-optimised base contracts.
• Foundry fork-тести на реальному mainnet (Uniswap, Chainlink, Aave) — тести до деплою покривають всі сценарії. Завдяки Foundry час тестування скорочується на 80% порівняно з Hardhat.
• Аудит: мінімум два незалежних аудитори для TVL від значного рівня. Code4rena або Sherlock для bug bounty.
• Деплой з Gnosis Safe 3/5 multisig + timelock 48–72 години.
• Моніторинг через Tenderly (alerts, симуляції), OpenZeppelin Defender (automation), Forta (on-chain threat detection).
• Підтримка після запуску: оновлення, патчі, апгрейди через proxy.

Наші компетенції та досвід

Ми розробляємо DeFi-протоколи з моменту активного розвитку ринку — за цей час реалізували 30+ проектів із загальним TVL понад $500M. Серед клієнтів — протоколи в топ-20 за TVL на Ethereum, Arbitrum та Base. Команда сертифікованих розробників Solidity, які пройшли аудиторські треки ConsenSys Diligence. Гарантія якості підтверджена багаторічним досвідом та відсутністю інцидентів після запуску.

Терміни

• DEX з AMM (Uniswap v2 fork): 6–10 тижнів
• Lending protocol (Aave-style, один колатераль): 3–5 місяців
• Yield aggregator з кількома стратегіями: 2–4 місяці
• Повноцінний DeFi-протокол з governance: 5–8 місяців включаючи аудит

Вартість розраховується індивідуально — зв'яжіться для оцінки вашого проекту. Отримайте консультацію з архітектури DeFi-протоколу — ми проаналізуємо ризики та запропонуємо оптимальне рішення.