What Is Tick Level Data?

Tick-level data is market data recorded at the smallest observable event level — an individual trade, a quote change, an order-book update, a funding payment, or a settlement — instead of compressed into time-based candles. So when the question is what is tick level data, the short answer is this: it is the raw event stream a market produced, preserved in sequence, rather than a summary of what that stream happened to average out to over a minute, an hour, or a day.

That distinction decides whether a backtest is defensible. A one-minute candle gives you open, high, low, close, and volume. It discards the order of events, the spread at the moment of execution, the depth available to fill an order, and whether one large trade or fifty small ones produced the move. For any strategy where execution timing, liquidity, or microstructure affects the result, those discarded details are the whole point. This guide explains what a "tick" actually is, how the event stream is structured, the timestamp and sequencing traps that quietly corrupt results, and how to decide when candles are enough.

Table of contents

A tick is an event record, not one fixed format

The word "tick" does not name a single standardized message. Its meaning depends on the venue and the provider, and treating every tick as the same object is the first mistake researchers make. A tick can be an executed trade, a change to the best bid or offer, a change at a deeper price level, a full book snapshot, a settlement value, or a funding event on a perpetual contract.

The equities world formalized this vocabulary long before crypto adopted it. The SEC describes trade records as including the symbol, timestamp, execution price, executed quantity, venue, and condition codes, with quote records carrying timestamped best bids and offers plus available quantity. That framework ports cleanly onto crypto and prediction markets, even though every venue ships its own schema. The concept is shared; the field names are not.

How tick data differs from candles in a backtest

Candles are an aggregation. Tick-level data is the underlying event stream, or a provider's closest faithful representation of it. The gap between the two is where profitable-looking strategies go to die.

Suppose a market moves from 100.00 to 100.20 and closes the minute at 100.10. The candle cannot tell you whether the move happened at the start or end of the minute, whether the spread widened before it, whether displayed liquidity was enough to actually trade, whether one large order or many small ones drove it, or whether your strategy would have received the printed price at all. Each of those unknowns changes the outcome. A strategy that looks profitable on closing prices can turn negative once you account for spread, available size, latency, slippage, and the book state at the instant of execution.

Consider a bot that receives a buy signal at 12:00:00.500. A candle-based test fills at the next minute close or an assumed midpoint. A tick-level test instead inspects the latest bid and ask before the signal, the quantity resting at each ask level, the trades that occurred between the signal and the simulated order, the book changes during assumed latency, and the price and size the order could realistically have received. The result is not automatically "correct execution." It is a more defensible simulation, because it uses the market state and event sequence that genuinely existed at that time. That honesty is the entire value proposition.

The three layers of tick-level market data

Most useful tick datasets decompose into three layers, and conflating them is a recurring source of error.

Trades record executions. Common fields are the instrument, execution price, quantity, timestamp, a trade identifier, the aggressor or taker side where available, and venue-specific flags. Trade ticks measure volume and intensity, buy-versus-sell pressure, trade-size distribution, VWAP and realized execution, market impact, and short-term momentum or reversal. A trade feed alone, though, tells you only what traded — not what was resting and available but untouched.

Quotes and order-book updates describe displayed liquidity. A quote covers the best bid and ask; a deeper book carries multiple levels on both sides. An update might say a bid at 0.42 now holds size 1,000, an ask at 0.43 was removed, a new ask appeared at 0.44, or a level was deleted when its quantity hit zero. Binance, for instance, documents separate trade streams and depth streams, with the depth stream supplying level updates for maintaining a local book and update identifiers plus timestamps so consumers apply changes in the correct order. Order-book data is what lets you study spread, depth, imbalance, slippage, price impact, queue behaviour, and execution feasibility. This article keeps the focus on the broad category; for a dedicated walkthrough of bids, asks, depth, snapshots, and updates, see our primer on Polymarket order book data and our trader-focused explainer on order book data for traders.

Reference, funding, and settlement events are the layer most people forget. Crypto-perpetual research may need funding rates, mark prices, index prices, contract metadata, and liquidation-related records where available. Prediction-market research may need contract outcomes, resolution events, settlement prices, market-status changes, and token-to-contract mapping. These fields prevent a classic error: treating an event contract or a perpetual as if it were an ordinary spot asset with nothing but a price series.

Snapshots, deltas, and rebuilding the book

Tick-level feeds generally use two complementary message types, and understanding how they fit together is what separates a usable dataset from a misleading one.

A snapshot carries the full state of the book at a moment, often across many levels. It is what you use to start a historical replay, initialize a local book, recover after a connection gap, validate periodically, or produce point-in-time analytics. A delta carries only the changes since the previous state — adding, modifying, or removing levels. Deltas are efficient because they avoid retransmitting an unchanged book, but they are strictly order-dependent: they must be applied in exact sequence or the reconstructed book drifts from reality. CME documentation draws the same distinction, with incremental messages transmitting only changes while full snapshots re-establish state.

Reliable reconstruction therefore needs far more than prices and sizes. It should preserve sequence numbers, event timestamps, source timestamps where available, snapshot identifiers, instrument identifiers, message type, update action, price and quantity precision, and a gap or recovery status. Strip any of those and the dataset may still look complete while quietly producing a book that never existed. Our live streams documentation describes sequenced book deltas and trade prints with reconnect guidance and heartbeats precisely so consumers can keep that reconstruction honest.

Timestamps, sequencing, and look-ahead bias

A single tick can carry several different times, and they are not interchangeable: event time (when the market event occurred), transaction or matching time (when the venue processed it), publish time (when the venue sent it), receive time (when your client got it), and storage time (when the provider recorded it). Choosing the wrong one silently rewrites history.

A backtest sorted by receive time can accidentally use information that was not available at event time. A delayed or out-of-order feed can make a valid event appear to happen later than it did. Binance documents timestamps in milliseconds by default, with microseconds available on supported streams — but the real decision is not millisecond versus microsecond. It is knowing what each timestamp means and reconstructing the market on one consistent clock.

This is where look-ahead bias creeps in: a backtest uses information that would not have been available at the simulated decision time. It typically arrives through joining a trade to the wrong book state, sorting only by client-receipt timestamp, using a final candle close to simulate an earlier execution, filling at a price that appeared only after the order was sent, ignoring network and processing latency, or using a corrected value without preserving when that correction became known. Tick-level data reduces these risks; it does not erase them. The test still needs explicit assumptions for latency, order type, queue position, partial fills, and fees.

Sequencing matters for a second reason. An incremental book feed is stateful — every update depends on the last. Lose one message and the subsequent deltas may no longer produce a correct book. A robust consumer tracks sequence numbers, detects missing or overlapping ranges, stops trusting the book after a gap, recovers from a fresh snapshot, records the gap in the dataset, and checks that prices, quantities, and sides stay internally consistent. CME documents sequence numbers and snapshot recovery for exactly this repair, and Binance documents update identifiers for maintaining a local book. The lesson is blunt: "real-time" does not mean "complete." A feed can be fast and still useless for research if it drops messages, conflates updates, omits sequence information, or offers no recovery path.

When candles are enough and when they are not

Tick-level data is not automatically the right choice, and defaulting to the most granular dataset is its own mistake — it adds storage, processing, and modelling cost that a long-horizon study may never recoup.

Candles are often sufficient when the holding period runs to days or weeks, when exact execution timing is not central, when signals are daily or hourly, when the question concerns broad returns or volatility, or when simplicity outweighs microstructure detail. Tick-level data earns its cost when the strategy trades frequently, holds briefly, depends on spread or depth for profitability, reacts to individual trades or book changes, needs to simulate limit orders, or tests execution, arbitrage, market making, or liquidity signals. Prediction-market strategies that hinge on contract resolution and order-book conditions around news or settlement fall squarely in this second group.

The guiding rule is to use the smallest granularity that actually answers the research question, not the assumption that more detail is always better. A strategy that only needs daily volatility gains nothing from processing every book update; a strategy that depends on queue position learns nothing from candles.

Criteria for choosing a tick-level dataset

Before committing to a dataset or delivery method, check six things. These are the filters that separate a dataset you can publish results from and one that will embarrass you later.

Coverage. Confirm which venues and which symbols or contracts are included, the historical start date, trading-session or downtime gaps, whether delisted or resolved markets remain available, and whether the data is venue-native or derived.

Granularity. "Tick-level" should never be assumed to mean full order-level data. Ask whether the dataset contains individual trades, top-of-book quotes, full price-level depth, order-level messages, periodic snapshots, incremental deltas, and funding or settlement events. A provider can record trades and level changes without ever exposing individual order identifiers or queue positions.

Ordering and completeness. Look for sequence numbers, gap indicators, duplicate handling, recovery procedures, snapshot-to-delta alignment, and documented treatment of out-of-order messages. Frequency and completeness are separate properties: millisecond timestamps do not prove that no messages are missing.

Timestamp semantics. Verify timestamp units, timezone, event-versus-receive time, precision and rounding, and whether timestamps are exchange-generated or provider-generated.

Delivery format. Match the surface to the workload rather than defaulting to one channel.

Schema consistency. A shared schema makes venues easier to compare, but it must not hide venue-specific behaviour. Check that normalization still preserves native identifiers, contract outcomes, tick size, quantity units, side conventions, funding and settlement semantics, source timestamps, and venue flags. Normalization helps only when the original meaning stays recoverable.

Our platform is built around exactly this layering. We provide timestamped snapshots, deltas, trades, and settlement events through our REST API, live book deltas and prints over WebSocket, daily Parquet/CSV bulk files for notebooks, DuckDB, Polars, and warehouse loads, and MCP access for agents that discover datasets and query markets through tools. We list Polymarket and selected Binance spot and perpetual datasets as live coverage with historical recording from June 2025, and our catalog identifies venue-specific limits, including selected symbols and different availability statuses for Kalshi and Hyperliquid. Because coverage varies by venue, confirm the symbol, contract, date range, and event types you need before locking in a backtest.

FAQ

Is tick-level data the same as real-time data?

No. Tick-level describes the granularity of the records. Real-time describes how quickly they arrive. Tick-level data can be historical, delayed, or live.

Does one tick always represent one trade?

No. A tick may be a trade, a quote change, an order-book update, a snapshot, a funding event, or a settlement event. Always inspect the provider's schema before counting ticks as volume.

Is tick-level data better than OHLCV data?

Not universally. It is better when execution timing, spread, depth, or individual events matter. OHLCV is often more efficient for longer-horizon research.

Can tick data eliminate slippage in a backtest?

No. It makes slippage modelling more realistic, but the model still needs assumptions about latency, order type, queue position, fees, partial fills, and unavailable liquidity.

What is the difference between tick-level data and order-book data?

Tick-level data is the broad category of event-level records. Order-book data is one type of tick, describing displayed bids, asks, and depth. A tick-level dataset can contain trades without containing an order book at all.

Where can I get tick-level crypto and prediction-market data?

We offer access to selected Polymarket, Binance, Kalshi, and Hyperliquid datasets through REST, WebSocket, bulk files, and MCP, subject to the coverage and availability stated in our catalog.