Bot de contrats événementiels : des données au rapprochement

Un bot de contrats événementiels a besoin d’un registre des contrats

Commencez par un registre explicite des contrats que le bot peut envisager. Enregistrez le contexte de la plateforme, l’identifiant du marché, les identifiants des issues, l’unité de règlement et la référence aux règles. Ajoutez l’heure de l’événement, l’heure limite de négociation et la source désignée dans le contrat. Le registre doit distinguer une publication initiale d’une valeur révisée et conserver la version de la correspondance utilisée pour chaque décision.

Cet enregistrement est plus précis qu’un résultat de recherche contenant un titre de marché. Une recherche automatisée peut découvrir un contrat candidat, mais cette découverte ne doit pas autoriser implicitement le trading. Deux marchés peuvent avoir le même intitulé tout en utilisant des seuils ou des fenêtres d’observation différents. Une correspondance vérifiée par une personne ou un processus éprouvé de mise en correspondance des règles doit établir que les données reçues par le bot répondent à la question que le contrat tranche lors de sa résolution.

Traitez tout changement de correspondance comme un événement significatif pour le système. Si un champ auparavant reconnu devient indisponible, le bot ne doit pas choisir un champ au nom similaire simplement pour maintenir le processus en fonctionnement. Si une clarification du contrat apparaît, conservez l’ancienne interprétation et consignez l’examen des nouvelles informations. Cet historique est nécessaire pour comprendre pourquoi une position antérieure a été ouverte sur la base d’hypothèses susceptibles de changer par la suite.

Le guide plus ancien sur l’API de bot pour les marchés de prédiction aide les lecteurs à comprendre le lien entre les identifiants de contrats et les actions sur le compte. Un registre n’est pas seulement une commodité de programmation. Il constitue la limite qui empêche qu’un signal concernant un événement soit dirigé vers une position superficiellement similaire, mais économiquement différente.

Séparer l’observation de l’interprétation

La couche d’observation consigne ce qu’une source a rapporté et le moment où le système l’a reçu. Elle ne doit pas immédiatement convertir chaque mise à jour en signal de trading. Conservez l’horodatage de la source, l’horodatage de réception, l’identifiant et la valeur pertinente exacte. Si un message est répété, indiquez qu’il s’agit de la même observation plutôt que d’une deuxième confirmation indépendante. Si des messages arrivent dans le désordre, conservez cette information d’ordre au lieu de remplacer une observation plus récente par une plus ancienne.

La couche d’interprétation détermine ce que l’observation signifie pour le contrat. Une publication indiquant qu’un indice vaut 100,3 peut étayer l’issue Oui pour un seuil supérieur à 100,2, mais uniquement si elle concerne la bonne publication, le bon champ et le bon traitement des arrondis. Un titre affirmant que l’indice a dépassé les attentes ne suffit pas lorsque le contrat porte sur une valeur absolue. Un analyseur doit extraire le fait pertinent pour le contrat plutôt qu’un sentiment général positif ou négatif.

Certaines données permettent d’estimer une probabilité plutôt que d’établir directement un fait. Le programme doit présenter ce résultat comme une prévision et en conserver l’incertitude. Une valeur de confiance renvoyée par un modèle de langage ou un classificateur n’est pas automatiquement une probabilité calibrée de versement au titre du contrat. Si l’interprétation nécessite un jugement juridique ou factuel inédit, le système peut la transmettre pour examen sans accorder au modèle le pouvoir de créer une exposition.

Une vue de diagnostic utile présente l’observation d’origine à côté de l’affirmation qui en a été déduite. Lorsqu’un opérateur remet une décision en question, il doit pouvoir examiner ce lien sans le reconstituer à partir d’un graphique de prix. Cela permet aussi d’isoler plus facilement les défaillances des sources : une observation périmée, une extraction incorrecte et une prévision raisonnable qui ne s’est pas réalisée sont des problèmes différents qui exigent des corrections différentes.

Définir le pouvoir de décision du bot de contrats événementiels

L’étape de recommandation propose une action en précisant un contrat, un sens, une quantité, un prix limite et un motif. L’étape d’autorisation détermine si cette proposition respecte les contraintes actuelles du compte. Ces étapes doivent être distinctes, même dans un petit programme. Une stratégie peut recommander un achat alors que le compte a déjà atteint sa limite pour l’événement, qu’un autre ordre reste non résolu ou que le flux de marché est devenu trop ancien pour justifier le prix proposé.

Un enregistrement d’autorisation doit préciser les limites vérifiées. Elles peuvent inclure un coût d’acquisition maximal, une exposition maximale à l’événement, un nombre maximal d’ordres ouverts et l’exigence que la correspondance du contrat reste à jour. Le résultat est une permission délimitée assortie d’une expiration, et non une instruction indéfinie de continuer les tentatives jusqu’à l’obtention de la quantité souhaitée. Si les conditions changent avant la soumission, le composant d’exécution doit demander une nouvelle décision ou refuser l’action.

Par exemple, une stratégie fictive recommande 100 unités Oui avec un prix limite d’achat de 0,56 $ et une réserve supplémentaire de 2 $ pour les frais. Le contrôle de risque du compte autorise un engagement maximal de 60 $ pour cet événement. L’engagement maximal proposé est de 58 $ ; il respecte donc cette contrainte particulière. Il peut néanmoins ne pas respecter une autre contrainte, telle qu’un ordre non résolu sur le même marché ou l’absence d’horodatage de la source officielle.

Cette distinction devient particulièrement importante lorsqu’un bot effectue plusieurs tâches. Un module de recherche peut ajouter des contrats à une liste de surveillance, mais il ne doit pas obtenir une autorisation de trading simplement parce qu’il partage un processus avec le composant d’exécution. Un module de notification peut avertir une personne d’un écart achat-vente inhabituel, mais cette alerte n’autorise pas une nouvelle stratégie. Des permissions explicites empêchent les observations utiles de devenir des instructions accidentelles sur le compte.

Réserver l’exposition avant tout envoi

La réservation de l’exposition par un bot de contrats événementiels empêche plusieurs décisions simultanées de consommer la même capacité. Lorsqu’une instruction est autorisée, réservez son coût maximal permis et l’exposition correspondante à l’événement avant de la soumettre. Maintenez la réservation tant que l’ordre est ouvert ou que son résultat est incertain. Ne libérez que la part dont les enregistrements faisant autorité établissent qu’elle ne peut plus être exécutée.

Supposons que l’ordre fictif de 100 unités commence à être exécuté. Quarante unités sont exécutées à 0,54 $, pour un coût de 21,60 $ avant frais. Soixante unités restent ouvertes avec un prix limite de 0,56 $, ce qui représente jusqu’à 33,60 $ de coût d’achat supplémentaire. Avec le maintien de la réserve de frais de 2 $, l’engagement total est de 57,20 $. Le prix inférieur de la part exécutée réduit l’engagement par rapport aux 58 $ initiaux, mais la part non exécutée constitue toujours une position future possible.

Si le budget de trésorerie concerné du compte est de 100 $, cette réservation simplifiée laisse 42,80 $ non engagés. Elle ne laisse pas 78,40 $ au seul motif que seulement 21,60 $ ont été dépensés jusqu’ici. Ce montant plus élevé ignorerait l’ordre ouvert et pourrait permettre à une autre stratégie de consommer des fonds déjà nécessaires à une exécution éventuelle. Les implémentations réelles doivent également rapprocher les frais effectifs et tout comportement de réservation propre à la plateforme.

Utilisez une vue commune de l’exposition pour les stratégies qui négocient sur le même compte. Des programmes séparés dotés de compteurs indépendants peuvent chacun croire que le compte dispose d’une capacité largement suffisante. La discussion plus ancienne sur l’automatisation du trading sur les marchés de prédiction fournit un contexte pour coordonner ces responsabilités. Le système de réservation doit adopter un comportement prudent en cas d’échec lorsqu’il ne peut pas déterminer si une autre instruction reste susceptible d’être exécutée.

Modéliser les ordres par des états plutôt que par des messages de réussite

Une demande d’ordre peut être préparée, soumise, acquittée, en attente dans le carnet, partiellement exécutée, achevée, rejetée, annulée ou incertaine. Ce sont des états conceptuels ; cela ne signifie pas que toutes les API utilisent exactement ces noms. Faites correspondre les réponses réelles de la plateforme à un modèle local documenté. Conservez la réponse d’origine avec son interprétation afin qu’une erreur de l’adaptateur puisse être examinée ultérieurement.

Une réponse réseau positive peut établir qu’une demande a été acceptée sans établir que la quantité prévue a été exécutée. À l’inverse, un délai d’attente réseau peut expirer après que la plateforme a accepté un ordre. Le bot doit éviter de traiter chaque réussite comme une position entièrement constituée et chaque expiration de délai comme un rejet. Les identifiants d’ordres, les enregistrements d’exécution et les instantanés du compte apportent des éléments de preuve différents sur ce qui s’est réellement passé.

La documentation actuelle de Polymarket sur le cycle de vie des ordres distingue les états des ordres de ceux des transactions. Cette distinction illustre pourquoi un seul booléen local nommé completed ne suffit pas. Une implémentation doit suivre les états propres à sa plateforme et à son produit, y compris les éventuels états intermédiaires d’exécution ou de règlement qui restent non résolus après le signalement d’un appariement.

Le composant d’exécution doit également conserver l’instruction autorisée d’origine. Si un ordre est exécuté à un meilleur prix, la position qui en résulte doit rester rattachable à la même permission. Si la quantité restante nécessite un prix plus élevé, il s’agit d’une nouvelle décision qui exige une autorisation selon les règles de la stratégie. Augmenter discrètement un prix limite pour atteindre la cible transforme un composant d’exécution encadré en un composant de stratégie non soumis à examen.

Les états de reprise du bot de contrats événementiels évitent de doubler l’exposition

Prenons une soumission dont la réponse ne parvient jamais au bot. L’enregistrement local indique qu’une tentative a été envoyée, mais ne permet pas de savoir si elle est devenue un ordre. L’état suivant approprié est incertain. Maintenez la réservation de l’exposition et interrogez la plateforme à l’aide des identifiants pris en charge et des données de compte permettant de déterminer l’issue de la tentative. Ne créez pas un nouvel ordre simplement parce que la première réponse manque.

Supposons que l’instruction initiale ait demandé 100 unités. Les données du compte révèlent ensuite que 40 ont été exécutées et que 60 sont toujours ouvertes. Le bot demande l’annulation du reliquat, mais 15 unités supplémentaires sont exécutées avant que l’annulation prenne effet. La position rapprochée est de 55 unités, et 45 unités ne sont plus ouvertes une fois l’annulation confirmée. Si le bot avait supposé que la tentative initiale avait échoué et soumis un autre ordre de 100 unités, l’exposition prévue aurait pu être largement dépassée.

La reprise doit rester possible malgré les redémarrages du processus. Enregistrez de manière persistante l’identifiant de la tentative et la réservation avant la soumission encadrée ou dans le cadre de ce processus, selon la conception de la cohérence du système. Au redémarrage, examinez les tentatives non résolues avant d’accepter de nouvelles recommandations pour la même exposition. Un lancement du programme dans un état vierge n’implique pas que le compte soit lui aussi vierge. La plateforme peut toujours conserver des ordres créés par le processus précédent.

Le guide de l’automatisation des contrats événementiels étend cette distinction au processus de recherche et d’examen qui l’entoure. La reprise n’est pas seulement un détail technique destiné aux pannes rares. Elle fait partie du contrôle de l’exposition de la stratégie, car le compte peut évoluer pendant que le système local est déconnecté, redémarre ou attend une réponse.

Construire une boucle de rapprochement indépendante de la stratégie

Un processus de rapprochement compare les attentes locales aux données de compte faisant autorité. Il doit fonctionner même lorsqu’aucun nouveau signal n’est généré. Comparez les ordres ouverts, les quantités exécutées, les positions, les frais et les soldes disponibles à l’aide d’identifiants et d’heures d’observation cohérents. Une divergence doit produire une anomalie explicite plutôt que d’être corrigée silencieusement d’une manière qui efface l’historique expliquant comment le modèle local est devenu erroné.

Distinguez les décalages temporels ordinaires des écarts inexpliqués. Une mise à jour d’exécution peut arriver avant la mise à jour de solde correspondante, selon le circuit de transmission de la plateforme. Le système peut autoriser un état temporaire documenté dans l’attente d’un instantané cohérent. Toutefois, un écart qui persiste au-delà du déroulement attendu doit bloquer toute nouvelle exposition dans le périmètre concerné jusqu’à ce qu’il soit expliqué. Ce périmètre peut être un marché, un compte ou l’ensemble du composant d’exécution.

L’enregistrement du rapprochement doit préciser quelles observations étayent la position actuelle. Un opérateur doit pouvoir voir que 55 unités proviennent de deux exécutions de 40 et 15, et non d’une différence déduite entre des soldes arrondis. Conservez les ajustements de frais séparément afin qu’une variation de trésorerie ne soit pas confondue avec une variation de la quantité de contrats. Après la résolution, reliez le versement à la position restante réelle et au résultat final du contrat.

Les lecteurs qui développent à partir d’une interface de compte peuvent utiliser la discussion plus ancienne sur le bot de trading avec l’API Kalshi pour organiser les enregistrements nécessaires. Le principe est indépendant du langage d’implémentation : la stratégie propose ce qui devrait se passer, tandis que le rapprochement établit ce qui s’est passé. Aucune de ces fonctions ne doit pouvoir substituer ses propres attentes aux éléments de preuve manquants.

Ajouter des limites aux systèmes à plusieurs jambes et de cotation

Un bot directionnel peut souvent exprimer son exposition par une seule position. Un système à plusieurs jambes doit suivre si la combinaison prévue est complète et ce qui reste lorsque seuls certains ordres sont exécutés. Une possibilité d’arbitrage de contrats événementiels dépend de versements compatibles et d’une exécution réalisable. Le bot doit représenter chaque jambe et les issues possibles de leur combinaison, plutôt que de consigner une paire comme complète dès l’acceptation du premier ordre.

Réservez de la capacité pour les jambes inachevées et définissez une durée maximale ou une condition limite pendant laquelle une jambe peut rester sans contrepartie. Si la deuxième jambe devient indisponible, le système a besoin d’une réponse prédéfinie compatible avec les limites de perte du compte. Cette réponse peut inclure l’annulation des ordres non exécutés, la réduction de la première position ou le maintien d’une exposition bornée en vue d’un examen. Elle ne doit pas supposer que n’importe quelle couverture, à n’importe quel prix, est automatiquement préférable à une décision prise de manière ordonnée.

Un système de cotation fait face à une autre difficulté : les deux côtés peuvent rester actifs pendant que les exécutions modifient l’inventaire. Un teneur de marché de contrats événementiels a donc besoin de permissions tenant compte de l’inventaire et d’une vue fiable des cotations en cours. Une mise à jour de cotation qui remplace un ancien ordre doit tenir compte de tout intervalle pendant lequel les deux instructions pourraient rester actives. Les expositions brute et nette autorisées du système doivent refléter cette possibilité.

Ces extensions illustrent pourquoi une fonction générique d’achat ou de vente ne constitue pas une architecture complète de bot. Des stratégies différentes nécessitent des représentations différentes du travail inachevé. Le socle commun repose sur un pouvoir explicite, la conservation de l’identité des ordres et le rapprochement ; la couche propre à la stratégie décrit quelles combinaisons d’exécutions sont acceptables et quels éléments de preuve sont nécessaires avant l’action suivante.

Suivre les horloges qui régissent une décision

Un bot doit conserver plusieurs références temporelles, car elles répondent à des questions différentes. L’horodatage de la source de l’événement indique quand l’information a été publiée. L’horodatage de réception indique quand le processus local l’a obtenue. L’horodatage du carnet indique l’état du marché utilisé pour la recommandation. L’horodatage de l’autorisation indique quand le compte a approuvé une action. Les regrouper dans un seul champ temporel peut dissimuler une observation périmée derrière un événement de traitement récent.

Supposons qu’une observation de source ait été publiée à 9:00, soit parvenue au collecteur à 9:01 et ait été rejouée après un redémarrage à 9:10. Cette relecture est nouvelle pour le processus redémarré, mais les éléments de preuve sous-jacents datent de dix minutes. Une règle de fraîcheur fondée uniquement sur l’heure d’insertion locale pourrait permettre au bot de traiter l’observation comme actuelle. Conservez les heures d’origine et signalez explicitement la relecture pour que la règle évalue bien le fait qu’elle a été conçue pour encadrer.

Les comparaisons d’horloges nécessitent aussi des règles pour les valeurs manquantes ou incohérentes. Si une source ne fournit aucune heure de publication fiable, le système ne doit pas en inventer une. Il peut utiliser une solution de repli documentée assortie d’une permission plus restrictive, ou s’abstenir d’effectuer les actions qui nécessitent des éléments temporels plus solides. L’objectif est de rendre l’incertitude temporelle visible dans l’enregistrement de décision, plutôt que de laisser un horodatage apparemment précis suggérer une connaissance que le système ne possède pas.

Tester avec des incidents qui modifient le compte

Une suite de tests utile se concentre sur les transitions qui ont des conséquences. Simulez une expiration du délai de réponse après acceptation, une exécution partielle pendant une annulation, un instantané de marché périmé et un redémarrage avec un ordre non résolu. Vérifiez que le bot conserve la réservation appropriée et refuse les actions susceptibles de dépasser ses limites. Un test qui confirme seulement qu’une fonction renvoie la valeur qui lui est affectée en interne apporte peu d’éléments sur ces scénarios de défaillance réels.

Utilisez un petit ensemble d’incidents rejouables dont les enregistrements attendus sont connus. Pour l’exemple de 100 unités, le test doit se terminer avec 55 unités exécutées et 45 annulées, sans deuxième soumission de 100 unités. Le modèle de trésorerie doit refléter les prix d’exécution et les frais réels plutôt que l’estimation maximale initiale. Un autre test peut omettre délibérément un événement d’exécution et exiger que le rapprochement retrouve l’exécution manquante au moyen d’une interrogation du compte.

Testez également l’inactivité sans conséquence dommageable. Lorsque la prévision est indisponible, que la correspondance du contrat n’est pas résolue ou que l’état du compte est incohérent, le bon résultat peut être l’absence d’ordre. Un système évalué uniquement sur les soumissions réussies peut récompenser l’activité tout en négligeant les décisions qui empêchent une exposition indésirable. Consignez pourquoi une action a été refusée afin que les opérateurs puissent distinguer une pause délibérée d’un dysfonctionnement passé inaperçu.

Le bot n’est prêt pour une utilisation plus large que lorsque ses enregistrements rendent compréhensibles le fonctionnement ordinaire et la reprise. Un opérateur doit pouvoir identifier sans deviner le contrat actuel, les éléments de preuve, la permission, les engagements ouverts et la position confirmée. Cette transparence ne démontre pas un avantage de trading, mais elle permet d’examiner le comportement du programme et donne à la stratégie un socle fiable pour son évaluation.