Как работают overcollateralized stablecoins в DeFi простыми словами: CDP, peg и automation layer вокруг залога

Когда про DeFi-стейблкоины говорят слишком упрощённо, всё часто звучит так: «положил крипту в залог, выпустил стейбл и пошёл дальше».

Для первого знакомства этого хватает. Для реальной работы — нет.

Потому что overcollateralized stablecoin — это не просто токен с курсом около доллара. Это система, в которой одновременно живут:

  • залог;
  • долг;
  • правила эмиссии;
  • механизм ликвидации;
  • контур поддержания peg;
  • набор ботов, keepers и risk-процедур вокруг всего этого.

Если убрать лишний жаргон, CDP-модель — это способ создать цифровой доллар под избыточное onchain-обеспечение. Пользователь не покупает новый актив у эмитента, а сам открывает долговую позицию под свой collateral.

Для бизнеса и продуктовых команд это интересно не только как финансовый примитив. Вокруг CDP быстро появляется прикладная инженерная работа:

  • мониторинг качества залога;
  • автоматическое пополнение позиции;
  • алерты по риску depeg;
  • policy-driven minting и burning;
  • treasury automation;
  • execution layer для экстренных действий.

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

Ниже — разбор простыми словами: как работает CDP, кто с кем взаимодействует, почему peg не держится «сам по себе», где здесь главный риск и какой automation layer имеет смысл строить вокруг таких протоколов.

Что такое CDP простыми словами

CDP — это collateralized debt position, то есть позиция, где пользователь:

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

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

Например:

  • пользователь кладёт ETH;
  • протокол разрешает выпустить против него часть долларового эквивалента;
  • пользователь получает стейблкоин;
  • пока залог остаётся достаточным, позиция живёт;
  • если залога становится недостаточно, позицию можно ликвидировать.

Ключевой момент здесь в слове overcollateralized. Система специально требует залога больше, чем размер выпущенного долга.

Иначе говоря, чтобы выпустить условные 1 000 единиц stablecoin, обычно нужно держать залог заметно дороже 1 000 долларов, а не ровно на эту сумму.

Почему стейблкоин выпускают не “под доллар”, а под риск

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

В CDP-модели это не так.

Peg держится за счёт сочетания нескольких вещей:

  • избыточного залога;
  • ограничений на объём выпуска;
  • стоимости заимствования;
  • возможности погасить долг и закрыть позицию;
  • ликвидаций, если позиция становится слишком слабой;
  • рыночного арбитража, если цена токена отклоняется от целевого уровня.

То есть стабильность курса — это не кнопка, а результат работы сразу нескольких механизмов.

Кто участвует в системе

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

1. Пользователь-заёмщик

Он приносит collateral и выпускает stablecoin.

Его мотивация обычно одна из трёх:

  • получить ликвидность, не продавая базовый актив;
  • использовать выпущенный стейбл дальше в DeFi;
  • управлять treasury, сохраняя long-экспозицию на collateral.

2. CDP-протокол

Протокол хранит правила:

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

3. Oracle

Без oracle протокол не понимает, сколько на самом деле стоит залог.

Именно oracle приносит цену, по которой считается:

  • достаточно ли обеспечения;
  • сколько ещё можно mint;
  • пора ли запускать liquidation flow.

4. Ликвидаторы или keeper-сеть

Это внешние исполнители, которые следят за unsafe-позициями и запускают ликвидацию, когда обеспечение уходит ниже допустимого уровня.

5. Вторичный рынок и арбитражёры

Stablecoin живёт не только внутри протокола. Он торгуется на DEX, попадает в пулы ликвидности, используется в лендинге и расчётах.

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

Что происходит, когда пользователь mint’ит stablecoin

Механика обычно выглядит так.

Шаг 1. Депозит залога

Пользователь вносит актив: например ETH, wstETH, BTC-wrapper или другой collateral, одобренный протоколом.

Шаг 2. Оценка залога

Oracle сообщает цену, а протокол считает текущую стоимость позиции и максимальный допустимый объём долга.

Шаг 3. Выпуск долга

Пользователь mint’ит stablecoin в пределах допустимого лимита.

В этот момент он не “получает бесплатные деньги”, а создаёт долг под свой collateral.

Шаг 4. Использование выпущенного стейбла

Дальше возможны разные сценарии:

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

Шаг 5. Погашение и возврат залога

Чтобы закрыть позицию, нужно вернуть выпущенный stablecoin и заплатить накопившуюся комиссию, если она предусмотрена моделью.

После этого collateral разблокируется.

Откуда берётся ограничение на выпуск

Самый важный вопрос в CDP — не «можно ли выпустить токен», а «сколько именно можно выпустить без немедленного самообмана».

Для этого используется collateral ratio.

Если протокол требует, например, 150% обеспечения, это означает:

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

Чем волатильнее актив, тем строже обычно требования:

  • выше минимальный collateral ratio;
  • ниже допустимый debt ceiling;
  • агрессивнее liquidation threshold;
  • осторожнее риск-параметры.

Почему peg может держаться около 1 доллара

Здесь полезно думать не о магии, а о стимулах.

Когда stablecoin торгуется выше $1

Если рыночная цена токена выше целевого уровня, участникам становится выгодно:

  • открыть CDP;
  • выпустить новый stablecoin;
  • продать его на рынке дороже целевой цены.

Это увеличивает предложение и давит цену вниз.

Когда stablecoin торгуется ниже $1

Если токен торгуется дешевле доллара, может быть выгодно:

  • купить его на рынке со скидкой;
  • погасить свой долг;
  • освободить collateral по более привлекательной эффективной цене.

Это уменьшает предложение в обращении и может подтягивать цену вверх.

Но важно понимать: арбитраж работает, только если участники верят, что система платежеспособна, ликвидна и корректно обрабатывает risk events.

Почему peg — это не просто график цены

У CDP-системы есть минимум четыре разных слоя риска.

1. Риск залога

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

2. Oracle risk

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

3. Liquidity risk

Даже если формально ликвидация разрешена, в реальности нужно ещё суметь продать залог или профинансировать закрытие позиции.

4. Governance / parameter risk

Слишком мягкие лимиты на выпуск, плохой выбор collateral и слишком оптимистичные debt ceilings часто ломают систему медленнее, но не менее опасно.

Поэтому нормальная поддержка peg — это всегда комбинация protocol design и внешней операционной дисциплины.

Как работает liquidation flow

Когда обеспечение становится слишком слабым, протокол разрешает внешнему исполнителю закрыть часть или весь долг позиции.

Упрощённо процесс выглядит так:

  1. oracle обновляет цену;
  2. health-показатель позиции опускается ниже порога;
  3. liquidator находит эту позицию;
  4. он гасит часть долга;
  5. взамен получает часть collateral с дисконтом или бонусом;
  6. позиция либо оздоравливается, либо закрывается полностью.

Смысл ликвидации — не наказать пользователя, а не дать системе остаться с недообеспеченным долгом.

На практике именно здесь особенно важна автоматизация:

  • быстрый мониторинг;
  • надёжный execution;
  • fallback-маршруты для продажи collateral;
  • лимиты на gas;
  • алерты при массовом росте ликвидаций.

Где automation layer нужен не “потом”, а сразу

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

Для CDP это плохая идея, потому что риск живёт не только inside smart contract, но и между системами.

1. Мониторинг позиций и health-метрик

Если у бизнеса есть treasury, которая mint’ит stablecoin под collateral, нужны:

  • расчёт safe operating band;
  • прогноз расстояния до liquidation threshold;
  • алерты по волатильности залога;
  • отдельные триггеры по oracle latency и liquidity depth.

2. Auto-top-up и deleveraging

Когда рынок движется быстро, полезно иметь автоматические сценарии:

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

Но такие действия нельзя отдавать “просто боту” без ограничений. Нужны лимиты, allowlists, staged approvals и журнал решений.

3. Treasury ops вокруг mint / burn

Для компании, фонда или DeFi-продукта важны не только onchain-действия, но и операционная дисциплина:

  • кто имеет право выпускать новый stablecoin;
  • при каких условиях разрешён burn;
  • как считается суммарная экспозиция;
  • где проходит дневной лимит на выпуск;
  • что делать при отклонении peg или проблеме с collateral.

4. Incident workflow

Если начинается stress event, полезен не просто alert, а заранее описанный workflow:

  • кто получает сигнал;
  • кто может подписать экстренное действие;
  • какой сценарий запускается первым;
  • когда автоматика стопается и эскалирует человеку.

Именно это превращает DeFi-интеграцию из “смарт-контракт подключили” в управляемую финансовую инфраструктуру.

Практический блок: что именно обычно нужно бизнесу

Проблема

Компания или продукт использует DeFi не ради теории, а ради конкретной задачи:

  • держать часть treasury в onchain-активах;
  • получать ликвидность без продажи базового актива;
  • выпускать внутренний liquidity buffer под collateral;
  • автоматизировать перераспределение капитала между протоколами.

Но как только появляется CDP, сразу появляются и вопросы:

  • сколько можно безопасно mint’ить;
  • кто контролирует risk band;
  • как не пропустить приближение ликвидации;
  • кто и как запускает экстренное погашение;
  • как не дать автоматике превысить полномочия.

Архитектурный паттерн

Практически обычно работает такой слой:

  1. Position monitor — сервис, который считает collateral ratio, расстояние до liquidation threshold, peg deviation и качество oracle updates.
  2. Policy engine — хранит лимиты по активам, протоколам, кошелькам, времени суток, объёму одной операции и режимам emergency execution.
  3. Execution worker — делает mint, burn, repay, top-up, hedge или swap только после policy-check.
  4. Approval layer — включает человека в цепочку, если операция выходит за нормальный коридор риска.
  5. Audit / reconciliation layer — сверяет, что планировалось сделать, что реально было отправлено onchain и к какому балансовому результату это привело.

Что можно дать как service / implementation layer

Если делать это прикладно, а не академически, вокруг CDP-протоколов можно собрать полезный сервисный слой:

  • dashboard по риску залога и debt utilisation;
  • алерты по приближению к liquidation band;
  • policy-driven treasury wallet automation;
  • автоматический top-up / partial repay с лимитами;
  • safe execution для mint/burn с multi-step approval;
  • incident runbooks и emergency controls;
  • журнал решений для finance, ops и compliance-команд.

Это полезно не только фондам. Такой слой нужен и криптопродуктам, которые держат onchain-ликвидность, и командам, которые хотят строить сервис поверх DeFi без ручного контроля каждой транзакции.

Где чаще всего ошибаются команды

Ошибка 1. Считать collateral ratio статической цифрой

На практике важна не цифра из документации, а рабочий коридор с запасом под волатильность, проскальзывание и задержку реакции.

Ошибка 2. Полагаться только на one-shot alerts

Один Telegram-алерт при падении health-метрики не спасает позицию сам по себе. Нужны сценарии действий, права и исполнители.

Ошибка 3. Давать боту слишком широкий доступ

Если бот умеет и top-up, и withdraw, и arbitrary swap без ограничений — это уже не автоматизация, а новый источник операционного риска.

Ошибка 4. Игнорировать риск ликвидности во время стресса

Даже хороший collateral не гарантирует хорошее исполнение, если на рынке тонкая ликвидность, высокий gas и все делают одно и то же одновременно.

Как на это смотреть трезво

Overcollateralized stablecoin — это не “безопасный цифровой доллар по умолчанию”.

Это инженерно-финансовая система, где стабильность возникает из:

  • качества collateral;
  • корректности risk-параметров;
  • скорости ликвидаций;
  • работы oracle;
  • ликвидности вторичного рынка;
  • внешнего automation layer, который следит за позицией и умеет действовать в рамках политики.

Именно поэтому самые полезные DeFi-интеграции сегодня выглядят не как одиночный смарт-контракт-вызов, а как контрольный слой вокруг капитала: с мониторингом, лимитами, approval flow, execution workers и понятным emergency mode.

Если вам нужен такой слой вокруг CDP, stablecoin, treasury automation или risk-driven wallet workflows, Sassoft может помочь спроектировать и реализовать его так, чтобы это было удобно не только разработчикам, но и людям, которые реально отвечают за деньги.