Delay, confirmation and the lag you did not cause

Latency is two separate problems wearing one word. The first is protocol latency: the chain will not tell you a block is safe until enough of the cluster has voted on it, and no amount of engineering shortens that. The second is pipeline latency: everything your stack, your provider and your cache added after the chain had already finished.

Separating the two is the whole job. Once you can say which stage owns a delay, you either accept it as a property of the network or you fix it in code. Until you can, every stale panel looks like the same unfixable problem.

target slot time 400 ms, a protocol target
rooting depth 31 confirmed blocks on top
pipeline stages ingest, decode, aggregate, cache, ship
gap behaviour Streams drop silently and never replay

3 notes in this section

The difference between a slot, a confirmation, a finalised root and a chart that has caught up. Where delay is added, which part of it is protocol and which part is pipeline.

01

Confirmed versus finalized

Three commitment levels, three different promises. What processed, confirmed and finalized mean on Solana, and which one belongs in a live volume counter.

Read the note
02

Why dashboards lag

A chart is the end of a pipeline with six places to wait. Ingestion, indexing, aggregation, cache, transport and render, and how to find which stage owns your delay.

Read the note
03

Data gaps and backfill

Streams drop and nothing replays them. Detecting the hole with slot watermarks, refilling it from getBlocks and signature cursors, and proving the seam is closed.

Read the note

What this section will not give you

You will not find a table of measured milliseconds per provider. Latency depends on your node, your region, your plan tier and the minute you measured, so a published figure would be a fact about somebody else's afternoon. What you will find is the list of places delay can hide and the method for attributing yours to one of them, which is the part that transfers between setups.