# Nanosecond timestamps

> Sub-millisecond arrival timestamps captured at our Amsterdam shred receiver. For MEV and microstructure analysis.

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

<Tip>
**When this matters:** MEV analysis, market microstructure research, comparing on-chain execution to centralized-exchange fills, transaction-propagation studies. If you're working in milliseconds, block-level timing is too coarse.
</Tip>

## 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.

<Warning>
This is **arrival time at our receiver**, not the time the transaction was created. Adjust for your geographic offset if you're correlating with another data source.
</Warning>

## How we capture it

A lock-free system on the Amsterdam shred receiver:

<Steps>
  <Step title="Detect and stamp">
    Primary thread monitors Geyser entry streams and records timestamps with **zero contention** - no locks, no buffering between detect and stamp.
  </Step>
  <Step title="Correlate and persist">
    Dedicated worker pool handles block correlation and database persistence concurrently in the background.
  </Step>
</Steps>

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

## Use cases

<CardGroup cols={2}>
  <Card title="Benchmark vs CEX" icon="scale-balanced">
    Match arrival time to off-chain quote timestamps to compare on-chain execution against CEX fills.
  </Card>
  <Card title="Quantify network latency" icon="gauge">
    Distance between transaction creation (your logs) and arrival at our receiver.
  </Card>
  <Card title="Propagation behavior" icon="diagram-project">
    Correlate `arrival_ts_ns` with `slot` and `tx_idx` to map propagation patterns.
  </Card>
  <Card title="Microstructure models" icon="chart-line">
    Build models grounded in real arrival timing rather than block-level approximations.
  </Card>
</CardGroup>

## Caveats

<Warning>
- **Reference point is Amsterdam.** If your application or exchange runs elsewhere, factor in the geographic offset between your location and AMS.
- **Nanosecond resolution, not nanosecond accuracy.** The clock has nanosecond precision but real-world variance is microsecond-level - which is still far better than block-time granularity.
- **Available on tables that have shred-level data.** Not every table carries `arrival_ts_ns`. Check the per-table schema.
</Warning>

## Sample query

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

```sql
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

<CardGroup cols={3}>
  <Card title="Database schema" icon="database" href="https://supanode.xyz/docs/solana/indexer/database-schema">
    All columns including `arrival_ts_ns`.
  </Card>
  <Card title="Access" icon="key" href="https://supanode.xyz/docs/solana/indexer/access">
    Connection and code samples.
  </Card>
  <Card title="Raw Shreds" icon="bolt" href="https://supanode.xyz/docs/solana/shreds/raw">
    Same upstream feed, raw UDP.
  </Card>
</CardGroup>