Skip to main content
This page is the single source of truth for how fresh each data product is. If you’re sizing a trading bot, a compliance alerting system or an agent feedback loop, these numbers are what matters.

End-to-end latency model

[chain event] → [ingestion] → [normalization] → [Kafka] → [REST / WS / GraphQL cache]
        ~0            <200ms         <200ms         <500ms         +50–500ms

Per-surface latency

SurfaceTarget p50Target p99Notes
Kafka Streams800 ms2 sClosest to source; used for low-latency pipelines
WebSocket1.0 s3 sSame source as Kafka; adds fan-out overhead
REST (cached)1.5 s5 sCache TTLs vary per endpoint — see each one
REST (uncached)3 s10 sRare; for deep historical lookups
GraphQL2 s6 sJoins multiple products; adds planning time

Per-product refresh

ProductReal-time?Snapshot cadence
Tokens — marketyesprice tick every trade
Tokens — securitydelayedminutes after creation
Tradesyesper block
Poolsyesper event
Wallets — holdingsyesseconds after transfer
Wallets — net worth historynohourly
Candles (OHLC)yesbar closes at interval
Holders (table)yesper transfer
Holders (distribution metrics)noevery 5 min
Smart Money (cohort membership)noweekly (Mon 00:00 UTC)
Smart Money (flow events)yesper trade
Blockchain Coreyesper block
Rankingsyes (most)1 min / block-level
Compliance (KYT / KYA)yeson request

Backfill behaviour

  • Solana / EVM archival data backfilled from genesis where feasible.
  • New chains start with ≥ 30 days of backfill at launch, full history streamed in within the first 90 days.
  • Reorgs cause rewrites of the affected slot/block in all downstream streams; consumers should be idempotent on (chainId, txHash) + logIndex.

Incidents & status

Current incidents and historical uptime live at status.chainstream.io (link to be finalized).

Next

Rate limits

Per-plan throughput limits and headers.

Kafka topic catalog

Exact topic names and retention per chain.