Как устроен Pendle под капотом: SY, PT, YT, expiry flow и как собрать упрощённый Pendle-like прототип

В серии про Pendle уже были статьи про PT и YT простыми словами, fixed yield на sUSDe и restaking-активах, LP, looping, maturity ladder, vault-интеграции и rate desk вокруг implied yield curve. Логичный следующий шаг — перестать смотреть на Pendle только как на готовый интерфейс и разобрать его как инженерную систему.

То есть не просто «покупаем PT и получаем fixed yield», а:

  • какой объект вообще лежит под серией;
  • зачем нужен слой вроде SY;
  • как из одного yield-bearing актива получаются PT и YT;
  • кто на самом деле покупает будущую доходность;
  • как проходит maturity и redemption;
  • какие данные, индексы, джобы и risk checks нужны, если строить свой продукт поверх Pendle;
  • и как собрать упрощённый Pendle-like прототип, не пытаясь сразу клонировать весь протокол.

Это полезно не только для DeFi-исследователя, но и для builder’а. Потому что Pendle интересен не тем, что у него есть ещё одна вкладка с APY, а тем, что он раскладывает доходный актив на principal leg и future-yield leg, а затем превращает это в рынок сроков, цен и сценариев.

Из общих свежих обсуждений в Hacker News здесь хорошо ложится одна практичная мысль: ценность сложной финансовой системы обычно не в «магической формуле», а в хорошо собранной архитектуре данных, расчётов и контроля состояний. Для Pendle это прямое попадание. Главная сложность не в том, чтобы назвать токены PT и YT. Главная сложность — корректно прожить весь lifecycle от wrapping до expiry, расчётов, мониторинга и operator workflows.

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

Сегодняшний фокус узкий и прикладной:

  • как устроен Pendle под капотом;
  • как простыми словами связаны SY, PT, YT, maturity и redeem flow;
  • зачем рынку нужен split между fixed yield и future yield;
  • какие реальные сценарии использования стоят за этой механикой;
  • где основные риски и trade-offs;
  • как собрать похожий MVP / prototype / automation layer / dashboard.

Если коротко: это статья не про «очередную стратегию», а про архитектуру Pendle как yield-splitting machine и execution layer для fixed-income use-case’ов.

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

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

  1. Есть актив, который сам по себе приносит доход.
  2. Этот доход не гарантирован и придёт в будущем.
  3. Pendle позволяет разделить экономику такого актива на две части:
    • principal;
    • future yield.
  4. После разделения появляются два разных типа покупателей:
    • те, кому нужен более понятный fixed yield через дисконт principal-части;
    • те, кто хочет спекулировать на будущей доходности и покупает yield-часть.

То есть Pendle делает с yield-bearing активом примерно то, что fixed-income рынок делает со сроками и денежными потоками: раскладывает один поток на несколько торгуемых claim’ов.

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

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

Зачем это вообще нужно:

  • разные yield-bearing активы ведут себя по-разному;
  • у них могут быть разные механики accrual, wrapping, redemption;
  • builder’у неудобно строить отдельную логику для каждого случая;
  • системе нужен более единый формат, поверх которого можно делать split на PT и YT.

Простыми словами, SY — это слой нормализации. Он помогает превратить «зоопарк доходных активов» в что-то, с чем Pendle может работать одинаково.

Если смотреть на это как инженер, SY — это не маркетинговая сущность, а adapter layer между конкретным underlying и рынком PT/YT.

Что такое PT

PT — это principal leg.

Покупатель PT не покупает всю будущую доходность актива. Он покупает право на основную стоимость актива на дату maturity. Из-за этого PT обычно торгуется с дисконтом к будущему redemption value.

Именно этот дисконт и создаёт fixed-yield логику:

  • покупаешь PT дешевле;
  • держишь до maturity;
  • на expiry получаешь value principal;
  • разница превращается в фиксируемую доходность на оставшийся срок.

Поэтому PT удобно объяснять как дисконтный сроковый claim на principal.

Что такое YT

YT — это yield leg.

Покупатель YT делает ставку на то, что будущий поток доходности окажется достаточно интересным, чтобы окупить цену входа. Это уже не история про фиксирование доходности, а история про покупку exposure к будущему yield.

Кто может покупать YT:

  • трейдер, ожидающий рост yield;
  • участник, которому нужен более выпуклый exposure к доходности;
  • strategy desk, который хочет отделить speculative yield-bet от principal-части;
  • builder, который строит overlay или structured strategy вокруг Pendle.

Если PT ближе к fixed-income логике, то YT ближе к yield-derivative leg.

Как двигаются деньги между SY, PT и YT

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

Базовый lifecycle

  1. Пользователь или стратегия приносит доходный актив.
  2. Актив проходит через стандартизирующий слой наподобие SY.
  3. Из этой позиции создаются два требования:
    • PT — право на principal на maturity;
    • YT — право на будущую доходность до maturity.
  4. Дальше рынок сам расставляет цены между этими leg’ами.
  5. На maturity split схлопывается: principal доезжает до расчётной точки, а право на будущую доходность перестаёт иметь смысл.

Это ключевая идея Pendle: yield становится отдельным активом, а не побочным эффектом владения базовым wrapper’ом.

Почему PT может давать fixed yield

Потому что цена PT ниже будущей стоимости на дату maturity.

В очень упрощённой форме:

  • есть будущая стоимость redemption;
  • есть текущая цена PT;
  • есть количество дней до maturity;
  • из этого можно вывести implied fixed yield.

Не «гарантированную доходность вообще», а зафиксированную экономику на остаток срока, если держать до maturity и если underlying не ломается.

Почему YT может резко меняться в цене

Потому что YT зависит от ожиданий по будущей доходности, а они меняются быстрее, чем многие думают.

На цену YT влияют:

  • expected yield underlying;
  • duration до maturity;
  • спрос на speculative exposure;
  • режим рынка вокруг restaking, stable yield или reward-token economics;
  • ликвидность и стоимость выхода.

То есть YT — это не «бесплатный бонус», а довольно чувствительный инструмент.

Зачем рынку вообще разделять principal и future yield

1. Чтобы одни участники покупали предсказуемость, а другие — волатильность доходности

У разных игроков разные цели:

  • одному нужен более понятный fixed yield;
  • другому нужен upside от будущей доходности;
  • третьему нужен building block для vault или structured product;
  • четвёртому нужен hedge или relative-value trade.

Если эти интересы не разделить, все сидят в одном активе и получают один смешанный риск. Pendle делает наоборот: разделяет риск-профили на leg’и.

2. Чтобы доходный актив стал материалом для новых продуктов

После split’а можно строить:

  • fixed-yield vault’ы на базе PT;
  • YT-overlays;
  • hedged carry-стратегии;
  • maturity ladders;
  • treasury sleeves;
  • rate dashboards и policy engines;
  • helper-tooling для rollover и risk management.

То есть Pendle интересен тем, что делает yield компонуемым.

3. Чтобы рынок сам формировал цену сроков и yield expectations

После разделения появляется наблюдаемая рыночная структура:

  • сколько стоит principal на 30, 60, 90 дней;
  • сколько рынок готов платить за future yield;
  • где серия выглядит дорогой или дешёвой;
  • как меняется implied curve.

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

Основные компоненты архитектуры Pendle-подобной системы

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

1. Adapter / SY layer

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

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

  • wrapping и unwrapping;
  • нормализацию accrual logic;
  • интерфейс для mint/split/redeem flow;
  • согласование единиц учёта;
  • базовые sanity checks по underlying.

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

2. Series layer

Нужна сущность серии, где фиксируются:

  • underlying или класс SY;
  • maturity timestamp;
  • правила expiry;
  • адреса или идентификаторы PT/YT leg’ов;
  • статус active / near-expiry / matured / settled.

Series — это базовая единица сроковой логики. Без чёткого registry дальше всё разваливается.

3. Split / mint / redeem engine

Сердце механики — это движок, который умеет:

  • принять стандартизированный актив;
  • выпустить pair из PT и YT;
  • корректно учесть срок;
  • на maturity обработать схлопывание economics;
  • провести redeem и settlement.

На бумаге это выглядит просто, но именно здесь сидят самые неприятные edge-case’ы:

  • переход в near-expiry;
  • частичный redeem;
  • неверные расчёты units;
  • события вокруг underlying во время жизни серии.

4. Market / quote layer

Одного split-механизма мало. Нужен ещё рынок, где эти leg’и получают цену.

Даже если не копировать полноформатный AMM, MVP должен уметь хотя бы:

  • оценивать PT discount;
  • считать implied fixed yield;
  • хранить historical snapshots;
  • показывать цену входа и примерную цену выхода;
  • отделять gross yield от net yield после издержек.

На этом слое строятся все будущие dashboards, screeners и control plane.

5. Indexer и derived-metrics pipeline

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

  • список серий;
  • состояние maturity;
  • PT quotes;
  • YT quotes;
  • liquidity snapshots;
  • estimated slippage;
  • series events;
  • redemption / settlement events.

Поверх этого нужны derived metrics:

  • days-to-maturity;
  • implied yield;
  • carry;
  • maturity buckets;
  • risk flags;
  • watchlists по underlying.

6. Risk engine

Любая Pendle-like система без risk engine быстро становится генератором красивых, но опасных цифр.

Минимально полезные правила:

  • max exposure per underlying;
  • min liquidity threshold;
  • max tenor;
  • freeze flag на проблемный wrapper;
  • запрет на новые входы рядом с expiry, если политика так требует;
  • stricter rules для YT и leveraged overlays;
  • quote freshness threshold.

7. Settlement и operator workflows

Очень важный слой, который часто недооценивают.

Нужно уметь:

  • отслеживать approaching maturity;
  • помечать серии к review;
  • проверять post-expiry settlement;
  • запускать redemption jobs;
  • вести audit trail по всем действиям;
  • алертить, если серия застряла в промежуточном состоянии.

Именно тут automation layer приносит реальную пользу.

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

1. Fixed yield через PT

Самый очевидный сценарий.

Пользователь или vault:

  • покупает PT со скидкой;
  • держит до maturity;
  • получает более понятный fixed-yield профиль.

Это подходит для:

  • treasury;
  • stable-yield use-case’ов;
  • ladder-стратегий;
  • managed wrappers поверх Pendle.

2. Спекуляция на future yield через YT

Здесь логика другая:

  • покупается exposure к будущей доходности;
  • позиция живёт ожиданиями рынка по yield;
  • основной риск — не только underlying, но и изменение yield regime.

Это уже не savings-продукт, а направленная ставка на доходность.

3. PT как base leg, YT как tactical overlay

Очень естественная конструкция для builder’ов:

  • PT даёт fixed-income core;
  • YT используется ограниченно как overlay;
  • risk engine ограничивает размер speculative leg;
  • operator dashboard следит за carry, maturity и exit quality.

Такой дизайн ближе к structured product, чем к «просто купил токен».

4. Vault / allocator / treasury control plane

Если строить продукт поверх Pendle, механика PT/YT становится внутренней деталью, а пользователю показывается:

  • fixed-yield bucket;
  • maturity map;
  • ladder;
  • rollover calendar;
  • risk score;
  • action recommendations.

В этом случае Pendle работает как execution venue, а ценность продукта рождается в data, policy и automation layer.

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

Здесь особенно важно не превращать текст в рекламу.

1. Underlying-риск важнее красивой механики split

Если базовый актив проблемный, PT/YT не спасают.

Остаются обычные риски:

  • depeg;
  • падение reward economics;
  • проблемы wrapper’а;
  • restaking/slashing risk;
  • redemption risk.

Split может перераспределить риск между участниками, но не убрать его.

2. YT легко недооценить

Покупка future yield звучит красиво, но это чувствительный и иногда очень нервный leg.

Проблемы начинаются, когда:

  • будущий yield падает;
  • срок быстро сокращается;
  • ликвидность тонкая;
  • цена входа уже включала слишком оптимистичный сценарий.

Поэтому YT нельзя считать просто «агрессивной версией PT». Это отдельный risk profile.

3. Expiry и settlement — это источник операционного риска

Даже если economics понятна, на maturity остаётся операционная работа:

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

Чем больше серий и automation, тем важнее operator discipline.

4. Инженерная ошибка в units и pricing опаснее красивой теории

Для Pendle-like MVP большая часть риска — не «неправильная философия DeFi», а обычная инженерная реальность:

  • неверное округление;
  • устаревшие quotes;
  • ошибка в days-to-maturity;
  • расхождение между onchain state и базой;
  • неверный post-expiry статус.

На практике именно эти вещи ломают продукт быстрее, чем абстрактные размышления про yield.

5. Автоматизация без guardrails опасна

Очень легко соблазниться идеей полностью автоматического rollover или auto-entry в серии.

Но без ограничений это плохая идея.

Нужны хотя бы такие guardrails:

  • не выполнять действие по старому quote;
  • не аллоцировать в illiquid market;
  • не открывать YT-позиции без stricter limits;
  • блокировать действия рядом с risk event по underlying;
  • требовать manual approval для крупных перемещений.

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

Если цель — не переписать весь Pendle, а собрать понятный demo/MVP, лучший путь — делать узкий Pendle-like prototype.

Вариант A. Split simulator + dashboard

Самый здравый первый MVP:

  • один класс yield-bearing underlying;
  • одна или несколько maturity;
  • выпуск PT-like и YT-like сущностей;
  • расчёт implied fixed yield;
  • страница со lifecycle серии;
  • dashboard по carry и maturity.

Это уже достаточно, чтобы объяснить механику и проверить UX.

Вариант B. Analytics-first control plane

Более прикладной путь:

  • индексировать реальные Pendle series;
  • хранить quotes и maturity;
  • считать PT discount и YT sensitivity;
  • строить operator view;
  • делать alerts по expiry и yield shifts;
  • готовить rebalance / exit suggestions.

Это не клон протокола, а инфраструктурный слой вокруг него.

Вариант C. Managed PT allocator

Если хочется продуктовый MVP:

  • ограниченный allowlist underlying;
  • только PT на первом релизе;
  • ladder или bucket allocation;
  • rollover planner;
  • risk flags;
  • semi-automatic execution workflow.

Это, пожалуй, самый реалистичный способ превратить идею Pendle в usable сервис.

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

Если проектировать MVP прагматично, структура примерно такая.

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

Если нужен собственный onchain demo:

  • YieldAdapter — нормализует underlying в SY-like форму;
  • SeriesRegistry — хранит серии и maturity;
  • Splitter — выпускает PT/YT-пару;
  • SettlementController — проводит expiry и redeem flow;
  • PolicyConfig — хранит лимиты и разрешённые серии.

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

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

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

  • underlyings
  • adapters
  • series
  • pt_quotes
  • yt_quotes
  • implied_yields
  • liquidity_snapshots
  • maturity_events
  • risk_flags
  • operator_actions
  • settlement_reports

Backend jobs

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

  • series_sync_job
  • quote_refresh_job
  • yield_compute_job
  • maturity_watch_job
  • quote_staleness_job
  • liquidity_risk_job
  • settlement_followup_job
  • daily_operator_digest_job

API и UI

На MVP достаточно нескольких API:

  • GET /series
  • GET /series/:id
  • GET /curve
  • GET /risk-flags
  • GET /maturity-calendar
  • POST /split/preview
  • POST /redeem/preview
  • POST /operator/approve

На UI хватит четырёх экранов:

  • обзор серий;
  • карточка серии с PT/YT economics;
  • maturity/settlement center;
  • operator dashboard с alerts и risk flags.

Что можно автоматизировать поверх Pendle

Вот здесь тема особенно хорошо ложится в Sassoft-угол.

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

Automation layer может:

  • считать T-14, T-7, T-3 и T-1 до expiry;
  • собирать action queue;
  • помечать серии, где нужен rollover review;
  • запускать post-maturity reconciliation.

2. Quote freshness и yield shifts

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

  • отслеживать устаревшие quotes;
  • отмечать резкое изменение implied fixed yield;
  • подсвечивать series, где PT перестал быть интересным;
  • показывать, где YT стал слишком чувствительным для заданной политики.

3. Risk controls по underlying

Если underlying входит в stress-режим, система должна:

  • поднимать risk flag;
  • блокировать новые входы;
  • усиливать approval path;
  • предлагать hold / reduce / watch action plan.

4. Settlement orchestration

После maturity автоматизация может:

  • проверять series status;
  • запускать или подготавливать redeem flow;
  • сверять expected vs actual settlement;
  • закрывать операторские таски;
  • писать audit trail.

5. Carry и exit-quality monitoring

Поверх PT-book или allocator’а полезно считать:

  • net carry после fees;
  • ожидаемое качество выхода;
  • series, где досрочный exit уже слишком дорог;
  • моменты, когда hold-to-maturity лучше любого активного ребаланса.

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

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

  • fixed-income логикой discount instruments;
  • strip-like представлением денежных потоков;
  • maturity-based treasury allocation;
  • yield derivatives и structured products.

Но сила Pendle в том, что он делает это в usable DeFi-форме, где builder может быстро опереться на уже существующий execution layer.

Если хочется сделать демонстрационный Pendle-like продукт без перегруза, лучший узкий scope такой:

  • один underlying class;
  • 2–4 maturity;
  • PT/YT split без сложной token zoo-архитектуры;
  • один dashboard по implied yield и expiry;
  • alerts по maturity и risk state;
  • semi-manual operator workflow вместо полной автоматики.

Это уже даст и понятную economics, и хороший прототип для дальнейшей автоматизации.

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

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

  • Pendle интересен не только как интерфейс с APY, а как архитектура разделения principal и future yield;
  • слой вроде SY нужен, чтобы стандартизировать разные yield-bearing активы и сделать split устойчивым;
  • PT — это fixed-income-like claim на principal, а YT — более чувствительный leg на будущую доходность;
  • ценность рынка появляется там, где эти leg’и получают цену, maturity и наблюдаемую implied curve;
  • реальные риски сидят в underlying, YT-volatility, settlement/expiry flow, устаревших данных и слабых guardrails;
  • самый здравый MVP — это узкий Pendle-like prototype или analytics/control plane поверх реальных Pendle series, а не попытка мгновенно скопировать весь протокол;
  • automation layer особенно полезен для maturity monitoring, settlement follow-up, quote freshness, risk flags и operator workflows.

Именно в этом месте Pendle становится по-настоящему интересен для builder’ов. Не как ещё одна «доходная штука», а как набор composable-механик, из которых можно собрать fixed-yield продукт, риск-контур, dashboard и довольно серьёзный automation layer.