Розробка протоколу опціонів на блокчейні (Dopex-стиль)

Розробка протоколу опціонів (Dopex-стиль)

Децентралізовані опціони — один з найбільш технічно складних сегментів DeFi. Dopex побудував архітектуру, яка вирішує головну проблему on-chain опціонів: ліквідність. Замість orderbook, де покупець і продавець повинні знайти один одного, Dopex використовує пули ліквідності (SSOV — Single Staking Option Vault), де LP-провайдери колективно виступають у ролі продавця опціонів. Купити call або put можна в будь-який момент, поки в пулі є резерви. Реалізація такого протоколу з нуля — це 6-16 тижнів роботи, залежно від глибини функціоналу.

Механіка SSOV: як працює пул опціонів

Структура епохи та страйк-ціни

SSOV працює епохами — фіксованими періодами (зазвичай 1 місяць). На початку епохи визначається набір страйк-цін (наприклад, для ETH: $2000, $2200, $2400, $2600). LP-провайдери вносять ETH у хранилище — їх кошти стають забезпеченням для опціонних контрактів.

Покупець опціону платить премію й отримує право на виплату при закінченні терміну:

• Call опцион: виплата = max(0, ціна_при_закінченні - страйк)
• Put опцион: виплата = max(0, страйк - ціна_при_закінченні)

Розрахунок премії — ключовий інженерний виклик. Dopex використовує Black-Scholes з on-chain імплементацією. Проблема: Black-Scholes потребує ln() та e^x — функцій, які не існують у EVM нативно. Реалізація через розкладення Тейлора або таблиці апроксимацій з фіксованою точкою.

Black-Scholes On-Chain: де втрачається точність

Класична формула Black-Scholes для call опціону:

C = S·N(d1) - K·e^(-rT)·N(d2)
d1 = (ln(S/K) + (r + σ²/2)·T) / (σ·√T)
d2 = d1 - σ·√T

де S — спот-ціна, K — страйк, r — безрисикова ставка, σ — передбачувана волатильність, T — час до закінчення.

На EVM працюємо з fixed-point арифметикою (WAD, 1e18). Функція ln(x) реалізується через бібліотеку PRBMath або ABDKMathQuad. Точність критична: помилка 0.1% в розрахунку премії на обсязі $1M = $1000 розходження за транзакцію. Накопичується на користь атакуючого, який знає про розходження.

Реальний випадок з аудиту: протокол використовував апроксимацію ln(x) ≈ x - 1 для значень близьких до 1.0 — це давало помилку до 2% при S/K у діапазоні 0.9-1.1 (at-the-money опціони). Саме там найбільший обсяг торгів. Збиток LP становив ~$80K за перший місяць до виявлення.

Передбачувана волатильність: оракул або on-chain розрахунок

Передбачувана волатильність (IV) — критичний параметр, від якого лінійно залежить премія. Варіанти:

Chainlink IV feed — доступний для ETH, BTC. Надійний, але з затримкою до 1 години. При різких рухах ринку IV може бути занижена — LP продають опціони занадто дешево.

DVOL-стиль (Deribit Volatility Index) — off-chain розрахунок через TWAP передбачуваної волатильності з orderbook. Потребує власної інфраструктури оракула або інтеграції Chainlink Functions.

On-chain історична волатильність — розрахунок за TWAP цінами за останні N періодів. Не відображає forward-looking ризик, але не залежить від зовнішніх оракулів. Мінус: недооцінювання опціонів перед подіями (merge, ETF схвалення).

Ми будуємо гібридну систему: Chainlink IV feed як первинне джерело, on-chain історична волатильність як fallback при застарілості > 2 години.

Архітектура протоколу

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

DopexStyleProtocol/
├── core/
│   ├── OptionMarket.sol          # Створення/покупка/закінчення опціонів
│   ├── SSOV.sol                  # Хранилище ліквідності LP
│   ├── OptionPricing.sol         # Black-Scholes on-chain
│   └── EpochManager.sol          # Управління епохами
├── oracles/
│   ├── VolatilityOracle.sol      # IV агрегатор
│   └── PriceOracle.sol           # Chainlink обгортка
├── rewards/
│   ├── DPX.sol                   # Governance/reward токен
│   └── StakingRewards.sol        # Емісія для LP
└── periphery/
    ├── Router.sol                 # Користувацький інтерфейс
    └── OptionToken.sol            # ERC-1155 опціонні токени

ERC-1155 для опціонів — правильний вибір. Кожна комбінація (страйк, закінчення, тип) = окремий token ID. Користувачі можуть утримувати опціони з різними страйками в одному гаманці, передача працює як звичайні токени — вторинний ринок створюється автоматично.

Механіка LP хранилища: ризики та захисти

LP вносять ETH, колективно продають опціони. При масовому закінченні in-the-money (ринок рухнув проти LP) — хранилище виплачує великі суми. Це внутрішній ризик, який LP приймають.

Керовані ризики, які ми закриваємо контрактно:

Максимальна ємність за страйком — неможна продати опціонів на один страйк більше N% від загального хранилища. Інакше концентрована експірація нулює хранилище.

Блокування виведення — LP не можуть вивести кошти в середині епохи. Інакше при русі ціни до страйку LP масово виходять, залишаючи протокол без забезпечення для виплат.

Пул хеджування дельти — опційно, для протоколів із серйозними інституціональними LP. Частина коштів хранилища автоматично хеджується через контракти вічних (GMX, Gains Network).

Інтеграція AtlasDEX для вторинного ринку

Опціонні токени ERC-1155 потребують місця для торгівлі. Варіанти:

• Інтеграція з OpenSea/Blur (вони підтримують ERC-1155)
• Власний AMM для опціонів (складно, потребує кастомної кривої)
• Інтеграція з Lyra Protocol як шар вторинного ринку

Для MVP рекомендуємо P2P торгівлю через Seaport (OpenSea протокол) — це безплатно й не потребує додаткової ліквідності.

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

Маніпуляція оракулом при закінченні. Момент істини для опціону — ціна при закінченні. Якщо використовується спот-ціна оракула в одному блоці — flash loan атака маніпулює ціною, створює штучний прибуток по опціонам. Захист: TWAP за останні 30 хвилин як ціна розрахунку.

Сендвіч-атака епохи. Атакуючий купує великий обсяг опціонів в кінці епохи (знаючи про наступний рух ринку), отримує виплату, на початку наступної епохи LP ще не відновили втрати — хранилище недокапіталізоване. Захист: охолодження між епохами з обов'язковим періодом узгодження.

Мукорування дрібними позиціями. Створення тисяч маленьких опціонних позицій (gas griefing) для функції розрахунку при закінченні. Захист: мінімальна премія > поріг пилу, комісія на створення позиції.

Стек розробки

Foundry як основний інструмент — fuzz-тести розрахунків Black-Scholes критичні. Тестування з vm.fuzz всіх граничних значень: S/K від 0.1 до 10, T від 1 години до 1 року, IV від 10% до 500%. PRBMath v4 для fixed-point арифметики. Chainlink ціни на mainnet fork для тестування логіки оракула.

Процес і терміни

Проектування (1-2 тижні). Архітектура контрактів, економічне моделювання в Python (сценарії: нормальний ринок, крах -50%, скачок +100%), параметри хранилища (макс. ємність, комісії, тривалість епохи).

Розробка ядра (3-5 тижнів). OptionMarket, SSOV хранилище, Black-Scholes on-chain з тестами точності, EpochManager, інтеграція оракула. Foundry fuzz + invariant тести.

Розробка периферії (2-3 тижні). Router, система награђ, frontend (wagmi + viem), The Graph субграф для історичних даних.

Аудит (2-4 тижні). Рекомендуємо зовнішній аудит для протоколів з TVL вище $500K. Внутрішній аудит — обов'язковий.

Деплой і моніторинг. Поетапний запуск: обмежена ємність хранилища на старті, поступове збільшення після підтвердження стабільності.

Базовий SSOV для одного активу — 6-8 тижнів. Повнофункціональний мультиактивний протокол з governance та вторинним ринком — 10-16 тижнів. Вартість розраховується після детального аналізу вимог та бажаного набору активів.