Как работают undercollateralized lending-протоколы в DeFi простыми словами: private credit, credit lines и MVP с automation layer

У DeFi долгое время была одна жёсткая привычка: если хочешь занять, положи залога больше, чем берёшь в долг.

Это удобно для смарт-контрактов, потому что ликвидация считается формулой. Но для реального бизнеса такой мир слишком узкий. Маркетмейкеру, торговой фирме, фонду, стейблкоин-оператору или финтеху часто нужен не «ломбард с мгновенной ликвидацией», а нормальная кредитная линия: лимит, срок, стоимость капитала, отчётность, covenants и процедура работы с просрочкой.

Именно отсюда вырос отдельный класс DeFi-протоколов: undercollateralized lending, onchain private credit и credit line protocols. Их задача — дать капитал без полного ончейн-залога, но не превратить продукт в хаос. То есть вынести часть доверия, проверки и enforcement в более взрослую кредитную модель: borrower onboarding, offchain документы, лимиты, repayment schedule, covenant monitoring и ручной/полуавтоматический workout flow.

Сейчас эта тема особенно интересна не как «очередной APY narrative», а как инженерная задача на стыке DeFi, RWA и risk systems. На рынке всё больше внимания к прозрачности денежных потоков, управлению лимитами и понятной операционной дисциплине — это хорошо ложится на логику кредитных протоколов, где важна не только доходность, но и контроль над тем, кто, на каких условиях и почему вообще может брать деньги.

Ниже — практический разбор без рекламы: какие undercollateralized-модели уже есть на рынке, как они работают простыми словами, как двигаются деньги, где основные риски и как собрать похожий прототип или MVP с automation layer вокруг covenant checks, repayment ops и risk limits.

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

Если упростить до сути, undercollateralized lending в DeFi — это попытка выдать кредит не под мгновенно ликвидируемый ончейн-залог, а под:

репутацию или проверку заёмщика;
его offchain активы и контракты;
юридическую структуру сделки;
будущие денежные потоки;
ограниченный резервный залог плюс набор covenant-правил.

Это уже гораздо ближе к private credit и fintech credit lines, чем к классическим overcollateralized lending pools.

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

1. Pool-based private credit

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

Самые заметные примеры этого класса — Maple Finance, частично Clearpool, а также несколько institutional credit-платформ, которые используют ончейн-пулы как оболочку вокруг более традиционной кредитной сделки.

Идея простая:

LP дают ликвидность;
pool delegate или credit manager отбирает заёмщиков;
у каждого займа есть лимит, ставка, срок, график выплат;
инвесторы получают доход, если заёмщик обслуживает долг.

2. Credit lines для whitelisted borrowers

В этой модели у протокола не обязательно есть широкий permissionless рынок. Вместо этого он работает с ограниченным списком заёмщиков:

маркетмейкеры;
OTC desk;
stablecoin issuers;
fintech-компании;
DAO treasury vehicles.

Похоже на корпоративный кредитный лимит:

borrower проходит onboarding;
получает лимит;
выбирает объём в пределах лимита;
платит проценты на использованный капитал;
обязан соблюдать covenants и reporting.

3. Invoice / receivables / cash-flow backed credit

Здесь займ опирается не столько на «доброе слово» заёмщика, сколько на конкретный источник будущего cash flow:

инвойсы;
подписанные контракты;
merchant receivables;
revenue-based repayment;
tokenized real-world collateral.

Это уже мост между DeFi и RWA/private credit. Onchain-часть отвечает за выпуск долей, учёт и выплаты, а offchain-часть — за юридическое право требования и работу с дефолтом.

4. Hybrid-модель с частичным залогом и covenants

Иногда протокол не идёт в полностью unsecured-кредит. Он оставляет:

небольшой залог;
reserve account;
first-loss tranche;
lender protections через covenants и manual approval.

Это часто самый практичный путь для MVP и раннего продакшна: не пытаться «магически» заменить кредитный риск кодом, а честно комбинировать частичный collateral, мониторинг и операционный контроль.

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

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

В обычном DeFi lending всё держится на простом правиле: если value залога падает ниже порога, позицию ликвидируют. В undercollateralized-модели так не получится, потому что полного ликвидного залога может не быть вообще.

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

кто именно может брать деньги;
какой ему дают лимит;
как часто он отчитывается;
какие есть covenants;
что будет, если метрики ухудшились;
как запускается collection / workout / legal enforcement.

Пример 1. Кредитная линия маркетмейкеру

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

У него есть:

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

Протокол после onboarding даёт ему credit line:

лимит: 5 млн USDC;
базовая ставка: 9% годовых;
utilisation fee на выбранную сумму;
срок review: 30 дней;
covenants: минимальный equity buffer, отчётность раз в неделю, лимит drawdown, лимит концентрации по биржам.

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

Пример 2. Private credit под будущие поступления

Другой кейс — финтех с повторяющимися merchant receivables.

Он хочет:

заранее получать ликвидность;
закрывать разрыв между расходами и будущими платежами;
не продавать весь бизнес-апсайд за equity.

Протокол или pool manager оценивает:

качество receivables;
исторический default rate;
концентрацию клиентов;
legal structure по праву требования;
haircut по ожидаемому cash flow.

После этого открывается займ или revolving facility, а repayment идёт из фактических поступлений.

Что происходит с точки зрения LP

Для поставщика ликвидности это уже не «нейтральный money market», а кредитный продукт.

LP фактически принимает несколько типов риска:

borrower default risk;
servicing/collection risk;
legal enforcement risk;
pool manager / delegate risk;
transparency risk, если данных недостаточно.

Именно поэтому у undercollateralized lending почти всегда выше требование к отчётности и governance, чем у обычного overcollateralized lending pool.

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

1. Delegate-managed pools

Пулом управляет делегат или кредитный менеджер.

Плюсы:

проще централизовать due diligence;
можно быстро принимать решения по лимитам;
удобно для институциональных сделок.

Минусы:

сильная зависимость от качества делегата;
риск конфликта интересов;
меньше permissionless-свойств.

2. Committee / approval-based credit

Здесь выдача крупного лимита требует approval от нескольких ролей:

risk officer;
legal reviewer;
treasury signer;
иногда DAO vote или multisig.

Плюсы:

лучше контроль;
меньше шанс выдать опасный займ «на авось».

Минусы:

медленнее процесс;
выше операционные издержки.

3. Tokenized credit funds

Протокол может выпускать onchain shares фонда, а внутри уже держать набор кредитных экспозиций.

Плюсы:

удобнее для инвестора;
можно диверсифицировать заёмщиков;
легче строить NAV-логику и waterfall.

Минусы:

меньше прозрачности по каждому отдельному займу;
появляется fund-layer risk.

4. Revolving credit lines

Наиболее прикладной формат для бизнеса.

Borrower получает лимит и выбирает средства частями, а repayment снова освобождает лимит.

Плюсы:

естественно для операционного финансирования;
удобно считать utilisation;
хорошо ложится на регулярные cash-flow циклы.

Минусы:

нужен сильный monitoring;
легко недооценить intra-period risk.

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

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

LP или treasury вносят ликвидность в пул.
Протокол или delegate распределяет доступный капитал по approved borrowers.
Borrower получает лимит, а затем делает drawdown на нужную сумму.
Средства уходят на его операционный адрес или settlement wallet.
Borrower платит проценты, комиссии и погашает principal по графику или по demand-note логике.
Протокол распределяет доход LP, часть удерживает в reserve / first-loss / fee bucket.
Если borrower нарушает covenants, drawdowns блокируются, ставка может расти, а позиция переводится в watchlist или workout mode.

Важное отличие от классического lending pool

В обычном DeFi деньги «контролируются» ценой залога и ликвидацией. Здесь — документами, лимитами, monitoring и процедурой эскалации.

То есть основной вопрос уже не «успеем ли мы ликвидировать?», а:

правильно ли выдали лимит;
не сломался ли borrower profile;
не скрывает ли он ухудшение cash flow;
есть ли у нас механизм остановить новые выдачи и начать collection.

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

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

1. Borrower Registry

Реестр заёмщиков со статусами:

pending review;
approved;
suspended;
watchlist;
defaulted;
closed.

Тут же хранятся:

KYC/KYB reference;
legal entity metadata;
linked wallets;
reporting cadence;
risk tier.

2. Credit Line Manager

Контракт или набор контрактов, которые управляют:

credit limit;
available-to-draw amount;
APR / spread;
utilisation fee;
maturity / renewal date;
grace period;
penalty logic.

3. Drawdown & Repayment Engine

Этот слой проводит реальные движения денег:

drawdown;
partial repayment;
full repayment;
interest accrual;
penalty accrual;
reserve contribution.

4. Covenant / Policy Engine

Здесь живут правила, по которым оценивается состояние займа:

max leverage;
min liquidity buffer;
min reserve ratio;
reporting freshness;
concentration limits;
max overdue days;
restricted counterparties.

Часть правил может проверяться onchain, часть — через offchain attestations или oracle-updates.

5. Accounting & Waterfall Layer

Для LP и treasury важно понимать:

accrued interest;
realised losses;
unpaid interest;
fee split;
reserve balance;
first-loss absorption;
NAV по пулу.

6. Collections / Workout Module

Самый недооценённый слой. Протокол должен уметь не только выдавать займы, но и жить с проблемными кейсами:

freeze new drawdowns;
move loan to workout;
calculate penalties;
record restructuring terms;
route case to legal or servicing team.

7. Oracle / Attestation Layer

Такой протокол почти всегда использует внешние данные:

финансовые отчёты;
broker statements;
reserve account balances;
receivables aging;
NAV snapshots;
compliance attestations.

Важно не делать вид, что эти данные «волшебно trustless». Лучше честно показывать источник, время обновления и кто их подписал.

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

1. Default risk

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

Borrower может:

потерять ликвидность;
скрыть ухудшение бизнеса;
попасть под рыночный шок;
нарушить covenants;
просто не вернуть деньги.

2. Delegate / underwriting risk

Если протокол полагается на pool manager или delegate, то именно качество андеррайтинга определяет результат сильнее, чем дизайн токена.

Плохой отбор заёмщиков быстро превращает красивый ончейн-интерфейс в коробку с просроченными долгами.

3. Data quality risk

Многое зависит от offchain данных.

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

4. Legal enforceability risk

Очень важно понимать, что стоит за дефолтом:

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

5. Liquidity mismatch risk

LP часто хотят «почти депозит», а private credit по природе своей неликвиден.

Если протокол обещает лёгкий exit, но активы внутри длинные и слабо ликвидные, можно получить неприятный конфликт между redemption UX и реальной структурой портфеля.

6. Governance capture risk

Если лимиты, approvals и waivers можно слишком легко менять через админку или multisig, инвестор получает не кредитный продукт, а чёрный ящик с непрозрачными override-ами.

7. Concentration risk

Даже хороший заёмщик становится плохой идеей, если он занимает слишком большую долю пула. Для MVP это особенно опасно: ранние продукты часто стартуют с 1–3 borrowers, и без лимитов это мгновенно превращается в concentration trap.

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

Если цель — показать механику, не надо сразу строить fully regulated private credit platform с десятками структур.

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

можно создать borrower profile и пройти approval flow;
можно открыть кредитную линию с лимитом, ставкой и сроком review;
borrower может сделать drawdown только в разрешённых пределах;
проценты и штрафы считаются корректно;
covenants можно обновлять и проверять;
просрочка переводит займ в watchlist / suspended / default workflow;
automation layer умеет мониторить отчётность, лимиты и repayment discipline.

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

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

одна сеть, например Base или Ethereum L2;
один пул в USDC;
3–5 whitelisted borrowers;
ручной approval через multisig или admin UI;
один тип продукта: revolving credit line;
offchain reporting через подписанные snapshots;
простой reserve bucket и penalty logic.

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

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

1. BorrowerRegistry

Хранит:

borrowerId;
linked wallet addresses;
status;
risk tier;
reporting cadence;
metadata hash на offchain документы.

Функции:

add borrower;
approve / suspend / default borrower;
rotate wallets;
update attestation references.

2. CreditLineFactory

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

pool;
borrower;
credit limit;
APR;
penalty APR;
review date;
grace period;
covenant set.

3. LoanAccount / CreditLine

Основной контракт конкретной линии.

Функции:

drawdown;
repay interest;
repay principal;
compute accrued interest;
mark past due;
freeze draws;
close account.

4. PoolVault

Принимает средства LP и ведёт базовый учёт:

total liquidity;
drawn liquidity;
reserve allocation;
realised loss bucket;
claimable yield for LP.

5. CovenantEngine

Проверяет правила и статусы:

stale reporting;
reserve threshold breaches;
max exposure breaches;
manual covenant exceptions;
watchlist triggers.

6. WorkoutController

Нужен даже в MVP, пусть и упрощённый.

Функции:

enter workout mode;
stop new drawdowns;
apply penalty spread;
record restructuring note;
mark recovered / defaulted amount.

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

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

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

borrowers
credit_lines
drawdowns
repayments
interest_accruals
reporting_snapshots
covenant_events
watchlist_events
defaults
recoveries
lp_positions
alerts

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

Postgres;
indexer на Go или TypeScript;
job-runner для accrual, covenant checks и отчётности;
admin dashboard для risk team;
borrower portal для upload/signing отчётов.

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

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

interest_accrual_job — регулярно пересчитывает проценты и penalty accrual;
reporting_freshness_job — следит, не устарели ли borrower snapshots;
covenant_check_job — проверяет лимиты, концентрации и threshold breaches;
payment_due_job — отслеживает ближайшие даты выплат;
watchlist_transition_job — переводит линию в watchlist при нарушениях;
drawdown_guard_job — отключает новые выборки при bad-state;
nav_reconciliation_job — сверяет onchain balances, reserve и offchain repayment ledger;
collection_queue_job — собирает проблемные кейсы для servicing / legal workflow;
alert_job — шлёт сигналы по overdue, stale data и concentration spikes.

Как упростить MVP честно

Главная ошибка — пытаться сделать вид, что undercollateralized credit можно полностью автоматизировать одной формулой.

Для demo лучше честно ограничить объём автоматизации:

borrower approval — вручную;
документы и KYC — offchain;
covenants — часть автоматические, часть operator-reviewed;
default resolution — через workout workflow, а не «мгновенную liquidation»;
NAV — на основе прозрачных snapshot-правил с датой и подписью.

Такой продукт выглядит менее «магическим», зато намного правдоподобнее.

UI для демо

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

список borrowers и их risk tiers;
обзор пула: liquidity, drawn, reserve, utilisation;
карточка кредитной линии с лимитом и APR;
история drawdowns и repayments;
covenant status и reporting freshness;
watchlist / workout queue;
LP dashboard с realised/unrealised PnL и reserve coverage;
admin panel для approvals, freezes и лимитов.

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

Именно здесь automation layer даёт реальную ценность. В undercollateralized lending automation нужен не для красивого «AI поверх DeFi», а для дисциплины вокруг кредитного процесса.

1. Borrower monitoring

Automation layer может:

проверять свежесть отчётности;
подтягивать reserve account snapshots;
сравнивать фактические метрики с covenant thresholds;
поднимать риск-скоринг при ухудшении профиля.

2. Drawdown controls

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

блокировать новые drawdowns при stale reporting;
снижать доступный лимит при росте концентрации;
включать manual approval для atypical requests;
применять time-based hold на крупные выборки.

3. Payment operations

Automation полезен для:

напоминаний о платежах;
расчёта due interest;
отслеживания partial repayment;
фиксации overdue и включения penalty APR.

4. Reserve and first-loss management

Если у продукта есть reserve bucket или first-loss tranche, automation может:

контролировать минимальный buffer;
переводить часть fee в reserve;
эскалировать depletion risk;
ограничивать новые выдачи при плохом reserve coverage.

5. Portfolio concentration control

На уровне пула automation должен уметь:

считать долю каждого borrower;
лимитировать отраслевые или counterparty-кластеры;
предупреждать о correlation risk;
рекомендовать freeze на новые выдачи в слишком похожие профили.

6. Workout orchestration

Когда позиция портится, автоматизация особенно важна.

Нужно уметь:

автоматически перевести займ в watchlist;
остановить выборки;
создать case в collection queue;
уведомить risk team;
зафиксировать timeline и операторские действия.

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

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

Borrower service — хранит профили, linked wallets и статусы.
Credit engine — считает лимиты, проценты, grace periods и penalties.
Covenant monitor — проверяет отчётность, резервы, leverage и концентрации.
Attestation service — публикует подписанные offchain snapshots и reference hashes.
Collection orchestrator — ведёт watchlist, workout и recovery pipeline.
Accounting service — считает NAV, reserve coverage, realised losses и LP yield.
Policy engine — управляет approvals, freezes, overrides и escalation rules.
Alerting layer — отправляет Telegram/Slack-сигналы по overdue, stale data и лимитам.
Operator dashboard — показывает состояние пула, borrowers, covenants и проблемные кейсы.

Для продуктовой команды ценность здесь простая: credit protocol перестаёт быть набором ручных таблиц и становится control plane для лимитов, выплат и risk governance.

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

Даже без полноценного большого private credit фонда такой MVP полезен как:

demo для onchain credit line platform под whitelisted business borrowers;
sandbox для DAO treasury, которая хочет выдавать ограниченные займы партнёрам;
инфраструктурный слой для fintech credit facility с прозрачным onchain accounting;
модель для RWA/private credit продукта с investor-facing dashboard;
внутренний risk engine prototype для команды, которая хочет проверить workflows до запуска более сложной юридической структуры.

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

Undercollateralized lending в DeFi — это не «DeFi без риска», а кредитный продукт, где риск управляется не только залогом, а процессом, лимитами и наблюдаемостью.

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

капитал выдаётся approved borrowers без полного ликвидного залога;
ключевыми становятся onboarding, лимиты, covenants, repayment discipline и workout flow;
главные риски лежат в default, андеррайтинге, качестве данных, юридическом enforcement и концентрации;
MVP должен доказывать корректный lifecycle credit line, а не симулировать волшебную trustless-кредитную систему;
automation layer нужен вокруг monitoring, drawdown controls, payment ops, reserve management и collection workflows.

Именно поэтому undercollateralized lending — один из самых взрослых и сложных классов DeFi-протоколов. Он заставляет команду думать не только о смарт-контрактах, но и о том, как на практике управлять доверием, прозрачностью и кредитным риском вокруг onchain-капитала.