В обзорах DeFi lending почти всегда останавливаются на красивой точке: «если health factor упал — позицию ликвидируют, и протокол снова безопасен».
На практике это не всегда так.
Иногда цена падает слишком быстро. Иногда oracle запаздывает. Иногда в market нет ликвидности, чтобы продать collateral без огромного slippage. Иногда ликвидаторам просто невыгодно приходить. Иногда сразу много позиций становятся unsafe в одном блоке.
И вот тогда появляется то, о чём в UI обычно молчат до самого конца:
bad debt — долг, который уже не покрыт залогом, но формально всё ещё висит в системе.
А рядом с ним — второй неприятный вопрос: кто за этот долг платит?
Именно здесь появляется socialized loss: убыток, который протокол распределяет не на одного заёмщика, а на более широкий круг участников — поставщиков ликвидности, держателей safety module, treasury или весь market.
Для бизнеса и treasury-команд тема важна не как академический edge case. Bad debt — это момент, когда:
- receipt token перестаёт быть «почти 1:1» к underlying;
- withdraw начинает упираться в дыру в балансе;
- APY на экране перестаёт объяснять реальный риск;
- нужна не кнопка Supply, а ops playbook.
Ниже — разбор без лишнего жаргона: как образуется bad debt, почему ликвидации иногда не успевают, как устроены модели покрытия убытка, где прячется risk для LP и какой automation layer имеет смысл строить вокруг deficit accounting.
Что такое bad debt простыми словами
Bad debt — это задолженность заёмщика, которую протокол уже не может полностью закрыть за счёт его collateral.
Упрощённо:
- у позиции был залог и долг;
- цена залога упала;
- liquidation должна была сработать;
- после всех попыток закрыть позицию collateral недостаточно, чтобы покрыть remaining debt;
- в системе остаётся «дыра».
Бытовая аналогия — не «штраф заёмщику», а непокрытый остаток после принудительной продажи залога.
Если банк продал квартиру, а выручки не хватило на ипотеку, разница и есть bad debt. В DeFi похожая математика, только вместо банка — пул поставщиков ликвидности и правила протокола.
Bad debt ≠ liquidation
Это важно разделить.
- Liquidation — процесс закрытия рискованной позиции.
- Bad debt — результат, при котором процесс не покрыл долг целиком.
Ликвидация может пройти успешно и не создать bad debt. Bad debt появляется, когда защитная механика уже не успела или не смогла.
Как обычно выглядит путь к bad debt
Типичный сценарий почти всегда многослойный.
Шаг 1. Позиция становится хрупкой
Health factor падает к порогу ликвидации.
Пока есть запас по collateral и рынок спокойный, система ещё выглядит управляемой.
Шаг 2. Стресс-событие
Дальше происходит одно или несколько событий сразу:
- резкий dump collateral;
- oracle lag / bad price update;
- network congestion и дорогой gas;
- liquidity crunch в DEX;
- cascade liquidations;
- pause / degraded mode у протокола или oracle.
Шаг 3. Liquidation не закрывает дыру
Liquidator приходит, погашает часть долга, забирает collateral — но:
- цена уже ушла ниже безопасного уровня;
- bonus не компенсирует market impact;
- remaining debt остаётся без покрытия.
Шаг 4. Deficit появляется в accounting
На уровне market ledger появляется разрыв:
- total debt claims больше, чем recoverable assets;
- или конкретный account имеет отрицательный net equity;
- или protocol-level reserve уже не покрывает shortfall.
Именно этот разрыв и есть объект ops-мониторинга.
Почему ликвидации иногда не спасают
В нормальном режиме liquidation — хороший safety valve. В стрессе у него есть слепые зоны.
1. Скорость рынка выше скорости keepers
Если цена падает на десятки процентов за минуты, даже быстрый liquidation bot может прийти уже к underwater позиции.
2. Oracle не совпадает с executable price
Протокол может считать collateral по oracle price, а продать его на рынке получится только хуже.
Тогда liquidation «по правилам» формально корректна, а по деньгам — нет.
3. Нет экономического стимула ликвидировать
Если:
- gas слишком высокий;
- bonus слишком маленький;
- collateral неликвиден;
- путь продажи ломается на slippage,
то keepers рационально не приходят. Позиция гниёт дальше.
4. Cascading liquidations
Много позиций ликвидируются одновременно → давление на рынок collateral → цена падает ещё сильнее → появляются новые unsafe positions.
Это уже не единичный fail, а системный feedback loop.
5. Illiquid or exotic collateral
Чем уже рынок актива, тем выше шанс, что liquidation bonus не покроет реальный exit cost.
Особенно это касается:
- long-tail tokens;
- LP positions;
- illiquid RWA wrappers;
- NFT collateral с плохим floor execution.
Кто платит, когда появляется дыра
Вот главный продуктовый и risk-вопрос: как протокол раскладывает убыток.
Разные дизайны отвечают по-разному.
1. Protocol reserves / insurance fund
Сначала убыток гасится из заранее накопленного резерва.
Откуда берётся резерв:
- часть interest margin;
- liquidation fees;
- treasury allocation;
- safety module contributions.
Плюс: LP и borrowers сначала не чувствуют прямого haircut.
Минус: резерв конечен. В большом событии его может не хватить.
2. Safety module / staked backstop
Участники стейкают governance или safety token и соглашаются быть первой линией поглощения убытка в обмен на rewards.
Логика:
- есть bad debt;
- протокол slashing’ит часть staked capital;
- дыра закрывается;
- stakers теряют часть principal.
Это уже явная socialized loss для отдельного класса участников.
3. Socialized loss на поставщиков ликвидности
Если резервов нет или их мало, shortfall может лечь на suppliers.
Практически это выглядит так:
- total assets market меньше, чем сумма claims;
- exchange rate receipt token падает;
- withdraw выдаёт меньше underlying на ту же share.
Пользователь думал, что держит «почти стейбл с доходом». На деле он держал claim на долю пула с residual credit risk.
4. Isolated market absorption
В isolated design убыток может остаться внутри одного market или одной risk bucket.
Это лучше для containment: проблема WETH-market не должна автоматически заразить все остальные markets.
Но для LP внутри этого market socialized loss всё равно реальна.
5. Bad debt hangs until governance acts
Иногда протокол просто фиксирует deficit и ждёт:
- treasury top-up;
- governance vote;
- emergency auction;
- debt auction / recapitalization.
Пока решение не принято, accounting может жить с «висящей дырой», а UX — с ограничениями на withdraw.
Socialized loss простыми словами
Socialized loss — это когда убыток от одной или нескольких неудачных позиций размазывают на более широкий набор участников по правилам протокола.
Не «виноват конкретный LP», а:
- система допустила непокрытый shortfall;
- правила заранее определяют, кто его разделяет;
- этот раздел может быть частичным, очередным или полным.
Почему это вообще делают
Потому что альтернатива ещё хуже:
- оставить протокол в состоянии, где claims не сходятся с активами;
- разрешить бесконечный «phantom withdraw»;
- или мгновенно обанкротить весь market без понятной процедуры.
Socialization — это не справедливость в бытовом смысле. Это механизм сохранения accounting consistency после хвостового события.
Как bad debt проявляется в token accounting
Здесь особенно полезно смотреть на слой receipt tokens и market ledger.
До события
- 1 receipt share ≈ понятный exchange rate к underlying;
- total supply claims согласованы с assets + healthy debt mechanics;
- withdraw работает в рамках available liquidity.
После bad debt
Могут произойти разные вещи в зависимости от дизайна:
- exchange rate receipt token падает;
- появляется отдельный deficit index;
- withdraw ограничивается сильнее, чем обычный utilization freeze;
- часть убытка закрывается из reserve, и rate почти не двигается;
- появляется mode, где новые suppliers входят уже в «очищенный» accounting, а старые несут historical shortfall.
Именно поэтому monitoring только health factor borrower’ов недостаточен. Нужно смотреть ещё и на market solvency.
Индикаторы, что система уже на пути к deficit
Практически полезный checklist для ops и treasury.
Market-level signals
- рост доли near-liquidation positions;
- падение available liquidity при высоком borrow demand;
- резкий рост utilization;
- увеличение estimated liquidation volume vs DEX depth;
- oracle deviation от executable CEX/DEX price;
- рост failed liquidation attempts.
Position-level signals
- позиции с очень низким HF и illiquid collateral;
- крупные whale accounts около порога;
- recursive leverage loops;
- collateral с плохим historical liquidation fill quality.
Execution-level signals
- liquidations revert из-за slippage;
- keepers перестают брать определённые markets;
- gas spike делает small liquidations невыгодными;
- auction / Dutch liquidation заполняется слишком медленно.
Если эти сигналы горят одновременно, bad debt уже не «теория», а вероятный operational scenario.
Где главные риски для разных ролей
Для supplier / LP
Главный риск — думать, что lending deposit = cash-like instrument.
На деле это:
- market risk через borrower quality and collateral mix;
- liquidity risk на withdraw;
- shortfall risk через socialized loss;
- governance risk вокруг того, как deficit будут закрывать.
Для borrower
Парадоксально, bad debt часто появляется уже после того, как borrower «потерял» свою позицию.
Но системный эффект всё равно важен: после крупного shortfall market может:
- ужесточить параметры;
- freeze listings;
- повысить rates;
- ограничить новые borrows.
Для protocol team
Риск не только финансовый, но и операционный:
- как быстро детектировать deficit;
- как коммуницировать его без паники;
- как выбрать порядок покрытия;
- как не допустить bank-run поверх уже повреждённого accounting.
Для treasury / fund integrating the protocol
Если вы держите aTokens / cTokens / vault shares как «yield sleeve», bad debt — это event, который должен сразу:
- пересчитать NAV;
- ограничить новый exposure;
- возможно, инициировать exit policy;
- эскалировать risk committee.
Что можно автоматизировать вокруг bad debt
Здесь automation особенно ценен, потому что событие редкое, быстрое и дорогое.
1. Solvency monitor
Не только HF пользователей, а market equation:
- assets;
- liabilities;
- reserves;
- estimated recoverable collateral under stress;
- deficit if any.
2. Liquidation quality tracker
Считать не «сколько ликвидаций произошло», а:
- success rate;
- average discount captured vs theoretical bonus;
- slippage on collateral dump;
- time-to-liquidation after HF breach;
- markets where keepers systematically skip.
3. Shortfall early-warning
Модель, которая говорит:
если oracle/executable gap и liquidation backlog такие, вероятность deficit в ближайшие N блоков растёт выше порога.
Это не идеальный predictor. Но для treasury ops уже полезный trigger.
4. Response playbooks
Когда deficit детектирован:
- freeze new deposits into affected market;
- alert risk owners;
- simulate reserve coverage;
- estimate socialized haircut scenarios;
- prepare governance/emergency checklist;
- ограничить downstream strategy, которая держит affected receipt tokens.
5. Post-event accounting reconciler
После покрытия shortfall нужно сверить:
- какой reserve сгорел;
- какой haircut получили LP / safety stakers;
- как изменился exchange rate;
- кто ещё остался underwater;
- можно ли снова открывать market в normal mode.
Как собрать MVP automation layer
Не нужно строить «ещё один lending protocol». Нужен bad debt control plane поверх существующего рынка.
Хорошая MVP-формулировка
Сервис, который для выбранного lending market считает solvency gap, quality ликвидаций и вероятный shortfall, а при ухудшении метрик запускает alerts и treasury response checklist.
Компоненты
1. Market state indexer
Собирает:
- total supply / borrow;
- reserves;
- utilization;
- oracle prices;
- top risky accounts;
- recent liquidation events.
2. Stress simulator
Для collateral set считает:
- что будет при -10% / -20% / -40% move;
- хватит ли DEX depth на expected liquidation volume;
- какой residual debt останется при realistic fill.
3. Deficit detector
Сравнивает:
- accounting assets vs claims;
- reserve buffer;
- unresolved underwater accounts after liquidation attempts.
4. Policy and alert layer
Примеры правил:
- если estimated shortfall > X% reserves → critical;
- если liquidation fail rate > Y% за час → high;
- если receipt exchange rate drop > Z bps → page risk owner;
- если market isolated — не эскалировать на весь portfolio без подтверждения.
5. Dashboard
Показывать:
- solvency status;
- reserve runway;
- liquidation backlog;
- socialized loss scenarios;
- affected receipt tokens / vault shares.
Практичный стек:
- Go для workers и API;
- PostgreSQL для market snapshots, liquidation history, alerts;
- Redis для realtime queues;
- price and depth adapters к oracle + DEX;
- Telegram/Slack/PagerDuty для escalation.
Частые ошибки
1. Считать, что «раз есть liquidation, bad debt невозможен»
Liquidation снижает вероятность shortfall. Она не обнуляет хвостовой риск.
2. Смотреть только на APY
APY не показывает:
- quality of collateral;
- liquidation executable depth;
- reserve adequacy;
- historical socialized loss events.
3. Игнорировать isolated vs cross-margin design
В cross-margin/account-based системах заражение шире. В isolated — localized, но для LP внутри bucket всё равно болезненно.
4. Путать pause с решением проблемы
Pause может остановить новые действия. Он сам по себе не закрывает уже возникший deficit.
5. Не готовить communication layer
Даже корректный механизм socialization без понятного ops communication выглядит как «протокол потерял деньги непонятно куда».
Как эта тема стыкуется с остальным lending-стеком
Bad debt — это продолжение уже разобранных механизмов:
- lending pools и health factor объясняют, когда позиция становится опасной;
- liquidations и keepers объясняют, кто пытается её закрыть;
- token accounting объясняет, как депозит и долг представлены в токенах;
- bad debt / socialized loss объясняет, что происходит, когда защитный контур не закрыл дыру.
Без этого последнего слоя картина lending неполная: остаётся только happy path.
Главное, что стоит запомнить
Bad debt в DeFi lending — это не редкая экзотика и не «ошибка UI». Это хвостовой режим системы, в котором:
- ликвидации не покрыли долг;
- в accounting появился shortfall;
- протокол должен решить, кто его абсорбирует;
- LP, safety stakers или treasury могут получить socialized loss;
- automation нужен не после пресс-релиза, а до того, как deficit стал сюрпризом.
Если упростить до сути:
- liquidation пытается не допустить дыру;
- bad debt — дыра уже есть;
- socialized loss — правила, по которым эту дыру раскладывают;
- automation layer — способ раньше увидеть риск, быстрее среагировать и честно посчитать последствия.
Пока рынок спокойный, можно жить на health factor alerts. Когда появляется реальный stress, ключевым активом становится solvency monitoring, liquidation quality tracking и заранее написанный response playbook.
Если нужен такой control plane — от deficit detector и stress simulation до treasury alerts и post-event reconciliation — можно обсудить архитектуру под ваш lending stack или интеграции: свяжитесь со мной.