Négocier automatiquement sur Polymarket et Kalshi : les journaux

Négocier automatiquement sur Polymarket et Kalshi : définir le coordinateur

Le coordinateur décide si une stratégie peut proposer des opérations. Il n’a pas besoin de faire comme si les deux plateformes acceptaient le même format de requête. Une répartition utile consiste à confier au coordinateur les calendriers, les limites communes et les identifiants de décision, tandis que les implémentations propres aux comptes gèrent l’authentification, les identifiants de marché et la conversion des ordres.

Cette séparation facilite l’examen des responsabilités. Si une proposition est rejetée parce que son budget consacré à l’événement est épuisé, il s’agit d’une décision de coordination. Si un compte rejette une forme d’ordre non prise en charge, il s’agit d’un problème d’exécution local. Fusionner les deux dans une erreur opaque complique la reprise.

Le guide général du trading automatisé sur les marchés de prédiction décrit le cycle observer-décider-agir. Avec deux plateformes, ce cycle exige une délimitation supplémentaire : une intention commune doit être convertie, pour chaque compte, en une action économique conforme à sa documentation actuelle, sans mélanger les identifiants d’accès ni les ressources.

Donner à chaque compte une identité sans ambiguïté

La fiche d’un compte doit identifier le service, l’environnement, le propriétaire et le produit concerné. Une étiquette telle que « portefeuille principal » ne suffit pas si plusieurs services ou environnements utilisent des adresses ou des noms d’utilisateur similaires. Les journaux et les alertes doivent inclure suffisamment d’informations d’identité pour indiquer où une action s’est produite.

Maintenez les identifiants d’accès associés à cette identité au lieu de les sélectionner au moyen d’un choix global par défaut. Une requête destinée à un compte ne doit pas hériter des autorisations d’un autre compte parce que les deux processus d’exécution utilisent la même fonction auxiliaire ou le même écran de paramètres. L’isolation des comptes de trading automatisé sur les marchés de prédiction commence par un routage explicite.

L’isolation désigne ici la manière dont l’automatisation traite les fiches des comptes et leurs autorisations. Elle ne signifie pas que le mode de compte de chaque plateforme sépare en interne toutes les ressources économiques. L’implémentation doit prendre connaissance du fonctionnement des ressources du compte réel et éviter d’inventer une séparation des garanties que ses conditions ne prévoient pas.

Séparer les calendriers d’observation des calendriers de négociation

Un marché peut être observé plus fréquemment qu’il n’est admissible à de nouveaux ordres. Distinguez l’actualisation des données, l’évaluation de la stratégie, l’autorisation des ordres et l’examen du règlement. Les traiter comme les déclenchements d’une seule minuterie récurrente incite à transformer chaque mise à jour en tentative de transaction.

Pour une stratégie horaire fictive, les observations peuvent arriver en continu alors que les nouvelles décisions ne sont envisagées qu’à des moments d’examen définis. Une annonce liée à un événement peut suspendre temporairement les entrées pendant que le système actualise les éléments probants relatifs au contrat. Les vérifications du règlement peuvent se poursuivre après l’arrêt des nouvelles négociations.

La planification des opérations sur les marchés de prédiction de deux plateformes doit rendre ces responsabilités visibles. Chaque tâche a besoin d’un déclencheur, d’un objectif et d’une condition dans laquelle elle est ignorée. Cela évite de prendre le silence d’un processus d’exécution pour une connexion aux données défaillante, ou l’activité d’un processus d’observation pour la preuve que la stratégie négocie activement.

Utiliser délibérément l’heure de l’événement et l’heure de traitement

L’heure à laquelle un événement s’est produit peut différer de celle à laquelle le système l’a reçu. Une mise à jour du marché peut porter un horodatage de source, arriver plus tard et être traitée encore plus tard. Préservez ces distinctions lorsque vous déterminez si l’observation reste pertinente.

Imaginez une cotation fictive produite à 12:00:00, reçue à 12:00:03 et évaluée à 12:00:07. Une stratégie qui mesure la fraîcheur uniquement à partir de l’heure d’évaluation peut considérer à tort cette cotation comme actuelle. Un processus de reprise qui la rejoue après un redémarrage peut aggraver l’erreur.

Définissez la fraîcheur à l’aide des éléments appropriés concernant la source et la réception, en signalant les cas où l’heure de la source n’est pas disponible. L’ordonnanceur doit aussi utiliser des fuseaux horaires explicites pour les échéances des marchés et les affichages destinés à l’opérateur. Une heure locale affichée sans fuseau constitue une base fragile pour coordonner entre plusieurs services une activité déclenchée par des événements.

Créer une intention avant de créer un ordre

Une intention est la décision économique autorisée par l’opérateur : un compte précis doit modifier son exposition à un contrat examiné, dans les limites de quantité, de prix et de coût indiquées. Un ordre est une tentative, propre à une plateforme, de mettre cette décision à exécution. Les garder distincts permet au système d’expliquer les nouvelles tentatives et les exécutions partielles.

Par exemple, une intention fictive peut autoriser l’acquisition d’un maximum de 40 unités YES en dessous d’un coût total défini. Le premier ordre est exécuté à hauteur de 15 unités, puis expire. Une tentative ultérieure autorisée peut ne viser que les 25 unités restantes, si l’intention reste valide et si ses limites sont toujours respectées.

Sans enregistrement de l’intention, le deuxième ordre peut sembler être une nouvelle décision sans rapport avec la précédente. Il devient alors difficile de déterminer si le total des quantités exécutées dépasse ce qui a été autorisé. Le guide du trading algorithmique sur les marchés de prédiction explique le contexte de la transformation des décisions de stratégie en actions vérifiables.

Faire ajouter des éléments probants au journal plutôt que réécrire l’historique

Les journaux coordonnés des ordres Polymarket et Kalshi doivent préserver la succession des décisions et des observations. Un ordre peut passer d’une soumission incertaine à une réception confirmée, puis à une exécution partielle et à une annulation. Remplacer la ligne initiale par la seule étiquette finale supprime des éléments probants nécessaires pour comprendre l’exposition intermédiaire.

Consignez l’identifiant de l’intention, le compte, le contrat, l’action demandée, les horodatages pertinents et chaque tentative d’exécution. Ajoutez les références des ordres de la plateforme et les exécutions confirmées lorsqu’elles deviennent disponibles. Les corrections doivent expliquer ce qui a changé au lieu d’effacer silencieusement l’observation antérieure.

Cela n’exige pas de stocker des identifiants d’accès sensibles ni des données personnelles inutiles. Le journal doit contenir suffisamment d’informations non secrètes pour reconstituer l’action économique et son résultat. Un enregistrement utile indique pourquoi un ordre a été autorisé et quels éléments probants ont établi son état final, sans exposer les moyens d’autorisation nécessaires pour passer un autre ordre.

Convertir localement les conventions actuelles des ordres

Les deux services peuvent modifier les représentations prises en charge, les points de terminaison et les règles de précision. Le coordinateur doit exprimer l’intention économique, tandis que l’implémentation de chaque compte convertit cette intention à l’aide de la documentation officielle actuelle. Ne supposez pas que les exemples plus anciens restent valables indéfiniment.

Le guide du sens des ordres de Kalshi constitue une référence actuelle pour sa représentation. L’intégration Polymarket réellement utilisée possède ses propres identifiants d’actifs et exigences de signature. La validation réussie d’une requête est nécessaire, mais ne prouve pas à elle seule que l’exposition obtenue correspond à l’intention de la stratégie.

Testez la conversion avec des actions fictives d’ouverture et de clôture. Montrez la variation de position attendue pour chaque sens. Si l’implémentation ne peut pas expliquer la différence entre augmenter l’exposition YES et réduire une position existante, elle ne doit pas déduire la correspondance de termes familiers dans une interface utilisateur.

Réserver du capital entre des décisions simultanées

Deux processus d’exécution peuvent observer chacun le même solde disponible avant que l’un d’eux ne l’engage. Un processus d’autorisation commun doit empêcher les deux de considérer ce montant comme exclusivement disponible pour eux. Cela reste vrai même lorsque les comptes sont distincts si une limite commune de portefeuille s’applique à eux.

Supposons qu’un portefeuille fictif dispose encore de 100 $ de capacité autorisée. Un processus propose 70 $ et un autre propose 60 $. Chaque proposition respecte la limite lorsqu’elle est considérée seule, mais ensemble elles la dépassent. Le coordinateur doit réserver la capacité nécessaire à une intention approuvée avant d’approuver une autre intention concurrente.

La disponibilité locale des fonds à dépenser reste une vérification distincte. Une proposition peut respecter la limite du portefeuille tout en manquant de fonds utilisables dans son propre compte. Les deux conditions doivent être remplies. Le total agrégé d’un tableau de bord ne doit jamais se substituer aux ressources propres au compte que l’ordre consommera effectivement.

L’exemple sur les ressources dans une comparaison entre plateformes étend ce problème de réservation à deux paires candidates qui, sans cela, réutiliseraient la même liquidité limitée du carnet.

Traiter les réponses manquantes comme une incertitude

Une connexion peut échouer après qu’un ordre est parvenu à la plateforme, mais avant que la réponse ne parvienne à l’application. L’état correct est incertain, et non automatiquement en échec. Répéter l’action économique sans vérification peut créer une position en double involontaire.

Le journal doit identifier la tentative non résolue et les éléments probants nécessaires pour la résoudre. Consultez les enregistrements pertinents des ordres et du compte auxquels vous êtes autorisé à accéder, selon la procédure documentée. Si l’ordre est retrouvé, rattachez son état à l’intention initiale. Si son absence ou son rejet sont établis de manière définitive, déterminez si une nouvelle tentative reste autorisée.

Ne libérez pas la totalité de la réservation au seul motif qu’un délai d’attente local a expiré. Cette réservation protège contre un ordre qui peut encore être exécuté. Si l’incertitude ne peut pas être levée rapidement, interrompez les nouvelles activités qui en dépendent et signalez l’exposition précise qui reste indéterminée au lieu de continuer comme si rien ne s’était passé.

Traiter les mises à jour en double sans dupliquer les transactions

Les flux de données peuvent répéter des observations, et les reconnexions peuvent rejouer des événements déjà traités. Une notification d’exécution répétée doit mettre à jour le même enregistrement économique au lieu de créer une autre exécution. Un signal de marché répété ne doit pas automatiquement autoriser un autre ordre.

Utilisez des identifiants stables lorsque la source en fournit et conservez le contexte nécessaire pour distinguer les événements réellement distincts. Les règles de déduplication doivent être propres au type d’événement. Une référence de transaction, une référence d’ordre et un identifiant de décision de stratégie répondent à des questions différentes et ne doivent pas être substitués les uns aux autres à la légère.

Testez le système avec une mise à jour volontairement répétée. La quantité et le coût enregistrés sur le compte doivent rester inchangés après la détection du doublon. Testez ensuite deux exécutions distinctes de montants similaires pour vérifier que le système ne fusionne pas des activités légitimes simplement parce que leurs lignes se ressemblent. Les deux erreurs faussent l’exposition.

Planifier l’annulation comme une opération à mener à son terme

Une demande d’annulation est une autre opération dont il faut observer le résultat. Elle ne doit pas être traitée comme une suppression locale de l’ordre. Une quantité peut être exécutée avant que l’annulation ne prenne effet, et l’état restant doit faire l’objet d’un rapprochement à l’aide d’éléments probants faisant autorité.

Pour un ordre fictif de 100 unités, 30 peuvent être exécutées avant une demande d’annulation et 10 autres avant la confirmation. La position finale est de 40, avec 60 unités annulées si les enregistrements de la plateforme établissent ce résultat. Ne déclarer que les 30 unités connues au moment de la demande sous-estime l’exposition.

Définissez ce que fait le coordinateur tant que l’annulation n’est pas résolue. Il peut interdire les ordres de remplacement pour la même intention ou maintenir une réservation prudente. Les contraintes actuelles liées à l’état des ordres sont propres au compte ; une commande d’arrêt générique ne doit pas promettre que toute action ouverte peut être annulée instantanément dans toutes les conditions.

Négocier automatiquement sur Polymarket et Kalshi : simuler un redémarrage

Un redémarrage doit commencer par reconstituer les obligations en cours avant d’autoriser de nouvelles opérations. Chargez les intentions non résolues, obtenez l’état actuel des comptes et des ordres, puis rapprochez les activités confirmées. Déterminez seulement ensuite quels calendriers peuvent reprendre en toute sécurité.

Imaginez un arrêt fictif après qu’une plateforme a confirmé une exécution partielle alors que l’autre laisse une soumission sans réponse. Au redémarrage, le système ne doit pas supposer que les deux intentions doivent être soumises à nouveau. Il doit reconnaître la position partielle connue et résoudre séparément la tentative incertaine.

La présentation des logiciels de trading sur les marchés de prédiction insiste sur l’observabilité pour cette raison. Un processus qui reprend rapidement mais duplique l’exposition est moins fiable qu’un processus qui s’interrompt brièvement pour établir l’état réel. La vitesse de reprise doit être mesurée en même temps que l’exactitude, et non isolément.

Maintenir l’examen des contrats indépendant du bon fonctionnement de l’ordonnanceur

Un ordonnanceur peut fonctionner parfaitement tout en agissant sur la base d’une interprétation invalide du contrat. Conservez une fiche de contrat examinée comprenant l’identité du marché, la définition de l’issue, la source et les dates importantes. Une intention doit faire référence à cette version examinée, et non uniquement au dernier titre affiché.

Si une clarification ou une modification des métadonnées affecte le sens du contrat, les nouvelles intentions doivent nécessiter un réexamen. Les positions existantes doivent faire l’objet d’un examen documenté plutôt que d’une réinterprétation automatique. Cela empêche une actualisation du logiciel de modifier silencieusement la question économique sur laquelle l’opérateur pensait négocier.

L’examen des contrats est particulièrement important lorsque les deux plateformes proposent des intitulés similaires. Coordonner leurs calendriers ne prouve pas que leurs paiements correspondent. Si une stratégie repose sur leur équivalence, cette relation exige des éléments probants distincts ; dans le cas contraire, maintenez les expositions séparées dans le registre du portefeuille.

Un bot opérant sur les deux marchés Polymarket et Kalshi gère les versions de la correspondance des contrats séparément de la politique de trading et recalcule l’exposition non appariée lorsque la relation change.

Respecter les limites de requêtes en hiérarchisant les tâches

Une intégration peut limiter la fréquence des requêtes ou l’utilisation d’autres ressources. L’ordonnanceur doit fonctionner dans les limites actuellement documentées et hiérarchiser les tâches selon leur effet sur l’exposition. La récupération répétée de données purement visuelles ne doit pas évincer la reprise ou les vérifications de l’état des ordres.

Séparez les actualisations courantes des rapprochements urgents. Lorsque les ressources sont limitées, un processus peut ralentir la découverte non essentielle tout en préservant la capacité d’examiner un ordre non résolu. Il s’agit d’une politique d’exploitation, et non d’une suggestion de contourner les limites de la plateforme ou de répartir les requêtes entre plusieurs identités pour s’y soustraire.

Consignez la limitation du débit et les délais de réessai comme des états explicites. Une vérification retardée peut rendre les données obsolètes, et la stratégie doit en être informée. Faire comme si une requête en attente avait déjà actualisé le compte crée une fausse certitude quant au capital disponible et à l’exposition existante.

Distinguer les heures de clôture, de détermination de l’issue et de crédit

Un calendrier ne doit pas utiliser un seul horodatage pour toutes les étapes de la vie d’un contrat événementiel. Les négociations peuvent s’arrêter avant que la plateforme ne détermine l’issue, et l’enregistrement du compte peut nécessiter un traitement supplémentaire avant que les ressources soient utilisables. Ces étapes exigent des observations distinctes.

La documentation du règlement de Kalshi décrit des délais variables. Le processus de résolution et de gestion des positions de Polymarket doit lui aussi être examiné pour le service réellement utilisé. Ne supposez pas qu’un événement ou un intitulé commun entraîne des crédits simultanés sur les comptes des deux plateformes.

Après la fin des négociations, maintenez les tâches d’examen du règlement actives pour les positions non résolues. Consignez les montants attendus comme des prévisions jusqu’à ce que des éléments probants réels du compte les confirment. Si le résultat diffère, examinez la quantité de la position, les conditions du contrat et le traitement applicable au lieu de forcer le registre à correspondre à la prévision initiale.

Construire les alertes autour des décisions nécessitant une attention

L’opérateur n’a pas besoin d’une notification pour chaque mise à jour courante. Les alertes doivent identifier les situations qui modifient l’exposition, bloquent le rapprochement ou exigent un jugement que le système ne peut pas porter. Il peut s’agir d’une soumission non résolue, d’un écart inattendu sur le compte ou d’une modification de la définition du contrat.

Chaque alerte doit préciser le compte, l’intention concernée, l’exposition connue et l’action actuellement suspendue. « Problème de connexion » est moins utile que « nouveaux ordres suspendus pendant la vérification de l’état final de cette soumission précise ». Des informations claires réduisent le risque qu’une action manuelle précipitée duplique ce que l’automatisation a déjà fait.

Regroupez les alertes répétées concernant le même incident sans masquer les nouveaux éléments probants. Une exécution confirmée ultérieurement peut modifier sensiblement la réponse à apporter, même si le problème de connexion persiste. La gestion des notifications doit réduire le bruit tout en préservant les informations nécessaires pour gérer la position restante.

Rapprocher les dépôts et les transferts séparément des opérations de trading

Les soldes des comptes peuvent varier en raison de dépôts, de retraits, de frais, de ventes ou du règlement. Un journal qui attribue chaque augmentation à un trading rentable produira des résultats trompeurs. Gardez les mouvements de ressources sans lien avec le trading distincts et rattachez-les à leurs propres enregistrements.

Pour un compte fictif, un dépôt de 50 $ et une perte de trading de 20 $ produisent une augmentation du solde de 30 $ avant les autres variations. Le rapport correct présente les deux composantes. Il ne décrit pas cette augmentation comme un gain de 30 $ issu de l’automatisation.

La documentation actuelle des garanties de Polymarket International constitue l’une des raisons d’éviter de supposer une représentation universelle du financement. Les ressources et mouvements réels de chaque compte doivent être normalisés avec soin pour les rapports, tout en conservant les unités d’origine et les éléments probants propres au service qui les sous-tendent.

Évaluer le coordinateur à l’aide de scénarios de défaillance

Une simulation utile comprend une réponse retardée, un événement d’exécution répété, une cotation obsolète, une annulation partiellement achevée et un redémarrage en situation d’incertitude. Le résultat attendu doit être précisé avant d’exécuter chaque scénario. Sinon, tout comportement observé peut être justifié après coup.

Pour chaque exercice, vérifiez à la fois la sécurité du processus d’autorisation et l’exhaustivité des enregistrements. Le système a-t-il évité de dépasser l’engagement prévu ? L’opérateur pouvait-il expliquer la quantité finale et les coûts ? Une défaillance locale est-elle restée locale, sauf lorsqu’une dépendance commune exigeait des restrictions plus larges ?

Ces tests ne prouvent pas la rentabilité future. Ils établissent si le processus de coordination peut préserver ses propres règles lorsque les informations arrivent de manière imparfaite. Ces éléments probants sont directement pertinents pour l’exploitation de deux plateformes, où les réponses asynchrones et les historiques de compte distincts constituent des considérations de conception normales plutôt que de rares cas limites.

Définir le cadre de l’intervention manuelle

Un opérateur peut avoir besoin d’agir en dehors de l’interface automatisée pendant un incident. Le journal doit détecter cette activité du compte au lieu de supposer que chaque variation provient de ses propres processus d’exécution. Une annulation ou une vente manuelle peut modifier la quantité encore disponible pour une instruction automatisée.

Définissez comment le système reprend après une intervention. Actualisez les ordres, les exécutions et les soldes, rapprochez la modification manuelle et invalidez toute proposition dont les hypothèses ne tiennent plus. Sinon, une réduction manuelle utile peut être suivie d’un remplacement automatique qui rétablit l’exposition indésirable. Une attribution claire des responsabilités pendant un incident fait donc partie de la coordination, et ne relève pas simplement d’une préférence d’interface utilisateur. L’opérateur doit savoir si l’automatisation est suspendue, en observation ou autorisée à agir pendant l’examen.

Garder un périmètre d’exploitation suffisamment restreint pour pouvoir l’expliquer

Commencez par un ensemble clairement défini de marchés, de calendriers et d’actions autorisées. L’ajout de stratégies multiplie les interactions possibles entre les budgets, les ordres et les heures des événements. Un vaste système que l’opérateur ne peut pas reconstituer est difficile à superviser, même si chaque composant paraît sophistiqué.

N’élargissez le périmètre que lorsque le journal et le processus de reprise peuvent expliquer le périmètre existant. La fonctionnalité suivante doit répondre à un besoin connu, comme un examen manquant du règlement ou une vérification importante de l’état d’un compte, plutôt que simplement augmenter le nombre de marchés connectés.

Pour négocier automatiquement sur Polymarket et Kalshi de manière cohérente, préservez les réalités distinctes de chaque compte au sein d’un processus de décision commun. Des calendriers explicites déterminent quand les opérations sont autorisées ; les enregistrements des intentions expliquent ce qui a été autorisé ; les éléments probants des plateformes établissent ce qui s’est produit. Le résultat est un processus qui reste vérifiable lorsque l’exécution est partielle, retardée ou interrompue.

Guides connexes et exemples détaillés

• Bot pour plusieurs marchés de prédiction : groupes d’exposition — Regroupez les expositions liées sur les marchés de prédiction au lieu de traiter chaque marché comme indépendant.
• Bot pour les marchés de prédiction Kalshi : sélectionner les événements avec soin — Admettez les marchés événementiels selon leurs règles, leur expiration et leurs exigences de règlement.