Arbitrage sur les prediction markets : couvrir entre Polymarket et les mirrors

Si vous exploitez déjà un bot Polymarket, la prochaine opportunité n’est peut-être pas un nouveau modèle de prévision. Il peut s’agir d’une seconde surface de liquidité où votre stack de pricing, d’exécution et de risque travaille davantage.

Le prediction market arbitrage paraît simple dans un tableur : trouver le même événement sur deux venues, acheter le côté moins cher, vendre le plus cher et conserver la différence.

En production, le travail consiste à prouver que les deux instruments ont le même payoff, mapper correctement leurs outcome tokens, exécuter les deux legs à des prix réels et tenir jusqu’au settlement.

C’est particulièrement important pour un mirror. Un mirror Polymarket peut fournir une référence externe et un hedge potentiel pour le flow Kuest, mais il ne rend pas chaque différence de prix sans risque.

Ce guide s’adresse aux market makers crypto-native, traders quantitatifs et desks qui maîtrisent déjà l’exécution cross-venue.

Qu’est-ce que l’arbitrage sur les prediction markets ?

L’arbitrage sur les prediction markets cherche à capter une différence entre des contrats économiquement équivalents ou à construire une position dont le payoff combiné est connu alors que le coût d’entrée est inférieur.

Arbitrage avec des outcomes complémentaires

Sur un marché binaire, YES et NO sont complémentaires. Si YES peut être acheté sur une venue et NO sur une autre pour moins de 1 dollar au total, avec des règles de résolution strictement identiques, la valeur brute au settlement est de 1 dollar.

edge brut = 1 $ - (prix d’entrée YES + prix d’entrée NO)

Les fees, le gas, le slippage, les partial fills, le capital immobilisé et les coûts de settlement réduisent l’edge réel.

Couvrir l’inventaire cross-venue

Un market maker ne cherche pas toujours à verrouiller un payoff garanti. Il peut coter sur Kuest et utiliser Polymarket pour réduire l’inventaire créé par les clients.

Si un client achète 1 000 contrats YES à votre ask Kuest, le système peut acheter une exposition YES équivalente sur Polymarket, si la profondeur le permet. C’est un hedge d’inventaire, pas automatiquement un arbitrage sans risque : le hedge peut être partiel, plus cher ou indisponible.

Cette distinction affecte le bot, le modèle de capital et la gestion du risque. Le guide PredictEngine explique pourquoi les prix exécutables comptent plus que les midpoints. La documentation Preduck aide à comparer les marchés cross-venue.

Pourquoi les traders Polymarket cherchent l’arbitrage sur les mirrors

Polymarket est une référence naturelle grâce à ses données CLOB, ses carnets actifs, son flux de traders et de bots et son infrastructure connue.

Une seconde surface peut apporter une autre audience, du flow, des campagnes de liquidité financées et la réutilisation d’une infrastructure Polygon, USDC, CLOB, pricing et inventaire. Le market maker peut combiner le P&L de trading avec une rémunération pour maintenir la profondeur.

Kuest relie les frontends de marque à la découverte, au matching, aux wallets et aux données de lifecycle partagés. Les marchés ayant les mêmes outcome token IDs utilisent les mêmes carnets Kuest. Deux pages d’opérateurs ne sont donc pas nécessairement deux venues indépendantes.

Une différence entre deux frontends Kuest n’est pas automatiquement une opportunité d’arbitrage.

L’edge peut se trouver entre le flow du réseau Kuest et une référence externe comme Polymarket, ou entre un marché propriétaire et un autre contrat dont la résolution a été validée strictement.

Comment fonctionnent les mirrors Kuest

« Mirror » décrit la relation avec une source externe sélectionnée. Le frontend n’intègre pas simplement le carnet d’une autre plateforme.

L’opérateur peut combiner des mirrors Polymarket, ses propres marchés et des sources partagées choisies. Il contrôle la marque, le domaine, l’expérience et les opérations. Kuest fournit le CLOB, les données, le matching, les actions wallet relayées et le settlement Polygon.

Pour un market maker :

1. La source définit la spécification. Vérifiez la question, les outcomes, la clôture, la source de résolution et les cas limites.
2. Kuest crée une représentation compatible. Le mirror possède ses propres métadonnées et son contexte de carnet.
3. Le mapping des outcomes doit être explicite. Le bot doit connaître les tokens YES et NO des deux côtés.
4. Le flow est attribué à l’opérateur d’origine. Site, bot et SDK peuvent entrer dans son économie.
5. Le settlement exige ses propres contrôles. La relation de prix dépend du lifecycle du marché.

Consultez l’architecture Kuest et le dépôt open source pour Polygon, USDC, APIs et SDKs.

La Polymarket hedge strategy : traiter le même outcome entre venues

Une Polymarket hedge strategy commence par la position réelle de votre book Kuest, pas par l’hypothèse que YES signifie la même chose partout.

Couvrir un quote exécuté avec le même outcome

Si vous vendez 1 000 YES sur Kuest à 0,54 $ et que l’ask équivalent sur Polymarket est à 0,55 $, vous pouvez racheter l’inventaire jusqu’à la profondeur disponible. Le résultat est la vente Kuest moins le coût du hedge, les fees, le gas, le slippage et l’adverse selection.

Si seulement 600 contrats sont exécutés sur Polymarket, les 400 restants restent exposés.

Construire une paire complète

Si YES coûte 0,53 $ sur Kuest et NO 0,43 $ sur Polymarket, la paire coûte 0,96 $ et paie 1 $ si les règles sont identiques. L’edge brut est de 0,04 $ par paire avant les coûts.

Cela exige une correspondance exacte des règles de résolution. Un titre similaire ne suffit pas.

Exemple étape par étape de prediction market arbitrage

1. Valider le contrat : comparer condition, ordre des outcomes, cutoff et resolver entre Kuest et Polymarket.
2. Lire les carnets exécutables : utiliser bid, ask et taille. L’API order book de Polymarket fournit les niveaux, timestamp, minimum et tick size.
3. Choisir la route de hedge : couvrir seulement la taille disponible, franchir le niveau suivant, utiliser une route complémentaire ou réduire les quotes.
4. Calculer le résultat :

résultat net = produit Kuest - coût du hedge - fees - gas - slippage
               - coût du capital et de l’inventaire

5. Réconcilier chaque état : accepted, partial fill, cancel, reject et resting doivent être enregistrés.
6. Surveiller jusqu’au settlement : résolution, litiges, redemption et changement de relation restent importants.

Trouver les mirrors et mapper les outcome tokens

Le raccourci le plus dangereux est le matching par titre. L’analyse d’Assymetrix montre comment traders, fees, liquidité et règles de résolution différentes créent des instruments distincts.

Conservez au minimum ce mapping par mirror :

{
  "source": "polymarket",
  "sourceConditionId": "0x...",
  "sourceYesTokenId": "...",
  "sourceNoTokenId": "...",
  "kuestConditionId": "0x...",
  "kuestYesTokenId": "...",
  "kuestNoTokenId": "...",
  "resolutionSource": "...",
  "closeTime": "...",
  "mappingStatus": "verified"
}

Les détails de marché Kuest incluent mirror condition IDs, mirror token IDs, outcomes, fees, source de résolution et bid/ask. Refusez le trade si un ID manque, si l’heure de clôture diffère, si la source change, si le marché est pausé ou si la taille ne permet pas un hedge complet.

Comment la shared liquidity change l’arbitrage

Les marchés compatibles utilisent les carnets Kuest partagés. Un ordre d’une page peut matcher avec le flow d’une autre, ce qui améliore l’efficacité du capital et réduit le cold start.

Mais deux pages montrant le même carnet ne sont pas deux legs indépendants. L’edge peut venir de la relation avec Polymarket, du flow d’un opérateur, des fees ou incentives, d’un déséquilibre d’inventaire ou d’une campagne financée.

Consultez le protocole Kuest et la page market maker pour comprendre le réseau et les mandats de liquidité.

Inventaire du market maker : collateral, YES/NO et settlement

Un market maker binaire gère du collateral USDC, un inventaire YES, un inventaire NO et des positions sur des venues externes. Le hedge correct dépend du bilan complet.

Une paire YES/NO de la même condition vaut 1 $ ensemble au settlement. Selon la venue, elle peut être mintée depuis le collateral ou mergée en retour. Séparez actions physiques et comptabilité : SELL YES reste SELL YES dans le log, même si le settlement utilise un merge.

Quel edge reste après fees, gas et slippage ?

Le midpoint n’est pas un prix exécutable. Modélisez le prix et la taille réels. Utilisez l’API des spreads et les informations CLOB.

edge net = payoff ou spread brut
         - fees de tous les legs - gas - slippage
         - failed fills - capital immobilisé - coût du hedge
         - overhead opérationnel

La récompense de campagne Kuest doit être une ligne de revenus distincte. Elle paie un service de liquidité défini et ne doit pas masquer adverse selection, pertes d’inventaire ou coût du bond.

Principaux risques de l’arbitrage sur les mirrors Polymarket

Basis risk

Une seule clause peut modifier le payoff. Comparez source de données, timestamp, cutoff, resolver et cas limites.

Exécution, latence et liquidité

Le leg bon marché peut disparaître avant l’arrivée du hedge. Le meilleur ask peut être trop petit.

Adverse selection

Le trader qui prend votre quote peut réagir à une information nouvelle avant le bot.

Resolution, venue et opérations

Outages, rate limits, ordres rejetés, wallets, websockets stale, litiges et settlement tardif doivent être couverts par la réconciliation et les kill switches.

Risque réglementaire

Prediction markets, dérivés et market making sont soumis à des règles différentes selon la juridiction. Obtenez vos propres conseils juridiques, fiscaux et compliance.

Comment les campagnes Kuest rémunèrent la liquidité

Une campagne peut définir marché ou série, dates, profondeur par côté, spread maximal, coverage, reward, bond et disponibilité d’un hedge externe.

Le flux escrow est le suivant :

1. Le sponsor dépose le reward et les montants de protocole.
2. Un market maker approuvé examine et accepte les conditions.
3. Il dépose le bond si nécessaire.
4. Il maintient la liquidité pendant le service.
5. La campagne passe en review et peut être contestée.
6. Après finalisation, l’allocation devient retirable via pendingWithdrawals.

L’escrow protège le mandat commercial, pas les fills du hedge ni le profit. Consultez l’API de création de marché et l’API de résolution.

Bots de prediction market arbitrage et infrastructure API

Un bot sérieux est une state machine :

discover -> valider le mapping -> lire la profondeur -> calculer l’edge net
         -> réserver le collateral -> placer le premier leg
         -> confirmer le fill -> placer le hedge -> réconcilier
         -> surveiller le settlement -> rééquilibrer l’inventaire

Il faut discovery, token mapping, order books, sizing, fills, inventory, routing, settlement monitoring, alertes, logs et kill switches. La vue market data de Polymarket et son API d’ordres documentent ces primitives.

Un bot Polymarket existant peut réutiliser wallet, CLOB, cancel-and-replace et contrôles de risque, mais validez IDs Kuest, shared books, auth, fees, sémantique des ordres, lifecycle et obligations de campagne.

Comment commencer le market making sur Kuest

1. Ouvrez la page market maker Kuest et le modèle du protocole.
2. Demandez l’approbation du wallet opérationnel.
3. Filtrez les campagnes par hedge Polymarket, spread, depth et durée.
4. Validez indépendamment le mapping et le carnet externe.
5. N’acceptez que les termes compatibles et déposez le bond si nécessaire.
6. Commencez avec une taille prudente et vérifiez order, fill et reconciliation.
7. Finalisez et retirez l’allocation après le service et la review.

Pourquoi les market makers crypto-native sont importants pour Kuest

Kuest a besoin de desks capables de coter un CLOB binaire, gérer l’inventaire YES/NO, reconnaître le basis risk, traiter les partial fills, opérer Polygon/USDC et maintenir kill switches, alertes et audit logs.

Cette expertise permet aux opérateurs de lancer des marchés avec une profondeur crédible et donne au maker accès au flow de communautés et aux campagnes financées d’un réseau partagé.

Pour aller plus loin

• Architecture Kuest : opérateurs, shared liquidity et settlement
• Order book Polymarket
• Envoyer des ordres Polymarket
• Recherche Assymetrix sur l’arbitrage cross-venue
• Guide de l’arbitrage sur les prediction markets
• Preduck : hedging et matching cross-venue

FAQ : Prediction Market Arbitrage

L’arbitrage Polymarket est-il sans risque ?

Non. Le spread peut disparaître et deux marchés similaires peuvent se résoudre différemment. Même une paire YES/NO exige des règles identiques et des fills complets.

Qu’est-ce qu’un mirror Polymarket ?

Un marché Kuest lié à un marché source Polymarket afin qu’un opérateur puisse proposer l’événement sous sa propre marque. Il faut vérifier mapping, résolution et liquidité.

Comment fonctionne une Polymarket hedge strategy ?

Le maker utilise Polymarket pour réduire l’exposition créée en cotant sur une autre venue : même outcome, outcome complémentaire ou paire complète. Le choix dépend du contrat, de la profondeur, des fees et des partial fills.

Quels IDs un bot doit-il mapper ?

Les condition IDs source et Kuest, les token IDs YES/NO, la source de résolution, le close time et le statut du mapping. En cas d’ambiguïté, il ne faut pas trader.

Qu’est-ce que MarketMakerEscrow ?

Un smart contract Polygon qui coordonne reward, bond, service, review et retrait des campagnes de liquidité. Il ne garantit pas le profit.

Kuest garantit-elle les rendements d’arbitrage ?

Non. Kuest fournit infrastructure, réseau, données et escrow. Pricing, exécution, inventaire, hedge et capital restent sous la responsabilité du market maker.