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

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

Hegic змінив підхід до on-chain опціонів у 2020 році: замість orderbook — пули ліквідності. Покупець опціону платить премію в пул, LP несуть ризик (і отримують yield). Нема контрагента, нема matching. Це зробило опціони доступними для звичайних користувачів, але додало LP-ризик, який потрібно правильно моделювати та хеджувати.

Як працюють pool-based опціони та де ризики для LP

Ціноутворення опціонів: Black-Scholes on-chain

Hegic використовує спрощену версію моделі Black-Scholes для розрахунку премії. Потрібні п'ять параметрів: ціна активу, страйк, час до закінчення, безрисикова ставка (можна вважати 0 для крипто) та передбачувана волатильність (IV).

Проблема — IV неможливо обчислити purely on-chain з перших принципів. Hegic v888 використовував фіксовану IV, що давало неправильне ціноутворення у періоди високої/низької волатильності. Hegic v8888 перейшов на IV оракул (IVOracle), оновлюваний через governance або децентралізований механізм.

Для нашої реалізації IV подається через Chainlink Custom Data Feed або власний оракул, який агрегує IV з Deribit через API → off-chain keeper → on-chain оновлення з підписом.

Vega (грецька чутливість до IV) — головний ризик LP. При зростанні IV всі опціони дорожають, LP втрачають (вони продали опцион по старій премії). Правильний протокол динамічно коригує коефіцієнт ціноутворення при зміні IV.

Коефіцієнт утилізації та ризик виплати

Hegic обмежує максимальний notional опціонів, які пул може продати, через ліміт утилізації:

maxOpenNotional = poolBalance * maxUtilizationRate

Якщо пул $1M з maxUtilizationRate = 0.8, максимальний сумарний notional відкритих опціонів — $800K. При досягненні ліміту нові опціони не продаються. Це захист від сценарію, коли пул не може виплатити всі виконані опціони.

Для кастомного протоколу калібруємо maxUtilizationRate на основі волатильності активу та бажаного ризик-профілю для LP. 80% — для стейблкоїн опціонів, 40-50% — для високоволатильних активів.

Розділені пули проти об'єднаної ліквідності

Hegic v888: один пул для всіх ETH опціонів (call + put). Це означає природний хеджинг: LP у пулі put програють при падінні ETH, але LP у пулі call виграють. Hegic v8888 зберіг розділення за базовим активом, але об'єднав call та put в один пул — LP отримують більш диверсифіковану позицію.

Для кастомного протоколу вибір залежить від очікуваного перекосу (tilt в бік puts або calls). Якщо користувачі переважно купують puts як інструмент хеджування, об'єднаний пул буде нести асиметричний ризик.

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

Основні модулі

OptionsProtocol.sol
├── HegicPool.sol           — пул ліквідності + відстеження позицій LP
├── OptionsManager.sol      — створення, виконання, закінчення опціонів
├── PriceCalculator.sol     — Black-Scholes + IV оракул
├── PayoffCalculator.sol    — розрахунок виплати при виконанні
└── StakingPool.sol         — yield для HEGIC/governance токена

HegicPool тримає ETH або ERC-20, відстежуючи кожну LP позицію як shares. При виплаті виконання LP пропорційно втрачають частку пулу. При отриманні премій — пул зростає, shares дорожають.

Логіка виконання: американський проти європейського стилю

Hegic підтримує американський стиль — опціони можна виконати в будь-який момент до закінчення. Це технічно складніше: потрібно постійно перевіряти, чи не став опцион in-the-money. Для on-chain це робиться permissionlessly: кожен може викликати exercise() для закінченого або ITM опціону.

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

function exercise(uint256 optionId) external {
    Option storage option = options[optionId];
    require(option.state == OptionState.Active, "Not active");
    require(block.timestamp <= option.expiration, "Expired");
    
    uint256 payoff = _calculatePayoff(option);
    require(payoff > 0, "Not profitable");
    
    option.state = OptionState.Exercised;
    pool.sendPayoff(option.holder, payoff);
    
    emit Exercise(optionId, payoff);
}

Відстеження Greeks для LP дашборду

LP мають бачити агрегований дельта, гамму й вегу пулу — це їх P&L при русі ринку. Зберігання Greeks on-chain дорого (газ), тому використовуємо The Graph субграф: індексуємо всі події створення/виконання/закінчення опціонів, розраховуємо Greeks off-chain та відображаємо в UI.

Типові уразливості опціонних протоколів

Oracle frontrunning. Якщо оновлення ціни оракула передбачувано (наприклад, Chainlink heartbeat кожні 3600 секунд), атакуючий може купити опцион перед оновленням, знаючи, що ціна оновиться на користь опціону. Захист: використовувати TWAP замість спот-ціни для умов виконання, або запровадити мінімальний період утримання.

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

Застаріла IV на розриві оракула. Якщо IV оракул не оновлювався 24 години, а ринок різко рухнувся — протокол продає опціони по старих цінах. Вимикач: якщо lastIVUpdate > maxStaleness, блокуємо створення нових опціонів.

Стек та інструменти

Процес розробки

Аналітика (3-5 днів). Вибір активів, стиль опціонів (американський/європейський), параметри IV оракула, tokenomics LP пулу.

Розробка (3-5 тижнів). Спочатку будуємо PriceCalculator — усе інше від нього залежить. Fuzz-тестуємо математику на граничних значеннях (дуже низька/висока IV, короткий час до закінчення).

Тестування (1 тиждень). Симуляція: що відбувається з пулом при flash crash -50% за 1 годину? Скільки втрачають LP? Відповідає це очікуваному ризик-профілю?

Аудит і деплой. Зовнішній аудит обов'язковий — опціонна математика містить нетривіальні edge cases.

Ориєнтири по термінах

Базовий протокол європейських опціонів для одного активу — від 4 до 6 тижнів. Повнофункціональний протокол з американськими опціонами, кількома активами та governance — від 8 до 14 тижнів.