Protocol design
AMM and YT routing
One pool prices PT, SY and YT together, on a curve that knows the clock is ticking. This page explains why an ordinary trading pool can't hold this market, how the curve works, and how YT trades through a pool that never holds YT.
First, what an AMM is
An AMM (automated market maker) is a trading venue with no order book and no counterparty to wait for. It is a pool holding two assets, and a formula that quotes a price from the pool’s current balances. Anyone can trade against the pool at the quoted price, and anyone can deposit both assets into it (becoming a liquidity provider, or LP) to earn a cut of the trading fees.
Why the standard formula fails here
The classic AMM formula (Uniswap’s constant product) assumes the two assets have no scheduled relationship over time. PT breaks that assumption: it must be worth exactly 1 SY on maturity day, by construction. Put PT in a standard pool and one of two bad things happens. Either the pool keeps overpricing PT along the way and arbitrage traders steadily drain the LPs as the price converges, or the pool underprices PT and nobody mints it in the first place.
The fix is a formula with time built in, so the drift toward one dollar happens inside the pricing itself instead of being extracted from LPs trade by trade.
The time-decay curve
Sidereal uses the curve Pendle V2 adapted from Notional, two established fixed-rate protocols on Ethereum:
rate_scalar = scalar_root · YEAR / τ
exchange_rate = ln(p / (1 − p)) / rate_scalar + a
p = PT_reserve / (PT_reserve + SY_reserve)Three parameters shape it:
- Rate scalar (
r): how sharply the price reacts when the pool’s balances shift. Higher means tighter prices near the going rate, but worse prices for trades that push the rate far. - Rate anchor (
a): the rate the curve centers itself around, set from the underlying interest rate at deployment and updated as the market discovers its own level. - Time to maturity (
τ): the countdown. As it approaches zero, v1’s curve flattens onto one PT face unit per SY share. That equals underlying-asset par only while one SY share is worth one underlying unit.
The curve concentrates liquidity around the current interest rate where trading happens, and its price can be read as a yearly rate. In deployed v1, however, PT is measured in underlying face units while the curve uses raw SY shares. Pendle converts those shares into asset units first. The missing conversion means v1’s rate is share-denominated once the SY exchange rate moves above 1; the factory-built AMM corrects that before longer maturities launch. The displayed number is the implied APY you see in the app: the fixed rate the market is currently offering.
Integer math, by necessity
Stellar’s smart-contract runtime rejects floating-point arithmetic outright, so the curve is reimplemented in whole-number (fixed-point) math. The build pipeline fails if any floating-point instruction sneaks into a contract. The AMM’s randomized custody/reserve suite runs at SY rate 1.0; the factory-built AMM adds the non-par unit tests described above.
How YT trades through a PT pool
The pool only ever holds PT and SY. YT trades ride through it in one atomic transaction, using the split identity. Buying YT with SY:
1. Your SY goes to the market contract. 2. It borrows extra SY from the pool, inside the same transaction. 3. The combined SY is split into PT + YT. 4. The PT goes back to the pool, repaying the borrow. 5. The YT comes to you.
Selling YT runs the same loop backwards. Because Stellar transactions succeed or fail as a single unit, the borrow can never be left hanging: either every step lands or none do.
The payoff of this design: all three assets share one pot of liquidity. Every YT trade is a PT trade underneath, so there is no separate, thinner YT pool, and the two prices can never drift apart. They are the same price read from opposite ends.
The built-in price average (TWAP)
Every trade updates a rolling 30-minute average of the implied rate, called a TWAP (time-weighted average price). It is useful for display during active trading. It is not, by itself, a collateral-grade oracle: after a long quiet spell, one trade resets the average and the warming-up flag expires 30 minutes later even if no second trade arrives. The grant-built oracle therefore also requires fresh observations, minimum in-window coverage, and a liquidity floor.
This exists for a painfully local reason: in February 2026, an attacker manipulated an external price feed over a Blend pool on Stellar (the YieldBlox exploit) and drained $10.8M. Sidereal’s pricing path uses no external feed at all. The interest rate comes straight from Blend on every interaction. The native TWAP is an oracle input, not a standalone manipulation-resistance guarantee.
What liquidity providers earn
LPs deposit PT and SY at the pool’s current ratio and earn two things:
- Trading fees, set per pool at deployment (the live market charges 0.1% on the embedded PT leg of each trade; a YT buy-and-sell round trip pays it twice).
- Curve convergence. V1 moves its PT-per-SY-share factor toward one as maturity nears. Because it omits the SY-share-to-asset conversion, this is not a guarantee of zero impermanent loss when an SY share is worth more than one underlying unit. The factory-built AMM normalizes the units before making that claim.
Every pool operation accepts a minimum-you-will-accept bound. If the price moves against you between quote and execution beyond that bound, the transaction cancels itself rather than filling badly. See the liquidity guide for the practical walkthrough.