Разработка протокола опционов (Hegic-стиль)
Hegic изменил подход к on-chain опционам в 2020 году: вместо order book — пулы ликвидности. Покупатель опциона платит премию в пул, LP несут риск (и получают yield). Никаких counterparty, никакого matching. Это сделало опционы accessible для обычных пользователей, но добавило LP-риск, который нужно правильно моделировать и хеджировать.
Как работает pool-based options и где риски для LP
Ценообразование опционов: Black-Scholes on-chain
Hegic использует упрощённую версию модели Black-Scholes для расчёта премии. Нужны пять параметров: цена актива, страйк, время до экспирации, risk-free rate (можно считать 0 для крипто), и implied volatility (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 update с подписью.
Upsilon (греческая чувствительность к IV) — главный риск LP. При росте IV все опционы дорожают, LP теряют (они продали опцион по старой премии). Правильный протокол динамически корректирует коэффициент ценообразования при изменении IV.
Utilization ratio и payoff risk
Hegic ограничивает максимальный notional опционов, которые может продать пул через utilization limit:
maxOpenNotional = poolBalance * maxUtilizationRate
Если пул $1M с maxUtilizationRate = 0.8, максимальный суммарный notional открытых опционов — $800K. При достижении лимита новые опционы не продаются. Это защита от сценария, когда пул не сможет выплатить все exercised опционы.
Для кастомного протокола калибруем maxUtilizationRate на основе волатильности актива и желаемого risk profile для LP. 80% — для стейблкоин опционов, 40-50% — для высоковолатильных активов.
Separateed pools vs. combined liquidity
Hegic v888: один пул для all ETH опционов (call + put). Это означает natural hedging: LP в put пуле проигрывают при падении ETH, но LP в call пуле выигрывают. Hegic v8888 сохранил разделение по базовому активу, но объединил call и put в один пул — LP получают более диверсифицированную позицию.
Для кастомного протокола выбор зависит от ожидаемого skew (перекоса в сторону puts или calls). Если пользователи в основном покупают put как hedging инструмент, объединённый пул будет нести асимметричный риск.
Архитектура контрактов
Основные модули
OptionsProtocol.sol
├── HegicPool.sol — пул ликвидности + tracking LP positions
├── OptionsManager.sol — создание, exercise, expire опционов
├── PriceCalculator.sol — Black-Scholes + IV оракул
├── PayoffCalculator.sol — расчёт payoff при exercise
└── StakingPool.sol — yield для HEGIC/governance токена
HegicPool держит ETH или ERC-20, tracking каждой LP позиции в виде shares. При выплате exercise LP пропорционально теряют долю пула. При получении премий — пул растёт, shares дорожают.
Exercise логика: American vs. European
Hegic поддерживает American стиль — опцион можно exercise в любой момент до экспирации. Это технически сложнее: нужно постоянно проверять, не ушёл ли опцион in-the-money. Для on-chain это делается permissionlessly: кто угодно может вызвать exercise() для просроченного или ITM опциона.
European стиль проще для LP: выплата происходит только при экспирации, LP могут лучше планировать ликвидность. Для начального протокола рекомендуем European — меньше поверхность атаки, проще 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 tracking для LP dashboard
LP должны видеть агрегированную дельту, гамму и вегу пула — это их P&L при движении рынка. Хранить Greeks on-chain дорого (gas), поэтому используем The Graph subgraph: индексируем все события создания/exercise/expire опционов, вычисляем Greeks off-chain и отображаем в UI.
Типичные уязвимости опционных протоколов
Oracle frontrunning. Если обновление цены оракула предсказуемо (например, Chainlink heartbeat каждые 3600 секунд), атакующий может купить опцион прямо перед обновлением, когда знает, что цена обновится в пользу опциона. Защита: использовать TWAP вместо spot price для exercise условий, или ввести минимальный hold period.
LP griefing через мелкие опционы. Создание тысяч мелких опционов заполняет utilization limit без реальной ценности для протокола (нет прибыльных exercise). Атакующий просто держит опционы и не даёт LP входить с крупной ликвидностью. Защита: minimum premium threshold и maximum open interest per address.
Stale IV при gap в оракуле. Если IV оракул не обновлялся 24 часа, а рынок резко двинулся — протокол продаёт опционы по старым ценам. Circuit breaker: если lastIVUpdate > maxStaleness, блокируем создание новых опционов.
Стек и инструменты
| Компонент | Технология |
|---|---|
| Математика | FixedPointMathLib (Solmate), PRBMath для ln/exp |
| IV оракул | Chainlink Custom Feed / off-chain keeper + signature |
| Тестирование | Foundry fuzz tests (все комбинации страйк/время/IV) |
| Subgraph | The Graph (Greeks, LP history, open interest) |
| Фронтенд | wagmi, viem, recharts для payoff визуализации |
Процесс разработки
Аналитика (3-5 дней). Выбор активов, стиль опционов (American/European), параметры IV оракула, tokenomics LP пула.
Разработка (3-5 недель). PriceCalculator первым — всё остальное зависит от него. Fuzz-тесты математики на граничных значениях (очень низкий/высокий IV, малое время до экспирации).
Тестирование (1 неделя). Simulation: что происходит с пулом при flash crash -50% за 1 час? Сколько LP теряют? Соответствует ли это ожидаемому risk profile?
Аудит и деплой. Внешний аудит обязателен — опционная математика содержит нетривиальные edge cases.
Ориентиры по срокам
Базовый протокол European опционов для одного актива — от 4 до 6 недель. Полноценный протокол с American опционами, несколькими активами и governance — от 8 до 14 недель.







