Solana slot vs block height: why they differ
Last updated:
Endpoint and plans: Solana RPC endpoint.
At a glance
| Property | Value |
|---|---|
| Slot | The period in which a leader ingests transactions and produces a block |
| Skipped slot | A past slot that did not produce a block |
| Block height | The number of blocks beneath the current block |
| Which is larger | The slot number — skipped slots advance it, not block height |
| Used for expiry | Block height (lastValidBlockHeight from getLatestBlockhash) |
What you see
getSlot and getBlockHeight return two different numbers at the same moment, and the difference keeps growing. Code that stores one and compares it with the other drifts, and getBlock fails for some slot numbers that lie between two valid ones.
Why this happens
Solana's terminology defines a slot as "the period of time for which each leader ingests transactions and produces a block", and a skipped slot as "a past slot that did not produce a block, because the leader was offline or the fork containing the slot was abandoned". Block height is "the number of blocks beneath the current block". Because every skipped slot advances the slot counter but not the block count, the slot number is always ahead of block height. RPC methods pick one or the other: most reads are evaluated at a slot and report it as context.slot, getBlock takes a slot, and a skipped slot has no block to return. Transaction expiry, on the other hand, is measured in block height: getLatestBlockhash returns lastValidBlockHeight, the "last block height at which this blockhash remains valid".
What to do
- Store slots when you record where a read or a block came from, and block heights only when you track blockhash expiry — never compare one with the other.
- Treat a failed getBlock for a slot between two produced blocks as a skipped slot, not a data outage; move on to the next slot.
- Check expiry by comparing getBlockHeight with the lastValidBlockHeight returned alongside your blockhash, not with getSlot.
When this is not our problem
Skipped slots and the slot-versus-height gap are part of Solana's protocol and show up on every node, whoever operates it, Triport included. Nothing on the RPC side can make the two counters line up.
FAQ
- Why is Solana's slot number bigger than the block height?
- Because slots in which no block was produced are skipped: the slot counter advances with time, while block height only counts blocks that exist.
- Should I use slot or block height to know when a transaction expires?
- Block height. getLatestBlockhash returns lastValidBlockHeight; compare it with getBlockHeight.