Nanosecond timestamps

We capture nanosecond-resolution timestamps the instant transactions arrive at our Amsterdam shred receiver. Useful when block-level timing isn't precise enough.

The problem with block-level timing

Solana blocks reveal transaction sequence within a block (tx_idx), but not precise arrival timestamps. Trading and MEV happen on millisecond timescales while blocks arrive roughly every 400ms - which means standard block data hides everything that matters about latency.

What we capture

For supported tables, we record an arrival_ts_ns column (or equivalent). It's the time, in nanoseconds, at which the transaction's shred reached our Amsterdam receiver.

How we capture it

A lock-free system on the Amsterdam shred receiver:

1. 1
   Detect and stamp

   Primary thread monitors Geyser entry streams and records timestamps with zero contention - no locks, no buffering between detect and stamp.

2. 2
   Correlate and persist

   Dedicated worker pool handles block correlation and database persistence concurrently in the background.

This split keeps stamp accuracy maximum (nothing competes with the timestamp path) while persistence is decoupled.

Use cases

Caveats

Sample query

Find transactions that arrived in the same slot but with a wide arrival-time spread:

SELECT
    slot,
    count() AS tx_count,
    min(arrival_ts_ns) AS first_arrival_ns,
    max(arrival_ts_ns) AS last_arrival_ns,
    (last_arrival_ns - first_arrival_ns) AS arrival_spread_ns
FROM pumpfun_all_swaps
WHERE block_date_utc = today()
  AND arrival_ts_ns IS NOT NULL
GROUP BY slot
HAVING tx_count > 10
ORDER BY arrival_spread_ns DESC
LIMIT 20

See also