A current slot is not a current account

On 2 September 2026 our sampler stored something that cannot happen on-chain: a stake pool's last_update_epoch went backwards. The RPC response said the data was from a current slot. The account bytes inside it were from the previous epoch.

We did not catch it at the time. The rows were written. We found them the next day because a 50-day figure moved in a direction the chain could not explain, and the trail led back to one provider.

What we saw

LST Radar reads every active pool's account roughly every fifteen minutes and stores its redemption value, the slot, and last_update_epoch, the field the pool itself stamps when it books an epoch's rewards. That field only ever increases.

Around 11:39 UTC on 2 September, reads through Helius (mainnet.helius-rpc.com) started returning last_update_epoch = 1026 for pools that had already booked epoch 1027. The context.slot on the same responses was current. The same accounts, requested from Triton and from the public api.mainnet-beta.solana.com endpoint at the same moment, returned 1027 and the newer redemption value.

By the time we probed all 260 SPL-layout pools we track, 129 were stale on Helius and current everywhere else. The pattern was not random: the affected pools were the ones whose epoch-1027 update landed between about 11:20 and 11:30 UTC. That window matches the recovery period of a Helius incident that morning (their status page recorded an outage from a network fork and reported the service "mostly recovered" shortly before). Our reading of the evidence is that account writes from those minutes were missed during their resync and never backfilled. That is an inference from timing, not something Helius has confirmed; their incident page did not mention account staleness. More than 24 hours later the same accounts were still stale on Helius.

Reproducing it

The JitoSOL stake pool account is Jito4APyf642JPZPx3hGc6WWJ8zPKtRbRs4P815Awbb. In the SPL stake pool layout, last_update_epoch is the little-endian u64 at byte offset 274 (after total_lamports at 258 and pool_token_supply at 266). Call getAccountInfo with encoding: base64 against two providers, decode those eight bytes, and compare. During the incident, Helius returned 1026 and every other provider returned 1027, both under a current context.slot. Nothing about the response marked it as old.

Why the slot is not enough

Every RPC response carries a context.slot. It is tempting to treat it as a freshness stamp for the data. It is not; it is the slot the node considers current, and it says nothing about when the specific account bytes in the response were last written. For a stake pool the only freshness signal inside the data is last_update_epoch, and it is worth checking on every read.

What we changed

• A regression guard on ingestion. If a read reports a lower last_update_epoch than the last stored sample, it is not written. The same accounts are re-read from the other provider; if that read is current it is kept, and if it also regresses the pool stays due and nothing is written.
• Triton first for pool reads. Helius is still the fallback, but the path that produces the numbers on this site no longer depends on it.
• Anchors that cannot be stale. The 50-day window is measured between pool updates. A sample whose last_update_epoch is lower than one already seen is never used as an anchor, even if a stale row were to reach the database again.
• Repair. We deleted the 332 stale samples from 2 September and recomputed the affected epoch-1027 metrics from clean reads.

The guard is still there and it will fire again the next time a provider serves yesterday under today's slot. That is the point. The site would rather show a gap than a number we cannot support.

is JitoSOL's live measured figure, rebuilt from clean samples, not a screenshot from the incident. See how the numbers work for where every reading comes from.