Polymarket Bot Tutorial · Chapitre 18 sur 32
Bots de prédiction de litiges UMA sur Polymarket : détecter les propositions de l'Optimistic Oracle, prédire la probabilité de litige, exploiter l'asymétrie de prix avant et après un litige, et éviter les spirales mortelles des marchés disputés.
Ce que couvre ce chapitre
L'Optimistic Oracle (OO) d'UMA résout les marchés Polymarket, et les litiges créent des anomalies de prix avant et après leur déclenchement. Des patterns tradables existent des deux côtés d'un litige, mais la stratégie est opérationnellement complexe et a fait brûler plus de bots qu'elle n'en a nourri. Ce chapitre est le playbook honnête.
- Comment fonctionne l'UMA Optimistic Oracle
- Détecter une proposition on-chain
- Predictors de litige (volume, ambiguïté, historique)
- Asymétrie de prix avant litige
- Setups de trade après litige
- Quand NE PAS trader les marchés disputés
- Code: subscribe aux événements UMA proposed/disputed
Comment fonctionne l'UMA Optimistic Oracle
L'Optimistic Oracle (OO) d'UMA est la couche de résolution des litiges pour Polymarket. Chaque résolution de marché passe par l'OO ; la plupart ne sont pas contestées et se règlent automatiquement. Celles qui sont contestées - les litiges - déclenchent une période de vote de 24 à 72 heures durant laquelle les détenteurs de tokens UMA décident de l'issue.
Le cycle de vie : le resolver de Polymarket propose un prix (0 = NO a gagné, 1 = YES a gagné). Après une fenêtre de contestation de 2 heures, si personne ne conteste, le prix est finalisé et le contrat CTF distribue les payouts. Si quelqu'un conteste, le marché entre dans une fenêtre de vote ; les détenteurs d'UMA votent, la majorité l'emporte.
Pour un bot, les événements pertinents sont ProposePrice (proposition déposée, fenêtre de contestation ouverte) et DisputePrice (litige déposé, période de vote commencée). Abonnez-vous à ces événements pour suivre l'état de résolution du marché en temps réel.
Détecter une proposition on-chain
Le contrat UMA OO sur Polygon émet un événement ProposePrice avec les paramètres (requester, identifier, timestamp, ancillaryData, proposer, proposedPrice). Filtrez par l'adresse requester connue de Polymarket pour limiter aux propositions pertinentes.
POLY_REQUESTER = "0x..." # Polymarket Adjudicator
filt = oo_contract.events.ProposePrice.create_filter(
fromBlock="latest",
argument_filters={"requester": POLY_REQUESTER}
)
for event in filt.get_new_entries():
market_id = decode_ancillary(event.args.ancillaryData)
proposed = "YES" if event.args.proposedPrice == 1e18 else "NO"
print(f"PROPOSE: market {market_id} → {proposed}")Le champ ancillaryData est du JSON encodé en hexadécimal qui décrit la question du marché. Le décoder vous donne l'identifiant du marché que vous pouvez recouper avec vos positions ouvertes.
Predictors de litige (volume, ambiguïté, historique)
Trois signaux pré-litige sont corrélés avec les litiges réels ultérieurs.
- Volume total : les marchés avec > 1 M$ de volume cumulé sont disputés à un taux 4x supérieur à celui des petits marchés. Plus de capital en jeu = plus d'incitation à contester.
- Formulation ambiguë : tout marché contenant "or similar", "officially confirmed", ou des conditions composées (date ET issue spécifique) présente des taux de litige plus élevés.
- Litiges passés sur le même événement : si une proposition antérieure a déjà été contestée puis reproposée, la seconde proposition est contestée à un taux 2 à 3x supérieur à la normale.
Un bot peut calculer un score de "dispute probability" à partir de ces signaux et éviter de prendre position sur les marchés au-dessus d'un seuil proche de la résolution.
Asymétrie de prix avant litige
Dans les heures qui précèdent un litige probable, le prix du marché montre souvent un mouvement asymétrique : le côté que le proposer a désigné comme YES s'affaisse (car les traders craignent qu'un litige l'inverse), l'autre côté monte.
Si vous avez une vision directionnelle de la façon dont le litige sera tranché, c'est une fenêtre tradable. Le risque : si le litige n'a pas lieu, l'asymétrie s'inverse lorsque la fenêtre de contestation se ferme sans incident et que les prix reviennent brusquement vers la direction proposée.
Honnêtement : la plupart des trades d'asymétrie pré-litige perdent de l'argent parce que la plupart des contestations se résolvent en faveur de la proposition initiale. La stratégie ne fonctionne que lorsque vous disposez d'informations spécifiques expliquant pourquoi ce litige a de fortes chances d'être maintenu.
Setups de trade après litige
Après le dépôt d'un litige, le marché trade pendant 24 à 72 heures dans une "zone d'attente" - il est connu comme disputé, l'issue doit être votée. Deux setups existent.
Convergence vers le consensus UMA : si la résolution du litige est signalée tôt (par exemple, un votant UMA influent prend publiquement position), le prix se dirige vers cette résolution. Un bot qui surveille les signaux de Discord / Twitter UMA + l'action des prix peut capter cela 30 à 60 % du temps.
Volatility farming : les périodes d'attente ont de larges spreads. Un market maker patient peut capter la taxe de spread auprès de plusieurs traders entrant et sortant pendant la fenêtre de vote. Le risque d'inventaire est élevé ; dimensionnez en conséquence.
Les deux exigent d'être à l'aise avec la possibilité réelle d'une résolution contre votre position. Traitez l'inventaire en période de litige comme la moitié de la taille, au maximum.
Quand NE PAS trader les marchés disputés
Trois situations où le trade sur litige est faux par défaut.
- Vous n'avez pas de vue spécifique à UMA. Si votre seul avantage est "la proposition initiale me semble correcte", vous n'avez aucun edge par rapport au proposer initial - et la personne qui a déposé le litige pense l'inverse. L'issue du vote est un pile ou face que vous ne pouvez pas prédire.
- Le litige porte sur une formulation ambiguë. Les votants UMA se rangent généralement du côté de la lecture stricte de la question. Si le marché disait "avant le 31 janvier" et que l'événement s'est produit le 1er février, UMA résoudra NO, indépendamment de l'intuition de la foule de traders.
- Vous détenez déjà de l'inventaire avant le litige. Ajouter à une position existante pour "moyenner à la baisse" pendant la zone d'attente est le pattern classique de destruction de capital. Conservez ou sortez, n'ajoutez jamais.
Code: subscribe aux événements UMA proposed/disputed
Référence: abonnement WebSocket aux événements UMA OO, filtré par requester Polymarket.
from web3 import Web3
w3 = Web3(Web3.WebsocketProvider(POLYGON_WSS))
oo = w3.eth.contract(address=UMA_OO_ADDR, abi=UMA_OO_ABI)
POLY = "0x...".lower()
dispute_filter = oo.events.DisputePrice.create_filter(fromBlock="latest")
propose_filter = oo.events.ProposePrice.create_filter(fromBlock="latest")
while True:
for event in dispute_filter.get_new_entries():
if event.args.requester.lower() == POLY:
on_dispute(event)
for event in propose_filter.get_new_entries():
if event.args.requester.lower() == POLY:
on_propose(event)
time.sleep(2)
def on_dispute(event):
market_q = decode_ancillary_to_question(event.args.ancillaryData)
send_telegram(f"DISPUTE: {market_q}")
# If we hold a position in this market, alert + consider exit
if market_q in our_positions:
flag_position_for_review(market_q)Le pattern : subscribe, decode, alert. Agir de manière algorithmique sur les litiges est à haut risque ; le rôle du bot est généralement de faire remonter l'événement à un humain pour revue.
