Solana LST Depeg Oracle (WIP)

Scope & motivation

Liquid staking tokens (mSOL, jitoSOL, bSOL, and the growing long tail of Sanctum-hosted LSTs) now sit as collateral inside most major Solana lending markets. Unlike Ethereum LSTs, a Solana LST's "backing" value is not a market-discovered peg — it's a mechanically computed exchange rate maintained by the SPL Stake Pool program (or a custom variant), updated once per epoch via UpdateStakePoolBalance. That distinction matters: the failure modes for Solana LST pricing are less about validator slashing (Solana has none today, only delinquency) and more about staleness windows, dual-oracle composition, and secondary-market liquidity gaps during redemption stress.

This is an open, self-funded research thread, not a commissioned engagement for any specific protocol or LST issuer. We're publishing scope and working notes as we go rather than waiting for a final writeup, consistent with how we approach research outside paid work — see our smart contract audit practice for the commissioned side of this work. Nothing here should be read as a finding against a named, live deployment.

What we are checking

Our working checklist, in priority order:

1. Rate source composition. Most integrations price an LST as LST/USD = (SOL/USD from Pyth or Switchboard) × (SOL-per-LST from the stake pool account). We're cataloguing which lending markets fetch the stake-pool leg on-demand versus caching it, and how long that cache can legally lag the actual pool state.
2. Epoch-boundary staleness. The stake pool exchange rate is only as fresh as the last UpdateStakePoolBalance call for that epoch. We're checking whether protocols enforce a max-age check on the pool account itself (not just the Pyth feed's publish_time), since these are two independently-updated clocks feeding one collateral price.
3. Circuit breaker presence and trigger conditions. Does the integration have any deviation check between the on-chain computed rate and a DEX-observed price (Orca/Raydium mSOL-SOL, jitoSOL-SOL pools), or does it trust the stake-pool rate unconditionally as "risk-free" collateral? A pool that only checks Pyth confidence intervals on the SOL/USD leg has no coverage on the LST/SOL leg at all.
4. Redemption-queue-driven discounting. During liquidity crunches (we're revisiting the November 2022 post-FTX period and subsequent smaller stress events) some LSTs traded at a discount to their computed backing on secondary markets purely from sell pressure exceeding available AMM depth — a discount the on-chain rate oracle structurally cannot see because it only reflects backing, not tradability.
5. Upgrade authority over the rate-computation program. Several stake pool deployments and their wrapping vault programs retain upgrade authority; we're mapping which LSTs a lending market accepts have time-locked or multisig-gated upgrades versus a single EOA, since this affects who can alter the rate math a liquidation engine depends on. This overlaps with themes we cover in our note on upgradeable Solana programs and BPF loader risk.

Preliminary observations

Nothing below is a confirmed vulnerability in a named live system — these are patterns we're seeing across public code and prior incident writeups that warrant closer per-protocol review.

• The two-oracle composition described above is the recurring theme. A naive collateral-valuation function looks like this, and the staleness gap is easy to miss in review:

// Illustrative — not a specific protocol's code
fn lst_price_usd(pyth_sol_usd: &PriceAccount, stake_pool: &StakePool) -> u64 {
    // Pyth freshness is checked...
    require!(clock.slot - pyth_sol_usd.valid_slot <= MAX_PYTH_STALENESS);

    // ...but the stake pool's last-updated epoch is not compared
    // against the current epoch before using its rate.
    let sol_per_lst = stake_pool.total_lamports / stake_pool.pool_token_supply;
    pyth_sol_usd.price as u64 * sol_per_lst / PRECISION
}

If stake_pool.last_update_epoch < current_epoch, the rate can reflect a pool state that predates a large deposit, withdrawal, or (rarer) validator delinquency event — the classic single-clock-checked, second-clock-ignored bug shape we also flag in cross-program contexts; see our CPI risk writeup for the general pattern.

• Circuit breakers, where present, tend to be borrowed from EVM designs (static percentage deviation caps) without accounting for Solana's epoch cadence — a 2-3 day update interval means a "reasonable" 5% deviation threshold can be crossed by legitimate reward accrual alone on some pools, producing false positives or, if loosened to compensate, an under-protective breaker.
• LST market depth is uneven enough across issuers that a single deviation threshold applied uniformly (top-3 LSTs vs. long-tail Sanctum LSTs) is very likely miscalibrated for at least one side.

Next steps

We're extending the review to: (1) pull actual UpdateStakePoolBalance cadence data across the major pools to quantify typical staleness windows rather than describe them qualitatively; (2) enumerate which lending markets' liquidation bots read DEX price as a secondary check versus relying solely on the composed oracle; (3) cross-reference against the collateral-onboarding checklists we've seen in the wild, in the spirit of the Solana program security audit checklist for trading systems. No severity ratings are being assigned until we have concrete, protocol-specific evidence rather than pattern-level observations. This page will be updated as the research progresses.

If you're integrating LSTs as collateral and want this checked against your specific rate-computation and liquidation code before shipping, that's exactly the kind of review we do under smart contract audit.