How to Run a One-Symbol Parity Test Before You Migrate Historical Data

Hyperliquid historical-data evaluations get messy when everything changes at once. A one-symbol parity run keeps the comparison bounded: use one market, one historical window, one study you plan to rerun, and one record of the native and managed results.

If you have not read the full comparison yet, start with Hyperliquid Historical Data API for Backtesting: Native API vs 0xArchive. This guide shows how to run the evaluation before deciding whether to migrate.

Short answer: hold one symbol, one window, and one downstream study constant. Compare the exact span returned, timestamp boundaries, gap behavior, and the repeated setup required on the second pass. Record the differences and repeated setup, then select the source that meets the study’s requirements.

In 30 Seconds

• Treat parity as one controlled comparison, not a migration plan.

• Record the first and second runs separately so repeated setup is visible.

• Keep source responses and 0xArchive request IDs beside the same UTC window so you can explain differences without rebuilding the study.

• Compare explainable differences and repeated setup, not just whether both sides returned rows.

Before you start

• Inspect the native response caps and rate limits so you know what extra pagination, retries, deduplication, or replay preparation the venue path requires.

• Check the matching 0xArchive coverage and routes before you compare outputs.

  Check symbol coverage with gaps for the same venue family, symbol, and UTC window used in the row comparison.

• Read the replay and checkpoint docs first if your study depends on reruns or event-window reconstruction.

Why one symbol is enough to learn something real

Broad tests create their own noise. Add multiple symbols, multiple windows, and multiple downstream transforms and it becomes hard to tell whether managed history helped or the setup simply changed. A one-symbol test isolates one useful question: does the comparison produce a rerunnable study with fewer hidden moving parts?

Choose a study you can rerun. A single notebook run can hide manual work, so record every step required to repeat it.

What must stay constant

• Symbol: pick one market only, ideally active enough to expose boundary issues.

• Window: use the exact same start and end timestamps on both sides.

• Downstream study: compare the same study output, not two different transforms.

• Field mapping: agree on which fields matter before you pull data.

• Anomaly fallback: keep native venue responses as the reference check for suspicious timestamps.

Compare delivery formats without assuming parity

REST history, historical replay and Parquet can have different windows, finalization states and dataset availability. Match grain, field meaning, depth and time boundary before comparing rows. A matching count alone does not show equivalent data.

Parity scorecard

What not to compare first

• Do not start with multi-symbol tests. They multiply ambiguity before you learn anything.

• Do not compare transformed strategy outputs before you compare raw historical boundaries.

• Do not declare a winner from a first-run screenshot. The second run reveals the repeated setup.

Record each source in a manifest

Keep one entry per compared source. A single shared observed start or finalized-through value cannot describe a disagreement. This is a local research file, not an API response.

{
  "study_id": null,
  "comparison_rule_version": null,
  "registered_windows": [],
  "rights_reference": "https://0xarchive.io/policies/data-license",
  "results_status": "not_run",
  "sources": [
    {
      "source_label": "A",
      "surface": null,
      "venue_family": null,
      "deployment": null,
      "raw_symbol": null,
      "hip4_outcome_id": null,
      "hip4_side_coin": null,
      "schema": null,
      "schema_version": null,
      "finalization_state": null,
      "finalized_through_utc": null,
      "depth_limit": null,
      "truncated": null,
      "observed_start_utc": null,
      "observed_end_utc": null,
      "request_ids": [],
      "cursors": [],
      "files": [{"uri": null, "bytes": null, "sha256": null}]
    }
  ],
  "window_outcomes": [
    {"window_utc": null, "outcome": "both_present | A_only | B_only | neither", "reason": null}
  ]
}

Null means not yet measured, not zero or unavailable. Fill each source entry from that source's own surface. For HIP-4, keep the canonical outcome and the side coin.

Sample selection and parity protocol

Freeze all eligible symbol, schema and window tuples within each advertised deployment before drawing a sample. Stratify by family, schema and early versus recent period, and include delisted or settled records when eligible. Register the eligible market, schema, surface and calendar windows before inspecting whether either source returned data. For each selected window record both present, A only, B only, or neither, with the reason where known. Use the earliest and latest common minutes separately to demonstrate the procedure. For any generalization, publish the full eligible and selected denominators and expand beyond the two fixtures.

Match one-to-one by contracted event identity where available. For timestamp, price and size matches, retain multiplicity and mark non-unique matches ambiguous. Define the timestamp tolerance before reading outcomes, and report exact and tolerance-only matches separately. Count source-A-only, source-B-only, duplicate, contradictory, unmatchable and ambiguous observations. Declare whether each denominator is rows, snapshots, orders, seconds or eligible windows. Do not read no-trade spacing as a capture gap. Finalization lag is separate from missing retained history.

Run order that avoids fake wins

1. Choose one symbol and one historical window you are likely to revisit.

2. Write down the exact study output you care about before you pull anything.

3. Pull the native window first and note every pagination, retry, deduplication, and replay-preparation step you needed.

4. Pull the matching managed route and compare returned span, boundaries, and obvious gaps.

5. The native pull remains the dispute fallback even if the managed path wins on convenience.

6. Rerun the same study a second time from both sides and measure how much setup you had to repeat.

7. Decide from the recorded comparison, not from how pleasant the first API response felt.

Ledger template

parity_ledger = {
  "symbol": "BTC",
  "window_start": "2026-01-15T00:00:00Z",
  "window_end": "2026-01-16T00:00:00Z",
  "native_first_ts": "...",
  "managed_first_ts": "...",
  "boundary_delta_notes": [],
  "gap_checks_run": 2,
  "second_run_glue_removed": ["paging", "replay_prep"]
}

Evaluation and Decision

• Resolve parity differences: verify timestamp boundaries and field mappings when outputs differ. Record the steps required to repeat the study.

• Choose Build: the managed path shortens the second run, preserves a clean native fallback, and makes replay or checkpoint work easier to reproduce.

• Choose Pro for capacity: Use the test to size credits, concurrent requests, and replay speed for recurring workloads. For order-level analysis, use the depth decision framework to choose the depth. Choose a plan for the history window and capacity you need.

Create a key and run the same parity test twice on the planned study. Compare the returned span, boundaries, gaps, and repeated setup.

Sources

• Hyperliquid Docs: Info endpoint

• Hyperliquid Docs: Rate limits and user limits

• 0xArchive REST API docs

• 0xArchive WebSocket backtesting docs

• 0xArchive sign up