How Much Data Does an Up/Down Trading Bot Need?

Every supervised model for short-horizon event contracts — will BTC close this 5-minute window up or down? — is bounded by a number most builders never compute: how many independently settled windows exist at all. This guide puts real numbers on that budget using the CryptoStruct archive of Kalshi and Polymarket tick data, and lays out a data plan that avoids the two classic failure modes: too little history, and leaked history.

The collection trap: why you cannot API your way to a dataset

The obvious plan — subscribe to the venue's API and start recording — has a structural flaw: it only moves forward. A market that settled yesterday no longer streams; its order-book evolution is gone unless someone recorded it live. Short-interval series make this brutal: each 5-minute market exists for minutes and is replaced by the next one. Start recording today and in three months you have three months — while the model next door trains on a year.

This is what series-day bundles exist for: one bundle contains every contract file of a series for one UTC day — for Polymarket BTC 5m that is ~577 files covering all 288 windows, tick-by-tick trades plus full L2 order-book depth, recorded co-located with exchange timestamps. History becomes something you buy per day (€1), not something you wish you had started recording earlier.

How many training examples a series actually produces

For fixed-interval up/down markets the arithmetic is merciless: windows per day × days of history. Nothing about your feature engineering changes the left factor — only choosing a faster series or buying more history does.

As a rough calibration: classical tabular learners (logistic regression, gradient boosting) start behaving sensibly in the thousands of examples; anything representation-heavy wants far more. On that scale a 4h series with 2,190 windows per year is a feature-engineering exercise, not a deep-learning dataset — while a 5m series crosses 100k windows in a single year. Whatever you train, more independent windows across more market regimes beats more parameters.

A window is more than a label

Each settled window contributes one label — but the tick file behind it contains the entire path: every trade with price, size and side, and every L2 order-book change, at nanosecond timestamps. That is where features live: odds mid and its velocity, book imbalance, trade-flow direction, time-to-settlement interactions. On the Kalshi 15m series alone that is ~437k trades per day to learn microstructure from, and the hourly strike ladder adds cross-strike structure — an implied distribution, not just one probability.

Split by time, or leak by construction

Adjacent windows are not independent samples: the 14:05 and 14:10 BTC windows ride the same underlying price path, the same volatility regime, often the same news. Randomly shuffling windows into train and test therefore leaks the near future into training, and validation scores inflate accordingly. The honest protocol is walk-forward: train on a contiguous past, validate on the contiguous next block, roll forward — and purge or embargo observations whenever feature or label horizons overlap. Derive the minimum gap from the maximum feature lookback plus the label horizon, and add separation when residual serial dependence remains.

Define labels from settlement rules, not from your chart

Each venue settles against a specific reference (its own index computation, at a specific cutoff, with specific rounding). Recompute your label from the venue's settlement rule — do not eyeball "close > open" on a candle from a different exchange, or a slice of your labels will simply be wrong, and wrong labels are noise you paid for. Derive labels from the venue's official settlement or resolution metadata and the contract's settlement rule — never infer the final outcome from the last traded price alone.

Data playbook

1. Pick the horizon to match your label budget: 5m/15m series for ML-scale datasets, hourly ladders for distribution signals, 4h+ only with strong priors.
2. Start with free full-day samples — one complete Kalshi and Polymarket contract day each — to build and test your parser before spending anything.
3. Buy history per regime, not per calendar: cover at least one violent repricing period and one quiet period per season of data.
4. Extract features from the book path (mid, imbalance, trade flow), not only from the final odds — the label is one bit; the file is the signal.
5. Validate walk-forward, purging or embargoing wherever feature or label horizons overlap; report performance per regime slice, never as one pooled number.
6. Recompute labels from settlement rules inside the files; audit a random sample by hand before training.

From research to production

The archive side is self-serve: browse series-day bundles in the shop at €1 per day, parse them with the free Python reader, and cross-check against the free per-minute statistics API. When a model graduates to live trading, the same normalized feed is available in realtime — see the latency guide for where to run it.

Limitations

Contract and trade counts are archive measurements as of 2026-08-12 and grow daily; trade averages cover the trailing 30 days only (the venues' statistics retention). Coverage starts differ per series (Kalshi recording began February 2026, Polymarket BTC 15m October 2025, 5m February 2026). Window counts are upper bounds on labels — occasional venue outages produce partial days. Nothing here is investment advice: data volume makes models trainable, not profitable.