Tardis

The paid crypto vendor — per-day CSV datasets of trades, quotes and the incremental L2 book, one UTC day at a time, with bars derived by resampling the ingested trades.

tardis_backfill ingests Tardis's downloadable CSV datasets. crates/vike-backfill/src/tardis/mod.rs states the lane: intraday trades, quotes and the L2 book — and bars via resample — from datasets.tardis.dev into the vike-data hist store, a sibling of the pmxt and EOD collectors. It is built only under the tardis feature (crates/vike-backfill/Cargo.toml), so the invocation is cargo run -p vike-backfill --features tardis --bin tardis_backfill.

What a run does

From crates/vike-backfill/src/bin/tardis_backfill.rs's usage text:

tardis_backfill --exchange deribit --symbol BTC-PERPETUAL --data-type trades \
    --start 2024-03-01 --end 2024-03-03 [--store DIR] [--venue NAME]
tardis_backfill --exchange deribit --symbol BTC-PERPETUAL --data-type bars \
    --start 2024-03-01 --end 2024-03-03 --interval 5m

--exchange is the Tardis exchange id (binance-futures, deribit), --symbol the instrument on that exchange, and --data-type one of trades, quotes, incremental_book_L2 or bars. --start/--end are inclusive YYYY-MM-DD days. --store resolves through the shared store_root ladder — $VIKE_HIST_STORE, then a $VIKE_SETTINGS_DIR-declared <project>/market_data/hist, then <repo>/market_data/hist when that checkout exists, then the project the working directory sits in, then the per-user vike-data directory; --venue is the label the series is stored under, defaulting to tardis.

bars is not something the vendor serves. The bin header is explicit: Tardis has no native OHLCV series, so --data-type bars ingests trades and then resamples them into --interval OHLCV (default 1m) — real OHLCV with real trade volume — and the trades series is persisted too. The resample is the store's own resample_trades_to_bars, called from the bin.

Transport and ingest

crates/vike-backfill/src/tardis/client.rs builds the per-day .csv.gz URL, authenticates with a Bearer token, and downloads plus gzip-decompresses one day's file. A missing day — HTTP 404 — is Ok(None), not an error, mirroring the pmxt collector's download_hour. crates/vike-backfill/src/tardis/ingest.rs drives the parsers one day at a time under the commit key tardis:{kind}:{symbol}:{YYYY-MM-DD}; backfill_range iterates the requested days and skips the absent ones. Because the unit is a whole UTC day, re-running a day is a store no-op.

The parsers

crates/vike-backfill/src/tardis/parse.rs is pure and fixture-tested, and its header carries the wire facts: timestamps are microseconds, reduced to milliseconds; trade side is buy/sell, where a sell taker means the buyer is the maker. incremental_book_L2 rows are single-level — is_snapshot selects Snapshot over Delta, side routes the level to bids or asks, and amount is the absolute size with 0 meaning the level was removed. A monotonic per-symbol seq is assigned in file order so that scan_book_updates reproduces file order. Column lookup is by name through crates/vike-backfill/src/csvutil.rs's Header, the helper shared with the Databento parsers.

Credentials

TARDIS_API_KEY is optional, and the reason is in the bin header: the first-of-month day is a free, keyless sample, so a run over that day needs no key at all. The bin reads the key and passes it in; the library takes it as a parameter (crates/vike-backfill/src/databento/client.rs's header records that the Tardis adapter always had the bin do the read, and that Databento was brought in line with it). The live smoke is #[ignore]d and runs keyless for exactly that reason — it asks for the first-of-month day (crates/vike-backfill/tests/tardis_smoke.rs's tardis_trades_one_day_roundtrip). Its Databento sibling has no free day to fall back on, so that one self-skips when the key is absent (crates/vike-backfill/tests/databento_smoke.rs).

Where it sits in the capability table

crates/vike-backfill/src/caps.rs's Tardis row is NONE for every roster venue: the comment on it says the vendor writes the tick lane — trades, quotes, incremental_book_L2 — with bars by resample, is crypto-only, and is vendor-namespaced rather than roster-keyed, the same shape as Databento. A gap plan over a roster venue therefore never offers Tardis; you reach it by naming the exchange and symbol yourself, and the --venue label decides which store partition the rows join.

The vendor's exchange id and your venue label are two different strings

--exchange binance-futures chooses what Tardis serves; --venue (default tardis) chooses the store partition. Writing vendor rows under a roster venue's name puts them beside whatever the recorder captured there, and the store dedups by commit key rather than by row value (crates/vike-data/src/datafusion_hist/sources.rs), so a window both covered is doubled until a source-precedence policy resolves it. The Data API page covers that policy.

The kinds these data types write are documented under concepts/data; the equities-and-futures counterpart is Databento.