Contract d5e9038212741f84510ec2ee0b614af4a8b4f8c34632e83f7ec8be4c5e82beb1

Strip. Pull sr_in SR from from, mint sr_in × index of PT and YT to receiver. Returns the PY face minted. Refused at/after expiry (Pendle's notExpired).

SR held beyond PT cover. All of this is owed to YT holders — see [Self::sweep_surplus]. Exposed for dashboards, never as a claim on the protocol's behalf.

Human-readable semver of the source build (informational; for verifiable identity use [Self::code_hash]).

Public read of the index (no writes) — the number every quote above should use.

(sr_held, sr_required, surplus) — the solvency dashboard for this series.

The current upgrade delay, seconds. Bounded on chain to [1h, 30d].

Move YT. Settles both parties first — this is the line that makes YT tradeable at all.

Burn on a spender's authority, consuming their allowance.

This must NOT route through [Self::burn]: that calls from.require_auth(), so delegating to it would demand the OWNER's signature as well and make every allowance unusable. Both entry points share [Self::burn_checked], which does the work and no auth, so each caller establishes authority in its own correct way.

The live deployed WASM hash (32-byte SHA-256) — reflects the running code across upgrades, so anyone can verify what is actually deployed rather than trusting a version string.

Recombine. Burn py_amount of face from from and send the released SR to receiver.

• Before expiry — burns py_amount PT and py_amount YT.
• At/after expiry — burns PT only. Matching Pendle's if (!isExpired()) _burn(...): a matured YT carries no principal claim, so demanding it would strand PT holders who sold their YT.

Returns the SR paid out.

The provably-unowed residue: surplus, minus credited claims, minus a conservative upper bound on every claim that could still be unsettled.

Settle user without paying — Pendle's "accrue, don't pay". Useful before an off-protocol transfer, and as the explicit version of what every balance change does implicitly.

One-shot, admin-gated init.

• sr — the SR token this series strips. Everything below Blend is its problem, not ours.
• pt — the PT SAC, which must already be admined by this contract.
• expiry — unix seconds.
• yield_fee_bps — protocol share of YT interest, ≤ [MAX_YIELD_FEE_BPS].

Permissionless TTL keep-alive for a holder's entries.

Covers both the Interest record and the YT balance entry. It used to bump only the former (tofix.md #30): a dormant YT holder's balance is a separate persistent entry with its own TTL, refreshed only when the balance is written, so keeping the interest record alive while letting the balance archive kept exactly the wrong half.

A holder's full interest record.

Accept a pending admin proposal (step 2 of 2). Callable only by the proposed address.

Bind admin + treasury atomically at deploy.

Apply a scheduled upgrade. Reverts until eta has passed.

The live PY index — max(SR.exchange_rate(), stored) before expiry, frozen after. Mutating: ratchets the stored index. The swap/mint paths use this.

Propose a new admin (step 1 of 2). The proposed address must then call [Self::accept_admin]; until it does, nothing changes.

Sweep genuinely-unowed SR to the treasury.

Read this before assuming it is a revenue line — it usually is not

In a share-based design the surplus is not free money. The conservation identity is exact: minting sr_in at index i0 creates face = sr_in × i0 and leaves held − pt_cover = sr_in − sr_in × i0/i, which is precisely what YT holders are owed. Every stroop above PT cover belongs to some YT holder — settled or not.

So this can only ever sweep what is provably owed to nobody:

• rounding remainder from the one-directional floors in the interest math, and
• claims abandoned by burning YT without withdrawing.

The unsettled part of holders' claims cannot be enumerated on chain, so it is bounded from above: no holder's settlement index can be below [storage::init_index], so the worst-case unsettled total is what the entire YT supply would have earned from that floor. That bound is deliberately loose — a healthy series sweeps ≈0, which is the correct answer, not a bug.

The mutating index — the number every value-MOVING path must price on.

[Self::py_index] is a pure view and may lag SR by one sync. That is harmless for a quote and wrong for a trade: srmarket used to price on the view while the mint_py/redeem_py it then called internally used this one, so a single transaction ran on two different indices (FINAL_CHECK.md V2-01). Anything that moves value calls this instead.

Mutating: refreshes SR from the strategy and ratchets the stored index. sr::sync_rate ALWAYS writes, so the footprint stays a function of the call graph alone and cannot depend on timing — the property that the 2026-08-24 testnet footprint failure taught us to keep.

Calling this and then mint_py/redeem_py in the same transaction is consistent, not doubled: the ledger timestamp is fixed for the transaction, so the second sync observes the same b_rate and returns the same index.

Schedule an upgrade to wasm_hash, applyable once the timelock elapses. Returns the eta. The pending hash is publicly readable via [Self::pending_upgrade] for the whole window.

SR user could withdraw right now, gross of the yield fee. Panic-free view; never writes.

Freeze the index at expiry. Permissionless — anyone may pin it, and the earlier it is pinned the tighter the ceiling. Write-once: a later call can never raise it.

Blend exposes only the current rate with no historical lookup, so the expiry index cannot be reconstructed after the fact — it has to be observed on chain. This is futureamm.md's "Rule A", made explicit and callable rather than left to whoever happens to touch the contract first.

Settle user and pay out their accrued SR, minus the protocol yield fee.

Returns (paid_to_user, fee_to_treasury), both in SR. Callable by anyone on anyone's behalf — it only ever moves value to the holder, so there is nothing to gate. That also makes it safe for a keeper to sweep dust claims.

Withdraw a pending proposal. Current admin only.

redeem_due_interest, but paying the holder's SR to receiver instead of to themselves.

This exists so a router can claim on the user's behalf and unwrap the proceeds to USDC in the same transaction. Without it the router would have to claim (paying the user), then pull the SR back — and the pull amount is only known on chain, which is exactly the simulate-vs-execute authorization drift that bit us on testnet (AUDITPREP.md §4, item 1).

Why the auth split is what it is

Paying a holder their own yield is safe for anyone to trigger — it only ever moves value to them. Redirecting that payment is not: it moves their value to a third party. So the permissionless case stays permissionless, and only the redirect requires the holder's signature. Note this deliberately checks receiver != user rather than trusting the caller.