Types d'ordres

Pourquoi Polymarket a besoin de types d'ordres synthétiques

Le CLOB de Polymarket n'expose que deux primitives : market et limit. Pas de stop natif, pas de bracket, pas d'OCO, et pas de trailing stop. Pour le copy-trading ou toute gestion active de position, ce manque vous force soit à veiller sur l'écran, soit à accepter qu'une position puisse chuter à zéro. La Pro Workstation comble cet écart avec des ordres conditionnels côté serveur qui soumettent l'ordre CLOB sous-jacent via le même chemin d'exécution qu'un ticket manuel dès qu'un déclencheur s'allume.

Chaque ordre du workstation est signé côté client avec l'officiel polymarket_client_sdk_v2 et soumis avec le code de builder V2 attaché pour l'attribution. PolyZig ne conserve jamais vos fonds, ne détient jamais votre clé privée, et ne re-signe jamais votre ordre — le watcher d'ordres conditionnels n'est qu'un déclencheur automatisé qui réutilise votre session authentifiée.

Stop et stop-limit

Un stop déclenche un ordre market quand le prix franchit votre déclencheur. Un stop-limit déclenche un ordre limit au prix que vous fixez, vous donnant un contrôle du slippage au prix d'un éventuel non-fill sur des marchés rapides. Les deux s'appliquent dans les deux sens : un sell stop se déclenche quand le prix passe sous le déclencheur ; un buy stop se déclenche quand le prix monte au-dessus.

side=sell, trigger_price=0,45  →  déclenche quand prix ≤ 0,45
side=buy,  trigger_price=0,55  →  déclenche quand prix ≥ 0,55

Trailing stop

Un trailing stop ré-ancre son déclencheur sur le pic glissant (côté vente) ou le creux glissant (côté achat) du prix observé. Le trail offset définit de combien le prix doit reculer depuis ce pic avant que le stop ne se déclenche. Utile pour laisser courir les gagnants tout en plafonnant le drawdown aller-retour — le workstation suit le pic en mémoire dans la tâche de monitor par ordre.

sell trailing-stop, trail_offset=0,05
  → pic monte à 0,70, déclencheur reste à 0,65
  → si le prix tombe à 0,65, le stop se déclenche

OCO et bracket — atomiques, liens réciproques

Un ticket OCO comporte deux jambes qui s'annulent mutuellement à l'exécution : typiquement un stop loss et un take profit. Un bracket est le motif OCO enveloppant une position existante. Le Workstation crée les deux jambes en une seule transaction de base de données et écrit un linked_order_id réciproque, de sorte que la jambe qui se déclenche en premier annule sa sœur — il n'existe pas de scénario où vous vous retrouvez avec un bracket à moitié annulé.

L'annulation est limitée à l'utilisateur : le watcher n'annulera qu'une sœur appartenant au même utilisateur que l'ordre déclencheur, même si un lien malveillant venait d'une manière ou d'une autre à être injecté.

Déclencheurs conditionnels cross-market

Un ordre conditionnel surveille un marché et agit sur un autre. Exemple : « si le YES Trump-2024 tombe sous 0,40 $, déclenche un buy sur la jambe corrélée Trump-loss ». Le Workstation les persiste de la même manière que les stops ; l'évaluateur cross-market est câblé aux côtés du constructeur de tickets multi-jambes.

TWAP et iceberg (roadmap)

Sur des paires Polymarket fines, même quelques milliers de dollars peuvent bouger le book. Le plan : TWAP découpe un gros ordre en N ordres enfants sur une fenêtre configurable ; iceberg ne montre au book que la tranche visible et la rééquilibre à mesure que la portion visible se remplit, masquant la taille totale. Les deux réduisent le slippage de market-impact sur des marchés illiquides. Aucun n'est implémenté dans cette build — ils relèvent du cut Phase 4 stratégies d'exécution, après que le watcher d'ordres conditionnels exposera un véritable executor CLOB.

Flags time-in-force

Chaque ticket limit est aujourd'hui soumis comme GTC (good-till-cancelled), puisque c'est ce que `polymarket_client_sdk_v2` expose sur le constructeur d'ordres. GTD, IOC et FOK font partie du cut TIF de la Phase 1b — une fois que la branche upstream du SDK aura intégré le flag (ou que le workstation y aura contribué), l'UI du ticket exposera une liste déroulante TIF et l'API d'ordres étendra `PlaceOrderRequest` avec `time_in_force` + `expires_at`. D'ici là, un comportement de type IOC peut être approché en soumettant un limit serré et en l'annulant à la prochaine passe du poller.

Sizing défini par le risque

Le ticket d'ordre comprend un assistant « perte maximale ». Saisissez le montant en dollars que vous êtes prêt à risquer ainsi que les prix d'entrée + stop, et le ticket calcule automatiquement la taille qui plafonne votre perte exactement à ce chiffre. La même primitive qu'utilisent les traders d'options pour dimensionner les verticals : positionnez votre downside, pas votre notional.

size = max_loss / |entry_price − stop_price|