Розробка системи ціноутворення опціонів (Black-Scholes для крипто)
On-chain опціонний протокол зустрічає проблему, якої нема у традиційних дериватив: модель Блека-Шоулеза потребує обчислень з плаваючою точкою — логарифмів, квадратних коренів, нормального розподілу — а EVM оперує тільки цілими числами. Deribit розраховує ціни опціонів off-chain та централізовано. Lyra, Hegic, Dopex вирішують це по-різному. Розробка власної системи ціноутворення — це, перш за все, вибір компромісу між точністю та вартістю газу.
Математика Black-Scholes у цілих числах
Формула BSM для європейського call опціону:
C = S * N(d1) - K * e^(-rT) * N(d2)
де d1 = (ln(S/K) + (r + σ²/2) * T) / (σ * √T)
Кожний елемент — джерело помилки при цілочисловій арифметиці.
Логарифм та експоненціала через таблиці або апроксимацію
Класичний підхід — апроксимація ln(x) через розкладення Тейлора з fixed-point (fixed-point арифметика, 18 знаків). Solidity не має нативного ln, але бібліотека PRBMath (Paul Razvan Berg) реалізує ln, exp, sqrt з точністю до 1e-9 використовуючи 59.18-decimal fixed-point. Це production-ready: Uniswap v3 використовує подібні техніки для sqrtPriceX96.
Альтернатива — lookup таблиці для стандартного нормального розподілу N(d). Таблиця з 1000 точок з інтерполяцією дає достатню точність для опціонів й обходиться дешевше по газу, ніж аналітична апроксимація. Lyra v1 використовувала саме цей підхід.
Передбачувана волатильність — обернена задача
Найскладніше — не розрахувати ціну за відомої волатильності, а знайти передбачувану волатильність з ринкової ціни. Рівняння BSM_price(σ) = market_price не розв'язується аналітично. Методи: Newton-Raphson ітерації або бісекційний пошук.
On-chain Newton-Raphson за 5-7 ітерацій сходиться до IV з точністю 0.1% — коштує близько 80-150k газу на Ethereum mainnet. Для L2 прийнятно, для mainnet — дорого. Рішення: IV розраховується off-chain, подається on-chain з підписом оракула, контракт тільки верифікує підпис і використовує значення.
Проблема застарілої волатильності
Крипто-волатильність змінюється швидко. IV біткоина за 24 години може зрости з 60% до 120% при різкому русі ринку. Якщо on-chain зберігає застарілу IV — опціони оцінюються неправильно. Покупець опціону з занижною IV отримує несправедливу ціну на збиток LP.
Lyra v2 вирішує це через off-chain оракул (спочатку SNX keeper, потім Lyra-специфічний) з оновленням IV кожні 15 хвилин. Hegic використовує Chainlink volatility оракул (експериментальний feed). Для кастомної системи — оновлення через keeper (Gelato або Chainlink Automation) з обмеженим оновленням: IV не може змінитися більше ніж на X% за одне оновлення.
Архітектура системи ціноутворення
Off-chain pricing engine + on-chain верифікація
Оптимальна архітектура для production: ціноутворення на TypeScript/Python сервері з повною точністю float64, результат підписується оператором або мульті-партійним комітетом, контракт верифікує підпис і використовує ціну.
Це не «централізовано» у негативному сенсі — є явне припущення довіри, яке задокументовано. Для порівняння: Deribit повністю централізований, Lyra v1 використовувала подібну схему оракула.
On-chain контракт зберігає: spotPrice (від Chainlink), impliedVolatility (від keeper), lastUpdateTimestamp. При застарілих даних (> maxStaleness) — нові позиції не можна відкривати.
Розрахунок Greeks для управління ризиком
Для LP-пулу, який виступає контрагентом для всіх опціонів, критично — агрегований дельта-хеджинг пулу. Дельта кожного опціону підсумовується в net delta пулу, keeper виконує хеджинг-свопи для утримання дельта-нейтральності.
| Greek | Значення для пулу | Метод розрахунку |
|---|---|---|
| Delta | Експозиція до спот-ціни | N(d1) для call, N(d1)-1 для put |
| Gamma | Швидкість зміни дельти | φ(d1) / (S * σ * √T) |
| Vega | Експозиція до волатильності | S * φ(d1) * √T |
| Theta | Часовий розпад | Аналітично |
P&L пулу від греків підсумовується в netDelta, netVega. Якщо |netDelta| > hedgeThreshold — keeper ініціює своп на Uniswap v3 для балансування.
Типи опціонів та розрахунок
Cash-settled проти фізичної доставки. Cash-settled простіший: при закінченні контракт запитує спот-ціну у Chainlink, розраховує виплату, переводить USDC. Фізична доставка потребує зберігання underlying активу в контракті.
Американські проти європейських. Американські опціони (виконання в будь-який момент) потребують binomial tree або Monte Carlo для коректної оцінки — on-chain непрактично. Всі on-chain опціонні протоколи використовують європейський стиль.
Ранні виконання через flash loan. Теоретично атакуючий міг би спробувати виконати опцион в момент маніпуляції оракулом. Захист: ціна розрахунку розраховується як TWAP за останню годину перед закінченням, не спот.
Процес розробки
Математична специфікація (2-3 дні). Формалізуємо: тип опціонів, механіка розрахунку, джерела даних для S та σ, модель комісій, механізм хеджингу.
Pricing бібліотека (2-3 дні). Solidity бібліотека для BSM з PRBMath. Unit-тести порівнюють результати з Python scipy.stats еталонною імплементацією.
Оракул та keeper (2-3 дні). Off-chain pricing engine, підписання даних, Gelato автоматизація оновлення IV.
Core контракти (3-5 днів). OptionPool (LP), OptionToken (ERC-1155), логіка розрахунку.
Тестування (2-3 дні). Fork-тести на mainnet з реальними Chainlink feeds, сценарії закінчення.
Ориєнтири по термінах
Система ціноутворення як бібліотека + оракульна інфраструктура — 3-5 днів. Повнофункціональний опціонний протокол з LP пулом, хеджингом та frontend — 6-10 тижнів.