Auto-cancellation

Four reasons the orderbook can cancel your resting orders without an explicit DELETE.

If your resting orders disappear and you didn’t issue DELETE /order, DELETE /orders, or DELETE /cancel-all, one of these four paths is the cause.

1. Heartbeat sweep (opt-in)

POSTing /heartbeats or /v1/heartbeats with valid L2 HMAC auth opts your user into a safety net: subsequent heartbeats must arrive within 30 seconds of each other, or every open order owned by your user is cancelled.

Setting	Value
Stale threshold	30 seconds without a heartbeat
Sweep cadence	every 5 seconds
Worst-case cancel latency	~35 seconds after the last beat
Opt-out	Stop calling /heartbeats. A user who has never successfully POSTed the endpoint is never tracked.

SDK gotcha. Both py-clob-client.start_heartbeats() and rs-clob-client’s heartbeat feature send these for you from a background task. If the background task dies (network blip, GC pause, process restart, event-loop block) without your main code noticing, your open orders get auto-cancelled ~30–35 seconds later. Either disable the SDK’s heartbeat option or actively monitor the background task’s health.

2. Balance rebalance

When the on-chain indexer reports a balance drop — a USDC withdrawal, an AMM trade, or a fill on another venue — the engine cancels enough resting orders to keep your remaining exposure within your new balance.

Cancellation order is LIFO (newest first), so your oldest resting orders are most likely to survive a rebalance.

The combined /ws channel emits an orders_rebalanced frame:

{
  "type": "orders_rebalanced",
  "cancelled_count": 2,
  "cancelled_order_ids": [
    "0x0011223344556677889900aabbccddeeff00112233445566778899aabbccddee",
    "0x1122334455667788990011223344556677889900aabbccddeeff112233445566"
  ]
}

On the canonical /ws/user channel, each affected order appears as a separate order/CANCELLATION frame.

3. Market lifecycle terminal transition

When a market transitions to Resolved, Voided, or Closed — see Market lifecycle — every open order in that market is cancelled atomically with the status change.

Paused is not in this set. Pausing freezes matching but retains resting orders; the market can resume to Active later.

WebSocket signature:

• /ws/user — one order/CANCELLATION frame per cancelled order, fanned out per user.
• Combined /ws — the bundled market_status_changed frame with cancelled_orders > 0.

4. GTD expiry sweep

Orders placed with orderType: "GTD" carry a signed expiration (Unix seconds). A background sweeper ticks every ~10 seconds, finds GTD orders past their expiration, and cancels them.

• WebSocket signature: order/CANCELLATION on /ws/user (or order_cancelled on combined /ws), with a reason flag indicating expiry.
• Typical cancel latency after the deadline: under 10 seconds.

GTD is the only order type that auto-cancels on a wall-clock deadline. GTC orders never expire on their own; FAK/FOK never rest, so expiry doesn’t apply.

Summary

Cause	Triggered by	WS signature
Heartbeat sweep	You stopped sending /heartbeats after opting in	order/CANCELLATION per order
Balance rebalance	On-chain balance drop	orders_rebalanced on /ws; per-order CANCELLATION on /ws/user
Market terminal	Market Resolved/Voided/Closed	market_status_changed + per-order CANCELLATION
GTD expiry	Order’s expiration reached	order/CANCELLATION per expired order

If you see unexplained cancellations, this is the order to check: heartbeat status first (most common SDK footgun), then balance changes, then market status, then expirations.