# ShredPrism customer benchmark, 8 October 2026 (run b): method

Dataset: `shredprism-customer-2026-10-08b.json` (summary) and `shredprism-customer-2026-10-08b.csv`
(matched pairs: every non-trade observation and every 20th trade observation in receipt order).

## Question

How much earlier does a customer receive a ShredPrism early observation than a provider's transaction
notification for the same transaction, at processed and at confirmed commitment?

## Setup

- Client: one server at OVH in Limburg, Germany, a different provider and network from the MadeOnSol
  production server. Node 22, `ws`, `@triton-one/yellowstone-grpc` 7.0.1.
- MadeOnSol feed: the public endpoint `wss://madeonsol.com/ws/v1/early`, reached with a normal ULTRA
  stream token from `POST /api/v1/stream/token`, subscribed to all six channels: `early:deploys`,
  `early:locks`, `early:trades`, `early:liquidity`, `early:migrations`, `early:token_changes`.
  Server versions: early-stream `52b97bf0`, app `dfb5cd79`.
- Reference feeds, received on the same client machine: Kaldera Yellowstone gRPC
  `transactions_status` from Frankfurt, one subscription at commitment PROCESSED and a separate one at
  CONFIRMED. Filter: transactions that include pump.fun, PumpSwap, Streamflow, Jupiter Lock, Bonfida,
  Token-2022 or Raydium LaunchLab; failed transactions included, vote transactions excluded.
- Not measured: token changes on the original SPL Token program. The provider refuses an SPL Token
  filter for `transactions_status`, so there is no reference for them; they are reported, not compared.

## Timing

- Window: 60 s warm-up (discarded), 600 s measured (20:04:44 to 20:14:44 UTC), 30 s tail buffer so
  late reference notifications can still match.
- Every receipt is stamped with `process.hrtime.bigint()` (CLOCK_MONOTONIC) as the message arrives, in
  three separate processes on the same machine, and appended to disk as a compact record during the
  run. The monotonic clock is shared by all processes on the machine.
- Client health is recorded every 5 s (event-loop delay, memory, write backpressure).

## Matching and statistics

- Only `early:observed` events are compared, never the later outcomes.
- A pair is the same transaction signature AND the same slot on both feeds. The first receipt per
  (channel, signature) counts; repeated observations of one transaction in one channel are dropped.
- `token_changes` is split by program (Token-2022, SPL Token).
- `lead_ms = reference receipt - early receipt`. Positive: the early observation arrived first.
  Negative results are kept.
- Percentiles (p5, p50, p95) only with at least 30 matched pairs; otherwise "not sufficiently measured".

## Separation from internal numbers

These are customer-side receipt differences over the public internet. They are not the internal
processing time on our server (receive to publish), which is reported separately on the solution page.

## Limitations

- One client, one location, one provider region, ten minutes. Not a guarantee and not an SLA.
- The reference is a provider notification, not an on-chain block time.
- "Matched" means the transaction appeared on both feeds; it does not measure market completeness.
- The lead distribution has long tails in both directions; read p5 and p95 next to the median.
- 38 `queue_stale` gap frames were received during the run (one burst at 20:10 UTC): observations
  the service dropped as too old; they cannot appear in any pair.