The epoch starts. The pools follow.

A new Solana epoch starts at one network boundary. Its liquid staking pools do not all become current at the same moment.

In five epochs we checked, BNSOL and JitoSOL completed their first pool-balance updates within roughly two-and-a-half to three-and-a-quarter minutes. Other pools varied more. JupSOL's first update ranged from 2 minutes 49 seconds to 30 minutes 33 seconds. For sctmSOL, four of the five were within twelve minutes; the fifth was 6 hours 18 minutes after the boundary.

These are successful transaction times. They describe what happened, without assigning a cause or treating update speed as a measure of investment quality.

LST Radar is run by Guardian Validator, and gS is our pool. We include its operating approach and measured history below; see our disclosure.

Starting with the largest pools

We selected the 16 largest SPL-compatible pools in Radar's catalog at the time of writing (8 September 2026, epoch 1030), then found their first successful pool-balance update in epochs 1025, 1026, 1028, 1029 and 1030. Together they held approximately 44.7 million SOL, or 88% of the tracked TVL in the comparable SPL-compatible catalog. Marinade and Infinity use different state models and are outside this comparison.

This selection gives the largest pools the most space without assuming that they will be the quickest. TVL measures the SOL represented by a pool; it does not tell us how much instant exit liquidity is available.

Open the full-size figure or download the timings and transaction signatures.

Among the largest pools:

• BNSOL (Binance), approximately 10.40 million SOL: median 2m41s; range 2m27s–3m16s.
• JitoSOL, approximately 10.25 million SOL: median 2m34s; range 2m33s–3m03s.
• JupSOL, approximately 5.18 million SOL: median 9m35s; range 2m49s–30m33s.
• dSOL, approximately 2.81 million SOL: median 5m43s; range 3m25s–30m17s.

Several smaller members of this large-pool sample also updated consistently within a few minutes. bbSOL (Bybit), with approximately 1.25 million SOL, ranged from 2m12s to 2m17s. xSHIN, with approximately 1.12 million SOL, ranged from 2m07s to 2m25s. PSOL, with approximately 1.65 million SOL, ranged from 2m06s to 3m25s. Their medians were 2m13s, 2m09s and 2m09s respectively.

These are the quickest and most consistent examples in the selected five-epoch sample, not an all-time leaderboard. The full figure also includes pools whose timings changed substantially: dynoSOL ranged from 11m27s to 1h12m57s, and JSOL from 2m21s to 30m18s.

Sanctum pools update in groups, with exceptions

Sanctum's documentation says that it runs the permissionless epoch-update crank for its pools and recommends that operators run a backup for redundancy. An update submitted for a Sanctum pool can therefore come from the shared service, the pool's operator or another participant. The program name alone does not identify who submitted it. Sanctum's operator guide.

Epoch 1028 provides a useful comparison. It began at 23:24:41 UTC on 3 September 2026. dSOL and dfdvSOL first updated 30m17s into the epoch; hSOL at 30m27s, fwdSOL at 30m32s and JupSOL at 30m33s. Those five updates landed within sixteen seconds, although they used different fee-payer addresses. The timing is consistent with coordinated activity; it does not establish common ownership of those addresses.

sctmSOL's first update landed at 05:42:45 UTC on 4 September, 6h18m04s after the boundary. Two smaller pools we checked, stepSOL and chSOL, first updated at 6h33m37s and 6h40m02s. All three used the same fee payer. Their sctmSOL, stepSOL and chSOL transactions are public.

In epoch 1029, those same three pools and gS first updated within 6–8 minutes. Their initial updates shared another fee payer and landed within a 75-second span. The evidence shows variation between epochs and groups of related activity. It does not show why the schedule differed, or prove that either fee payer belongs to Sanctum.

Why freshness matters when liquidity is thin

An LST can reach a user through an exchange trade or through a native pool operation. Native routes can deposit SOL into a pool to mint its LST, withdraw available reserve SOL, or move value through active stake accounts. These routes can matter particularly when an LST's exchange liquidity is shallow relative to the requested trade.

Sanctum documents a router integrated into Jupiter that connects staking, withdrawals and swaps through stake accounts. Some routes can also use Sanctum's Reserve for instant SOL liquidity. Sanctum Router documentation.

These pool-dependent routes need usable pool state. SPL pool operations check epoch freshness, so an unupdated pool can make an otherwise useful staking or withdrawal path unavailable until an update succeeds. A route builder may be able to include the required update, but that is implementation-dependent and can add transaction work. SPL stake-pool documentation.

Jupiter can compare these paths with other liquidity sources. Titan operates above multiple aggregators and simulates candidate quotes; consequently, the availability of the underlying paths matters to users of Titan too. This is a routing implication, not a claim that we measured a specific Titan route failure. Titan's explanation of meta aggregation.

An exchange market may continue trading while a pool is unupdated. Conversely, a pool can be current and still have insufficient reserve SOL for an immediate native SOL withdrawal. Pool freshness, exchange depth and available reserve liquidity are separate questions. We have not measured lost trade volume, slippage or failed quotes in this study.

The benefits and costs of updating promptly

Prompt, correct updates shorten the period in which native operations depend on an outstanding epoch refresh. They can make more routing options available sooner and make newly delivered payments visible in the pool's accounting. A backup updater also reduces dependence on a single service. These are operational benefits; an earlier accounting update does not itself create additional staking rewards.

There are costs to pursuing that goal. Updates consume transaction fees and RPC capacity, and the updater needs reliable scheduling, monitoring and retries. Large validator lists require multiple updates before the aggregate pool balance can be refreshed. Additional payments or rewards arriving later may need further updates. Stake-pool operation documentation.

Correctness takes priority over hitting a timestamp. Epoch reward distribution and stake-account operations have protocol constraints, so a first successful update is not proof that every reward component has finished arriving. An operator must respect those constraints and continue updating as appropriate. Solana's partitioned-reward design.

The tradeoff is the cost and reliability of maintaining fresh state. There is no inherent yield bonus for being first, and this dataset does not establish a universally optimal update interval.

Our approach for gS

For gS, our operating approach is to include a pool update with every payment, on a roughly hourly payment cadence. We checked 37 successful payments from our payer into the gS reserve during epoch 1029 and the observed portion of epoch 1030: all 37 included a pool update in the same transaction. The median time between those payments was 60m16s. There were longer gaps, so this is a description of the usual cadence, not a guarantee of one payment every clock hour. An example payment and update.

We have also recently adopted an operating target of refreshing gS approximately one minute after an epoch begins, subject to successful execution and protocol constraints. We consider a prompt epoch-start refresh, plus an update with each subsequent payment, a useful operating standard to work toward.

That target is newer than most of the history examined here. It is not a claim that gS has always met it: our verified first updates were 2h23m32s in epoch 1028, 6m26s in epoch 1029, and 2m55s in epoch 1030. The epoch-1030 transaction therefore does not establish a one-minute result. Future observations can show how consistently the new target is met.

How we measured this

The initial investigation combined approximately 1.84 million value samples with RPC epoch snapshots across 262 SPL-compatible pools. It examined 30 completed epochs, 1000–1029. Among observed updates for pools holding at least 25 SOL at the observation time, 89.3% were first seen within thirty minutes. That percentage is conditional on observing an update; records without one were kept separate.

Polling is useful for finding patterns, but a fourteen-minute first observation may follow a transaction that landed at minute six. For the figure, we therefore queried finalized transaction history in ascending order from each epoch's first slot, checking successful transactions until we found the pool's UpdateStakePoolBalance instruction. We checked the instruction's program and pool address, including inner instructions, rather than treating any transaction mentioning the pool as an update.

The figure contains 80 verified pool-epoch cases, plus five separate gS cases in the downloadable evidence. The five epochs cover 30 August–7 September epoch starts: 1025–1026 provide earlier comparisons, 1028 contains the identified variation, 1029 follows it, and 1030 is the latest start at the time of capture. This is a deliberately selected case series, not a random sample or a long-term service-level estimate. Epoch 1027 remains outside this transaction comparison; the broader investigation flagged its observation coverage alongside a documented stale-RPC incident.

Elapsed times use finalized transaction block times minus Radar's non-estimated epoch boundary times. TVLs come from the 8 September catalog and are rounded; they are not trade liquidity estimates or historical TVL weights. The first pool update does not measure completion of all inflation rewards, MEV distributions or external payments. Those require their own definitions and evidence.