Skip to main content
Predexon ships several derived signals out of the box — smart-money flow, top-holders, pending-trade detection. The honest question before you build a strategy around any of them is: did this signal actually predict anything historically? This page walks the workflow for answering that. The pattern is the same for every signal:
  1. Pull the signal’s historical state at decision time t.
  2. Pull the price/orderbook state at t + horizon from market data.
  3. Compute realized PnL if you had acted on the signal at t.

Signal 1 — smart-money flow

GET /v2/polymarket/market/{condition_id}/smart-money tells you whether profitable wallets are net buyers or sellers in a market over a window. The natural backtest: does smart-money net-buying predict price up over the next N hours? The smart-money endpoint reflects current state, not historical state. To backtest, you reconstruct the signal from raw trade data:
Then for each decision time:
A monotonic relationship between flow quintile and forward return is the signal you’re hoping to see. Flat means the signal isn’t predictive at that horizon.

Signal 2 — top-holders concentration

GET /v2/polymarket/markets/{condition_id}/top-holders shows position concentration. The hypothesis: when one side is held by a few large wallets, it’s vulnerable to a flush. Reconstruct from snapshots of positions over time:
  • For each condition_id in your universe, sample top-holders periodically (e.g. daily).
  • Compute a concentration metric (HHI, top-5 share, etc.).
  • Pair with the same-day orderbook snapshot to know what depth was sitting against that concentration.
  • Look at forward price moves over a 1d / 1w horizon, bucketed by concentration.
This is a slow signal — daily decisions, weekly horizons — so candle data plus periodic snapshots are usually enough. No need for tick-by-tick orderbook replay.

Signal 3 — pending-trade leading indicator

The pending-trades WebSocket detects fills from the Polygon mempool 3–5 seconds before confirmation. The backtest question: does the pending side predict the next confirmed-trade direction tight enough to act on? Pending events are real-time only — there’s no historical replay endpoint for them. To backtest, you have two options:
  1. Run a recorder for a week. Connect to the pending-trades channel and dump every event to disk. Then pair against the confirmed trades endpoint for the same window. Compute hit rate, average lead time, and PnL under realistic latency assumptions.
  2. Proxy with confirmed trades + book delta. For each confirmed trade, look at the orderbook snapshot ~3 seconds before. Did the best bid/ask shift in the direction of the trade? Use that as a proxy for what pending-trade detection would have told you.
The recorder approach is more honest. Plan on a week of paper-collection before you trust the signal enough to size into it.

What to actually measure

Three numbers matter more than total PnL: A signal with a 55% hit rate that survives realistic slippage at $10k/trade is more valuable than a 70% hit rate that collapses at $1k.

Going live with the same code

If the backtest holds up, the live version connects to: The data shapes are the same in REST and WebSocket, so your decision function should rarely need to change.