Historical crypto tick data is the difference between a backtest that approximates the market and one that can reproduce trades, spread, queue conditions and order-book state. The DN Historical Tick Data Provider Index compares Tardis.dev, Kaiko, Amberdata, CoinAPI and Coin Metrics across raw event fidelity, historical depth, exchange coverage, replay tooling, delivery options and institutional usability.
Tardis.dev ranks first for pure crypto microstructure research and replay because its product is built around raw exchange WebSocket capture, tick-by-tick L2/L3 data, full order-book reconstruction and historical replay. Kaiko is the strongest broad institutional alternative, Amberdata is especially compelling when market data must sit beside derivatives and on-chain intelligence, CoinAPI offers unusually accessible API and flat-file delivery, and Coin Metrics is strongest when market microstructure needs to connect with institutional network and reference data.
DN Evidence Block
- Tardis.dev publishes tick-by-tick L2 and L3 order-book data where available, individual trades, options chains, funding, open interest and liquidations, with data sourced from exchange WebSocket feeds and replayable through Python, Node.js and Tardis Machine.
- Kaiko offers normalized tick-level trades and full order books across more than 100 exchanges, with delivery through REST, streaming, CSV, cloud storage, Snowflake and BigQuery.
- Amberdata documents tick-level trades and order books, over a decade of market-data history, and enterprise delivery through WebSocket, REST, AWS S3, Snowflake and Databricks.
- CoinAPI's archive starts in February 2014 and includes tick-level trades, quotes and order books. Its Flat Files product provides full limit-book updates and snapshots through an S3-compatible interface.
- Coin Metrics exposes raw market trades, quotes and order books through API v4, including exchange, event and collection timestamps that are particularly useful for institutional research and data-quality work.
Author: Decentralised News Research
Methodology: DN Historical Tick Data methodology
Primary evidence: Provider documentation and product pages
The best historical data vendor is not the provider with the longest list of exchanges. For serious backtesting, the critical question is whether the dataset preserves the sequence, timing and state transitions your strategy actually uses. A strategy that depends on queue position, spread changes or liquidation bursts cannot be validated on candles alone.
Why “Historical Crypto Data” Is Too Broad a Category
A one-minute BTC candle is historical data. So is every individual Binance order-book update for the same minute. They are not substitutes.
DN separates historical market data into six levels:
The closer a strategy is to execution, market making or microstructure, the further down that stack it needs to go.
The DN Historical Tick Data Provider Score
| Component | Weight | What DN Measures |
|---|---|---|
| Tick & order-book fidelity | 30% | Raw trades, quotes, L2/L3 updates, sequence/state reconstruction and event granularity. |
| Historical depth | 20% | How far back useful granular data extends, not simply OHLCV history. |
| Venue & product coverage | 15% | Spot, perpetuals, futures, options, liquidations and exchange breadth. |
| Replay & developer tooling | 15% | Python/Node libraries, replay APIs, reconstruction support and local research workflows. |
| Delivery architecture | 10% | REST, streaming, flat files, cloud storage, warehouse integrations and bulk access. |
| Institutional operations | 10% | Normalization, enterprise support, licensing clarity and suitability for production research stacks. |
Best Historical Crypto Tick Data Providers 2027
| Rank | Provider | DN Score | Best For | Key Strength | Main Trade-Off | Status |
|---|---|---|---|---|---|---|
| 1 | Tardis.dev | 98/100 | Microstructure, HFT research, order-book replay | Raw WebSocket capture + L2/L3 reconstruction + replay | Premium full-history access becomes expensive at broad coverage | LIVE |
| 2 | Kaiko | 96/100 | Institutional normalized multi-venue research | Broad CeFi/DeFi coverage and flexible enterprise delivery | Full tick-level institutional tiers are comparatively expensive | LIVE |
| 3 | Amberdata | 94/100 | Market data plus derivatives and on-chain context | Deep order-book history + institutional data stack | Pricing is enterprise-led rather than lightweight self-service | LIVE |
| 4 | CoinAPI | 92/100 | Developer access, flat files and broad exchange normalization | API + S3-compatible historical full-limit-book delivery | L3 availability is limited to selected venues | LIVE |
| 5 | Coin Metrics | 90/100 | Institutional research combining market and network data | Strong timestamp provenance and integration with broader crypto datasets | Less purpose-built for local tick replay than Tardis.dev | LIVE |
1. Tardis.dev: Best Overall for Raw Crypto Tick Replay
Tardis.dev is the most specialized provider in this comparison. Its core proposition is not a generalized analytics API. It is the preservation and replay of the exchange event stream itself.
The platform documents:
- tick-level L2 order-book updates,
- L3 market-by-order data where available,
- reconstructed order-book snapshots,
- individual trades,
- quotes and book-ticker feeds,
- options chains,
- funding and open interest,
- liquidations,
- spot, perpetual, futures and options instruments.
Tardis says its historical data is collected from exchange WebSocket feeds rather than by periodically polling REST endpoints. That distinction matters for event-driven backtesting because a REST snapshot can miss hundreds or thousands of intermediate book states.
The strongest feature: time-machine-style replay
Tardis provides Python and Node.js libraries plus Tardis Machine, a local server designed to replay historical exchange feeds in a form that resembles live data.
That makes the provider especially attractive when a research team wants one strategy code path for both:
- historical simulation, and
- live exchange data.
Its public product page now advertises more than seven years of high-frequency history, more than 200,000 spot and derivatives instruments and over 20 trillion tick-level L2 updates. Access to the full back history depends on billing plan: lower plans advertise four years with yearly billing and five years with invoicing, while the Business tier can unlock all available history with annual billing.
For a market-making model, liquidation strategy, lead-lag engine or execution simulator, that replay architecture is more important than a glossy dashboard.
2. Kaiko: Best Institutional Normalized Market-Data Stack
Kaiko is broader. It has supplied crypto market data since 2014 and positions its Level 1 and Level 2 products around institutional trading, risk, transaction-cost analysis and backtesting.
The current public product page says it covers more than 100 exchanges across centralized and decentralized markets and supports:
- all trades at tick level,
- best bid and ask,
- raw order-book snapshots,
- full bids and asks,
- liquidations,
- market-depth and slippage analytics,
- spot and derivatives markets.
Delivery is unusually flexible:
- REST API,
- live stream,
- CSV through AWS, Azure and Google Cloud,
- Snowflake,
- BigQuery.
The distinction between product tiers matters. Kaiko's public page lists Level 1 tick-level access from $1,500 per month and Level 2 tick-level access from $2,500 per month. Its full bids-and-asks cloud files are tick-level and currently show history from August 2023, while minute-style raw order-book snapshots extend further back on supported exchanges.
For an institution that wants normalized multi-venue data delivered into an existing cloud warehouse rather than operating a local replay server, Kaiko is exceptionally strong.
3. Amberdata: Best for Joining Tick Data With Derivatives and On-Chain Context
Amberdata is compelling because the market-data layer is only part of the platform. Its institutional stack also includes blockchain and derivatives intelligence.
The company's current market-data materials describe:
- full order-book events and tickers,
- aggregate order-book snapshots,
- tick-level trades,
- OHLCV, VWAP and TWAP,
- funding rates and open interest,
- liquidations,
- real-time and historical asset and pair prices.
Amberdata says its platform contains more than a decade of market-data history, while earlier product documentation specifies tick-level order-book history dating back to 2017.
Delivery spans:
- real-time WebSockets,
- REST,
- bulk AWS S3,
- Snowflake,
- Databricks.
This matters when the strategy does not stop at the order book. A volatility desk may want:
- spot trades,
- options surfaces,
- funding,
- liquidations,
- and on-chain flows
inside the same broader research environment.
4. CoinAPI: Best Flexible Developer Access to Historical Flat Files
CoinAPI has one of the deepest openly documented archives in this group. Its FAQ says the market-data archive begins on 24 February 2014 and includes tick-level trades, quotes and order-book data where available.
The Flat Files product is particularly useful for systematic researchers because it exposes:
- Trades,
- Quotes,
- Full Limit Book data,
- periodic 50-level snapshots,
- depth-band summaries,
- OHLCV.
CoinAPI describes the full limit book format as a snapshot followed by every update, allowing the book to be reconstructed over time. Flat Files use an S3-compatible API, which is easier to integrate into commodity research infrastructure than a vendor-specific download client.
CoinAPI also double-timestamps trade and quote data using exchange and CoinAPI timestamps, which is valuable for latency and data-quality analysis.
The L3 caveat
CoinAPI's current FAQ says full Level 3 order-book data is available only for selected exchanges, currently Bitso and Coinbase. That prevents it from taking the top spot for universal queue-level research.
For L2 work, however, its combination of REST, WebSocket, FIX and flat files makes it one of the most practical general-purpose options.
5. Coin Metrics: Best When Market Data Must Connect to Network Data
Coin Metrics is less narrowly focused on replay and more oriented toward institutional crypto data infrastructure. That can be an advantage if the research question crosses market and blockchain layers.
Its API v4 exposes raw:
- market trades,
- quotes,
- order books,
- funding rates,
- open interest,
- liquidations,
- options-related metrics.
A particularly valuable feature is timestamp provenance. Market order-book objects can contain:
- market event time,
- database time,
- collection time.
Those fields help researchers distinguish the exchange event from the moment a vendor received or stored it. That is useful for validating the sort of lead-lag and execution-quality studies DN has been building.
Coin Metrics also has the advantage of placing market data beside network, asset, index and reference-rate datasets. A fund researching whether exchange microstructure changes after on-chain flows or protocol events can keep those signals inside one institutional environment.
Decision Matrix: Which Provider Fits Which Research Problem?
| Research Need | Best Fit | Why | Avoid If |
|---|---|---|---|
| Tick-by-tick order-book replay | Tardis.dev | Replay-centric tooling and raw exchange-event preservation | You mainly need aggregated BI data and cloud dashboards |
| Institutional normalized multi-venue data | Kaiko | Broad exchange coverage, normalization and warehouse/cloud delivery | You are a small researcher with a tight budget |
| Market + derivatives + on-chain stack | Amberdata | Combines order books, derivatives and blockchain context | Your sole requirement is inexpensive raw tick replay |
| API + bulk flat files | CoinAPI | S3-compatible archive plus REST/WebSocket/FIX | You require L3 across many exchanges |
| Market + network research | Coin Metrics | Strong market timestamps plus broader institutional crypto datasets | Your workflow is purely local HFT replay |
What a Quant Actually Needs From Tick Data
The correct vendor depends on the strategy. DN would not use the same dataset for a daily factor model and a market-making simulator.
| Strategy | Minimum Data | Preferred Data | Why |
|---|---|---|---|
| Momentum / trend | Trades or fine OHLCV | Trades + top of book | Spread and execution filters improve realism |
| Cross-venue arbitrage | Quotes | Tick trades + synchronized L2 | Need to model which price was actually executable |
| Market making | L2 | L3 where available | Queue state and book transitions determine fills |
| Liquidation strategies | Trades + liquidation feed | L2 + mark/index + funding + liquidations | Need to separate forced flow from ordinary trading |
| Options research | Trades + quotes | Full option chain + Greeks/underlying state | Surface state matters more than standalone prints |
| Execution simulation | L2 snapshots | Incremental L2/L3 event stream | Static snapshots understate path-dependent impact |
The Hidden Problem: Historical Data Can Be Correct and Still Be Wrong for Your Backtest
A file can contain accurate exchange events and still generate unrealistic results if the backtest processes them incorrectly.
Common failure modes include:
- using exchange timestamp for one venue and receive timestamp for another,
- sorting events that share the same timestamp in the wrong sequence,
- starting from an incomplete order-book snapshot,
- ignoring dropped or duplicated updates,
- treating a quote as executable for the entire sampling interval,
- using candles to simulate a strategy that reacts inside the candle,
- assuming a historical trade occurred at a price your order could also have received.
DN rule: the closer the strategy is to the matching engine, the less acceptable aggregated data becomes.
The DN Tick Data Integrity Test
Before trusting a vendor dataset, test one liquid market over a short period. For example, BTC-USDT perpetual on a major exchange.
DN recommends five checks:
- Book reconstruction: can snapshots plus updates reproduce a continuous non-crossed book outside genuine exchange anomalies?
- Trade reconciliation: do trade counts and volume approximately reconcile with the exchange's published higher-level totals?
- Sequence continuity: are gaps detectable rather than silently hidden?
- Timestamp sanity: are exchange and vendor timestamps internally monotonic enough for the intended study?
- Corporate-action / symbol history: can the dataset distinguish renames, contract migrations and delisted instruments?
DN Tick Data Fit Calculator
The tool below does not invent a universal winner. It maps a research requirement to the documented strengths of the five providers.
Choose a Historical Data Stack
Best Fit: —
Ask for a sample of the exact market you will backtest.
Do not evaluate a provider from BTC spot screenshots if your model will trade altcoin perpetuals or options. Download a representative day for the exact exchange, symbol and data type, then run the DN integrity checks before signing an annual contract.
Pricing: Compare Data Scope, Not Just Monthly Subscription
Tick-data pricing is difficult to compare because plans differ by:
- number of exchanges,
- asset class,
- history window,
- transfer allowance,
- API versus flat-file access,
- support level,
- redistribution rights.
Tardis currently publishes self-service pricing. Its plans vary by product set and billing period, with solo and professional tiers aimed at individual quants and small prop firms and higher Business pricing for broad full-history access.
Kaiko also exposes starting prices on its Level 1/Level 2 product page, including Level 1 tick-level from $1,500 per month and Level 2 tick-level from $2,500 per month.
Amberdata and Coin Metrics remain more enterprise-sales oriented, while CoinAPI combines subscription/API access with usage-credit flat files.
How Much Storage Does Tick Data Need?
The answer can move from gigabytes to terabytes quickly. A full order book on BTC or ETH during a volatile period can produce orders of magnitude more records than a one-minute candle series.
Tardis says it receives more than 15 TB of new market data per day across its entire collection estate. That is not the size of one user's dataset, but it illustrates the scale difference between tick capture and ordinary historical price APIs.
For research architecture, DN recommends:
- store original immutable raw files,
- build compact derived Parquet or columnar datasets,
- partition by exchange / symbol / date,
- store reconstruction checkpoints for order books,
- version all normalization logic,
- never overwrite the raw source when correcting a derived dataset.
Historical Replay vs Historical Query
These sound similar but solve different problems.
A query API answers:
“Give me trades between 10:00 and 10:05.”
A replay system answers:
“Feed my strategy those historical messages in the original order as though the market were live.”
The latter is more useful for:
- event-driven engines,
- stateful order-book models,
- execution simulation,
- strategy code shared between research and production.
This is the core reason Tardis takes first place in DN's microstructure-specific ranking.
DN Alpha Thesis: The Data Vendor Becomes Part of the Strategy
At high frequency, the dataset is not a neutral input. Its timestamping, gap policy, normalization and reconstruction logic become part of the trading model.
Two teams can run the same strategy idea on “Binance BTC tick data” and get different results because:
- one dataset captured every incremental book update,
- one reconstructed snapshots every 100 milliseconds,
- one uses exchange time,
- one uses receive time,
- one repairs packet gaps,
- one silently omits them.
This is why provider selection should be documented in the same methodology file as transaction costs and execution assumptions.
What DN Should Measure Next
The next version of this index should move from documented readiness to a matched empirical test.
| Test | Method | Primary Output |
|---|---|---|
| Trade completeness | Compare identical BTC market/day across vendors | Missing/duplicate trade rate |
| Timestamp divergence | Compare common exchange events | Median/P95 timestamp difference |
| Order-book reconstruction | Replay same L2 day | Crossed-book errors and gap rate |
| Download throughput | Retrieve fixed 100 GB-equivalent sample | Effective MB/s and setup friction |
| Schema stability | Compare fields across exchanges | Normalization burden |
| Backtest reproducibility | Run same execution model on all usable feeds | P&L / fill divergence caused by data |
Future DN Tick Data Dataset
What Would Change the Ranking?
- A provider expands or removes L2/L3 coverage.
- Historical access windows or licensing terms change materially.
- Replay tooling improves or degrades.
- Exchange-native sequence and timestamp fields are no longer preserved.
- Cloud or flat-file delivery becomes materially easier or more restrictive.
- DN's observed completeness testing shows persistent gaps or reconstruction failures.
- A provider changes operational status or discontinues a major data product.
Methodology & Limitations
The DN Historical Tick Data Provider Score is a modelled research-readiness framework based on current public product documentation, provider FAQs and API specifications.
It does not claim that DN has independently audited every historical file or measured actual completeness across all exchanges. Provider marketing claims such as total event counts, completeness percentages and dataset size are treated as provider-reported unless independently measured.
The score weights:
- tick and order-book fidelity 30%,
- historical depth 20%,
- venue and product coverage 15%,
- replay and developer tooling 15%,
- delivery architecture 10%,
- institutional operations 10%.
The ranking is optimized for systematic trading, microstructure analysis and realistic backtesting. A user who needs only daily prices, tax data or portfolio analytics should not use this ranking as a general market-data recommendation.
Evidence Classification
| Classification | Meaning |
|---|---|
| Provider-reported | Coverage, history, pricing or architecture stated by the vendor. |
| Modelled | DN readiness scores and provider-fit conclusions derived from documented capabilities. |
| Calculated | Values derived from published prices or user-entered assumptions. |
| Observed | Direct matched DN dataset testing. No cross-provider completeness ranking is claimed in this edition. |
Related DN Research
FAQ
What is the best historical crypto tick data provider?
For raw crypto microstructure and replay, Tardis.dev ranks first in DN's 2027 methodology. Kaiko is the strongest institutional normalized alternative. The correct choice depends on whether you need L2/L3, cloud delivery, on-chain data, derivatives or local replay.
What is tick data in crypto?
Tick data records individual market events rather than aggregating them into time bars. Depending on the dataset, ticks can include trades, quote changes, order-book updates, liquidations, funding events and other exchange messages.
Do I need L2 order-book data for backtesting?
Not for every strategy. A slow momentum model may work with trades or bars. A strategy that depends on spread, market impact, queue state or intrasecond execution should use order-book data.
What is L3 crypto order-book data?
L3 is market-by-order data. Where an exchange exposes it, individual resting orders can be identified rather than only aggregated size at each price level. It is useful for queue and market-making research.
Why is historical replay useful?
Replay lets an event-driven strategy consume historical messages in sequence as though they were arriving live. This can reduce differences between research code and production code and enables stateful book reconstruction.
Can tick data guarantee a realistic backtest?
No. Realism also depends on latency, queue position, fee assumptions, order logic, dropped-message handling and whether the model assumes fills that were not actually available to the simulated order.
Primary Research Sources
- Tardis.dev — tick-level L2/L3, trades, options, funding, liquidations, WebSocket-source methodology, replay and current pricing.
- Kaiko Level 1 & Level 2 Data — tick trades, full order books, historical coverage, cloud delivery and public tier starting prices.
- Amberdata — enterprise historical and real-time market, derivatives and blockchain data.
- CoinAPI Market Data FAQ — archive start date, tick timestamps, order-book reconstruction and L3 limitations.
- CoinAPI Flat Files — S3-compatible trades, quotes and full limit-book datasets.
- Coin Metrics API v4 — raw market trades, quotes, order books, timestamps and coverage catalog.
Change Log & Corrections
15 October 2026: First 2027 methodology edition. Verified current historical-data and delivery capabilities for Tardis.dev, Kaiko, Amberdata, CoinAPI and Coin Metrics. Added the DN Historical Tick Data Provider Score, Tick Data Integrity Test and interactive provider-fit calculator.
To flag a product change or provide primary-source evidence for a correction, use the Decentralised News contact page.
Final Takeaway
For most quant teams, the real question is not:
“Who sells historical crypto data?”
It is:
The DN principle: candles describe what happened. Tick data lets you test how it happened.
Risk disclosure: Historical data can contain gaps, exchange errors, corrected records and vendor-specific normalization decisions. Backtested performance can differ materially from live results because of latency, queue position, fees, slippage and execution uncertainty. This research is educational and is not financial or investment advice.
