Как работают DeFi options-протоколы простыми словами: от covered calls и puts до MVP с automation layer

Когда в DeFi говорят про options, разговор часто ломается в одном и том же месте: либо всё сводят к трейдерскому жаргону про volatility smile и Greeks, либо продают идею как «пассивный доход» без нормального объяснения, кто именно за него платит и какой риск скрыт внутри.

Если убрать лишний шум, options-протоколы в DeFi — это способ программно продавать или покупать право на сделку по заранее заданной цене и дате. Для одних это хедж, для других — ставка на движение рынка, а для третьих — инфраструктура, на которой можно собрать structured product, vault или automated yield-стратегию.

Именно этот класс протоколов сейчас особенно интересен по трём причинам.

Во-первых, рынок стал взрослее: у DeFi уже есть спот-ликвидность, lending, stablecoin-слой и automation rail, на которые можно опирать более сложные деривативы. Во-вторых, options удобно объясняют разницу между красивой доходностью и реальным распределением риска. В-третьих, вокруг option vaults и automated execution постоянно всплывает практический вопрос: как построить MVP так, чтобы он не развалился на котировках, лимитах и settlement.

Ниже — практический разбор без рекламы: какие options-протоколы и модели есть на рынке, как они работают простыми словами, как двигаются деньги, где находятся основные trade-offs и как собрать похожий прототип или MVP с нормальным automation layer вокруг price feeds, auction/execution, margin и risk controls.

Что это за класс протоколов и кто есть на рынке

Если упростить до сути, options-протокол делает три вещи:

  1. создаёт контракт с понятными параметрами — базовый актив, strike, expiry, тип опциона;
  2. связывает покупателя права и поставщика риска;
  3. организует pricing, collateral, исполнение и settlement так, чтобы обещание реально можно было выполнить.

На рынке можно выделить несколько заметных направлений.

1. Option AMM и onchain orderflow

Исторически самый очевидный путь — сделать рынок опционов прямо onchain.

Это могут быть:

  • протоколы с AMM-логикой для опционов;
  • orderbook / RFQ-подходы для более точного pricing;
  • гибридные системы, где котировка строится offchain, а расчёт и custody остаются onchain.

В разных циклах рынка в этой зоне обсуждали Premia, Lyra, Dopex и похожие продукты. Архитектуры у них разные, но пользовательская идея одна: купить или продать option-exposure без централизованной биржи.

2. Vault-based options strategies

Это самый понятный для широкой аудитории сегмент. Пользователь не торгует опцион вручную, а вносит актив в vault, который по стратегии регулярно:

  • продаёт covered calls на deposited ETH, BTC или LST;
  • продаёт cash-secured puts под stablecoin collateral;
  • иногда собирает более сложные конструкции через заранее заданные правила.

Именно вокруг таких стратегий было много продуктового внимания, потому что они выглядят как «yield-продукт», хотя по сути являются автоматизированной продажей optionality.

3. Structured products и packaged strategies

Здесь options — не конечный продукт, а компонент более крупной обёртки:

  • downside buffer note;
  • capped upside strategy;
  • principal-protected или quasi-protected формат;
  • treasury overlay для long-only портфеля;
  • auto-compounding strategy с rollover логикой.

Для B2B и fintech-угла это особенно полезно: можно собрать интерфейс, где пользователь видит не «short call strike 1.1x», а понятный продуктовый результат — диапазон доходности, downside protection и сценарии payoff.

4. Hedging layer вокруг других DeFi-протоколов

Options всё чаще нужны не только спекулянтам.

Например:

  • LP хочет захеджировать downside после входа в concentrated liquidity;
  • treasury desk хочет продать covered calls против части long-позиции;
  • stablecoin / RWA-продукт хочет докупить protection на extreme move;
  • vault manager хочет ограничить tail-risk у своей базовой стратегии.

Это важный угол: options-протокол может быть не отдельной «биржей для сложных ребят», а сервисным слоем вокруг других DeFi-механик.

Как это работает простыми словами

Самая полезная отправная точка — не формулы, а вопрос: кто за что платит и какое право получает.

Call option

Call даёт покупателю право купить актив по фиксированной цене до срока или в дату истечения.

Простой пример:

  • ETH сейчас стоит 3 000;
  • покупатель берёт call со strike 3 300 и expiry через 7 дней;
  • за это право он платит premium.

Что дальше:

  • если ETH уходит на 3 700, право становится ценным;
  • если ETH остаётся ниже 3 300, option, скорее всего, истечёт worthless;
  • продавец опциона сохраняет полученную премию, но взял на себя обязательство отдать upside выше strike.

Put option

Put даёт покупателю право продать актив по фиксированной цене.

Пример:

  • ETH сейчас 3 000;
  • покупатель хочет защиту от падения и покупает put со strike 2 700;
  • если ETH падает до 2 200, этот put становится защитой;
  • если рынок не падает, покупатель теряет уплаченную premium, зато купил страховку.

Covered call простыми словами

Самая популярная vault-идея выглядит так:

  1. у вас уже есть ETH;
  2. вы согласны продать его дороже текущей цены, если рынок резко вырастет;
  3. за это вы заранее получаете premium.

То есть covered call — это не «магическая доходность», а продажа части будущего upside в обмен на деньги сегодня.

Cash-secured put простыми словами

Здесь логика зеркальная:

  1. у вас есть стейблкоины;
  2. вы готовы купить актив дешевле текущего рынка, если он упадёт;
  3. за готовность взять этот риск получаете premium.

Это похоже на лимитную заявку на покупку, но с дополнительной механикой option premium и обязательством исполнить сделку, если сценарий наступит.

Откуда берётся доходность у option vault

Не из воздуха и не из «DeFi magic». Источник доходности — premium, которую кто-то другой платит за право на asymmetry:

  • рост выше strike;
  • защита от падения;
  • волатильностный экспожер;
  • заранее определённый payoff.

Именно поэтому важное правило такое: APR у option vault — это цена проданного риска, а не бесплатный yield.

Какие модели options-протоколов чаще всего встречаются

1. Fully collateralized options

Это самый консервативный и понятный для MVP путь.

  • для covered call продавец реально держит базовый актив;
  • для cash-secured put продавец реально держит stablecoin collateral;
  • протокол не создаёт «голые» обязательства без покрытия.

Плюсы:

  • проще risk engine;
  • понятнее ликвидационная логика;
  • меньше хвостовых сценариев.

Минусы:

  • капитал используется менее эффективно;
  • сложнее конкурировать с централизованными деривативными площадками по capital efficiency.

2. Margin-based options

Здесь продавец опциона кладёт не полное покрытие, а margin, который должен быть достаточным для worst-case или model-based exposure.

Плюсы:

  • выше capital efficiency;
  • глубже рынок для активных трейдеров.

Минусы:

  • нужен сильный risk engine;
  • при экстремальной волатильности быстрее ломается UX;
  • появляется more serious liquidation and oracle risk.

3. Vault auction model

Популярная модель для vault-продуктов:

  1. пользователи депонируют актив в vault;
  2. vault по расписанию формирует опционный лот;
  3. market makers или solvers покупают этот лот через auction/RFQ;
  4. собранная premium распределяется по пайщикам vault.

Это удобно, потому что pricing не обязательно полностью тащить внутрь onchain-AMM. Протокол может оставить onchain custody, но котировку вынести в более гибкий execution layer.

4. Peer-to-pool / pool-to-trader model

Пул капитала становится коллективным продавцом options, а трейдеры приходят за готовой ликвидностью.

Такой подход удобен для продуктовых команд, потому что:

  • не нужно ждать второго конкретного контрагента;
  • liquidity management можно централизовать на уровне протокола;
  • проще строить consumer-facing vault UX.

Но именно здесь особенно важно не продавать слишком дешёвую волатильность и не перепутать «стабильный продукт» с плохо оценённым short-vol бизнесом.

Как двигаются деньги в options-протоколе

Если смотреть на денежный поток, базовая схема примерно такая.

Covered call vault

  1. Пользователи вносят ETH в vault.
  2. Vault выбирает expiry и strike, например weekly call на 8–12% выше spot.
  3. Через auction или RFQ vault продаёт call market maker’у.
  4. Покупатель опциона платит premium upfront.
  5. Premium попадает в vault и учитывается как доход стратегии.
  6. В дату expiry происходит один из двух сценариев:
    • если цена ниже strike, option сгорает, vault сохраняет ETH и premium;
    • если цена выше strike, часть upside отдана покупателю, а vault получает settlement по правилам контракта.
  7. Стратегия делает rollover в следующий цикл.

Cash-secured put vault

  1. Пользователи вносят USDC.
  2. Vault продаёт put на выбранный актив.
  3. Покупатель платит premium.
  4. Если рынок не падает ниже strike, vault забирает premium.
  5. Если цена падает, vault обязан купить актив по strike или рассчитаться по cash-settlement-модели.
  6. Дальше стратегия либо удерживает купленный актив, либо продаёт его, либо перекладывается в следующий цикл.

Ключевая мысль

Доходность vault зависит сразу от четырёх вещей:

  • размера полученной premium;
  • выбранного strike;
  • realized volatility;
  • дисциплины rollover и execution.

Поэтому два vault с «похожим» APY могут на самом деле продавать очень разный риск.

Основные компоненты архитектуры

Если смотреть на options-протокол как на инженерную систему, почти всегда появляются следующие слои.

1. OptionSeriesFactory

Модуль, который создаёт серии контрактов с параметрами:

  • underlying;
  • quote asset;
  • strike;
  • expiry;
  • option type;
  • settlement mode.

Для MVP лучше сразу ограничить свободу: не бесконечный конструктор, а whitelist поддерживаемых серий и расписаний.

2. CollateralVault

Хранит обеспечительный актив.

Для covered call это базовый актив, для cash-secured put — stablecoin. Этот слой должен уметь:

  • принимать депозит;
  • резервировать collateral под открытую серию;
  • освобождать collateral после expiry;
  • блокировать вывод во время активного цикла.

3. Pricing / RFQ / Auction layer

Самая болезненная часть options-продукта — честная котировка.

Нужен слой, который:

  • принимает reference price;
  • использует volatility assumptions;
  • даёт минимально допустимую premium;
  • собирает внешние биды от market makers или solvers;
  • отклоняет слишком плохое исполнение.

Для production система может быть сложной, но для MVP важнее не «идеальный Black-Scholes onchain», а нормальный guardrail против продажи опциона слишком дёшево.

4. Settlement engine

После expiry протокол должен корректно посчитать результат:

  • ITM или OTM серия;
  • intrinsic value;
  • cash settlement или physical settlement;
  • какая часть collateral возвращается;
  • сколько premium остаётся у vault.

5. Oracle layer

Options не живут без доверенного источника цены и времени.

Протоколу нужны:

  • spot oracle для underlying;
  • правила freshness;
  • fallback logic;
  • expiry price snapshot;
  • защита от аномального ценового тика в момент settlement.

6. Strategy controller

Если продукт работает как vault, поверх опционных контрактов нужен orchestration layer:

  • выбрать следующую серию;
  • задать strike policy;
  • определить размер продаваемого notional;
  • rollover позицию;
  • удержать reserve buffer на комиссии и edge cases.

7. RiskConfig / Policy engine

Этот слой хранит лимиты:

  • max vault utilization;
  • allowed underlyings;
  • max tenor;
  • max notional per auction;
  • min premium threshold;
  • oracle stale threshold;
  • pause / emergency flags.

Где основные риски и trade-offs

У options-протоколов почти никогда нет «бесплатной» доходности. Есть аккуратная упаковка short-vol или hedging-механики, а значит и список неприятных рисков довольно длинный.

1. Underpriced volatility risk

Если vault системно продаёт опционы слишком дёшево, он выглядит красиво в спокойный рынок, а потом одномоментно отдаёт слишком много value во время сильного движения.

Это, пожалуй, главный бизнес-риск для option vault.

2. Capped upside / hidden downside misunderstanding

Пользователь видит APY и может не понимать, что:

  • covered call режет upside;
  • cash-secured put может привести к покупке падающего актива;
  • несколько спокойных недель не доказывают устойчивость стратегии.

То есть большой риск лежит не только в протоколе, но и в product communication.

3. Oracle and expiry manipulation risk

Если settlement зависит от цены в один конкретный момент, появляется риск:

  • манипуляции тонким рынком;
  • stale price;
  • рассинхрона между oracle и реальным market snapshot;
  • спора о корректной expiry price.

4. Liquidity and auction risk

Vault может оказаться без нормального bid в нужное время.

Тогда два плохих варианта:

  • не продать серию и пропустить цикл;
  • продать серию по слишком плохой premium ради «стабильности стратегии».

Именно поэтому execution discipline важнее маркетингового APR.

5. Smart-contract and rights management risk

Как и в любом DeFi-продукте, проблемы могут быть в:

  • неверной логике mint/burn option token;
  • ошибке распределения collateral;
  • чрезмерных правах администратора;
  • баге rollover-автоматики;
  • неверно обработанном paused state.

6. Strategy drift risk

Даже если базовая стратегия хорошая, со временем она может расползтись:

  • strike слишком близко к spot;
  • notional слишком большой;
  • market regime уже другой;
  • automation продолжает катать старое правило, не замечая, что risk/reward испортился.

7. Secondary integration risk

Если vault token или option token дальше живёт в lending или AMM, добавляются новые риски:

  • плохая оценка collateral;
  • illiquid secondary market;
  • wrong assumptions about NAV/PPFS;
  • несоответствие между внутренним payoff и внешней оценкой.

Как сделать похожий прототип или MVP

Если цель — показать механику, не надо сразу строить универсальную options-биржу.

Хороший MVP должен доказать семь вещей:

  1. пользователь может депонировать актив в vault;
  2. протокол умеет создавать ограниченный набор option series;
  3. premium приходит через предсказуемый auction/RFQ-flow;
  4. collateral резервируется и освобождается корректно;
  5. settlement проходит без ручной магии;
  6. risk limits реально блокируют плохие сделки;
  7. automation layer умеет делать rollover и алертинг.

Разумные границы MVP

Для demo достаточно:

  • одна EVM-сеть;
  • одна стратегия covered call или одна стратегия cash-secured put;
  • один underlying, например ETH;
  • weekly expiry;
  • набор strike buckets, например 105%, 110%, 115% от spot;
  • cash settlement;
  • ограниченный whitelist market makers для auction.

Такой MVP уже покажет реальную механику без лишнего архитектурного шума.

Какие контракты нужны

1. VaultShares

ERC-20 или share-accounting модуль для депозитов пользователей.

Функции:

  • deposit / withdraw;
  • mint shares;
  • lock shares during active option cycle;
  • account for collected premium.

2. OptionSeriesFactory

Создаёт серии опционов по whitelist-параметрам.

Функции:

  • create series;
  • validate tenor/strike bounds;
  • track active and expired series;
  • expose metadata for indexers and UI.

3. AuctionController

Запускает продажу очередной серии.

Функции:

  • open auction;
  • collect bids;
  • verify min premium threshold;
  • choose winning bid;
  • allocate notional.

4. CollateralManager

Держит и блокирует обеспечение.

Функции:

  • reserve collateral;
  • release unused collateral;
  • track utilization;
  • enforce max sold notional.

5. SettlementController

Закрывает серию после expiry.

Функции:

  • snapshot expiry price;
  • determine ITM/OTM;
  • calculate payout;
  • settle winning counterparty;
  • update vault accounting.

6. RiskConfig

Хранит лимиты и guardrails.

Примеры параметров:

  • max utilization 80–90%;
  • min premium as % of notional;
  • max series tenor;
  • oracle staleness threshold;
  • max slippage between reference quote and executed bid;
  • emergency pause.

Индексация и data layer

Без внешнего data layer options-продукт быстро становится непрозрачным.

Минимальный набор сущностей:

  • vault_deposits
  • vault_withdrawals
  • option_series
  • auction_rounds
  • bids
  • settlements
  • oracle_snapshots
  • premium_accruals
  • alerts
  • operator_actions

Практичный стек для MVP:

  • Postgres;
  • indexer на Node/TypeScript или Go;
  • cron/jobs для rollover;
  • admin UI для auctions, settlements и alerts.

Бэкенд-джобы, без которых MVP будет хрупким

Минимально полезный набор такой:

  • spot_snapshot_job — забирает reference price и пишет snapshot;
  • strike_selection_job — предлагает допустимый strike bucket;
  • auction_open_job — открывает новый RFQ/auction cycle;
  • auction_finalize_job — валидирует и выбирает лучшую котировку;
  • settlement_job — закрывает серию после expiry;
  • rollover_job — переносит vault в следующий цикл;
  • reconciliation_job — сверяет collateral, sold notional и vault NAV;
  • alert_job — шлёт сигналы по stale oracle, missing bids, bad premium и settlement failures.

Как упростить pricing в MVP

Главная ошибка — пытаться сделать «идеальную» модель волатильности с первого дня.

Для demo лучше честно упростить:

  • reference spot брать из одного oracle;
  • implied vol выбирать из ручной таблицы по tenor/strike;
  • считать fair premium в backend;
  • onchain держать только reference bounds и факт принятой ставки.

То есть не нужно тащить весь quant-движок в смарт-контракт. Достаточно сделать протокол так, чтобы он не принимал заведомо плохое исполнение.

UI для демо

Для MVP хватит семи экранов или блоков:

  1. overview vault и текущая стратегия;
  2. deposit / withdraw;
  3. активная серия и её strike/expiry;
  4. история собранных premium;
  5. auction status и winning bids;
  6. settlement history;
  7. operator dashboard с лимитами и alert history.

Что можно автоматизировать поверх такого протокола

Именно здесь options-продукты становятся не просто «контрактами на волатильность», а нормальным управляемым сервисом.

1. Strike selection и policy-based execution

Automation layer может выбирать серию не «на глаз», а по правилам:

  • target delta range;
  • minimum premium;
  • max downside tolerance;
  • запрет продавать опционы слишком близко к важным событиям;
  • снижение utilization в stressed volatility regime.

2. Auction/RFQ orchestration

Если протокол завязан на внешних market makers, automation должен:

  • открыть раунд в нужное окно;
  • собрать котировки;
  • проверить reference bounds;
  • исключить аномальные bids;
  • завершить аукцион вовремя;
  • перевести vault в следующий статус без ручной возни.

3. Oracle monitoring

Automation должен постоянно следить за качеством цены:

  • freshness;
  • deviation against fallback source;
  • пропущенные обновления;
  • аномальный тик перед expiry;
  • рассинхрон spot vs settlement snapshot.

4. Risk controls и circuit breakers

Для options это особенно важно. Automation layer может:

  • паузить новый auction, если volatility резко выросла;
  • снижать max notional;
  • блокировать rollover при отсутствии нормального bid;
  • выключать strategy leg при oracle uncertainty;
  • поднимать лимиты только после явного operator approval.

5. Treasury and premium accounting

Если premium собирается каждую неделю или каждый день, нужен автоматический учёт:

  • сколько premium earned;
  • какая часть уже распределена пайщикам;
  • какой текущий effective NAV vault;
  • сколько было отдано в settlement;
  • какая реальная net performance после fees.

6. Strategy health monitoring

Это тот слой, который отличает витрину от реального продукта.

Нужно автоматически отслеживать:

  • premium-to-risk ratio;
  • utilization;
  • percentage of ITM expiries;
  • cumulative foregone upside для covered call;
  • drawdown после assignment для puts;
  • просадку против простого hold-бенчмарка.

7. Alerting для операторов и интеграторов

Самые полезные сигналы:

  • stale oracle;
  • auction missed window;
  • bid below threshold;
  • settlement failed;
  • unexpected vault NAV jump;
  • excessive ITM concentration over последние N циклов.

Практическая архитектура automation layer

Если собрать всё в одну рабочую схему, получится примерно такой набор:

  1. Market data service — собирает spot, fallback prices и volatility assumptions.
  2. Strategy policy engine — выбирает strike, expiry и допустимый sold notional.
  3. Auction orchestrator — открывает RFQ/auction, валидирует bids и фиксирует победителя.
  4. Execution gateway — единственная точка для reserve collateral, open series, settle expiry и rollover.
  5. Vault accountant — считает NAV, premium accrual, fees и realized payoff.
  6. Risk monitor — следит за oracle quality, utilization, bad fills и regime changes.
  7. Alerting layer — шлёт Telegram/Slack сигналы по сбоям и выходам за лимиты.
  8. Operator dashboard — показывает состояние стратегии, историю циклов, overrides и audit trail.

Для продуктовой команды ценность здесь простая: options-механика становится управляемым control plane, а не смесью из красивого лендинга, ручных Excel-расчётов и надежды, что волатильность «поведёт себя нормально».

Где такой MVP реально полезен

Даже без запуска полной options-биржи похожий MVP полезен как:

  • demo для treasury desk, который хочет monetise long spot через covered calls;
  • consumer savings / yield layer поверх ETH или BTC exposure;
  • structured-product sandbox для fintech;
  • hedge overlay для LP или vault manager;
  • internal execution/risk prototype для команды, которая хочет проверить механику short-vol продукта до public launch.

Главное, что стоит запомнить

DeFi options-протоколы — это не «сложная магия для квантов», а вполне прикладной класс систем, где нужно аккуратно упаковать право, риск, collateral и исполнение.

Если упростить механику до сути, получается следующее:

  • покупатель опциона платит premium за право на асимметричный payoff;
  • продавец опциона получает premium, но берёт на себя обязательство и tail-risk;
  • option vault превращает эту механику в автоматизированный продукт, чаще всего через продажу covered calls или cash-secured puts;
  • главные риски лежат не только в смарт-контрактах, но и в котировках, oracle quality, settlement discipline и плохом управлении лимитами;
  • automation layer нужен вокруг strike selection, auction/RFQ, rollover, мониторинга и circuit breakers.

Именно поэтому options — один из самых полезных DeFi-классов для инженерного разбора. Здесь особенно хорошо видно, как из красивой доходности получается вполне конкретный продуктовый и операционный риск — и почему без нормального automation layer такой протокол очень быстро начинает жить не по модели, а по удаче.