Как работают fixed-rate lending-протоколы в DeFi простыми словами: от maturity vaults и PT/YT до MVP с automation layer

У DeFi давно есть очевидная слабая точка: почти всё крутится вокруг плавающей ставки.

Сегодня lending pool даёт одну доходность, завтра другую. Сегодня borrow стоит приемлемо, через неделю utilisation улетает вверх — и вся экономика стратегии уже другая. Для активного трейдера это нормально. Для treasury, консервативного продукта или понятного savings-интерфейса — уже не очень.

Отсюда и вырос целый класс fixed-rate DeFi-протоколов. Их цель простая: дать пользователю более предсказуемый денежный поток и понятную дату расчёта. Не обещать «волшебную стабильность», а аккуратно упаковать будущую доходность или стоимость фондирования в отдельный onchain-инструмент.

Именно поэтому тема fixed-rate lending сейчас снова выглядит практичной. На рынке всё больше задач, где нужна не максимальная гибкость, а понятный срок, фиксируемая ставка, заранее видимый payoff и нормальная операционная модель вокруг maturity, rollover и risk checks. Плюс свежие обсуждения на Hacker News про очередной крупный DeFi exploit лишний раз напоминают: чем сложнее продукт, тем важнее объяснять, где именно лежит риск и как его не прятать под красивым APY.

Ниже — разбор без рекламы: какие fixed-rate модели есть на рынке, как простыми словами работают maturity vaults, principal tokens и yield tokens, как двигаются деньги, где находятся основные trade-offs и как собрать похожий прототип или MVP с automation layer вокруг учёта, settlement и лимитов.

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

Если упростить до сути, fixed-rate DeFi-протокол пытается решить одну из двух задач:

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

Это уже отличается от классического lending pool, где ставка обычно плавает вместе с utilisation и общим состоянием рынка.

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

1. Maturity-based рынки

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

Пользователь не просто «кладёт деньги под процент», а входит в инструмент со сроком:

до конца июня;
до конца квартала;
до определённого expiry.

Такие рынки в разных формах развивали Notional, Term Finance и похожие продукты. Ключевая идея одна: у займа или доходности есть срок жизни, а не бесконечный плавающий режим.

2. Yield stripping через PT/YT

Одна из самых интересных моделей последних циклов — разделение актива на:

PT (principal token) — право получить базовый актив в дату maturity;
YT (yield token) — право на доходность этого актива до даты maturity.

Эту механику популяризовали Pendle и похожие архитектуры вокруг tokenized yield. По сути, рынок начинает отдельно торговать телом актива и его будущей доходностью.

3. Fixed-rate borrow / fixed-income продукты поверх variable-rate рынков

Иногда протокол не строит всё с нуля, а упаковывает плавающую доходность или плавающий borrow в более предсказуемую структуру:

vault, который роллит позиции по срокам;
fixed-income слой поверх доходных базовых активов;
structured savings / treasury product для ончейн-доходности.

Для бизнеса это особенно интересно: можно дать пользователю понятный срок и предсказуемый payout, даже если под капотом часть риска всё равно живёт в variable-rate мире.

4. Treasury-linked fixed-yield DeFi

Ещё один угол — продукты, где fixed-rate логика используется для treasury management:

заранее зафиксировать доходность на свободный USDC;
отделить principal от доходности;
продать или захеджировать yield-exposure;
построить onchain-аналог short-duration fixed income.

Это уже мост между классическим DeFi lending и более «казначейским» thinking, близким к RWA- и treasury-практике.

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

Самая полезная стартовая мысль такая: fixed-rate DeFi не создаёт доходность из воздуха. Он просто перераспределяет будущий денежный поток между разными участниками.

Кому-то нужна предсказуемость. Кому-то нужен upside от плавающей доходности. Кому-то важно зафиксировать borrowing cost на срок. Протокол упаковывает эти интересы в торгуемый onchain-формат.

Пример 1. Фиксируем доходность по USDC

Представим, что на рынке есть актив, который сейчас приносит плавающую доходность, условно 8–12% годовых, но никому не обещает точное значение.

Один пользователь говорит:

мне не нужен весь upside;
я хочу просто зафиксировать понятную доходность до даты X.

Другой говорит:

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

Протокол может разделить эти интересы через PT/YT или похожую maturity-механику.

Principal Token простыми словами

PT можно представить так:

вы покупаете право получить 1 базовый актив в дату maturity;
если PT сейчас торгуется дешевле 1, разница и есть ваш implied fixed yield.

Пример:

1 PT на 1 USDC maturity через 6 месяцев стоит 0.96 USDC;
в дату maturity он погашается в 1 USDC;
ваша доходность заранее зафиксирована в цене входа.

То есть PT — это почти ончейн-аналог дисконта к номиналу.

Yield Token простыми словами

YT — это отдельное право на весь доход, который базовый актив принесёт до maturity.

Примерно так:

PT держит тело актива;
YT собирает весь будущий yield;
если доходность окажется высокой, YT выигрывает;
если доходность проседает, YT может оказаться слабым активом.

Именно поэтому PT больше нравится тем, кто хочет предсказуемость, а YT — тем, кто хочет directional view на yield.

Пример 2. Fixed-rate borrow

Логика на стороне заёмщика похожая.

Вместо плавающего borrow-rate пользователь хочет:

занять на 30/90/180 дней;
заранее понимать стоимость фондирования;
не зависеть от того, что utilisation внезапно вырос завтра.

В maturity-модели он фактически договаривается о цене денег на срок, а не на каждую минуту жизни позиции.

Для treasury и торговых стратегий это очень полезно: можно считать PnL и лимиты без постоянного страха, что funding economics съедет в самый неудобный момент.

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

1. Zero-coupon / discount-to-par модель

Это самый понятный формат.

Покупатель приобретает токен дешевле номинала, а в дату maturity получает полный номинал.

Плюсы:

легко объяснить;
прозрачно видно, где зафиксирован yield;
удобно для savings и treasury use-cases.

Минусы:

нужна хорошая secondary liquidity, если пользователь хочет выйти раньше срока;
цена до maturity зависит от рыночных ожиданий и ликвидности.

2. PT/YT split model

Это более гибкий и более «дефишный» подход.

Плюсы:

можно отдельно торговать principal и yield;
удобно строить стратегии на рост/падение будущей доходности;
появляется рынок implied yield.

Минусы:

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

3. Orderbook / auction-based maturity borrow markets

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

Плюсы:

лучше контролируется цена фондирования;
удобно для fixed-term кредитования;
можно работать крупными объёмами.

Минусы:

сложнее UX;
рынок может быть менее ликвидным в длинном хвосте сроков;
больше operational pain вокруг matching и settlement.

4. Vault wrapper поверх income-bearing активов

Это более прикладной путь для MVP.

Берётся базовый доходный актив, например:

lending receipt token;
staking receipt;
treasury-linked yield token.

Поверх него строится обёртка, которая:

фиксирует срок;
выпускает PT и YT;
считает payout в дату maturity;
роллит новую серию.

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

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

Сценарий с PT/YT

Пользователь приносит доходный актив или его базовый аналог в протокол.
Протокол помещает его в yield-bearing vault.
Взамен выпускаются PT и YT на определённую дату maturity.
PT можно продать тем, кто хочет фиксированную доходность.
YT можно продать или держать тем, кто хочет заработать на будущей переменной доходности.
До maturity базовый актив продолжает генерировать доход.
В дату maturity PT погашается в principal, а права YT заканчиваются.

Сценарий fixed-rate borrow

Borrower создаёт спрос на средства до конкретной даты.
Liquidity side соглашается дать деньги на этот срок по определённой ставке.
Протокол резервирует collateral и записывает maturity-обязательство.
До срока живёт долг с заранее согласованной economics.
В дату maturity заём должен быть погашен, пролонгирован или переведён в default/auction-flow.

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

В fixed-rate протоколе очень важно уметь честно ответить на вопрос:

кто именно держит риск изменения будущей доходности или будущей ставки?

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

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

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

1. Series / Maturity Factory

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

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

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

2. Yield Source Adapter

Этот слой подключает базовый источник доходности:

lending protocol receipt token;
staking / restaking receipt;
treasury-linked yield asset;
vault share token.

Он должен уметь:

принять актив;
положить его в underlying yield-source;
считать накопленную доходность;
вернуть состояние к maturity.

3. PT/YT Tokenization Layer

Если протокол использует split-модель, нужен модуль, который:

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

4. Pricing / Yield Curve Layer

Даже если сам протокол простой, пользователю нужна цена.

Нужен слой, который отвечает за:

implied fixed yield;
discount-to-par расчёт;
reference price PT;
расчёт доходности YT;
fair-value bounds для secondary trade или auction.

Для MVP большая часть этой логики может жить offchain, но guardrails всё равно должны быть в системе.

5. Settlement Engine

После maturity протокол должен:

остановить accrual по серии;
зафиксировать итоговую доходность;
дать PT redemption;
завершить права YT;
закрыть серию в учёте;
записать итоговый NAV / payout.

6. Oracle and Accounting Layer

Если базовый доходный актив зависит от цены, share-rate или exchange-rate, нужен слой для:

получения rate snapshots;
проверки freshness;
фиксации final exchange ratio;
reconciliation между expected и actual yield.

7. RiskConfig / Policy Engine

Хранит лимиты:

supported maturities;
allowed yield sources;
max series TVL;
max exposure per underlying;
stale-rate thresholds;
secondary liquidity limits;
pause / emergency mode.

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

1. Underlying yield risk

Fixed-rate слой не может быть надёжнее своего базового актива.

Если underlying yield-source ломается, теряет peg, уходит в плохую ликвидность или получает exploit, вся fixed-rate упаковка тоже становится проблемой.

2. Liquidity before maturity

Очень важный нюанс: fixed-rate не значит «ликвидный в любой момент без потерь».

Если пользователь хочет выйти раньше срока, он зависит от:

secondary рынка PT/YT;
AMM-глубины;
спредов;
текущих ожиданий рынка по yield.

3. Valuation complexity risk

PT объяснить легко. YT — уже сложнее.

Если продукт не показывает:

что именно куплено;
откуда берётся доходность;
какой срок жизни у инструмента;
как меняется стоимость до maturity,

то пользователь рискует принимать решение по красивому APR, не понимая реального payoff.

4. Maturity rollover risk

Многие команды недооценивают, что fixed-rate продукт надо не только запустить, но и аккуратно перекатывать между сериями.

Если rollover сделан плохо, можно получить:

простой капитала;
неверный выпуск новой серии;
конфликт в расчётах;
слишком раннее или слишком позднее закрытие старой серии.

5. Oracle / exchange-rate risk

Если в основе лежит share-bearing актив, важно корректно считать его курс в дату maturity и между циклами. Иначе PT redemption и YT accounting могут уехать.

6. Smart-contract and rights risk

Как и в любом tokenized-income протоколе, опасные места обычно такие:

ошибка выпуска/сжигания PT/YT;
некорректный redemption flow;
двойной учёт доходности;
слишком широкие админские права;
баг в maturity transition.

7. Product communication risk

Одна из самых частых продуктовых ошибок — продать PT как «почти стейбл доход», а YT как «просто дополнительный yield», не объяснив, что YT — это отдельная спекулятивная ставка на будущий доход.

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

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

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

пользователь может внести один базовый актив;
протокол умеет выпускать серию на одну фиксированную дату;
PT и YT корректно минтятся и учитываются;
есть понятный redemption flow в дату maturity;
расчёт доходности не ломается при rollover;
risk limits блокируют неподдерживаемые серии и источники;
automation layer умеет закрыть старую серию и открыть новую без ручной магии.

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

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

одна EVM-сеть;
один yield-source, например vault receipt или lending receipt token;
один базовый актив, например USDC;
одна серия на 90 дней;
простой PT/YT split;
redemption только после maturity;
secondary pricing offchain, а не полноценный onchain orderbook.

Такой MVP уже покажет сущность продукта без перегруза.

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

1. SeriesFactory

Создаёт серии и хранит метаданные:

underlying;
maturity;
yieldSource;
seriesStatus;
ptToken;
ytToken.

2. YieldVaultAdapter

Отвечает за работу с базовым доходным активом.

Функции:

deposit underlying;
withdraw underlying;
read exchange/share rate;
expose accrued yield;
enforce adapter allowlist.

3. PrincipalToken

ERC-20 или ERC-4626-подобный токен, представляющий principal claim.

Функции:

mint on split;
redeem after maturity;
burn on redemption;
reject early principal redemption, если модель его не поддерживает.

4. YieldToken

Токен права на доходность до maturity.

Функции:

mint with PT pair;
track accrual entitlement;
settle or expire after maturity;
expose preview of claimable yield.

5. RedemptionController

Закрывает серию и проводит финальный расчёт.

Функции:

freeze series at maturity;
snapshot final exchange rate;
enable PT redemption;
close YT accrual window;
emit settlement events.

6. RiskConfig

Параметры и guardrails:

allowed adapters;
max TVL per series;
supported maturities;
stale-rate threshold;
emergency pause;
operator roles.

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

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

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

series
pt_balances
yt_balances
underlying_deposits
underlying_withdrawals
rate_snapshots
maturity_events
redemptions
alerts
operator_actions

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

Postgres;
indexer на Go или TypeScript;
job-runner для maturity и rollover;
admin UI для серий, ставок и проблемных событий.

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

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

rate_snapshot_job — регулярно пишет exchange/share rate;
maturity_watch_job — следит за сериями, которым скоро закрываться;
settlement_prepare_job — проверяет готовность к maturity;
series_close_job — закрывает accrual и фиксирует final rate;
redemption_enable_job — переводит PT в redeemable-state;
rollover_open_job — создаёт следующую серию;
reconciliation_job — сверяет PT/YT supply, TVL и итоговый underlying;
alert_job — шлёт сигналы по stale rates, failed settlement и TVL anomalies.

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

Главная ошибка — сразу строить сложную yield curve и полноценный рынок secondary execution.

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

PT price считать offchain как discount-to-expected-par;
YT price считать как residual claim;
показывать пользователю сценарии, а не «точную справедливую цену»;
onchain держать только settlement truth, а не весь quant-мотор.

То есть фокус MVP должен быть не на идеальном трейдинге, а на корректном lifecycle серии.

UI для демо

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

обзор активной серии и даты maturity;
split underlying into PT/YT;
текущая implied fixed yield;
holdings пользователя по PT и YT;
countdown до maturity и финальный статус;
redemption flow;
operator dashboard с лимитами, stale-rate alerts и rollover history.

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

Именно здесь fixed-rate DeFi перестаёт быть просто «интересной токенизацией доходности» и становится управляемым сервисом.

1. Maturity lifecycle orchestration

Automation layer может:

заранее готовить серию к закрытию;
блокировать новые risky actions перед maturity;
запускать settlement window;
открывать следующую серию по расписанию;
не допускать overlapping state между старой и новой серией.

2. Rate monitoring и stale-data control

Нужно постоянно следить:

не устарел ли exchange/share rate;
не разошёлся ли основной источник с fallback;
не выглядит ли доходность аномально;
не сломан ли underlying adapter.

3. TVL and exposure limits

Automation должен уметь:

ограничивать объём новой серии;
снижать лимит при деградации underlying-протокола;
блокировать rollover в проблемный актив;
эскалировать крупные изменения only-with-approval.

4. Treasury and accounting automation

Для fixed-rate продуктов важен аккуратный учёт:

сколько underlying зафиксировано в серии;
сколько principal claims выпущено;
сколько yield уже накоплено;
какой итоговый payout прогнозируется;
нет ли расхождения между внутренним ledger и onchain supply.

5. Redemption operations

Если продукт B2C или B2B, automation layer может:

открывать массовое redemption window;
напоминать о непогашенных PT;
группировать операторские действия;
поднимать алерты по stuck-redemption кейсам.

6. Strategy overlays поверх PT/YT

На более зрелом слое можно автоматизировать:

ladder по срокам;
автоперекладку из погасившейся серии в следующую;
treasury allocation между short-duration сериями;
risk-off режим, если implied yields перестали окупать базовый риск.

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

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

Series scheduler — управляет календарём выпусков и maturity.
Rate service — собирает exchange/share rate, fallback values и freshness checks.
Policy engine — хранит лимиты по срокам, TVL и supported underlying.
Settlement orchestrator — закрывает серию, фиксирует итоговый rate и включает redemption.
Accounting service — считает PT/YT supply, accrued yield и final payout.
Risk monitor — следит за stale data, проблемами underlying и аномалиями в TVL.
Alerting layer — шлёт Telegram/Slack сигналы по failed rollover, settlement lag и расхождениям в учёте.
Operator dashboard — показывает состояние серий, лимиты, историю maturity и ручные overrides.

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

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

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

demo для onchain savings-продукта с понятной датой погашения;
treasury-инструмент для фиксации доходности на свободный stablecoin;
sandbox для PT/YT-механики поверх yield-bearing активов;
инфраструктурный слой для fintech, который хочет показать пользователю «ставку до срока», а не плавающий APY;
компонент более сложного DeFi-structured product.

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

Fixed-rate lending в DeFi — это не попытка отменить рыночный риск. Это способ разложить будущий денежный поток на более понятные части: principal, yield, срок и правила погашения.

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

PT — это право на principal в дату maturity;
YT — это право на доходность до maturity;
fixed-rate borrow и maturity vaults дают более предсказуемую economics на срок;
главные риски лежат в underlying yield-source, liquidity before maturity, valuation, rollover и settlement discipline;
automation layer нужен вокруг календаря серий, rate monitoring, redemption, учёта и risk limits.

Именно поэтому fixed-rate DeFi — один из самых полезных классов протоколов для инженерного разбора. Здесь хорошо видно, как из плавающей ончейн-доходности можно собрать более предсказуемый продукт — но только если не экономить на lifecycle orchestration и контроле риска.