Un bot d’arbitrage sur contrats événementiels doit gérer la période pendant laquelle une combinaison envisagée n’est que partiellement concrétisée. Un outil de détection peut repérer des prix qui paraissent intéressants ensemble, mais un compte reçoit des ordres et des exécutions individuels. Un ordre peut être accepté alors qu’un autre est rejeté. Une annulation peut intervenir après une exécution supplémentaire. Une réponse peut se perdre alors même que la plateforme a accepté la demande. Le bot doit décrire ces états sans prétendre que la paire prévue existe déjà.
Le principal problème de conception est la coordination dans l’incertitude. Réservez la capacité nécessaire aux deux jambes, conservez leurs identités et mesurez l’exposition qui subsiste lorsqu’elles ne progressent pas ensemble. Les exemples fictifs présentés ici utilisent des paiements binaires d’un dollar explicitement compatibles. Ils illustrent des contrôles d’exécution, sans affirmer qu’une opération réelle entre plateformes peut être réalisée de manière atomique ni qu’un arbitrage apparent est sans risque.
Les réservations d’un bot d’arbitrage sur contrats événementiels commencent par une paire approuvée
Le moteur d’exécution doit recevoir une définition de paire ayant fait l’objet d’un examen, plutôt que deux noms de marchés vaguement liés. Cette définition comprend le contexte de chaque plateforme, l’identifiant du contrat, le côté de l’issue, la version des règles et la relation entre les paiements. Elle doit aussi préciser quelles issues exceptionnelles ont été envisagées et quelles conditions invalident la correspondance. Une paire de contrats dont le sens reste indéterminé relève de la recherche et ne doit pas figurer dans la file des instructions prêtes à être exécutées.
L’instruction envisagée ajoute les quantités actuelles, les prix plafonds, les estimations de frais et les heures d’observation. Elle précise le coût combiné maximal acceptable et le niveau d’exposition non appariée que le compte est prêt à tolérer. Ces limites sont distinctes. Une paire peut être abordable une fois complétée, alors que sa première jambe crée une exposition directionnelle temporaire trop importante pour le compte. Il faut répondre aux deux questions avant de soumettre le moindre ordre.
Utilisez un identifiant de dossier persistant pour relier la définition, la recommandation, l’autorisation et les ordres éventuels. Chaque jambe doit aussi posséder sa propre identité d’instruction stable. L’identifiant de paire explique pourquoi les ordres vont ensemble ; les identifiants des jambes permettent au système d’examiner une soumission individuelle. Aucun ne doit être remplacé simplement parce qu’une requête réseau dépasse son délai d’attente ou qu’un processus redémarre.
L’article antérieur sur le bot d’arbitrage sur marchés de prédiction présente plus largement le lien entre une occasion détectée et un processus de trading. Cette conception commence au stade où l’analyse des paiements a déjà été examinée. Son rôle est de veiller à ce que la combinaison réelle du compte reste visible à mesure que les ordres passent par différents états.
Réserver les fonds de chaque compte et la capacité de risque partagée
Supposons qu’une paire fictive prévoie 500 unités de A Yes à un prix maximal de 0,37 $ et 500 unités de B No à un prix maximal de 0,60 $. Supposons que, selon les règles, une unité de chaque contrat donne un paiement combiné d’un dollar dans les issues modélisées. Les montants d’achat s’élèveraient à 185 $ et 300 $. Avec des frais hypothétiques de 3 $ et 4 $, le coût total d’acquisition est de 492 $, soit 8 $ de moins que le paiement supposé de 500 $.
Dans ces hypothèses, le bot doit disposer de 188 $ pour A et de 304 $ pour B. Si les jambes utilisent des comptes distincts, la présence de 492 $ quelque part dans le portefeuille global ne suffit pas. Chaque compte doit disposer de sa propre capacité utilisable avant l’exécution. La réservation doit inclure les frais appropriés et toute marge supplémentaire de reprise choisie par l’opérateur. Cette marge relève d’une règle de contrôle ; elle n’entre dans le calcul du bénéfice prévisionnel que si elle est effectivement dépensée.
Au niveau du portefeuille, réservez la capacité d’exposition à l’événement concerné ainsi que les liquidités. Plusieurs paires envisagées peuvent toutes dépendre du même événement ou de la même plateforme pour la seconde jambe. Permettre à chaque dossier de réserver des fonds indépendamment, sans vérifier les limites partagées, peut entraîner une accumulation excessive de premières jambes incomplètes. Un service commun de gestion des risques, ou une autre méthode de coordination cohérente, doit empêcher ces dossiers de revendiquer la même capacité restante.
Les réservations doivent subsister pendant l’incertitude. Un ordre dont le rejet est confirmé par une source faisant autorité peut libérer son montant inutilisé. Un ordre dont la réponse manque ne le peut pas. Au redémarrage, un processus doit recharger les réservations non résolues avant d’accepter de nouveaux dossiers. Sinon, le programme peut sembler disposer d’un nouveau budget alors que les comptes contiennent encore des engagements créés pendant la session précédente.
Choisir délibérément la séquence d’exécution
Soumettre les deux jambes presque au même moment réduit une partie du délai lié au séquencement, mais ne garantit ni leur acceptation ni leur exécution simultanées. Envoyer une jambe en premier peut simplifier la coordination, mais crée une période d’exposition directionnelle connue. Un système doit choisir sa séquence en fonction de la liquidité observée, du comportement des plateformes et de l’exposition autorisée pour le compte, puis évaluer les résultats de ce choix au lieu de le traiter comme un détail d’implémentation.
Il est souvent tentant d’exécuter d’abord la jambe la plus difficile. Cela peut être raisonnable dans un processus testé, mais une réponse définie reste nécessaire si la jambe la plus facile devient indisponible. Une autre approche consiste à placer un ordre en attente pour un côté et à réagir à ses exécutions. Cela peut améliorer le prix d’entrée coté tout en augmentant le risque que le prix complémentaire change avant la réaction. L’évaluation doit porter sur la combinaison complétée et sur les dossiers restés incomplets.
Les instructions d’exécution d’un ordre individuel ne créent pas une transaction entre plateformes. Par exemple, une instruction « tout ou rien » peut imposer une contrainte à une jambe sur une plateforme qui la prend en charge, mais elle n’oblige pas une autre plateforme à exécuter l’ordre correspondant. La documentation de Polymarket sur le cycle de vie des ordres décrit plusieurs comportements d’ordres individuels. Le bot doit vérifier le comportement réellement pris en charge pour chaque jambe et éviter d’étendre une garantie locale à l’ensemble de la paire.
Documentez la séquence choisie dans le dossier. Enregistrez le moment où chaque autorisation a été créée, celui où chaque requête a été envoyée et les informations disponibles avant la seconde soumission. Ces éléments permettent de comparer ultérieurement les règles de séquencement. Sans eux, une paire réussie peut masquer la même faiblesse de synchronisation qui provoquera une exécution partielle coûteuse dans le dossier suivant.
Suivre les quantités à chaque étape
Pour chaque jambe, distinguez les quantités demandées, acceptées, exécutées, annulées et encore incertaines. Ces chiffres répondent à des questions différentes. La quantité demandée exprime une intention. La quantité exécutée établit une position. La quantité encore ouverte peut toujours accroître cette position. La quantité incertaine représente une exposition que le système local n’a pas encore résolue. Les regrouper dans un seul pourcentage d’achèvement peut masquer le sens et l’ampleur du risque restant.
La quantité appariée est celle pour laquelle les positions requises ont effectivement été acquises dans des proportions compatibles. Dans l’exemple simple à un pour un, si 500 unités de A et 300 de B sont exécutées, la quantité appariée est de 300 et la quantité de A non appariée est de 200. Si un paiement plus complexe exige un ratio différent, le calcul d’appariement doit suivre ce ratio préalablement examiné plutôt que de supposer une égalité.
Gardez le calcul des quantités indépendant des soldes de liquidités. Une variation de solde peut inclure des frais, des transferts ou des opérations sans rapport ; elle remplace donc mal les enregistrements d’exécution. Stockez l’identifiant, le sens, la quantité et le prix de chaque exécution, et dédupliquez les notifications répétées d’une même exécution. Un événement rejoué doit confirmer les informations existantes plutôt que créer une seconde écriture de position.
Le guide antérieur du bot d’arbitrage Kalshi peut aider à structurer les enregistrements côté compte pour une implémentation propre à une plateforme. La règle générale est que l’achèvement d’une paire doit être déduit des quantités réelles de ses jambes. Une cotation combinée favorable, un lot soumis ou deux requêtes dont la réception a été confirmée ne suffisent pas à établir la position complète.
Les exécutions partielles d’un bot d’arbitrage sur contrats événementiels imposent une nouvelle décision
Poursuivons l’exemple fictif avec les 500 unités de A entièrement exécutées à 0,37 $, mais seulement 300 unités de B exécutées à 0,60 $. Les montants d’achat sont de 185 $ et 180 $, soit un total de 365 $ avant frais. Trois cents unités forment des paires complètes, pour un coût de 291 $ avant frais. Les 200 unités de A restantes coûtent 74 $ et présentent une exposition directionnelle. Le résultat net initialement prévu de 8 $ pour 500 paires complètes ne décrit plus cet état du compte.
Le bot doit cesser d’évaluer le dossier uniquement à partir de son score d’opportunité initial. Il lui faut désormais une décision de reprise fondée sur les cotations actuelles et des limites explicites. Peut-on acquérir 200 unités de B supplémentaires en respectant un coût total autorisé ? Les unités de A non appariées peuvent-elles être vendues dans la limite d’une perte autorisée ? Leur conservation temporaire est-elle permise, et pendant combien de temps ? Chaque option doit s’appuyer sur la position réellement existante et les quantités exécutables en temps réel.
Supposons que la règle écrite de l’opérateur autorise à réduire la position de A non appariée à un prix acheteur d’au moins 0,34 $, après confirmation de l’annulation de l’ordre B restant. La vente de 200 unités de A à ce prix rapporte 68 $. Le compte détient alors 300 paires complètes, qui versent 300 $ selon les hypothèses de l’exemple. Les recettes combinées sont de 368 $ pour un montant d’achat de 365 $, soit un solde de 3 $ avant frais. Si le total des frais réels pour ce parcours est de 5 $, le résultat final est une perte de 2 $.
Cette perte ne prouve pas que le calcul d’une paire entièrement complétée pour 492 $ était faux. Elle montre que l’exécution prévue n’a pas eu lieu et que la reprise a eu un coût. Le registre doit conserver les deux calculs. Évaluer uniquement les paires favorables complétées en excluant les dossiers partiels ayant nécessité une reprise surestimerait l’utilité des règles d’exécution.
Recommandez et gagnez des USDC
Recommandez et gagnez des USDCNotre programme d’affiliation paie en temps réel.
Conserver l’identité d’une soumission dont le délai d’attente a expiré
Lorsqu’une requête dépasse son délai d’attente, le bot sait que la communication locale a échoué. Il ne sait pas nécessairement si la plateforme a accepté l’ordre. Faites passer la jambe à un état incertain, conservez sa réservation et interrogez les registres d’ordres et de compte accessibles par les mécanismes pris en charge. Utilisez les identifiants d’origine du client ou de la plateforme lorsqu’ils sont disponibles. Si ces registres ne permettent pas de déterminer immédiatement le sort de la tentative, l’incertitude reste intégrée au calcul de l’exposition.
Ne créez pas de nouvel ordre simplement parce que la quantité souhaitée n’est pas encore visible dans la position locale. L’ordre initial peut être en attente, partiellement exécuté ou dans une phase de traitement propre à la plateforme. Une seconde instruction peut doubler la quantité prévue. Dans un système à deux jambes, cela peut entraîner une surexécution d’une jambe même après l’achèvement de l’autre côté, et réintroduire une exposition directionnelle dans un dossier théoriquement apparié.
La reprise d’un bot d’arbitrage sur contrats événementiels nécessite une condition d’escalade. Après une durée définie ou une erreur particulière, le système peut désactiver les nouveaux dossiers sur le compte concerné et demander un examen par l’opérateur. Il s’agit d’une mesure de contrôle face à l’absence d’éléments probants, et non d’une déclaration selon laquelle la plateforme aurait perdu l’ordre. Le dossier doit préciser exactement ce qui reste inconnu et quelles requêtes ou quels instantanés de compte ont été examinés.
Lorsque le sort de la tentative est enfin déterminé, mettez à jour le dossier initial plutôt que de le masquer derrière un enregistrement de remplacement. Si elle a été rejetée, libérez la réservation inutilisée. Si elle a donné lieu à une exécution, intégrez les exécutions et recalculez la quantité appariée. Si l’ordre reste ouvert, décidez de le conserver ou de l’annuler à partir de l’état actuel du dossier. Chaque issue doit conserver le lien avec l’autorisation initiale.
Définir un cadre propre à l’annulation et au remplacement
Annuler un ordre n’annule pas les exécutions déjà survenues. Cela n’établit pas non plus qu’aucune exécution n’a eu lieu pendant l’acheminement de la demande d’annulation. Le bot doit continuer à surveiller la jambe jusqu’à disposer de suffisamment d’éléments faisant autorité pour déterminer la quantité finale exécutée et celle qui ne peut plus être exécutée. Libérer la réservation entière immédiatement après l’envoi d’une annulation peut sous-estimer l’engagement du compte.
Un ordre de remplacement pose un problème similaire. Si l’ancien ordre peut encore être actif, soumettre de nouveau la totalité de la quantité prévue peut temporairement doubler la quantité susceptible d’être exécutée. Le moteur d’exécution a besoin de règles de remplacement documentées et conformes au comportement réel de la plateforme. Ces règles peuvent exiger une confirmation avant le remplacement ou une réservation couvrant tout chevauchement pris en charge. Elles ne doivent jamais considérer le masquage de l’ancien ordre dans l’interface locale comme une preuve de sa suppression par la plateforme.
Dans l’exemple à 500 contre 300, supposons que 40 unités de B supplémentaires soient exécutées pendant l’annulation. La quantité appariée passe à 340 et la quantité de A non appariée tombe à 160. Une vente de reprise de 200 unités de A fondée sur l’instantané antérieur corrigerait excessivement le dossier, laissant une exposition excédentaire à B. La décision de reprise doit donc utiliser un état des quantités rapproché, ou tenir explicitement compte de l’incertitude qui subsiste.
L’article connexe sur le bot de trading sur marchés événementiels examine plus largement les interruptions et les changements programmés. L’exécution à deux jambes ajoute une exigence particulière : une mesure de contrôle sur une jambe peut modifier ce qui doit se passer sur l’autre. Le système doit coordonner ces mises à jour au moyen d’un état de dossier partagé, plutôt que laisser chaque jambe fonctionner comme un programme de trading sans lien avec l’autre.
Préserver un budget de reprise sans chercher à compléter à tout prix
Un budget de reprise définit le coût supplémentaire ou la perte que le système peut accepter pour réduire une exposition liée à une exécution incomplète. Il doit être distinct du seuil d’entrée initial. Le compte peut rationnellement accepter une perte limitée après une exécution partielle pour éviter de conserver un risque événementiel plus important, mais cette autorisation doit être explicite. Sinon, un bot peut justifier presque n’importe quel prix en prétendant compléter un arbitrage.
Définissez le budget en termes que l’opérateur peut examiner : coût maximal d’acquisition de la partie non appariée, coût supplémentaire maximal pour compléter la paire, perte maximale autorisée lors de la réduction et conditions nécessitant un jugement humain. Un prix plafond pour la seconde jambe peut être recalculé à partir du coût réel de la première jambe et du résultat autorisé. Le calcul doit inclure les frais réels déjà engagés et des estimations prudentes pour l’action restante.
Un budget n’est pas une instruction de dépenser toute l’enveloppe autorisée. Comparez les possibilités disponibles à partir des quantités actuellement exécutables. Si une annulation et une petite réduction rétablissent une position acceptable, le système n’a pas à forcer l’achèvement de la taille initiale. Si aucune solution ne respecte les limites approuvées, mettez le processus en pause et affichez clairement la position non résolue. Le risque restant du compte doit être visible même lorsque le bot ne peut pas le résoudre automatiquement.
L’article antérieur sur le bot d’arbitrage automatisé Polymarket éclaire cette séparation entre détection et action encadrée. La logique de reprise mérite son propre jeu de données d’évaluation, car elle est sollicitée dans des conditions différentes de celles d’une entrée ordinaire. Un comportement qui fonctionne dans des instantanés de marché calmes peut échouer lorsque la liquidité disparaît précisément au moment où la première jambe est exécutée.
Les positions peuvent s’accumuler sur plusieurs dossiers
Un bot peut traiter de nombreuses paires à la fois, mais le compte porte l’ensemble de leurs positions. Deux dossiers incomplets peuvent laisser une exposition à la même issue même si leurs identifiants de paire diffèrent. Agrégez les positions et les engagements ouverts par événement et par scénario défavorable pertinent. Ne supposez pas que des dossiers distincts créent des limites de risque indépendantes.
Un teneur de marché sur contrats événementiels utilise ses positions pour orienter ses décisions de cotation suivantes. Un bot à deux jambes bénéficie de la même connaissance lorsque des jambes incomplètes restent dans le compte. De nouveaux dossiers pourraient réduire un déséquilibre existant, l’accroître ou créer une exposition différente en cas d’issues exceptionnelles. Le contrôle des risques doit évaluer le portefeuille qui en résulte plutôt que de considérer chaque paire proposée comme automatiquement neutre.
Si le bot participe aussi à la tenue de marché sur contrats événementiels, ses cotations en attente doivent figurer dans le même modèle d’exposition. Une cotation créée pour fournir de la liquidité peut être exécutée pendant que le moteur d’arbitrage réserve de la capacité pour une seconde jambe. Des budgets distincts qui s’ignorent peuvent tous deux être validés localement et échouer au niveau du compte. Des réservations partagées et un rapprochement cohérent sont nécessaires même lorsque les stratégies poursuivent des objectifs différents.
Un rapprochement périodique doit comparer le modèle local combiné aux positions, aux ordres et aux frais faisant autorité. Un dossier ne peut être déclaré clos sur le plan opérationnel que lorsque le sort de ses ordres est déterminé et que sa position restante est correctement attribuée. Si une position résiduelle délibérément conservée est transférée à une autre stratégie, enregistrez ce transfert de responsabilité. Retirer le dossier d’un écran ne doit pas retirer son risque du registre.
Tester les cas qui modifieraient la décision
Utilisez des reconstitutions d’incidents qui mettent la coordination à l’épreuve, et pas seulement la réussite des soumissions d’ordres. Un test doit accepter A et rejeter B. Un autre doit exécuter partiellement B pendant une annulation. Un troisième doit transmettre deux fois la même exécution. Un quatrième doit redémarrer le processus après la soumission d’une requête, mais avant l’enregistrement de sa réponse. Le résultat attendu doit préciser les quantités, les réservations, les actions suivantes autorisées et toute pause nécessaire.
Pour le cas chiffré d’exécution partielle, vérifiez le calcul indépendamment : 365 $ dépensés, 68 $ récupérés en réduisant les 200 unités de A non appariées, 300 $ reçus des paires compatibles restantes et 5 $ de frais supposés réels produisent une perte de 2 $. Le test ne doit pas qualifier le dossier de paire rentable de 500 unités simplement parce que telle était la recommandation initiale. Il doit conserver la raison pour laquelle le résultat diffère du plan.
Testez aussi la décision de ne pas commencer. Rejetez une paire dont les règles ne correspondent pas, dont les fonds disponibles sur chaque compte sont insuffisants, dont les données de profondeur sont périmées ou dont l’état du compte n’est pas résolu. Ces refus font partie du comportement prévu du bot. Un système qui ne réussit que des tests d’exécution active peut encore présenter des risques, car il n’a jamais démontré qu’il respecte les conditions dans lesquelles l’exécution doit être suspendue.
L’examen final doit permettre de reconstituer chaque dossier, depuis la relation de paiement approuvée jusqu’au résultat du compte après rapprochement. Un bot à deux jambes est utile lorsqu’il rend explicites les combinaisons incomplètes, limite leurs conséquences et conserve suffisamment d’éléments pour expliquer la reprise. C’est le critère pratique d’une automatisation dans un processus où deux prix intéressants ne garantissent pas deux opérations exécutées.