Strata security record

The `cancelRebalance()` function checks the aggregate share-token balance held by the `Rebalancer` rather than proving that the cooldown request associated with the selected pending rebalance has completed. Share tokens recovered from another request can therefore satisfy `minShares`, allowing the selected pending entry to be removed while its own proxy remains active. If that proxy returns its shares later, the shares arrive at the `Rebalancer` after the corresponding accounting entry has already been deleted. There is no dedicated recovery path for those late tokens, so they can remain stranded or be incorrectly consumed by a future cancellation.

The Senior loss floor is Junior-funded insurance: it caps Senior's loss to `floorRate` per day of a baseline `windowStartSrtNav + windowNetFlows`, and Junior pays any shortfall. `updateBalanceFlow()` adds every Senior deposit to `windowNetFlows`, and `_computeSrtNavFloor()` applies no age weighting, so a Senior deposit made moments before a loss raises the baseline and is protected exactly like capital that has been exposed for the whole window. The floor is presumably intended to insure Senior's long-term exposure rather than capital that just arrived, so granting fresh deposits the same instant, unpriced protection quietly transfers value from Junior to whoever deposited last. This does not require a deliberate attacker: any Senior deposit that happens to land shortly before a loss is over-protected, so Junior systematically overpays for the floor. It is only worse when abused: someone expecting a loss can deposit at the last moment and push most of it onto Junior, the depositor still loses money, just far less than their fresh capital's real share, and Junior absorbs the difference.

On loss entry, `setValuationPrice()` disables `actionsJrt.isWithdrawEnabled` and `actionsSrt.isDepositEnabled` but never disables `actionsJrt.isDepositEnabled`, so Junior deposits stay open during a de-peg. While `valuationPrice < 1e18`, `calcEffectiveNav()` marks Junior down by `extraTaken` (returning `jrtFact - extraTaken`), and `Tranche.totalAssets()` feeds this lowered NAV into the ERC-4626 `convertToShares()` pricing, so a new Junior depositor mints shares at the marked-down price. The deposit is gated only by the grace period, so the discounted buy-in becomes available as soon as any configured grace period ends. `extraTaken` is a temporary markdown taken from the existing Junior holders at loss entry to keep Senior buffered, and it is not tied to any single share. When the peg recovers (`extraTaken` returns to zero) the markdown is given back evenly across every Junior share that exists at that moment, including shares minted after the loss. A depositor who joined after the markdown therefore takes a share of a recovery it never carried the loss for, so it dilutes the holders who actually took the loss. The depositor is not risk-free, since a deeper de-peg also falls on its shares and Junior withdrawals are frozen so it cannot exit in the same block, but the loss to existing holders is locked in once the peg recovers, no matter when the depositor exits.

`SaturnCooldownRequestImpl` always passes zero as `minUsdatReceived` when requesting redemption from `sUSDat`. The withdrawal queue therefore applies no request-specific minimum and relies only on Saturn's global execution tolerance, which is initially wide and can be configured up to one hundred percent. A redemption may consequently settle for materially less USDat than the value recorded when the request was created, with the shortfall borne by the withdrawing user. A simple fixed minimum also risks leaving an asynchronous request unprocessable if market conditions change, so recovery behavior must be considered.

`getOracleRate()` calls `oracle.latestRoundData()` but only validates that `answer > 0`. It does not check the `updatedAt` timestamp for staleness. If the custom aggregator v3 feed stops updating, the strategy would continue using a stale rate for all conversions, affecting deposits, withdrawals, `totalAssets()`, and NAV calculations. The oracle updates by Midas are infrequent, occurring around every 2-5 days, so a staleness threshold should be chosen with some headroom. Note that the overloaded `totalAssets(latestNav, timestamp)` does check `updatedAt` against the accounting timestamp, but `getOracleRate()` which is used in `convertToAssets` and `convertToTokens` for all other operations does not.