Which crypto backtesting data do you need: candles, trades or order books?

Should a crypto backtest use OHLCV candles, trades or order books?

An OHLCV bar gives open, high, low, close and volume for a fixed interval. It can support a rule whose inputs are only completed bars and whose execution assumptions are explicit. Individual trades add transaction sequence and signed-side proxies where supplied. Order-book snapshots or updates add visible resting liquidity and spread. These data families answer different questions; a provider's 'historical crypto data' label is insufficient to establish fit.

Tick detail creates storage and synchronization work. It is necessary only when the research conclusion depends on intrabar sequence, depth, spread or execution. Even a full historical book cannot tell exactly where an unplaced hypothetical order would have sat in the queue without a fill model and venue rules.

Verify: Binance public OHLCV and trade fields · Specialist tick and order-book data types

What changed when the same BTC rule used 5m, 15m and 1h data?

All three BTC presets produced negative net account returns; faster presets traded more and incurred more modeled costs, but the experiment changed EMA calendar horizons too and cannot isolate frequency as the cause. The frozen test uses Binance BTCUSDT spot from 2025-09-25 06:00 UTC to 2026-09-25 06:00 UTC, exclusive end. It applies the same EMA9/EMA21 long-only crossover definition to each completed-bar interval, enters at the next open, permits a 2% stop and 4% target, and charges 5 basis points commission plus 2 basis points adverse slippage per fill. The 15m bars are rebuilt only from complete groups of three 5m bars; warmup is outside the score window.

The 5m test produced 2,516 trades and −18.99% net account return, 15m produced 819 and −6.72%, and 1h produced 191 and −0.67%. These are three different clock-time EMA horizons, not merely three compressions of an otherwise identical trade. The 1h result was least negative here; no causal or future superiority claim follows.

Verify: Frozen three-timeframe result JSON · Full BTC interval and trade study · Deterministic reproduction script

Does higher-frequency crypto data make a backtest more accurate?

More detail can resolve a question that coarse data cannot, but it cannot repair an incorrect universe, leaked future feature, unrealistic fee, missing observation or unfilled order. If both stop and target lie within one OHLC bar, their true sequence is unknown from that bar; the BTC example deliberately resolves ambiguous touches stop-first. Trades may clarify sequence if complete, while realistic fills still require execution assumptions and often order-book information.

In the fixed example the 5m policy traded about 13.2 times as often as the 1h policy and incurred materially more modeled commission. Doubling both fee and slippage assumptions worsened net account returns to −36.64%, −12.42% and −1.99% respectively. Faster signals without a measured edge can simply create more cost.

Verify: Frozen protocol and cost sensitivity · Order-type and book-cost example

What should a backtesting data vendor specify before you buy?

Request instrument identity, venue, historical eligible symbols, timestamp unit, event versus arrival time, exchange timezone, exact interval semantics, missing-bar policy, source corrections, file version and sample dates. For derivatives also pin contract type and funding/OI units. A daily ZIP and a live API response may represent different observation times; do not concatenate without a documented overlap policy.

If the strategy relies on trades or order books, ask whether the supplier distributes exchange-native messages, normalized records or both, and how sequence gaps are flagged. The same word 'tick' may refer to individual trades, quote changes or depth updates. A sample for the exact symbol and old date you need is more informative than a headline row count.

Verify: Binance public data field and timestamp documentation · Tardis exchange-native and normalized formats · Supplier quality checklist

Which CoinNudge data is actually available for a backtest?

The public BTC three-timeframe study supplies the frozen inputs and replay evidence required to check that particular experiment. It is separate from the paid pack catalogue, and its files do not grant access to all internal raw history.

CoinNudge's new historical purchases are fixed-edition research data packs, bought once rather than renewed monthly. The purchased edition provides its listed downloadable files and 90 days of hosted download/optional API access; downloading does not require an API key, and an API does not add real-time data or unpurchased families. Later editions are separate purchases. Check the sole coverage catalogue for the exact pack, fields, instruments, dates and published status. Existing legacy customers retain their original rights.

Processed historical feature or label files are not automatically a raw multi-year candle archive, a complete point-in-time record or a tick-by-tick execution feed. Match the catalogue's file families to the strategy's necessary inputs. If order-book sequence or historic queue modeling is essential and not listed, that requirement remains unmet regardless of how many candle or feature rows are available.

Verify: Single dataset coverage catalogue · Public BTC example evidence · Current paid plan entitlements

Which extra data does a funding-rate or open-interest backtest require?

Add actual funding settlements, the contract's notional convention and the OI quantity definition when those are part of the question. A predicted rate is not the final payment; a dollar OI value can rise because price rose even when contract quantity did not. Candles alone cannot supply that distinction.

Identify venue, contract, settlement time, rate unit and exposure active at each payment. For OI, preserve raw quantity and conversion information, then align only a record available by the decision time; keep unavailable or delayed OI as missing rather than carrying a later number backwards. Spot and perpetual symbols can share a ticker while representing different tradable products.

Select the pack or source only after those fields and actual historical coverage match. A price-strategy study that ignores these costs must remain labeled a spot or simplified paper test, not a leveraged derivatives performance result.

Verify: Historical funding and OI data selection · Exact published research-pack coverage

How do you validate crypto backtest inputs before the full replay?

Run a preflight on the most demanding interval first: verify identity, closed-bar boundaries, ordering, duplicates and a complete UTC grid, then reconcile one aggregated bar and one cost-sensitive trade. A successful file download is not the pass condition.

For 15m derived from 5m, require three contiguous closed inputs in the same 15m bucket: first open, maximum high, minimum low, last close and summed volume. If an input is missing, flag the bucket rather than treating two bars as a complete three-bar candle. For event-driven data, inspect sequence gaps and arrival-time ordering instead of fabricating fixed-grid rows.

Next challenge an ambiguous stop/target bar, a missing interval and a symbol boundary. State whether each produces an explicit conservative assumption, a skipped trade or HOLD. Store the schema, exclusions and input hashes with the run; buy finer data only if the remaining uncertainty can materially change the question's answer.

Verify: Frozen BTC candle coverage and deterministic replay · BTC test input and execution protocol

How do I choose the cheapest data that can answer my crypto research question?

Define the strategy first: decision interval, required fields, hold length, stop and target, order type, venues, years and eligible assets. Then choose the coarsest history that still observes the crucial event and test one difficult date. A data sample fails if it cannot explain a missing interval or if a purported pre-trade feature was not available at the decision time.

Calculate storage and ingestion burden after validating scientific fit. A one-hour portfolio question may start with free candles. An event-and-outcome study may use a processed event release. Intrabar execution work can justify trade and depth history, but needs a separate source and fill model. Preserve exact source and release versions whichever path you choose.

Verify: Evaluate actual CoinNudge product coverage · Check a real event-row sample

Frequently asked questions

Sources and verification

• CoinNudge frozen BTC three-timeframe studyCommon one-year inputs, trade counts and modeled outcomes.
• CoinNudge calculation protocolSignal, fill, cost and ambiguity rules.
• Binance public archiveOfficial data types, intervals and timestamp units.
• Tardis historical data FAQSpecialist trade and order-book format distinctions.

Choose data by the decisions your backtest must reconstruct.

Use the public BTC replay to test assumptions, then verify the exact dates, intervals and entitlements of any dataset you plan to buy.