Skip to main content
Polymarket trades have to wait for the next Polygon block to confirm. Predexon decodes the mempool so you see those trades 3–5 seconds before they settle on-chain — up to 5 seconds before Polymarket’s own real-time feed shows them. That window is enough to lift the book or take the other side, depending on your strategy. You’ll build:
  1. A WebSocket subscription that fires on pending trades
  2. A latency-honest decision function
  3. (Optional) An execution path — via your own venue client — that acts inside the 3–5s window
Endpoints used: 1 WebSocket channel + 1 REST call. Requires Dev+ for WebSocket.
This is a latency-sensitive strategy. If your handler takes >1 second to decide or your round-trip to your execution venue is high, you’ll miss the window. Co-locate near your execution venue’s infrastructure and benchmark before sizing.

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

Same orders channel as confirmed trades — just add filters.status: "pending".
For maximum coverage, replace 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.
Latency budget for this handler: <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.
If lead time is <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:
  1. 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.
  2. 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