Как работают delta-neutral и synthetic dollar-протоколы в DeFi простыми словами: basis trade, hedging и MVP с automation layer

В DeFi давно есть спрос не просто на «ещё один стейблкоин», а на продукт, который умеет превращать волатильные криптоактивы и деривативы в более предсказуемый долларовый профиль доходности.

Именно на этом вырос отдельный класс протоколов: delta-neutral vaults, synthetic dollar protocols, basis-trading stable yield products. Их идея не в том, чтобы обещать магическую безрисковую доходность, а в том, чтобы собрать конструкцию, где цена базового актива максимально захеджирована, а доход идёт из funding, basis spread, staking yield или комбинации нескольких источников.

Проще говоря: протокол пытается взять криптоактив, открыть к нему встречную короткую позицию через perpetual futures или другой дериватив, а разницу между двумя ногами превратить в продукт, похожий на «криптодоллар с доходностью».

Сейчас это особенно заметный сегмент рынка, потому что пользователи и treasury-команды ищут не только рост токена, но и операционно понятную доходность: где именно она берётся, как её считать, как контролировать margin, что делать при отрицательном funding и как не утонуть в ручном risk management.

Ниже — практический разбор без рекламы: какие модели и игроки есть на рынке, как работает delta-neutral/synthetic dollar-механика простыми словами, как двигаются деньги, где основные риски и как собрать похожий прототип или MVP с automation layer вокруг hedging, margin control и rebalance workflows.

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

Если упростить до сути, delta-neutral протокол в DeFi — это система, которая старается убрать или сильно снизить направленный ценовой риск по активу, а доход строить на других источниках:

funding payments на perpetual market;
basis между spot и futures;
staking yield или restaking yield;
LP/borrow spread;
protocol fees;
treasury management поверх этих позиций.

На рынке встречается несколько заметных моделей.

1. Synthetic dollar через spot + short perp

Самая обсуждаемая схема последних циклов — когда протокол держит long spot exposure и одновременно открывает short perpetual position примерно на тот же объём.

Примеры и близкие по духу проекты, которые часто обсуждают в этом классе: Ethena, частично продукты вокруг basis vault-модели, а также более нишевые structured-yield решения.

Логика такая:

пользователь вносит collateral;
протокол покупает или уже держит базовый актив;
сверху открывает short на perp-рынке;
если hedge подобран правильно, чистая directional delta близка к нулю;
доход идёт из funding и сопутствующих источников.

2. Delta-neutral vaults для market-neutral yield

Это уже не обязательно «синтетический доллар» как отдельный токен. Иногда это просто vault, который принимает активы и автоматически держит market-neutral стратегию.

Такие продукты могут использовать:

централизованные биржи;
perp DEX;
lending markets;
options overlays;
multi-venue execution.

Для пользователя это выглядит как «положил капитал в vault, получил yield, а команда/протокол сама следит за hedge, margin и rebalance».

3. Hedged LST/LRT yield products

Отдельная ветка — когда протокол использует liquid staking token или другой yield-bearing актив, а directional exposure нейтрализует деривативом.

Примерная логика:

протокол держит stETH, eETH или похожий yield-bearing asset;
зарабатывает staking/restaking yield;
одновременно хеджирует ETH-ценовой риск через short perp;
в итоге пользователю показывает доход как комбинацию staking yield и деривативной ноги.

4. Treasury / cash management продукты

Некоторые команды строят не consumer-facing «стейблкоин», а treasury-продукт для DAO, фонда или криптобизнеса.

Там та же базовая математика, но другая упаковка:

лимиты по площадкам;
whitelisted counterparties;
policy engine;
отчётность по NAV;
контроль drawdown и emergency unwind.

Это уже очень похоже на инфраструктурный control plane вокруг стратегии, а не только на красивый токен.

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

Главная мысль здесь такая: протокол не убирает риск, он пытается заменить ценовой риск на набор более управляемых операционных и рыночных рисков.

В обычной длинной позиции по ETH ты зарабатываешь или теряешь на движении ETH. В delta-neutral конструкции протокол хочет сделать так, чтобы рост или падение ETH почти не влияли на итоговый результат.

Для этого он собирает две ноги.

Нога 1. Long spot или yield-bearing asset

Протокол держит актив, который даёт базовую экспозицию:

ETH;
BTC;
LST;
иногда basket активов;
иногда collateral в виде liquid stable assets с последующей покупкой базового актива.

Нога 2. Short derivative

Чтобы убрать directional risk, протокол открывает встречную короткую позицию:

short perpetual futures;
short dated futures;
реже — options structure;
иногда несколько хеджей на разных площадках.

Если размер short примерно равен размеру long, то при движении цены:

spot растёт — short теряет;
spot падает — short зарабатывает.

То есть направление рынка частично взаимно компенсируется.

Откуда тогда доход

Если цена почти захеджирована, протоколу нужен другой источник дохода. Обычно это один или несколько источников сразу:

positive funding по short perpetual позиции;
staking yield или restaking yield по базовому активу;
basis spread между spot и futures;
execution edge при roll и venue selection;
комиссии за выпуск/погашение продукта.

Поэтому такие протоколы правильнее думать не как про «стейблкоин с APY», а как про обёртку над набором хеджированных доходных потоков.

Пример на пальцах

Представим, что протокол принимает 1 ETH, когда ETH стоит 2 000 USDC.

Он делает следующее:

Держит 1 ETH или 1 stETH как long-ногу.
Открывает short perp на 1 ETH номинала.
Следит, чтобы margin на деривативной площадке оставался безопасным.
Получает staking yield по long-ноге и funding по short-ноге, если funding положительный для шорта.

Что дальше:

если ETH вырастет до 2 400 — long заработает, short потеряет;
если ETH упадёт до 1 700 — long потеряет, short заработает;
суммарная directional PnL должна быть небольшой относительно чисто длинной позиции;
итоговый PnL смещается к funding, carry и издержкам на хедж.

На практике идеального нуля почти не бывает, потому что появляются:

basis drift;
funding volatility;
slippage;
комиссии;
residual delta;
timing mismatch между ногами.

Но для пользователя снаружи это выглядит как более стабильный долларовый или near-dollar продукт, если протокол хорошо держит hedge.

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

1. Fully collateralized synthetic dollar

Пользователь вносит collateral, протокол выпускает synthetic dollar claim, а внутри держит hedge-стратегию.

Плюсы:

понятная упаковка для пользователя;
легче строить mint/redeem flow;
удобно показывать NAV и backing.

Минусы:

сложнее risk engine;
высокий спрос на точный accounting;
много скрытых операционных рисков.

2. Vault без собственного stablecoin-токена

Протокол не выпускает «новый доллар», а просто создаёт yield vault с market-neutral стратегией.

Плюсы:

меньше продуктовой сложности;
проще MVP;
меньше вопросов вокруг peg-management.

Минусы:

хуже consumer UX, если пользователю нужен именно долларовый актив;
сложнее позиционирование.

3. Multi-venue hedge

Long-актив хранится в одном месте, а short исполняется на нескольких CEX/DEX.

Плюсы:

выше гибкость;
можно искать лучший funding и ликвидность;
меньше зависимость от одной площадки.

Минусы:

резко растёт операционная сложность;
нужен routing и exposure control;
больше counterparty risk.

4. Yield stacking

Протокол совмещает несколько доходных слоёв:

staking yield;
funding;
lending spread;
incentive rewards.

Плюсы:

выше потенциальная доходность;
можно гибче перераспределять капитал.

Минусы:

труднее объяснить источник дохода;
больше путей поломки стратегии;
сложнее честно считать реальный net APY.

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

Базовый сценарий

Пользователь вносит collateral — например, USDC, ETH или LST.
Протокол конвертирует его в нужную структуру long-ноги.
Часть капитала отправляется в custody/vault, часть — на margin account для short-позиции.
Hedge engine открывает short через perp DEX или другую деривативную площадку.
Funding, staking rewards и fees начинают накапливаться в strategy accounting layer.
Если hedge уходит от цели, система делает rebalance.
При redeem протокол частично или полностью закрывает позицию, сводит PnL и возвращает пользователю его долю.

Где здесь самое хрупкое место

Самое хрупкое место — не mint-кнопка и не интерфейс, а операционная связка между long-ногой, short-ногой и margin discipline.

Если у протокола красивый фронтенд, но плохой hedge lifecycle, то продукт быстро превращается в источник скрытого tail risk.

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

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

1. Vault / Collateral Manager

Хранит депозит пользователя и учитывает:

shares;
NAV;
deposit/redemption queue;
fee accounting;
available liquidity.

2. Hedge Engine

Это ядро стратегии. Оно отвечает за:

target hedge ratio;
open/close short;
partial rebalance;
venue selection;
roll logic;
emergency unwind.

3. Margin & Risk Manager

Следит за самым опасным местом конструкции:

margin ratio;
liquidation buffer;
max leverage;
venue exposure;
collateral transfer thresholds;
drawdown triggers.

4. Funding / Yield Accounting Layer

Должен отдельно считать, из чего складывается доход:

funding received/paid;
staking rewards;
realised PnL по hedge;
unrealised PnL;
fees;
insurance reserve.

5. Oracle & Pricing Layer

Нужен для:

mark price;
NAV;
share price;
hedge ratio checks;
venue reconciliation.

Важно не строить всё на одном источнике цены без sanity checks.

6. Mint / Redeem Controller

Управляет пользовательским lifecycle:

deposit;
mint shares or synthetic units;
withdrawal request;
delayed redeem, если нужен unwind;
fee deduction.

7. Policy / Automation Layer

Вокруг стратегии почти всегда нужен отдельный control plane:

лимиты по площадкам;
запрет новых депозитов при stress-state;
авто-ребалансировка;
алерты по funding regime shift;
emergency modes.

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

1. Funding risk

В теории short perp может приносить funding. На практике funding бывает и отрицательным.

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

2. Basis risk

Spot и derivative не двигаются идеально синхронно.

Из-за этого delta-neutral на бумаге может давать неожиданный PnL на практике, особенно при стрессовых движениях или слабой ликвидности.

3. Liquidation risk

Даже если общая стратегия market-neutral, короткая нога живёт на margin.

Недостаточный collateral buffer, резкий move, latency или плохой rebalance — и протокол получает liquidation event.

4. Counterparty / venue risk

Если часть логики работает через CEX, custodial layer или отдельный perp DEX, появляется зависимость от:

биржи;
bridge;
settlement layer;
oracle design;
операционной дисциплины команды.

5. Redemption mismatch risk

Пользователь хочет быстрый redeem, а стратегия внутри может требовать unwind, перевода collateral и закрытия short.

Если это не продумать, возникает конфликт между UX «почти как стейблкоин» и реальной механикой стратегии.

6. Hidden complexity risk

Многие такие продукты выглядят простыми только на лендинге. Но внутри там:

derivatives accounting;
venue routing;
margin management;
price reconciliation;
insurance reserve;
stress procedures.

Если команда прячет эту сложность под маркетинговым слоем, пользователи хуже понимают, что именно они держат.

7. Governance and override risk

Если у админов есть возможность быстро менять лимиты, выключать хедж, переключать площадки или останавливать redeem, это нужно честно отражать в модели риска. Иначе получается не алгоритмический продукт, а чёрный ящик с ручным управлением.

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

Если цель — доказать механику, не надо сразу строить глобальный synthetic dollar на десятки площадок.

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

депозит создаёт долю в vault;
стратегия умеет открыть и закрыть hedge;
система считает NAV и PnL по ногам отдельно;
risk engine умеет держать margin buffer;
rebalance и emergency unwind запускаются предсказуемо;
automation layer умеет ловить funding/margin anomalies и реагировать.

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

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

одна сеть, например Base или Arbitrum;
один базовый актив, например ETH;
один perp venue;
один тип стратегии: long ETH или stETH + short perp;
shares vault вместо полноценного synthetic dollar;
простые комиссии и один reserve bucket;
operator-controlled emergency stop.

Такой MVP уже показывает суть продукта без попытки симулировать весь институциональный стек.

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

1. StrategyVault

Хранит депозиты и выпускает shares.

Функции:

deposit;
requestRedeem;
settleRedeem;
reportNAV;
accrueFees.

2. HedgeExecutor

Контракт или адаптерный слой, который взаимодействует с деривативной площадкой.

Функции:

openHedge;
increaseHedge;
reduceHedge;
closeHedge;
emergencyClose.

3. RiskManager

Проверяет:

target hedge ratio;
max leverage;
min margin ratio;
max venue exposure;
max slippage.

4. TreasuryReserve

Держит:

insurance buffer;
accrued fees;
покрытие операционных потерь;
emergency liquidity reserve.

5. OracleRouter

Собирает цены и sanity checks из нескольких источников.

6. PolicyController

Даже в MVP нужен слой, который умеет:

pause deposits;
cap TVL;
cap venue exposure;
require manual approval на большие ребалансы;
переключать протокол в degraded mode.

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

Без нормального data layer такой продукт превращается в нечитабельную смесь onchain-событий и позиций на деривативной площадке.

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

vault_positions
deposits
redemptions
hedge_positions
margin_snapshots
funding_events
staking_rewards
rebalance_events
nav_snapshots
risk_alerts
venue_exposures
insurance_reserve_events

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

Postgres;
indexer на Go или TypeScript;
scheduler/job runner;
небольшая admin-панель;
отчётный API для фронтенда и алертов.

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

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

hedge_ratio_check_job — сравнивает long и short exposure;
margin_monitor_job — следит за margin ratio и liquidation buffer;
funding_regime_job — считает, funding положительный или уже вредный;
nav_reconciliation_job — сверяет vault NAV, unrealised PnL и reserve;
rebalance_job — инициирует частичный хедж или де-хедж;
redeem_queue_job — планирует unwind под запросы на вывод;
venue_exposure_job — следит за концентрацией на одной площадке;
oracle_sanity_job — ловит price divergence и stale data;
stress_mode_job — переводит стратегию в ограниченный режим при bad-state;
alert_job — шлёт сигналы в Telegram/Slack по margin, funding и emergency событиям.

UI для демо

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

overview vault: TVL, NAV, net APY, reserve;
breakdown доходности: funding, staking, realised PnL, fees;
состояние hedge: target ratio, actual ratio, venue, margin buffer;
deposit/redeem queue;
risk dashboard с алертами и лимитами;
history rebalance/unwind событий;
admin panel для pause, cap и emergency close.

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

Именно здесь automation layer не «добавка для красоты», а основа выживаемости стратегии.

1. Hedge maintenance

Автоматизация должна уметь:

поддерживать target hedge ratio;
частично ребалансировать позицию;
переключать стратегию в manual mode при нестабильном рынке;
не открывать новый hedge при плохой ликвидности.

2. Margin defense

Система может автоматически:

пополнять margin account из reserve;
снижать размер позиции;
временно закрывать mint;
эскалировать оператору при приближении к liquidation threshold.

3. Funding regime control

Если funding перестал быть источником дохода, automation layer должен это заметить раньше, чем пользователь увидит развалившийся APY.

Нужно уметь:

считать rolling funding yield;
сравнивать его с порогами;
снижать TVL cap;
выключать стратегию при устойчиво плохом carry.

4. Redemption orchestration

Автоматизация нужна и на выходе:

агрегировать redeem requests;
планировать unwind батчами;
минимизировать рыночное воздействие;
удерживать честный NAV на момент исполнения.

5. Venue risk controls

Если площадка деградирует, нужна быстрая реакция:

freeze new exposure;
лимит на перевод collateral;
forced de-risking;
перенос hedge на резервную площадку.

6. Reporting and investor transparency

Для treasury и LP-пользователей ценность automation ещё и в отчётности:

ежедневный PnL breakdown;
доля дохода из funding vs staking;
текущая концентрация по площадкам;
reserve coverage;
события риска и ручные override-ы.

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

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

Vault service — ведёт доли, NAV, депозиты и выводы.
Execution adapter — работает с perp venue и исполняет hedge-операции.
Risk engine — считает margin, exposure, slippage и stop conditions.
Funding analytics service — анализирует carry regime и net strategy yield.
Rebalance orchestrator — запускает hedge maintenance и unwind workflows.
Oracle service — валидирует цены и marks из нескольких источников.
Policy engine — применяет лимиты, pause, degraded mode и emergency logic.
Alerting layer — отправляет Telegram/Slack-сигналы по margin, funding и venue anomalies.
Operator dashboard — показывает доход, риск, историю ребалансов и ручные действия.

Для продуктовой команды ценность здесь простая: delta-neutral стратегия перестаёт быть «чёрной магией трейдера» и становится воспроизводимым сервисом с нормальными лимитами, алертами и управляемым lifecycle.

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

Даже без запуска большого consumer stablecoin такой MVP полезен как:

demo для synthetic dollar протокола;
sandbox для DAO treasury, которая хочет market-neutral cash management;
инфраструктурный слой для yield product с прозрачным NAV;
внутренний risk engine prototype для команды, которая тестирует hedged carry strategies;
операторский control plane вокруг basis/funding стратегии.

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

Delta-neutral и synthetic dollar-протоколы в DeFi — это не «безрисковый доллар на блокчейне», а упаковка вокруг хеджированной стратегии, где основной challenge лежит в margin discipline, funding regime и операционном контроле.

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

протокол собирает long-ногу и встречный short-hedge;
доход приходит не из направления рынка, а из funding, staking, basis и fees;
главные риски лежат в margin, basis, venue reliability, funding regime shift и redemption orchestration;
MVP должен доказывать корректный lifecycle hedge-стратегии, а не только красивый mint/redeem UX;
automation layer нужен вокруг ребалансировки, margin defense, лимитов, отчётности и emergency procedures.

Именно поэтому этот класс протоколов так интересен с инженерной точки зрения: он заставляет думать не только о смарт-контрактах, но и о том, как превратить рыночную стратегию в устойчивый продукт с понятной архитектурой, наблюдаемостью и дисциплиной исполнения.