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:Documentation Index
Fetch the complete documentation index at: https://docs.predexon.com/llms.txt
Use this file to discover all available pages before exploring further.
- Pull the signal’s historical state at decision time
t. - Pull the price/orderbook state at
t + horizonfrom market data. - 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:
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_idin 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.
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:- 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.
- 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.
What to actually measure
Three numbers matter more than total PnL:| Metric | Why |
|---|---|
| Hit rate by horizon | Does the signal predict at 5min, 1h, 4h, 1d? Often the edge only exists in one band. |
| Slippage realism | After paying spread + walking the book for your size (see orderbook replay), does the PnL survive? |
| Capacity | What’s the max position size before the signal’s edge equals your market impact? Reconcile against trade-tape volume to answer this honestly. |
Going live with the same code
If the backtest holds up, the live version connects to:- WebSocket trades and activity for real-time flow
- WebSocket pending-trades for the mempool edge
- Unified Order Router for cross-venue execution when your signal fires
