Tipos de orden

Por qué Polymarket necesita tipos de orden sintéticos

El CLOB de Polymarket expone solo dos primitivas: market y limit. No hay stop nativo, ni bracket, ni OCO, ni trailing stop. Para copy-trading o cualquier gestión activa de posición, ese hueco te fuerza a vigilar la pantalla o a aceptar que una posición pueda caer a cero. La Pro Workstation cierra ese hueco con órdenes condicionales del lado servidor que envían la orden CLOB subyacente a través del mismo camino de ejecución que un ticket manual una vez que un disparador se activa.

Cada orden de la workstation se firma del lado cliente con el oficial polymarket_client_sdk_v2 y se envía con el código de builder V2 adjunto para atribución. PolyZig nunca custodia tus fondos, nunca guarda tu llave privada, y nunca refirma tu orden — el watcher de órdenes condicionales es solo un disparador automático que reusa tu sesión autenticada.

Stop y stop-limit

Un stop dispara una orden market cuando el precio cruza tu disparador. Un stop-limit dispara una orden limit al precio que pongas, dándote control de slippage al coste de un posible no-fill en mercados rápidos. Ambos aplican en cualquier dirección: un sell stop dispara cuando el precio cae bajo el disparador; un buy stop dispara cuando el precio sube sobre él.

side=sell, trigger_price=0,45  →  dispara cuando precio ≤ 0,45
side=buy,  trigger_price=0,55  →  dispara cuando precio ≥ 0,55

Trailing stop

Un trailing stop reancla su disparador al máximo (lado venta) o mínimo (lado compra) corrientes del precio observado. El offset de trail define cuánto debe retroceder el precio desde ese pico antes de que el stop dispare. Útil para dejar correr a los ganadores mientras se limita el drawdown del round-trip — la workstation rastrea el pico en memoria dentro de la tarea de monitor por orden.

sell trailing-stop, trail_offset=0,05
  → pico sube a 0,70, disparador queda en 0,65
  → si precio cae a 0,65, el stop dispara

OCO y bracket — atómicos, enlazados recíprocamente

Un ticket OCO son dos patas que se cancelan entre sí al fill: típicamente un stop loss y un take profit. Un bracket es el patrón OCO envolviendo una posición existente. La Workstation crea ambas patas en una sola transacción de base de datos y escribe un linked_order_id recíproco, así la pata que dispare primero cancela a la hermana — no hay escenario donde acabes con un bracket a medio cancelar.

La cancelación está acotada al usuario: el watcher solo cancelará una hermana que pertenezca al mismo usuario que la orden que dispara, incluso si un enlace malicioso fuera inyectado de algún modo.

Disparadores condicionales cross-market

Una orden condicional vigila un mercado y actúa sobre otro. Ejemplo: «si el YES de Trump-2024 cae bajo $0,40, dispara un buy en la pata correlacionada Trump-loss». La Workstation las persiste igual que los stops; el evaluador cross-market se cablea junto con el constructor de tickets multi-leg.

TWAP e iceberg (roadmap)

En pares delgados de Polymarket incluso unos pocos miles de dólares pueden mover el libro. El plan: TWAP rebana una orden grande en N órdenes hijas a lo largo de una ventana configurable; iceberg muestra al libro solo la rebanada visible y rellena conforme la porción visible se llena, ocultando el tamaño total. Ambos reducen slippage por market-impact en mercados ilíquidos. Ninguno está implementado en este build — pertenecen al corte de estrategias de ejecución de la Fase 4, después de que el watcher de órdenes condicionales exponga un ejecutor CLOB real.

Flags time-in-force

Cada ticket limit hoy se envía como GTC (good-till-cancelled), ya que es lo que `polymarket_client_sdk_v2` expone en el constructor de órdenes. GTD, IOC y FOK son parte del corte de TIF de la Fase 1b — una vez que la rama upstream del SDK aterrice el flag (o la workstation lo aporte), la UI del ticket expondrá un desplegable TIF y la API de órdenes extenderá `PlaceOrderRequest` con `time_in_force` + `expires_at`. Hasta entonces, el comportamiento tipo IOC se puede aproximar enviando un limit ajustado y cancelando en el siguiente pase del poller.

Sizing definido por riesgo

El ticket de orden incluye un asistente de «pérdida máxima». Introduce el monto en dólares que estás dispuesto a arriesgar y los precios de entrada + stop, y el ticket calcula automáticamente el size que limita tu pérdida exactamente a esa cifra. La misma primitiva que usan los traders de opciones para dimensionar verticals: posiciona tu downside, no tu notional.

size = max_loss / |entry_price − stop_price|