Bot de trading Oui/Non : distinguer clairement le côté, le prix et les frais

La correspondance des côtés d’un bot de trading Oui/Non commence par les identifiants

Enregistrez explicitement l’identifiant du contrat et celui de chaque issue. Un libellé comme Oui n’a de sens que dans le cadre d’un contrat particulier. Deux marchés voisins peuvent tous deux comporter une issue Oui tout en renvoyant à des seuils, des dates ou des sources différents. La correspondance doit relier la condition de la stratégie à l’issue exacte que le composant d’exécution soumettra, avec une référence de règle versionnée qui explique cette relation.

Conservez l’achat et la vente dans des champs d’action distincts. Un achat augmente la position sélectionnée et consomme les liquidités ou les garanties nécessaires selon les mécanismes réels du compte. Une vente réduit ou modifie autrement la position selon le modèle pris en charge par la plateforme. Ne supposez pas que la vente à découvert est sans restriction ni qu’un complément économique peut toujours se traduire par la même action opérationnelle.

Par exemple, une recommandation d’achat de 120 unités Non doit rester un achat Non dans l’enregistrement de l’instruction. Le système peut aussi calculer l’exposition directionnelle équivalente à Oui pour analyser les risques, mais cette représentation dérivée ne doit pas remplacer l’identité réelle de l’ordre. Si l’adaptateur la convertit silencieusement en vente Oui, il peut créer une instruction que le compte ne permet pas d’exécuter ou un circuit de trésorerie différent de celui approuvé par le contrôle des risques.

Le guide antérieur sur l’achat automatique de parts Oui et Non sur Polymarket fournit du contexte sur la sélection des issues. Un test robuste de correspondance doit délibérément utiliser des noms de contrats similaires et des côtés opposés. L’objectif est de prouver que le bot sélectionne l’issue et l’action approuvées, plutôt que de simplement produire un prix qui semble plausible.

Distinguer les cotations observées des cotations dérivées

Une plateforme peut communiquer directement les carnets des deux issues ou fournir une représentation à partir de laquelle un prix vendeur du côté opposé est dérivé. Le bot doit documenter cette correspondance et conserver l’observation d’origine. Une cotation dérivée doit identifier le côté source, le prix, la quantité et l’horodatage sur lesquels elle repose. Cela permet à une personne chargée de l’examen d’inspecter la transformation lorsque l’action réelle du compte paraît surprenante.

La documentation de Kalshi sur le carnet d’ordres décrit des tableaux d’offres d’achat Oui et Non et leurs relations avec les offres de vente complémentaires. Dans un exemple standard à un dollar, un prix acheteur Oui de 0,33 $ correspond à un prix vendeur Non de 0,67 $. Cette relation peut éclairer le calcul d’un achat Non, mais elle ne fait pas de toute valeur Oui affichée une donnée d’entrée appropriée. Un cours médian ou une dernière transaction ancienne ne sont pas équivalents au prix acheteur actuel du côté opposé.

Conservez la profondeur en même temps que le prix. Si l’offre d’achat source ne porte que sur 40 unités, l’offre de vente dérivée porte sur cette quantité à ce niveau, et non sur un achat illimité. Une quantité supplémentaire nécessite des niveaux supplémentaires et un nouveau calcul du coût moyen. Un adaptateur qui dérive le bon prix mais lui associe la mauvaise quantité peut tout de même produire une recommandation inexacte.

Le guide connexe des logiciels de trading de cotes examine plus largement les données normalisées. Un format interne utile doit préciser le type et l’origine de l’observation. La normalisation ne rend les valeurs comparables que si elle conserve les faits nécessaires à leur interprétation ; supprimer les informations sur le côté ou l’horodatage peut rendre une structure de données soignée moins fidèle que la réponse brute.

Préserver la précision des prix et des quantités

Traitez les prix et les quantités selon les unités documentées et la précision autorisée par la plateforme actuellement utilisée. Ne supposez pas que tous les marchés utilisent des centimes entiers ou des contrats entiers. Une chaîne décimale représentant des dollars ne doit pas être interprétée comme un nombre entier de centimes, et un champ de quantité ne doit pas être arrondi simplement parce qu’une interface utilisateur affiche moins de chiffres. L’adaptateur a besoin d’une règle de conversion explicite, assortie de tests aux limites pertinentes.

Utilisez une arithmétique adaptée aux montants monétaires et à la précision requise. Les représentations binaires à virgule flottante peuvent produire de petits artefacts d’arrondi ; l’implémentation doit donc utiliser une approche décimale ou à virgule fixe vérifiée lorsque cela convient. L’exigence essentielle est une conversion et un arrondi déterministes selon les règles réelles de la plateforme. Une technique de programmation particulière ne suffit pas si ses résultats n’ont pas été vérifiés par rapport aux prix et aux quantités pris en charge.

Le bot doit distinguer l’arrondi d’affichage de l’arrondi des ordres. Afficher un prix avec deux décimales pour faciliter la lecture n’autorise pas l’envoi de cette valeur arrondie si la limite réellement autorisée ou prévue diffère. De même, une quantité d’ordre réduite pour respecter un incrément doit se refléter dans l’autorisation et le calcul de l’exposition. Un arrondi silencieux peut modifier le résultat économique ou laisser une position résiduelle inattendue.

L’analyse antérieure de l’API de trading Kalshi aide à comprendre la nécessité d’adaptateurs propres à chaque plateforme. Les tests d’acceptation doivent inclure des valeurs proches des incréments autorisés, des quantités minimales et des limites du compte. Un bot qui ne fonctionne que pour des nombres ronds familiers n’a pas démontré qu’il peut préserver correctement toute la gamme des valeurs d’entrée prises en charge.

La comptabilisation des frais d’un bot de trading Oui/Non commence avant la soumission

Estimez les frais pour le côté, le prix, la quantité et le rôle d’exécution réellement envisagés, selon les conditions actuelles propres au marché. Conservez l’estimation séparément des frais finalement déclarés par le compte. L’estimation éclaire l’autorisation ; les frais réels déterminent l’enregistrement final. Un écart de frais doit pouvoir s’expliquer sans réécrire la recommandation initiale comme si elle avait parfaitement prévu l’avenir.

Supposons que le bot fictif propose d’acheter 120 unités Non à un prix vendeur exécutable de 0,67 $. Le coût d’achat est de 80,40 $. Supposons que les frais d’acquisition estimés soient de 1,60 $, ce qui porte l’engagement total à 82 $, tous frais compris. Selon le versement ordinaire indiqué, une victoire de Non rapporte 120 $ et produit un gain de 38 $, tandis qu’une défaite de Non entraîne une perte de 82 $. Ces chiffres doivent apparaître avec leurs hypothèses plutôt que sous la forme d’un pourcentage de bénéfice générique.

L’autorisation du compte doit réserver le coût d’achat maximal autorisé et une provision suffisante pour les frais. Si l’ordre peut s’exécuter sur plusieurs niveaux jusqu’à un prix plafond, utilisez l’engagement maximal pertinent plutôt que le seul premier prix vendeur observé. Les frais peuvent aussi varier en cas d’exécutions partielles ou de changement de rôle d’exécution ; les règles doivent donc tenir compte du barème réel plutôt que de supposer un montant universel par unité.

La documentation actuelle de Polymarket sur les frais utilise des paramètres propres à chaque marché. C’est une raison de vérifier le barème applicable, et non de recopier une valeur par défaut dans tous les bots. Le montant hypothétique de 1,60 $ ci-dessus est une donnée pédagogique et ne décrit pas les frais d’une plateforme nommée pour cette quantité ou ce prix.

Un enregistrement complet de l’ordre relie l’intention aux éléments de preuve

Les enregistrements d’ordres d’un bot de trading Oui/Non doivent conserver la recommandation, l’autorisation, la tentative de soumission, l’identité de l’ordre sur la plateforme et les exécutions ultérieures. La recommandation explique pourquoi l’action a été envisagée. L’autorisation encadre ce que le compte peut faire. L’enregistrement de soumission établit ce qui a été envoyé. Les exécutions établissent ce qui a modifié le compte. Séparer ces étapes facilite la localisation des erreurs.

Chaque tentative a besoin d’une identité persistante. Si une réponse est perdue, le bot peut enquêter sur cette tentative plutôt que créer un nouvel ordre inexpliqué. Enregistrez le côté, l’action, la quantité et le prix limite d’origine avec la tentative. Un processus de reprise ne devrait pas avoir à les reconstituer à partir d’un instantané ultérieur des positions ou du souvenir qu’un opérateur garde d’un libellé de tableau de bord.

Les enregistrements des exécutions ont besoin d’identifiants d’exécution stables ainsi que des quantités, des prix et des frais réels. La réception répétée d’une même exécution ne doit pas augmenter deux fois la position. Un ordre partiellement exécuté doit conserver l’engagement correspondant à sa partie non exécutée jusqu’à ce qu’il soit entièrement exécuté, rejeté ou annulé avec des éléments suffisants pour l’établir. La vue des risques du compte dépend à la fois des unités confirmées et de celles qui peuvent encore arriver.

Un bot de trading de marchés binaires utilise ces enregistrements pour maintenir une exposition encadrée et assurer la comptabilisation du règlement. L’adaptateur Oui/Non ajoute une responsabilité précise : chaque enregistrement doit conserver l’issue détenue et l’action qui a créé ou réduit la position. Une quantité correcte du mauvais côté produit tout de même un versement potentiel incorrect.

Une sortie doit utiliser le prix acheteur du côté détenu

Reprenons l’achat Non fictif coûtant 82 $, tous frais compris. Supposons que le compte envisage ensuite de vendre les 120 unités Non à un prix acheteur exécutable de 0,63 $. Le produit brut de la vente serait de 75,60 $. Avec des frais de sortie supposés de 1,20 $, le produit net serait de 74,40 $, soit une perte de 7,60 $ par rapport au coût d’acquisition. Le calcul utilise le prix acheteur Non parce que le compte vend Non.

Utiliser directement le prix vendeur Oui comme prix de vente serait incorrect sans la transformation appropriée et vérifiée. Le bot doit récupérer ou dériver le prix correspondant à l’action réelle, vérifier la quantité disponible à ce prix et appliquer l’estimation actuelle des frais. Une fonction utilitaire partagée nommée get price est dangereuse si ses appelants ne peuvent pas préciser s’ils ont besoin d’un prix vendeur pour acheter, d’un prix acheteur pour vendre ou d’une référence non exécutable.

Une recommandation de sortie doit aussi préciser si elle clôture la totalité des avoirs ou seulement une partie. Vendre 60 des 120 unités laisse 60 unités Non assorties d’un versement conditionnel. Le bot ne doit pas considérer la position sur le contrat comme nulle simplement parce que l’instruction de sortie a été acceptée. Les exécutions de vente confirmées déterminent la quantité restante, et tout reliquat ouvert reste une composante de l’état futur possible du compte.

L’article connexe sur le bot de trading de cotes explique comment normaliser les formats de cotation avant l’évaluation. Cette conversion ne remplace pas la sélection du carnet en fonction de l’action. Un prix correctement converti pour acheter un côté reste une donnée inappropriée pour calculer ce que le compte recevrait en le vendant.

Des limites tenant compte des côtés nécessitent une interprétation par scénario

Les limites de risque peuvent porter sur les quantités, l’engagement de trésorerie ou les pertes possibles, mais la correspondance entre les avoirs et les scénarios doit respecter le contrat. Pour les côtés exactement complémentaires d’une même question binaire standard, des quantités égales de Oui et de Non peuvent former des paires assurant un versement selon les règles indiquées. Des quantités inégales laissent une exposition résiduelle. Entre des contrats différents, une compensation Oui/Non apparente peut ne pas exister du tout.

Supposons qu’un compte détienne 120 unités Non et 80 unités Oui dans le même contrat fictif. Selon le modèle simple, 80 unités forment des paires et 40 unités Non conservent une exposition directionnelle. Si Oui gagne, le compte reçoit 80 $ ; si Non gagne, il reçoit 120 $. Les coûts d’acquisition et les frais déterminent le résultat net dans chaque cas. Une quantité nette de moins 40 peut résumer la différence directionnelle, mais elle ne doit pas remplacer les avoirs bruts ni l’historique de trésorerie.

Les quantités brutes comptent sur le plan opérationnel, car vendre ou gérer chaque côté peut nécessiter des actions et des avoirs distincts. Un tableau de bord des risques qui n’affiche que l’exposition nette peut masquer le montant du capital engagé des deux côtés. Il peut aussi dissimuler quels ordres restent actifs et peuvent modifier l’équilibre. Gardez les avoirs bruts, la quantité appariée et l’exposition résiduelle disponibles pour examen.

Le guide antérieur de l’API de bot Polymarket fournit du contexte sur les enregistrements de compte propres à chaque issue. Le bot doit expliquer toute mesure nette dérivée à partir des positions réelles et des relations de versement vérifiées. Un modèle de risque devient peu fiable lorsqu’un nombre signé pratique est considéré comme la preuve d’une compensation que les conditions du contrat ne permettent pas.

Les ordres au statut inconnu doivent conserver leur côté d’origine

Si la demande d’achat Non dépasse le délai d’attente, le bot doit la conserver comme un achat Non incertain avec sa quantité et sa limite de coût d’origine. Il ne doit pas réagir en soumettant une vente Oui simplement parce que les deux actions peuvent être économiquement liées dans un modèle simplifié. Un tel changement introduit une nouvelle action du compte et peut nécessiter des avoirs, des autorisations et un traitement de trésorerie différents.

Examinez la tentative d’origine à l’aide des enregistrements d’ordres et de compte pris en charge. Si elle a été partiellement exécutée, intégrez les unités Non confirmées et conservez tout reliquat non résolu. Si elle a été rejetée, libérez la réservation inutilisée correspondante. Si elle reste ouverte, décidez de la maintenir ou de l’annuler selon la stratégie actuelle. Ces décisions doivent s’appuyer sur l’identité d’origine et sur les éléments réels du compte.

Une course entre l’annulation et l’exécution peut modifier l’équilibre entre les côtés. Supposons que 50 unités Non soient confirmées au moment de la demande de retrait de l’ordre et que 15 unités supplémentaires soient exécutées avant la fin de l’annulation. La position est de 65 unités Non, et non de 50. Si le bot avait déjà soumis une opération de compensation fondée sur la quantité antérieure, le portefeuille résultant nécessite un nouveau rapprochement. Le système ne doit pas le faire artificiellement correspondre à l’exposition nette prévue en modifiant un champ récapitulatif.

Testez ces cas avec un compte initial délibérément asymétrique, par exemple une petite position Oui et une demande d’achat Non plus importante. Cela rend les erreurs de côté plus faciles à détecter qu’un test commençant à zéro dans tous les champs. Le résultat attendu doit préciser les avoirs bruts, la trésorerie et le versement possible, et pas seulement une quantité finale signée.

Rapprocher les frais et le règlement sans perdre la piste d’audit

Après l’exécution, remplacez les frais estimés dans les calculs de performance par les frais réels du compte, tout en conservant l’estimation d’origine pour examen. Si des frais d’acquisition supplémentaires de 0,20 $ sont confirmés ultérieurement dans l’exemple de sortie, le coût d’acquisition total passe de 82 $ à 82,20 $. Avec le même produit net de vente de 74,40 $, la perte devient 7,80 $. L’ajustement doit avoir une source et un horodatage identifiables.

Au règlement, utilisez la quantité finale restante de chaque côté. Une position Non entièrement vendue ne donne plus droit à aucun versement Non, même si la prévision initiale se révèle ensuite correcte. Une position partiellement vendue ne donne lieu à règlement que pour les unités conservées. Le grand livre final doit relier l’issue officielle, les quantités détenues, les montants crédités et tout traitement exceptionnel prévu par le contrat.

Distinguez une modification de prévision d’une correction comptable. Une nouvelle estimation ne modifie pas les liquidités déjà payées, et un ajustement de frais ne change pas l’issue sur laquelle porte le contrat. Les enregistrements du bot doivent permettre de représenter ces deux changements sans que l’un altère l’autre. Cette séparation aide la personne chargée de l’examen à comprendre pourquoi la valeur projetée et la performance finale diffèrent.

Si le rapprochement du compte échoue, conservez l’écart et limitez les nouvelles activités concernées jusqu’à ce qu’il soit compris. Une différence inexpliquée ne doit pas être dissimulée dans un gain divers ou une perte diverse simplement pour clore le dossier. De petits écarts peuvent révéler un problème récurrent de conversion d’unités ou de double comptabilisation des exécutions qui deviendrait significatif à plus grande échelle.

Comparer les frais estimés et réels par action

Un examen des frais doit déterminer si une différence provient du prix, de la quantité, du rôle d’exécution ou d’un barème incorrect. Supposons que le bot ait estimé les frais d’un achat intégralement exécuté immédiatement, mais qu’une partie de l’ordre soit restée dans le carnet avant de s’exécuter. Le traitement réel dépend des règles actuelles de la plateforme et du marché. Le grand livre doit conserver la classification de chaque exécution plutôt que d’attribuer le même rôle à toutes les unités sur la base de l’intention initiale.

La comparaison nécessite aussi une unité cohérente. Des frais exprimés sous la forme d’un montant de trésorerie ne doivent pas être comparés directement à un pourcentage du versement maximal ou à une provision par unité. Convertissez explicitement chaque mesure et conservez la valeur d’origine déclarée. Cela aide à distinguer une véritable erreur du modèle de coûts d’un affichage utilisant des dénominateurs différents.

Si l’estimation était prudente et que les frais réels étaient inférieurs, ne libérez la réserve inutilisée que lorsque les enregistrements pertinents justifient cette décision. Ne présentez pas la réserve inutilisée comme un revenu. Il s’agissait d’une capacité réservée pour un coût éventuel, et non d’argent gagné en négociant. Cette distinction empêche la performance apparente du bot de s’améliorer simplement parce que son estimation initiale était délibérément prudente.

Tester l’adaptateur avec quatre actions et deux issues

Un ensemble utile de tests d’acceptation comprend l’achat Oui, la vente Oui, l’achat Non et la vente Non, lorsque chacune de ces actions est autorisée pour le compte réel. Pour chaque action, vérifiez le côté du carnet sélectionné, la quantité, l’effet sur la trésorerie et les avoirs restants. Appliquez ensuite les deux issues ordinaires de résolution et confirmez le versement qui en résulte. Cela couvre des comportements aux conséquences plus importantes que la démonstration répétée d’un seul achat Oui réussi.

Ajoutez des tests portant sur une cotation dérivée du côté opposé, une profondeur insuffisante, une modification de frais et une exécution retardée. Les enregistrements attendus doivent conserver l’observation brute et l’interprétation normalisée. Si une conversion utilise un moins le prix acheteur opposé, vérifiez la correspondance du prix comme celle de la quantité. Si le marché utilise des incréments plus fins, incluez des valeurs pour lesquelles l’hypothèse de centimes entiers échouerait.

Le bot achevé doit permettre de formuler une affirmation simple pour chaque action : ce compte a acheté ou vendu cette quantité de cette issue à ces prix réels, en vertu de cette autorisation, avec ces frais et cette exposition restante au versement. Cette clarté est la raison d’être d’une automatisation tenant compte des côtés. Elle maintient le lien entre les calculs de probabilité du logiciel et les positions et flux de trésorerie que le compte détient réellement.