Define whether a crypto tick is a trade, a quote update or an order-book event before storing or replaying it.
Retain venue sequence or trade identifiers when available, along with source and receive timestamps. Two observations with the same price are not necessarily duplicates; their size, side or event identifier may carry distinct information.
Plan for out-of-order arrival and venue-specific recovery. A historical loader should use an idempotent key and expose missing ranges rather than claiming completeness from the first and last timestamps alone.
Bring the proposed instrument list, source documentation and consumer workflow to a technical discussion. The agreed integration specification defines coverage, fields, usage permissions and acceptance tests.
| Dataset definition | Confirm raw ticks, bid/ask events, trades or OHLC bars and the source instrument. |
|---|---|
| Time and ordering | Define UTC boundaries, timestamp precision, sequence ordering and duplicate policy. |
| Quality and gaps | Document missing intervals, corrections and any backfill or normalization applied. |
| Export and retention | Agree format, pagination, permitted storage and the consumers allowed to use the dataset. |
Historical data for digital assets needs an instrument definition and provenance. Tick history, aggregated bars and replay events are different outputs. Record which prices form each bar, how gaps are represented and whether corrections can change an earlier result.