Tipos de ordem

Por que o Polymarket precisa de tipos de ordem sintéticos

O CLOB do Polymarket expõe apenas duas primitivas: market e limit. Não há stop nativo, nem bracket, nem OCO, nem trailing stop. Para copy-trading ou qualquer gestão ativa de posição, esse buraco te força a vigiar a tela ou aceitar que uma posição pode despencar para zero. A Pro Workstation fecha esse buraco com ordens condicionais do lado servidor que enviam a ordem CLOB subjacente pelo mesmo caminho de execução de um ticket manual assim que um gatilho dispara.

Toda ordem da workstation é assinada no cliente com o oficial polymarket_client_sdk_v2 e enviada com o código de builder V2 anexado para atribuição. PolyZig nunca custodia seus fundos, nunca guarda sua chave privada, e nunca reassina sua ordem — o watcher de ordens condicionais é apenas um gatilho automatizado que reaproveita sua sessão autenticada.

Stop e stop-limit

Um stop dispara uma ordem market quando o preço cruza seu gatilho. Um stop-limit dispara uma ordem limit no preço que você definir, dando controle de slippage ao custo de um possível não-fill em mercados rápidos. Ambos se aplicam em qualquer direção: um sell stop dispara quando o preço cai abaixo do gatilho; um buy stop dispara quando o preço sobe acima dele.

side=sell, trigger_price=0,45  →  dispara quando preço ≤ 0,45
side=buy,  trigger_price=0,55  →  dispara quando preço ≥ 0,55

Trailing stop

Um trailing stop reancora seu gatilho ao pico (lado venda) ou vale (lado compra) corrente do preço observado. O offset de trail define quanto o preço precisa retroceder desse pico antes do stop disparar. Útil para deixar os vencedores correrem mantendo um teto no drawdown de ida e volta — a workstation rastreia o pico em memória dentro da tarefa de monitor por ordem.

sell trailing-stop, trail_offset=0,05
  → pico sobe a 0,70, gatilho fica em 0,65
  → se preço cai a 0,65, o stop dispara

OCO e bracket — atômicos, links recíprocos

Um ticket OCO são duas pernas que se cancelam mutuamente no fill: tipicamente um stop loss e um take profit. Um bracket é o padrão OCO envolvendo uma posição existente. A Workstation cria as duas pernas em uma única transação de banco de dados e escreve um linked_order_id recíproco, então a perna que disparar primeiro cancela a irmã — não há cenário em que você termine com um bracket cancelado pela metade.

O cancelamento é com escopo de usuário: o watcher só vai cancelar uma irmã que pertença ao mesmo usuário da ordem que dispara, mesmo que um link malicioso fosse de algum modo injetado.

Gatilhos condicionais cross-market

Uma ordem condicional observa um mercado e age sobre outro. Exemplo: «se o YES de Trump-2024 cair abaixo de $0,40, dispara um buy na perna correlacionada Trump-loss». A Workstation persiste essas igual aos stops; o avaliador cross-market é cabeado junto com o construtor de tickets multi-leg.

TWAP e iceberg (roadmap)

Em pares finos do Polymarket até alguns milhares de dólares conseguem mover o livro. O plano: TWAP fatia uma ordem grande em N ordens filhas em uma janela configurável; iceberg mostra ao livro só a fatia visível e a recompõe à medida que a porção visível preenche, escondendo o tamanho total. Ambos reduzem slippage por market-impact em mercados ilíquidos. Nenhum está implementado nesta build — pertencem ao corte Fase 4 de estratégias de execução, depois do watcher de ordens condicionais expor um executor CLOB real.

Flags time-in-force

Hoje todo ticket limit é enviado como GTC (good-till-cancelled), pois é o que `polymarket_client_sdk_v2` expõe no construtor de ordens. GTD, IOC e FOK são parte do corte TIF da Fase 1b — quando o branch upstream do SDK incluir o flag (ou a workstation contribuir), a UI do ticket vai expor um dropdown TIF e a API de ordens estende `PlaceOrderRequest` com `time_in_force` + `expires_at`. Até lá, comportamento estilo IOC pode ser aproximado enviando um limit apertado e cancelando no próximo passo do poller.

Sizing definido por risco

O ticket de ordem inclui um auxiliar de «perda máxima». Informe o valor em dólares que está disposto a arriscar e os preços de entrada + stop, e o ticket calcula automaticamente o size que limita sua perda exatamente nesse valor. A mesma primitiva que traders de opções usam para dimensionar verticals: posicione seu downside, não seu notional.

size = max_loss / |entry_price − stop_price|