Guides / Backtesting

ETH Backtesting Data — Historical Up/Down Markets from 5m to 24h

A backtest of ETH Up/Down markets needs two aligned inputs: what the book looked like when your rule fired, and what actually traded around that moment. ProbSights serves both on the same timeline for Ethereum Up/Down markets across Kalshi and Polymarket, which is what separates a testable result from a curve drawn through mid-prices.

Choosing an interval

Interval choice is a statistical decision before it is a strategy decision. Short intervals give many observations and punishing costs; long intervals give clean signal and too few independent samples to trust.

Contract interval	What it means for ETH Up/Down
`5m`	Resolves every 5 minutes. Thinnest books; spread is usually the dominant cost.
`15m`	Resolves every 15 minutes. Enough depth to test size without moving the book much.
`1h`	Hourly resolution. The most consistently quoted interval across both venues.
`4h`	Four-hour resolution. Slower drift, fewer independent observations per day.
`24h`	Daily resolution. Closest to a directional bet; overnight gaps matter most here.

Contract interval vs. snapshot granularity

These are two different things, and mixing them up is the usual reason a backtest looks wrong. The contract interval (5m through 24h) is a property of the market itself — how often that series resolves. The snapshot granularity is how often ProbSights recorded the book, set with the granularity query parameter, which accepts 1m or 5m. A 24h contract sampled at 1m gives you roughly 1,440 snapshots across its life; a 5m contract sampled at 5m gives you a handful. Pick the granularity from the resolution your strategy needs, not from the contract interval.

The two feeds you need

Feed	Endpoint	Answers
Orderbook snapshots	`/api/v1/historical/{venue}/orderbook`	Could I have traded, at what size, at what price?
Executed trades	`/api/v1/historical/{venue}/trades`	Did anyone actually trade there, and how much?

Both take market_id, start_time, end_time, limit, and pagination_key; orderbook also takes granularity (1m or 5m). Both return a pagination object — page with pagination_key, never by advancing timestamps.

A workable loop

Resolve the market series you want via /api/v1/search/markets?coin=ETH&status=closed — settled markets matter, because they carry through to a known outcome.
Pull orderbook snapshots at the granularity your rule needs.
Pull the trade tape over the same window.
Replay in timestamp order. When the rule fires, walk the book for your size rather than filling at mid.
Check each simulated fill against nearby real trades. If the tape never shows that size, cap it.
Score against settlement, not against the last quoted price.

The failure modes worth naming

Mid-price fills. The most common way a ETH strategy looks profitable and isn't — see why mid-price backtests lie.
Look-ahead through resolution. Filtering on settled markets and then trading them from the start leaks the answer. See look-ahead bias.
Survivorship in the market set. Only testing series that stayed liquid overstates results.
Too few independent samples. Two hundred 24h contracts is not two hundred independent bets if they share a macro driver.

Access

ETH Up/Down history at 5m–24h is included from the Pro plan. Cross-venue history — Polymarket and Kalshi together over 60 days — is on Builder, which is what you need to backtest anything that trades the spread between the two venues.

Related guides

Data from Kalshi and Polymarket. Search live API docs Pricing