# Valuing stETH and Liquid Staking Positions > Rebasing and wrapped staking tokens need different valuation logic. Why stETH balances change with no transaction, and how wstETH breaks naive pricing. - **URL:** https://octav.fi/blog/valuing-steth-liquid-staking - **Published:** 2026-02-25 - **Author:** Octav Team — Portfolio Intelligence for Digital Assets - **Topic:** Protocols - **Tags:** lido, staking, defi - **Source:** Octav, Practical guides on crypto NAV reporting, multi-chain portfolio management and digital asset APIs, from the team behind Octav. --- Liquid staking tokens look like ordinary ERC-20s and behave like nothing of the sort. Two mechanisms — rebasing and wrapping — each break a different assumption that portfolio tooling makes. ## Rebasing: the balance changes on its own `stETH` is a rebasing token. Staking rewards are distributed by increasing every holder's balance, so the number in your wallet grows without any transaction ever touching it. Three consequences: | Assumption | Why it breaks | | --- | --- | | Balance changes come from transfers | Rebases produce no transfer event | | Cached balances stay valid | A cached balance is stale by design | | Every increase is income to be booked | Rebases are continuous, not discrete events | For [reconciliation](/crypto-transaction-reconciliation), the last row matters most: a system that books every balance increase as a receipt will manufacture thousands of phantom income events from a single stETH position. ## Wrapping: the balance does not change, the value does `wstETH` solves the rebasing problem by doing the opposite. The balance is fixed; the **exchange rate** to stETH increases over time. This trips a different wire. `wstETH` is not worth the same as ETH, and never was. Its correct value is: ``` value = wstETH balance × (stETH per wstETH) × ETH price ``` Price `wstETH` at the ETH price and you understate the position by the entire accumulated staking yield since the wrapper launched — a gap that grows every day and looks like nothing in particular. ## The general rule | Token type | Correct valuation | | --- | --- | | Rebasing LST (`stETH`) | Live balance × underlying price | | Wrapped LST (`wstETH`, `jitoSOL`, `mSOL`) | Balance × exchange rate × underlying price | | Native staked | Stake account value, including pending rewards | The wrapped case is where the error is silent. There is no exception thrown, no missing field — just a number that is quietly and increasingly too low. The same pattern applies on Solana with `jitoSOL` and `mSOL`, covered in [Tracking Solana DeFi Positions](/solana-defi-portfolio-tracking). ## Depegs and withdrawal queues An LST's market price can diverge from its redemption value. Which number is "correct" depends on what the portfolio is for: - **Mark-to-market reporting** wants the price you could actually sell at today. - **Fund accounting** may prefer redemption value where redemption is available. Neither is universally right, but a portfolio system should be explicit about which one it uses. If your provider ships a price source per asset, you can check — which is the practical answer to the question of which number a report is built on. Withdrawal queues add a further wrinkle: an LST in the process of being unstaked may be neither liquid nor yet redeemed, and its treatment should be consistent with how you handle other [locked positions](/tracking-eigenlayer-restaking). ## Checking a provider For a wallet holding both `stETH` and `wstETH`: - Does the `wstETH` value exceed a naive balance × ETH price? It should. - Does the `stETH` balance reflect the current rebased amount? - Is the price source visible, so you can tell market price from redemption value?