Order types

Why Polymarket needs synthetic order types

Polymarket’s CLOB exposes only two primitives: market and limit. There is no native stop, no bracket, no OCO, and no trailing stop. For copy-trading or for any active position management, that gap forces you to either babysit the screen or accept that a position can ride to zero. The Pro Workstation closes that gap with server-side conditional orders that submit the underlying CLOB order through the same execution path as a manual ticket once a trigger fires.

Every workstation order is signed client-side with the official polymarket_client_sdk_v2 and submitted with the V2 builder code attached for attribution. PolyZig never custodies your funds, never holds your private key, and never resigns your order — the conditional-order watcher is just an automated trigger that re-uses your authenticated session.

Stop and stop-limit

A stop fires a market order when price crosses your trigger. A stop-limit fires a limit order at the price you set, giving you slippage control at the cost of a possible non-fill in fast markets. Both apply in either direction: a sell stop fires when price drops below the trigger; a buy stop fires when price climbs above it.

side=sell, trigger_price=0.45  →  fires when price ≤ 0.45
side=buy,  trigger_price=0.55  →  fires when price ≥ 0.55

Trailing stop

A trailing stop re-anchors its trigger to the running peak (sell side) or trough (buy side) of observed price. The trail offset defines how far price has to retrace from that peak before the stop fires. Useful for letting winners run while still capping the round-trip drawdown — the workstation tracks the peak in-memory inside the per-order monitor task.

sell trailing-stop, trail_offset=0.05
  → peak rises to 0.70, trigger sits at 0.65
  → if price drops to 0.65, stop fires

OCO and bracket — atomic, reciprocal links

An OCO ticket is two legs that cancel each other on fill: typically a stop loss and a take profit. A bracket is the OCO pattern wrapping an existing position. The Workstation creates both legs in one database transaction and writes a reciprocal linked_order_id so whichever leg fires first cancels the sibling — there is no scenario where you end up with a half-cancelled bracket.

Cancellation is user-scoped: the watcher will only cancel a sibling that belongs to the same user as the firing order, even if a malicious link were somehow injected.

Conditional cross-market triggers

A conditional order watches one market and acts on another. Example: "if the Trump-2024 YES drops below $0.40, fire a buy on the Trump-loss correlated leg." The Workstation persists these the same way as stops; the cross-market evaluator is wired in alongside the multi-leg ticket builder.

TWAP and iceberg (roadmap)

On thin Polymarket pairs even a few thousand dollars can move the book. The plan: TWAP slices a large order into N child orders over a configurable window; iceberg shows the book only the visible slice and refills as the visible portion fills, hiding total size. Both reduce market-impact slippage on illiquid markets. Neither is implemented in this build — these belong to the Phase 4 execution-strategies cut, after the conditional-orders watcher exposes a real CLOB executor.

Time in force flags

Every limit ticket today is submitted as GTC (good-till-cancelled), since that is what `polymarket_client_sdk_v2` exposes on the order builder. GTD, IOC, and FOK are part of the Phase 1b TIF cut — once the SDK’s upstream branch lands the flag (or the workstation contributes it), the ticket UI exposes a TIF dropdown and the order API extends `PlaceOrderRequest` with `time_in_force` + `expires_at`. Until then, IOC-style behaviour can be approximated by submitting a tight limit and cancelling on the next poller pass.

Risk-defined sizing

The order ticket includes a "max loss" helper. Enter the dollar amount you’re willing to risk and the entry + stop prices, and the ticket auto-computes the size that caps your loss at exactly that figure. Same primitive options traders use to size verticals: position your downside, not your notional.

size = max_loss / |entry_price − stop_price|