QUANT_API's Polymarket coverage spans binary (YES/NO) markets on m5, m15, h1, h4 and daily horizons. The five-minute contract is not the hourly one sped up — at that distance to expiry, the things that move price are different objects entirely. Macro is silent, narratives are irrelevant, and what remains is microstructure: who is crossing the spread, what the book looks like, and how many seconds are left on the clock.
What actually drives five minutes
Over five minutes, BTC's price is close to a pure function of order arrival. The features with explanatory power live at windows of one second to a few minutes — which is exactly why the window grid runs 1s 5s 15s 30s 1m … instead of starting at one hour. Four served signals cover most of the picture:
flow.ofi@30s— order-flow imbalance: which side is paying to trade right now. The most direct m5 input there is.orderbook.microprice_dev@1s— the size-weighted lean of the book versus the mid; the book tilts before the mid moves (full microprice guide).velocity.vel_60sandvelocity.trades_per_sec— how far price travelled in the last minute and how busy the tape is; the same flow means different things in a fast tape and a dead one.liquidations.liq_imbalance@1m— a forced-flow burst inside the window is the one event that reliably overwhelms everything else at this horizon.
One plan note before reaching for these addresses: windows are tier-gated, so flow.ofi@30s needs the Edge plan, where sub-minute windows start, and orderbook.microprice_dev@1s needs the Quant plan, where the 1-second windows unlock. Both signals are available from the Signal plan upward, starting at the 5m–1h windows the Signal plan includes.
Expiry makes it a different trade
A binary with 240 seconds to resolution is a different instrument from spot exposure. Two reads frame every m5 decision: context.tte_seconds, the seconds remaining to expiry, and the prediction-market book itself via polymarket.pm_microprice (the size-weighted YES fair value) and polymarket.pm_spread. The interplay is the trade: when spot flow has clearly turned but the YES book has not repriced — and polymarket.pm_spread says you can cross without donating the edge back — the lag is measurable rather than felt. The catalog also lists polymarket.dist_strike_pct, the live distance from spot to the strike, which sets how much any given flow burst should matter.
Time-of-day structure matters more at m5 than anywhere else: tape speed and book depth are not flat across the day, and funding events leave a footprint on the minutes around them. context.time_of_day and context.minutes_since_funding let a model condition on both instead of pretending every five-minute window is exchangeable.
# One m5 decision row for BTC: flow, book lean, tape speed, clock curl -s -G https://api.quant-api.dev/v1/features/live \ -H "Authorization: Bearer fk_live_<secret>" \ --data-urlencode "asset=BTC" \ --data-urlencode "features=flow.ofi@30s:zscore,orderbook.microprice_dev@1s:level,velocity.vel_60s@1m:level,velocity.trades_per_sec@30s:level,liquidations.liq_imbalance@1m:level,context.tte_seconds@5m:level,polymarket.pm_microprice@5m:level,polymarket.pm_spread@5m:level"
At a five-minute horizon, look-ahead is not a subtle bias — it is the whole result. A feature built from the closing values of the bar you are deciding inside has already leaked the answer, and even a few seconds of future tape is fatal at m5. Every QUANT_API value is computed strictly from data with ts <= as_of, and the live and historical endpoints share one resolver — so the row you backtest on is the row you would have seen with 240 seconds on the clock.
Researching m5 honestly
The research loop is mechanical: take a set of past m5 windows, build one row per decision time (say, entry at T−240s for each expiry), post them to POST /v1/features/historical, and you get a point-in-time matrix of every address above at exactly those instants. Feed it to POST /v1/backtest and read the result against the 50/50 prior — including span_days, so a short test stays a caveat instead of becoming a headline. No promised hit-rates here: the entire point is that your own matrix tells you the truth. Request shapes are in the docs, and the Polymarket signal set has its own guide.