Skip to main content
Pending trade events are available on Dev, Pro, and Enterprise plans.
Pending events are detected from the Polygon mempool before the transaction is mined. They arrive on average ~3 seconds before the corresponding confirmed event, typically 3–5 seconds early. This gives you an early signal for copytrading, alerting, or analytics - before the trade is finalized on-chain.

​
How It Works

  1. A trade transaction enters the Polygon mempool
  2. Predexon detects it and emits a pending event
  3. ~3–5 seconds later, the transaction is mined and a confirmed event is emitted
  4. Match the two events by tx_hash - the confirmed event supersedes the pending one

​
Enabling Pending Events

Add a status filter to your orders subscription. There are three modes:
status ValueWhat You ReceivePlan Required
"confirmed" (default)Only confirmed (mined) eventsAny plan
"all"Both pending + confirmed eventsDev+
"pending"Only pending (mempool) eventsDev+
Omitting status defaults to "confirmed" - fully backward compatible.

​
Subscribe to both pending and confirmed

{
  "action": "subscribe",
  "platform": "polymarket",
  "version": 1,
  "type": "orders",
  "filters": {
    "users": ["*"],
    "status": "all"
  }
}

​
Subscribe to pending only

{
  "action": "subscribe",
  "platform": "polymarket",
  "version": 1,
  "type": "orders",
  "filters": {
    "users": ["*"],
    "status": "pending"
  }
}

​
Update an existing subscription

{
  "action": "update",
  "subscription_id": "sub_abc123",
  "filters": {
    "users": ["*"],
    "status": "all"
  }
}

​
What Differs Between Pending and Confirmed

Every order_filled event includes a status field ("pending" or "confirmed"). Most fields are identical, but a few differ:
FieldPendingConfirmedWhy
status"pending""confirmed"
priceMay differ slightlyExactCan differ by a fraction of a cent if partial fills change the effective price
shares / shares_normalizedMay differ slightlyExactIf the tx partially fills, final on-chain amounts may differ
feeEstimatedExactActual fee may vary slightly after on-chain settlement
log_indexnullIntegerNo log exists yet for pending
order_hashStringStringNow included in both pending and confirmed events
timestampTime seen in mempoolBlock timestamp
tx_hashExactExactSame hash - use this to match pending → confirmed
All other fields - user, taker, token_id, side, and all metadata (market slug, title, outcome, etc.) - are identical between pending and confirmed.

​
Important Caveats

  • Not guaranteed to confirm - some pending transactions may be dropped, reverted, or replaced. Treat status: "pending" as a strong signal, not a guarantee.
  • Only order_filled events - pending detection applies to trade fills only. Fee refunds, activity, and lifecycle events remain confirmed-only.
  • Match by tx_hash - when the confirmed event arrives, it supersedes the pending one. Use tx_hash to correlate them.

​
Example: Handling Both Pending and Confirmed

const pendingTrades = new Map(); // tx_hash → pending data

ws.onmessage = (event) => {
  const msg = JSON.parse(event.data);

  if (msg.type === 'event' && msg.data.event_type === 'order_filled') {
    const data = msg.data;

    if (data.status === 'pending') {
      // Early signal from mempool - act on it, but expect confirmation
      pendingTrades.set(data.tx_hash, data);
      console.log(`[PENDING] ${data.side} ${data.outcome} ${data.shares_normalized} @ ${data.price}`);
      console.log(`  Market: ${data.title}`);
      console.log(`  Maker: ${data.user}`);
    }

    if (data.status === 'confirmed') {
      const wasPending = pendingTrades.delete(data.tx_hash);
      const label = wasPending ? '[CONFIRMED]' : '[NEW]';
      const value = data.shares_normalized * data.price;
      console.log(`${label} ${data.side} ${data.outcome} ${data.shares_normalized} @ ${data.price}`);
      console.log(`  Market: ${data.title}`);
      console.log(`  Value: $${value.toFixed(2)}`);
    }
  }
};