Loading page…
Loading page…
Method
Every figure on the site is defined here, with the arithmetic written out and its limits stated. Each section opens with the one sentence to keep; the rest is detail. New to liquid staking? Start with the basics instead.
Most places that list LST yields print a number the pool advertises or a recent epoch's payout. We print what a stake actually earned, and show how we got there.
The APY a pool advertises, what it paid in its last epoch, or an average of its last few are honest as far as they go, but none of them is what a stake earns over the time you actually hold it. So this site does four things differently:
The result is the number you would have seen in your wallet. Every step of the arithmetic is on this page so you can disagree with it rather than have to trust it.
Every number on this site is derived from one on-chain figure: how much SOL one pool token redeems for.
A liquid staking token is a claim on a pool of staked SOL. As the stake earns rewards, each token redeems for a little more SOL than before. We read that SOL-per-token figure directly from the chain.
It is not the market price. A token can trade below what it redeems for; that gap is a matter of liquidity, not of what the pool earned, and we do not track it.
Redemption value is measured after the pool’s ongoing fee and its validators’ commissions. Those costs are already inside every return shown here. There is nothing further to subtract.
APY is the annualised growth of redemption value over a trailing window of up to fifty days, measured over the real time that elapsed.
We record each pool’s redemption value roughly every fifteen minutes.
APY = (value_end / value_start) ^ (365 / elapsed_days) − 1
Worked example
A token redeemed for 1.0000 SOL at the start of the window and 1.0087 SOL 49.6 days later.
(1.0087 / 1.0000) ^ (365 / 49.6) − 1 = 6.58% APY
Redemption value moves in steps, once per epoch when the pool books its rewards, and is flat in between. So both ends of the window sit on a step, and each step is dated to the boundary of the epoch that booked it, not to the moment the pool’s operator got round to booking it or the moment we read it. The end is the pool’s latest update; the start is the update closest to fifty days before it. That way the ratio always covers whole epochs of rewards over exactly the epochs they were earned in, and the figure only moves when a new epoch is booked or an old one falls out of the window, not with the hour of day you happen to look or how late the pool ran its update.
Fifty days is the target: long enough to survive one bad epoch, short enough to show a change in how a pool is run. Because the ends sit on updates, a window runs a little over or under fifty days, by at most half an epoch. What a pool actually gets is also bounded by how far back our stored readings reach. The longest window in use today is 51.7 days. Each pool’s page states its own window, and the figure is always annualised from the time actually measured.
Our own readings begin the day we started sampling a pool. Older history is imported from Sanctum, and the join is marked rather than hidden.
Sanctum publishes one growth figure per epoch, without intra-epoch timestamps. Over the period that history was recorded, twenty-five epochs spanned roughly fifty days, so a trailing twenty-five-epoch figure is the nearest counterpart to our own headline window. Every point in a pool’s APY history is tagged with where it came from:
| Tag | Meaning |
|---|---|
| Sanctum | Entirely from Sanctum's published per-epoch figures, before we measured the pool. |
| Blended | Our own readings cover the most recent days of the window; the older days we do not yet reach are filled at Sanctum's last trailing rate. Our share grows by one epoch's readings every epoch. |
| LSI | Measured entirely from our own readings. The blend ends once we cover the full window. |
On a pool’s page the blended stretch is shaded and labelled, with the epoch it began stated beside the chart. Once the shading ends, the following points come from our readings alone. The API carries the same tag on every epoch.
Pools we saw launch have no imported history. Their record starts at their first measured window and nothing is blended.
Comparisons replay each pool's actual recorded redemption values, epoch by epoch. We never compound an APY forward.
Compounding an APY over a period measures a smooth average, not what happened. Instead, your stake is placed at the pool’s value on the first day of the window and grows exactly as the pool grew, through its good epochs and its bad ones. The realised annual figure is derived from that result, not assumed at the start.
net_at_t = stake × (1 − deposit_fee) × (value_t / value_start) × (1 − withdrawal_fee) realised = (net_at_end / stake) ^ (365 / window_days) − 1
Worked example
100 SOL staked when the token redeemed for 1.1200, held 60 days to 1.1290, with no deposit fee and a 0.1% withdrawal fee.
100 × (1.1290 / 1.1200) × 0.999 = 100.70 SOL
(100.70 / 100) ^ (365 / 60) − 1 = 4.35% realised (4.99% before the fee)
One consequence: a pool that entered the window already worth more per token gets no credit for that. Growth is measured from the day you would have staked, so every pool in a comparison starts from the same position.
When pools of different ages are compared, the window shrinks to the youngest pool's history so every line covers the same stretch.
Comparing a three-year-old pool against one launched last month over “three years” would credit the older pool with time the younger one never had.
Deposit and withdrawal fees are charged once, so they are applied to the holding period you choose rather than buried in an APY.
What a one-off fee costs you per year depends entirely on how long you hold. Folding it into APY would mean quietly picking a holding period for you. Instead you choose the period, we apply the fee to it, and you can switch the fee off to see the return before costs.
The overview chart is a net-exit curve: every point answers how much SOL would reach your wallet if you left at that point. A withdrawal fee therefore lowers every plotted point, including the first one. This does not mean the fee was charged on entry; the first point shows the proceeds of an immediate hypothetical exit. For a constant percentage fee, scaling the curve this way gives the same ending value as applying the fee once when you leave.
| Fee | When | Effect on the comparison |
|---|---|---|
| Deposit | On entry | Buys you fewer tokens, so it scales every later figure down. A pool that charges to enter opens below the SOL you handed over. |
| Withdrawal | On exit | Applied once to the SOL redeemed whenever you leave. Because every chart point is a hypothetical exit, it also lowers the line's opening net-exit value. |
Periods use the real recorded start and end of every epoch, never an assumed length.
An epoch is a fixed count of 432,000 slots, not a fixed span of time. How long it takes depends on how fast the network is producing slots, and that has changed as the network has sped up, so any rule of thumb in days goes stale. We store when each epoch actually began and ended and use those durations, so a holding period reflects the calendar. Across the last 195 settled epochs the average was 1.9286 days.
Where an epoch is too old for us to have timed it, we fall back to an assumed length and label any period containing one as approximate.
Past growth is not a promise, and some APYs are artifacts of size or timing rather than returns anyone earned.
The overview opens with Over 1,000 SOL TVL enabled to compare yields at larger pool sizes. The recorded 50-day APY describes past returns; it does not model what happens when more SOL is deposited. If rewards grow more slowly than deposits, the APY can fall as the pool grows.
Smaller high-APY pools can still be attractive when your deposit is small relative to the pool. Turn the filter off to include them in the chart, ranking and search. The cutoff uses the latest TVL, not the pool’s size throughout the selected period. A larger pool does not guarantee future APY. The LST average still includes all eligible pools, and a chosen comparison baseline stays visible.
Rounding is applied only for display. Every calculation runs on the nine decimals the API returns, which is the precision SOL itself is denominated in.
SOL amounts are shown with as much precision as the size of the number warrants, so a difference that matters is always visible without printing nine decimals on a five-figure stake.
| Amount | Shown to |
|---|---|
| Below 10 SOL | 4 decimals |
| 10 to 250 SOL | 3 decimals |
| 250 to 10,000 SOL | 2 decimals |
| Above 10,000 SOL | Whole SOL |
If a number here looks wrong, it may well be — tell us and we will fix it or explain it. LST Radar is run by Guardian Validator; the quickest way to reach us:
Tracking 265 pools. Currently in epoch 1047.