Как строить vault и managed product поверх Pendle: PT-аллокатор, YT-overlays и control plane для fixed yield

У Pendle есть удобный способ смотреть на него не как на «ещё один DeFi-протокол с токенами», а как на бэкенд для managed fixed-income продуктов. Сам по себе PT уже похож на сроковый fixed-yield leg. Сам по себе YT уже похож на отдельный рынок будущей доходности. А если добавить поверх policy layer, dashboard, jobs и нормальную операторскую дисциплину, из этого собирается не просто стратегия, а vault, treasury product или automation-heavy yield wrapper.

Это и есть естественный следующий шаг для серии про Pendle. На Sassoft уже были материалы про базовую механику PT/YT, про LP, про looping и hedging, про sUSDe/restaking и про maturity ladder. Сегодняшний фокус уже не на одном инструменте внутри Pendle, а на более прикладном вопросе: как использовать Pendle как инфраструктурный слой для продукта, который сам управляет fixed yield, maturity, rollover и risk policy.

Это особенно полезно для трёх сценариев:

если нужен понятный fixed-yield vault вместо ручной работы с сериями;
если treasury хочет policy-driven слой вокруг PT и maturity;
если хочется построить MVP, который не копирует Pendle, а интегрируется с ним и добавляет control plane.

Из сегодняшних сигналов вокруг Hacker News здесь хорошо ложится одна мысль: ценность систем часто не в магической модели, а в хорошем control flow. Для Pendle это очень в тему. Купить PT несложно. Сложно потом системно жить с series registry, maturity windows, carry tracking, policy enforcement и operator actions. Именно в этом месте и начинается продукт.

Что именно разбираем сегодня в Pendle

Фокус у статьи такой:

как использовать Pendle как нижний слой для vault / managed product / treasury wrapper;
как простыми словами распределять капитал между PT, YT и вспомогательными leg’ами;
откуда в такой конструкции берётся fixed yield и зачем вообще нужен управляемый слой поверх Pendle;
какие архитектурные компоненты нужны для MVP;
где реальные риски и trade-offs;
что стоит автоматизировать поверх такого продукта.

Если коротко, сегодня разбираем не «как купить PT руками», а как собрать продукт, который использует Pendle под капотом и при этом выглядит как понятный fixed-income сервис.

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

Самая полезная стартовая модель такая:

Есть доходный базовый актив или wrapper.
Pendle позволяет разделить его economics на principal и future yield.
Продукт поверх Pendle выбирает, какие именно leg’и покупать или продавать.
Пользователь уже видит не набор серий и токенов, а более понятный интерфейс: vault, fixed-yield bucket, carry strategy или treasury sleeve.

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

Что именно покупает vault

В зависимости от дизайна vault может покупать разное:

в консервативном режиме — в основном PT, чтобы фиксировать yield до maturity;
в более активном режиме — комбинацию PT + cash reserve + tactical YT overlay;
в market-making или carry-режиме — PT как base leg, плюс соседние позиции для rebalances и rollovers.

То есть vault не обязан быть одной сделкой. Он может быть policy-driven сборкой из нескольких Pendle-инструментов.

Почему просто PT недостаточно для готового продукта

Потому что реальный продукт отвечает не на один вопрос «какая доходность», а сразу на несколько:

когда у позиции maturity;
что делать при приближении срока;
какой лимит на один underlying;
как действовать, если liquidity просела;
когда роллить, а когда лучше не трогать;
как объяснить пользователю текущую форму риска.

Именно поэтому вокруг Pendle почти неизбежно появляется второй слой — control plane.

Зачем делать vault поверх Pendle, если можно просто купить PT

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

1. Пользователю нужен простой интерфейс

Большинству людей не хочется вручную выбирать:

серию;
срок;
момент rollover;
качество ликвидности;
допустимую долю в конкретном underlying.

Они хотят кнопку уровня:

«fixed yield на 3 месяца»;
«консервативный stable-yield vault»;
«ladder из коротких серий».

Vault скрывает внутреннюю механику, но не обязан скрывать риски. Хороший продукт как раз объясняет их лучше, чем голый рынок.

2. Treasury нужен policy layer, а не только рынок

Treasury редко хочет жить по логике «сегодня APY красивый — заходим». Ему нужны правила:

max exposure per underlying;
max tenor;
min liquidity threshold;
stop rules при risk event;
allowed rollover windows;
ручное подтверждение для крупных действий.

Pendle даёт рынок, а vault даёт правила работы с рынком.

3. Managed product может использовать Pendle как execution venue

Это важная идея. Не обязательно строить новый yield-протокол. Можно использовать Pendle как execution layer, а самому сфокусироваться на:

strategy packaging;
risk engine;
automation;
monitoring;
operator UX;
reporting.

Для builder’а это часто разумнее, чем пытаться с нуля делать собственный рынок доходности.

Какие бывают модели vault поверх Pendle

Ниже несколько практичных дизайнов, не уходящих в фантазию.

1. Fixed-yield PT vault

Самый понятный вариант.

Логика простая:

продукт покупает PT выбранных серий;
удерживает их до maturity или до формализованного rollover window;
пользователь получает exposure к более предсказуемому yield-профилю.

По сути это обёртка над PT-book, где продукт берёт на себя:

выбор серий;
laddering;
maturity tracking;
redemption operations;
risk limits.

Кому это полезно

treasury;
DeFi cash management;
пользователям, которым нужен более читаемый onchain fixed-income слой.

2. Maturity ladder vault

Это уже следующий уровень.

Продукт не держит всё в одной серии, а строит лестницу сроков:

короткие PT;
средние PT;
иногда немного более длинных PT.

Такой vault лучше подходит, когда нужны:

регулярные окна освобождения капитала;
меньше зависимости от одной даты;
плановый rollover;
более аккуратное управление duration-like risk.

3. PT + tactical YT overlay

Более активный дизайн:

основной объём сидит в PT как fixed-yield base;
небольшая доля может идти в YT, если стратегия считает, что future yield недооценён рынком;
overlay отключается при ухудшении risk flags.

Это уже не «тихий savings-вариант», а управляемый carry/convexity продукт.

Здесь очень важно не продавать его как консервативный fixed yield, если внутри реально есть существенный YT-risk.

4. Stable-yield wrapper на базе Pendle

Ещё один прикладной формат — продукт, который работает только с понятным классом underlying, например:

stable-yield wrappers;
sUSDe-подобными активами;
более консервативной доходной базой.

Тогда Pendle используется как рынок для оптимизации fixed yield, а верхний слой делает упор на:

простой UX;
понятные сроки;
отчётность;
alerts;
cash-like portfolio management.

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

Чтобы не осталось магии, полезно пройти это по шагам.

Базовый сценарий fixed-yield vault

Пользователь вносит актив или стейбл в vault.
Vault policy engine решает, в какие серии Pendle можно зайти.
Execution layer покупает PT выбранных maturity.
PT удерживаются до maturity или до заранее определённого rollover window.
После maturity principal возвращается.
Аллокатор решает: переложить капитал в новую серию, оставить часть в reserve bucket или вывести в cash-like leg.

В этой схеме fixed yield формируется не «из воздуха», а из дисконта PT к будущему redemption value.

Где здесь место для YT

Если продукт использует YT, то только как отдельный, явно ограниченный leg:

для тактической ставки на рост доходности;
для overlay поверх PT-book;
для research/demo-продукта, где цель — показать механику yield trading.

Если делать это всерьёз, YT almost always требует:

маленьких лимитов;
более жёстких stop-rules;
отдельной отчётности;
более частого мониторинга.

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

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

1. Series Registry

Этот слой хранит:

chain;
market address;
underlying;
maturity;
days-to-maturity;
liquidity bucket;
allowed / blocked status;
risk tags.

Без нормального registry vault очень быстро превращается в набор ad-hoc решений.

2. Market Data Indexer

Индексер должен регулярно собирать:

PT prices;
YT prices, если используются;
liquidity snapshots;
volumes;
implied yields;
состояние maturity;
исторические carry snapshots.

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

Go или TypeScript для индексера;
Postgres для хранения;
scheduled jobs для пересчётов и снимков рынка.

3. Allocation Engine

Это мозг продукта.

Он отвечает на вопросы:

какие серии допустимы;
как распределить капитал по срокам;
какой процент держать в reserve;
когда роллить;
можно ли добавить tactical YT overlay;
как реагировать на ухудшение yield или liquidity.

На первом MVP этот слой может быть rule-based. И это нормально. Не нужен магический optimizer там, где хватит хороших правил.

4. Risk Policy Engine

Вот где живёт настоящая дисциплина.

Минимальный набор правил:

max exposure per underlying;
max exposure per series;
min liquidity threshold;
max tenor;
min days-to-maturity for fresh entry;
pause flag при risk event в underlying;
stricter rules для YT overlay.

Именно этот слой превращает «стратегию на бумаге» в продукт, который можно реально эксплуатировать.

5. Rollover Planner

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

Rollover planner должен:

отмечать позиции в rollover window;
считать hold-to-maturity vs early-exit вариант;
сравнивать candidate-серии;
учитывать fees и slippage;
предлагать operator action plan.

6. Execution Gateway

Даже если продукт highly automated, execution лучше держать отдельным слоем.

Он отвечает за:

подготовку сделок;
симуляцию;
sanity checks;
лимиты по цене и slippage;
ручное или полуавтоматическое подтверждение.

Это особенно важно для treasury и managed capital.

7. Dashboard и reporting layer

Хороший интерфейс должен показывать не просто APR, а:

распределение по maturity;
текущий implied fixed yield;
reserve bucket;
ближайшие rollover events;
concentration by underlying;
долю рискованных overlay-позиций;
историю carry и отклонений.

Реальные стратегии и сценарии использования

1. Treasury fixed-income sleeve

Часть treasury уходит в Pendle-обёртку с короткими и средними PT.

Что это даёт:

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

Это один из самых здравых use-case’ов для Pendle вне спекулятивного шума.

2. Stable-yield managed vault

Продукт работает только с более понятными доходными активами и не лезет в экзотические рынки.

Подходит, если цель — не максимальный upside, а:

cleaner UX;
более аккуратный risk profile;
понятная доходная стратегия;
automation вокруг maturity и rollovers.

3. Carry product для advanced users

Более активный формат:

PT служит fixed-income core;
overlay может менять позиционирование между short и medium maturities;
система отслеживает carry compression;
при хорошем сигнале разрешён небольшой YT sleeve.

Такой продукт требует намного более жёсткой операционной дисциплины.

4. White-label helper для других команд

Иногда лучший продукт — не vault для конечного пользователя, а toolkit для других операторов:

series analytics API;
maturity calendar;
risk flags;
rollover recommendations;
operator dashboard.

Это уже не «финансовый продукт», а инфраструктурный слой для Pendle-экосистемы.

Где главные риски и trade-offs

Вот здесь лучше без романтики.

1. Underlying-риск по-прежнему главный

Если underlying ломается, policy engine не превращает его в хороший актив.

Остаются все обычные проблемы:

depeg;
падение reward flow;
риски wrapper/adaptor;
slashing/restaking risk;
проблемы redemption.

Vault может лучше управлять риском, но не может отменить экономику underlying.

2. Rollover — это источник операционного риска

Многие считают, что главное — красиво выбрать PT. На деле большая доля ошибок сидит в rollover:

слишком ранний выход;
плохой execution;
неверная оценка slippage;
автоматическое продление в уже неинтересную серию;
недостаточный reserve перед важным событием.

3. YT overlay легко испортить профиль продукта

Стоит добавить даже маленький спекулятивный слой — и характер риска уже меняется.

Поэтому YT в managed product нужно держать:

отдельно маркированным;
отдельно лимитированным;
отдельно репортируемым.

Иначе пользователю продадут «fixed yield», а внутри будет hidden convexity bet.

4. Слишком умная автоматизация может вредить

Есть типичная ловушка builder’ов: попытаться полностью автоматизировать всё сразу.

На практике часто лучше работает полуавтоматическая модель:

расчёты и алерты автоматические;
risk checks автоматические;
execution — с human-in-the-loop для крупных действий.

Это скучнее, но обычно надёжнее.

5. Ликвидность до maturity имеет значение

Даже если конечная идея — держать PT до погашения, реальная жизнь подкидывает:

экстренные выходы;
смену market regime;
need for rebalance;
внезапную просадку качества серии.

Поэтому liquidity и exit quality — не второстепенные поля, а часть базового risk model.

6. Reporting и объяснимость не менее важны, чем yield

Управляемый продукт проиграет, если оператор не может объяснить:

почему он сидит в этих сериях;
откуда формируется yield;
почему rollover был сейчас;
что произойдёт при stress-сценарии.

Скрывать механику за красивым APR — плохая идея.

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

Если цель — не мечтать, а собрать работающий прототип, лучший путь — не клонить весь Pendle, а построить Pendle vault control plane.

Вариант A. Analytics-first MVP

Самый быстрый и здравый старт:

индексировать 10–20 Pendle markets;
считать implied fixed yield;
хранить maturity schedule;
показывать candidate-серии для fixed-yield vault;
отмечать rollover windows;
строить risk flags по liquidity и concentration.

Это уже полезный продукт для research, treasury и operator workflow.

Вариант B. Policy-driven rebalance assistant

Следующий уровень:

оператор задаёт policy;
система ежедневно считает допустимые аллокации;
показывает текущие отклонения;
рекомендует partial rollover или hold;
готовит action plan для ручного подтверждения.

Это почти идеальный MVP для Sassoft-угла: много automation, мало лишней onchain магии.

Вариант C. Demo vault для узкого сегмента

Можно собрать узкий прототип, например для stable-yield use-case:

только ограниченный список underlying;
только короткие и средние maturity;
без YT на первом релизе;
с простым user flow: deposit → allocation → maturity tracking → rollover report.

Такой MVP легче объяснить и легче безопасно поддерживать.

Какие контракты, данные и backend jobs нужны

Если делать не просто дашборд, а реальный прототип, структура примерно такая.

Контрактный слой

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

VaultRouter — принимает депозит и маршрутизирует аллокацию;
PolicyConfig — хранит лимиты и разрешённые рынки;
ReserveManager — держит буфер ликвидности;
SettlementAdapter — помогает с maturity/redemption flow.

Не всегда всё это нужно onchain. Часть логики разумно держать offchain, особенно на MVP.

Сущности в базе

Минимальный набор:

series
markets
underlyings
pt_quotes
yt_quotes
implied_yields
vault_positions
allocation_targets
rollover_windows
risk_flags
operator_actions
execution_reports

Backend jobs

Практичный набор джоб:

series_snapshot_job
maturity_watch_job
policy_evaluation_job
rollover_candidate_job
carry_comparison_job
liquidity_deterioration_alert_job
execution_sanity_job
post_maturity_reconciliation_job

API и UI

Полезные endpoints для MVP:

GET /markets
GET /series/:id
GET /vault/allocation
GET /vault/risk
GET /vault/rollover-plan
POST /operator/rebalance-preview
POST /operator/rollover-approve

На UI достаточно трёх основных экранов:

market overview;
vault state and maturity map;
operator action center.

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

Вот где Pendle особенно хорошо сочетается с automation layer.

1. Мониторинг maturity и rollover windows

Система должна:

отслеживать приближение maturity;
формировать action queue;
напоминать, где нужен review;
после maturity проверять redemption и reconciliation.

2. Carry tracking и curve shifts

Очень полезная автоматика:

считать net fixed yield после costs;
сравнивать short vs medium maturities;
замечать carry compression;
подсвечивать, когда rollover уже невыгоден.

3. Rebalance alerts

Нужны алерты на:

концентрацию по одному underlying;
выход за target allocation;
ухудшение liquidity;
превышение лимита по YT overlay;
изменение policy state.

4. Exit quality monitoring

Automation должна заранее показывать:

где серия становится слишком тонкой;
где early-exit может стоить слишком дорого;
когда лучше держать до maturity;
когда безопаснее выходить частями.

5. Operator workflow orchestration

Это особенно интересный слой.

Система может не просто алертить, а:

собирать daily action packet;
прикладывать rebalance preview;
требовать подтверждение для больших движений;
вести audit trail по каждому rollover.

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

Кто ещё использует похожую механику и как сделать Pendle-like prototype

Если смотреть шире, сама идея разделять principal и доходность не уникальна как класс. Она соседствует с:

fixed-income и discount-instrument логикой;
maturity-based vault дизайнами;
treasury ladders;
yield stripping как концепцией.

Но именно Pendle делает это в форме, удобной для DeFi-интеграций.

Если хочется сделать собственный Pendle-like prototype, не обязательно сразу строить весь рынок. Можно начать с урезанного демо:

один класс underlying;
короткий набор maturity;
PT-like claim на principal;
отдельный модуль расчёта future-yield leg;
простой settlement flow;
dashboard с carry и maturity.

Это уже достаточно, чтобы показать economics продукта и проверить UX.

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

Если убрать лишний шум, картина простая:

Pendle можно использовать не только как место для ручных сделок, но и как execution layer для vault и managed fixed-yield продуктов;
в основе такого продукта обычно лежат PT, а YT годится только как явно ограниченный overlay или отдельный risk sleeve;
ключевая ценность верхнего слоя — это policy engine, maturity management, rollover planning, reporting и automation, а не просто красивый APR;
реальные риски сидят в underlying, liquidity, rollover execution, hidden YT-risk и слабой операторской дисциплине;
самый здравый MVP — это analytics + policy-driven rebalance assistant + operator dashboard, а не попытка сразу клонировать весь протокол;
лучший automation layer вокруг Pendle помогает с maturity monitoring, carry tracking, rebalance alerts, exit-quality checks и operator workflows.

Именно поэтому Pendle интересен не только трейдерам, но и builder’ам. Когда рынок уже умеет разделять principal и future yield, следующая логичная работа — построить поверх него понятный продуктовый слой. Там и начинается реальная экосистема.