- A WebSocket subscription that fires on pending trades
- A latency-honest decision function
- (Optional) An execution path — via your own venue client — that acts inside the 3–5s window
How pending trades work
You’re seeing the fill before the rest of the world does — including most other Polymarket traders. The strategies that work in this window are typically:- Lift the book: a large pending buy means the next mid-tick will be higher. Buy ahead of it.
- Pre-emptive cancel: if a pending trade is about to take your resting order, cancel and re-quote.
- Quote tightening: maker strategies tightening spread when the book is about to move.
Step 1 — Subscribe to pending trades
Sameorders channel as confirmed trades — just add filters.status: "pending".
market_slugs with ["*"] (firehose — Pro plan only).
Step 2 — Decide fast
The handler runs on every pending event. It has 3–5 seconds to make a decision and ship an order. Anything longer and the window closes. Predexon gives you the signal and the current book state; the order itself goes out through your own venue client.<500ms ideally. If you’re processing more than a few events per second, queue them — your decision must happen before the next block confirms.
Step 3 — Measure your hit rate
You don’t actually know if your strategy is working until you compare pending events to confirmed events. Log both, reconcile after the fact.<1s consistently, the strategy doesn’t have edge — you’re not getting enough lookahead. If hit rate is <30%, your sizing is too aggressive or your target price too tight.
Avoiding self-front-running
If you’re running this on the same wallet that places the parent order, your handler will see your own pending trade and try to act on it. Two fixes:- Track your own outgoing orders: keep a set of token_ids and timestamps for orders you’ve placed in the last 10s; skip pending events that match.
- Use a separate wallet for the strategy: your front-running wallet never places anything you’d want to detect.
Reality check
For honest backtesting before going live, see Signal Backtesting → pending-trade approach. Plan on collecting a week of real pending+confirmed data before sizing in.
Reference
- WebSocket pending trades — the
status: "pending"filter - WebSocket trades (confirmed) — for measuring lead time and reconciling
- Market Price — for current best bid/ask before sizing
- Signal backtesting
