Settlement and maturity

The problem the freeze solves

Blend doesn’t know Sidereal’s maturity date exists. The lending pool keeps earning interest right past it. If PT redemption naively read the live rate whenever each holder showed up, interest earned after maturity would leak into payouts, and two people redeeming the same claim on different days would get different amounts. The boundary that defines the whole product (before maturity is YT’s, at maturity is PT’s) would be blurry exactly where it must be sharp.

Freezing to an observed rate

The protocol records the exchange rate at every interaction: splits, collections, recombines, even plain YT transfers report their rate through the same path. Each recording is an observation. At maturity, the redemption rate freezes to the last observation made at or before the maturity instant, never to a reading taken afterwards. The snapshot happens automatically on the first post-maturity interaction, or anyone can trigger it explicitly by calling freeze_maturity_rate.

“Anyone” is deliberate. Both maintenance calls, observe_rate before maturity and freeze_maturity_rate after, are open to any caller: a bot, the team, or a YT holder protecting their own interest. Whoever calls, the effect is the same, so there is nothing to abuse. Frequent observations near the boundary pin the frozen rate as close to the maturity instant as possible.

And if the market goes quiet and the last observation lands early? The small tail of unrecorded interest stays in the escrow behind the principal, resolving predictably in PT’s favor. The failure mode is a known, bounded lean toward the senior claim. It is never a race where the fastest claimant wins.

Who gets paid first

Settlement enforces a strict order on the escrow: the full PT principal is reserved before any YT interest is paid. In normal operation this ordering is invisible, because the escrow covers both sides in full (see the tokenizer’s coverage rule). It only bites if the underlying pool genuinely loses money:

• PT holders share any shortfall proportionally. Each redemption is capped at that holder’s fair share of the escrow, so being first in line buys nothing and there is no bank-run dynamic on the senior side.
• YT holders stand behind PT and are paid from whatever remains above the principal reservation. Within that junior slice, collections during an active shortfall are served in the order they arrive. Splitting that slice proportionally instead is a documented v2 item; it needs an extra piece of shared bookkeeping the contracts don’t carry today.

What stays open after maturity

• PT redemption: open indefinitely, always at the frozen rate. There is no deadline to beat and nothing gained or lost by redeeming late.
• Final YT collections: interest earned up to the freeze remains collectible through a grace window, paid at the frozen rate. Nothing new accrues.
• SY withdrawal: unwrapping SY to USDC has no maturity attached. It works before, at, and after.
• LP withdrawal: liquidity providers can exit; the pool’s PT has finished its glide to face value by then.

Long-lived storage

On Stellar, contract data pays rent: each stored entry has a time-to-live that must be topped up. Per-holder interest ledgers and LP balances live in persistent storage, and if an entry’s time-to-live ever runs out, the network archives it rather than deleting it. A standard network operation restores archived entries without needing anything special from the contracts. The app tops entries up automatically, and the restore path is the documented recovery for dormant ones. Funds cannot be lost to an expired timer.