Guides / Backtesting

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

A backtest of SOL 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 Solana 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 SOL 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

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

The failure modes worth naming

• Mid-price fills. The most common way a SOL 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

SOL 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

• SOL orderbook history
• SOL trade history
• Prediction market backtesting API
• Common backtesting mistakes
• BTC backtesting data

Related guides

• SOL Orderbook History — Kalshi & Polymarket Up/Down Markets (5m–24h)
• SOL Trade History — Executed Fills on Kalshi & Polymarket Up/Down
• Prediction Market Backtesting API
• Avoiding Look-Ahead Bias in Prediction Market Backtests
• BTC Backtesting Data — Historical Up/Down Markets from 5m to 24h

Data from Kalshi and Polymarket. Search live · API docs · Pricing