Slots, blocks and commitment levels, explained

Most blockchains talk in blocks. Solana talks in slots. Once you understand slots and the three commitment levels built on top of them, a lot of confusing behavior makes sense: balances that flicker, bots that act on trades that never happened, and transactions that fail with “blockhash not found”.

01Solana’s clock: the slot#

A slot is a short window of time in which one validator, the leader, is allowed to produce a block. Slots target about 400 milliseconds, and each leader gets four consecutive slots before the turn passes to the next validator on the schedule.

Slot numbers only go up, which makes them the most useful timestamp on Solana. Nearly every RPC response includes the slot it was answered at, and data tools sort and join on slot rather than wall-clock time.

02Slots vs blocks#

A slot is an opportunity; a block is what fills it. If the leader is offline, too slow, or its block loses out to a competing fork, that slot ends up skipped: it has a number, but no block. Skips are normal and happen every day.

That is why Solana tracks two different counters:

• Slot (getSlot): counts every window, filled or not.
• Block height (getBlockHeight): counts only blocks that actually exist, so it is always lower than the slot.

03Epochs and the leader schedule#

Slots are grouped into epochs of 432,000 slots, which works out to roughly two to three days. At each epoch boundary, staking rewards are paid and a new leader schedule is fixed: a list of which validator leads which slots, weighted by stake. Because the schedule is known in advance, RPC nodes know exactly which leader to forward your transaction to.

04The three commitment levels#

A block does not become permanent the instant it is produced. Validators vote on it, other blocks get built on top, and its chance of being rolled back shrinks with each step. Solana exposes three checkpoints along the way as commitment levels, and almost every RPC method lets you choose one.

processed

The node has seen and executed the block, but the cluster has not reached agreement on it yet. This is the freshest view and the least certain: the block can still be dropped, and for a moment a slot can have more than one candidate block.

confirmed

Enough stake has voted for the block that it is very unlikely to change. It arrives a moment after processed and is the default most apps read at.

finalized

The cluster’s consensus has finalized the block, and it will not be rolled back. This is the strongest guarantee Solana gives.

The glossary entry on processed, confirmed and finalized is a quick reference to come back to.

05Which level for which job#

You can measure the gap between the three levels yourself. Ask one node for its slot at each level:

const RPC = 'https://YOUR-ENDPOINT'

const LEVELS = ['processed', 'confirmed', 'finalized'] as const

async function getSlot(commitment: (typeof LEVELS)[number]) {
  const res = await fetch(RPC, {
    method: 'POST',
    headers: { 'Content-Type': 'application/json' },
    body: JSON.stringify({ jsonrpc: '2.0', id: 1, method: 'getSlot', params: [{ commitment }] }),
  })
  return (await res.json()).result as number
}

const [processed, confirmed, finalized] = await Promise.all(LEVELS.map(getSlot))
console.log({ processed, confirmed, finalized, gap: processed - finalized })

Run it a few times. On a cluster running Alpenglow, confirmed and finalized should match or sit within a slot of each other. If finalized trails by dozens of slots, the endpoint is on a node that still behaves like TowerBFT, and that gap is real waiting time for anything you settle at finalized.

06Blockhashes expire#

Every transaction includes a recent blockhash, which proves it was built recently and stops it being replayed later. The network only accepts a blockhash for about 150 blocks after it was produced, roughly a minute or so. getLatestBlockhash returns a lastValidBlockHeight so you know exactly when yours runs out.

If you see blockhash not found or an expired transaction, the usual causes are:

• The transaction sat unsigned or queued too long before it was sent.
• The blockhash was fetched at processed commitment from a block that was later dropped.
• Retries kept re-sending the same transaction after its blockhash expired.

The fix is to fetch a fresh blockhash at confirmed, re-sign, and stop retrying once lastValidBlockHeight passes. For transactions that must wait, such as multisig approvals, use a durable nonce instead.

Frequently asked questions#