Historical Crypto Data for Backtesting
A practical workflow for constructing crypto history that remains reproducible after symbols, venues, and contracts change.
Historical crypto data is a time series of past market observations tied to a specific venue and instrument. A backtest-ready dataset needs stable instrument identity, venue symbol history, UTC interval rules, spot or derivatives classification, price and quantity units, gap states, listing and delisting history, source lineage, and a frozen cutoff so later backfills do not leak into earlier experiments.
Specify the market, not only the ticker
BTCUSDT can refer to spot, a perpetual contract, or another venue's similarly named instrument. Store venue, market type, base, quote or settlement asset, contract specification, and the original symbol beside every observation.
Do not rebuild an old universe from today's active catalog. Delisted pairs, expired contracts, redenominations, and status changes are part of the historical sample.
Make continuous trading measurable
Use UTC interval boundaries and an expected-interval ledger. Holidays do not explain gaps in a continuously traded market, although venue maintenance, listing times, suspensions, and source outages may.
Preserve raw trades or source bars where permitted, then version normalization and aggregation logic. A historical export should report incomplete windows rather than silently forward-filling them.
- Pin the source venue and market type.
- Retain listing and delisting states.
- Distinguish zero activity from missing collection.
- Freeze the dataset cutoff and schema version.
Test the backtest contract
Validate OHLC relationships, nonnegative quantities, duplicates, UTC boundaries, extreme moves, symbol mappings, funding intervals, and contract expiries where relevant. Compare samples with raw source objects and keep the checks with the research artifact.
Model fees, spread, slippage, funding, liquidation rules, and venue-specific execution separately from market observations. A candle does not prove a fill was available at its high, low, or close.
How DataCedar preserves the evidence
DataCedar separates acquisition from serving. Permitted source responses are retained with retrieval time and identifiers, normalized into DataCedar-owned tables, checked against expected coverage, and exposed through a stable versioned API. A collector can be replaced without changing the customer contract or making an upstream provider a runtime dependency.
Every research stream carries effective and known-at time where the distinction matters. Rights-restricted, unavailable, partial, stale, and genuinely empty states remain visible, so a backtest can fail closed and a buyer can see the product boundary before committing engineering time.
Key takeaways
- 01Identify venue and market type on every row.
- 02Include inactive and delisted instruments in historical universes.
- 03Report continuous-market gaps explicitly.
- 04Freeze source, cutoff, schema, and validation evidence.