Polymarket Bot Tutorial · Chapter 18 of 32
Polymarket पर UMA dispute prediction bots: Optimistic Oracle proposals को detect करें, dispute likelihood predict करें, pre-and-post-dispute price asymmetry का फायदा उठाएँ, और disputed-market death spirals से बचें।
यह अध्याय क्या कवर करता है
UMA का Optimistic Oracle (OO) Polymarket markets को resolve करता है, और disputes fire होने से पहले और बाद में price anomalies पैदा करते हैं। Dispute के दोनों sides पर tradeable patterns मौजूद हैं, लेकिन यह strategy operationally complex है और इसने जितने bots को feed किया है, उससे ज़्यादा को burn किया है। यह अध्याय honest playbook है।
- UMA Optimistic Oracle कैसे काम करता है
- On-chain proposal detect करना
- Dispute predictors (volume, ambiguity, history)
- Pre-dispute price asymmetry
- Post-dispute trade setups
- Disputed markets में कब trade NOT करना चाहिए
- Code: UMA proposed/disputed events subscribe करना
UMA Optimistic Oracle कैसे काम करता है
UMA का Optimistic Oracle (OO) Polymarket के लिए dispute resolution layer है। हर market resolution OO से होकर गुजरती है; ज़्यादातर uncontested होते हैं और automatically settle हो जाते हैं। जो contested होते हैं - disputes - वे 24-72 hour voting period trigger करते हैं, जिसमें UMA token holders outcome decide करते हैं।
Lifecycle यह है: Polymarket का resolver एक price propose करता है (0 = NO जीता, 1 = YES जीता)। 2-hour challenge window के बाद, अगर कोई dispute नहीं करता, तो price finalized हो जाती है और CTF contract payouts distribute करता है। अगर कोई dispute करता है, तो market voting window में चला जाता है; UMA holders votes cast करते हैं, majority जीतती है।
एक bot के लिए relevant events हैं ProposePrice (proposal enter हुई, challenge window खुलती है) और DisputePrice (dispute file हुई, voting period शुरू होता है)। Real time में market resolution state track करने के लिए इन्हें subscribe करें।
On-chain proposal detect करना
Polygon पर UMA OO contract ProposePrice event emit करता है, parameters के साथ (requester, identifier, timestamp, ancillaryData, proposer, proposedPrice)। Relevant proposals तक सीमित रहने के लिए Polymarket के known requester address से filter करें।
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}")ancillaryData field hex-encoded JSON होता है जो market question describe करता है। इसे decode करने पर आपको market identifier मिलता है, जिसे आप अपनी open positions के साथ cross-reference कर सकते हैं।
Dispute predictors (volume, ambiguity, history)
तीन pre-dispute signals बाद के actual disputes से correlate करते हैं।
- Total volume: जिन markets का lifetime volume > $1M है, उनमें छोटे markets की तुलना में disputes 4x rate पर होते हैं। ज़्यादा capital at stake = challenge करने की ज़्यादा incentive।
- Ambiguous wording: जिन markets में "or similar," "officially confirmed," या compound conditions (date AND specific outcome) हों, उनमें dispute rates ज़्यादा होते हैं।
- Past disputes on the same event: अगर earlier proposal already disputed होकर re-proposed हुई थी, तो दूसरी proposal normal rate की 2-3x dispute होती है।
एक bot इन features से "dispute probability" score compute कर सकता है और resolution के करीब threshold से ऊपर वाले markets में position लेने से बच सकता है।
Pre-dispute price asymmetry
Likely dispute से पहले के घंटों में market price अक्सर asymmetric movement दिखाती है: proposer ने जिस side को YES नामित किया था, वह नीचे drift करती है (क्योंकि traders को डर होता है कि dispute उसे flip कर देगा), और दूसरी side ऊपर drift करती है।
अगर आपके पास यह directional view है कि dispute किस तरफ resolve होगा, तो यह एक tradeable window है। Risk: अगर dispute नहीं होता, तो challenge window बिना किसी issue के close होने पर asymmetry उलट जाती है और prices proposed direction की ओर snap back कर जाती हैं।
सच यह है: ज़्यादातर pre-dispute asymmetry trades losing trades होते हैं, क्योंकि ज़्यादातर challenges original proposal के favor में resolve होते हैं। यह strategy तभी काम करती है जब आपके पास इस बारे में specific information हो कि यह dispute sustained होने की संभावना क्यों है।
Post-dispute trade setups
Dispute file होने के बाद market 24-72 घंटे तक "limbo" में trade करता है - यानी dispute known है, outcome vote से तय होना है। दो setups मौजूद हैं।
UMA consensus की ओर convergence: अगर dispute resolution का संकेत जल्दी मिल जाए (जैसे कोई prominent UMA voter publicly एक side ले ले), तो price उस resolution की ओर move करती है। UMA Discord / Twitter signals + price action देखने वाला bot इस मौके को 30-60% समय पकड़ सकता है।
Volatility farming: limbo periods में spreads wide होते हैं। एक patient market maker voting window के दौरान multiple traders के अंदर-बाहर घूमने पर spread tax कमा सकता है। Inventory risk high है; size उसी हिसाब से रखें।
दोनों के लिए यह comfort ज़रूरी है कि resolution आपकी position के खिलाफ भी जा सकती है। Dispute-period inventory को अधिकतम half-size ही मानें।
Disputed markets में कब trade NOT करना चाहिए
तीन situations जहाँ dispute trade default रूप से गलत होता है।
- आपके पास UMA-specific view नहीं है. अगर आपकी only edge बस यह है कि "original proposal मुझे सही लगती है," तो आपके पास original proposer से कोई edge नहीं है - और dispute filer को उल्टा लगता है। Voting outcome एक coin flip है जिसे आप predict नहीं कर सकते।
- Dispute ambiguous wording पर है. UMA voters आम तौर पर question की strict reading के पक्ष में होते हैं। अगर market ने "by January 31" कहा था और event February 1 को हुआ, तो UMA NO resolve करेगा, trader population की intuition चाहे कुछ भी हो।
- आपके पास dispute से पहले inventory है. Limbo के दौरान existing position में "average down" करने के लिए और जोड़ना capital-destruction का classic pattern है। Hold करें या exit करें, कभी add न करें।
Code: UMA proposed/disputed events subscribe करना
Reference: UMA OO events की WebSocket subscription, Polymarket requester के filter के साथ।
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)Pattern यह है: subscribe करें, decode करें, alert करें। Disputes पर algorithmically act करना high-risk है; bot का काम आम तौर पर event को human reviewer तक पहुंचाना होता है।
