Polymarket Bot Tutorial · Chapter 18 of 32
Polymarket پر UMA dispute prediction bots: Optimistic Oracle proposals کو detect کریں، dispute likelihood کا اندازہ لگائیں، pre-and-post-dispute price asymmetry سے فائدہ اٹھائیں، اور disputed-market death spirals سے بچیں۔
اس chapter میں کیا شامل ہے
UMA کا Optimistic Oracle (OO) Polymarket markets کو resolve کرتا ہے، اور disputes ان کے fire ہونے سے پہلے اور بعد میں price anomalies پیدا کرتے ہیں۔ Dispute کے دونوں sides پر tradeable patterns موجود ہیں، لیکن یہ strategy operationally پیچیدہ ہے اور اس نے fed کرنے سے زیادہ bots جلائے ہیں۔ یہ chapter ایک honest playbook ہے۔
- UMA Optimistic Oracle کیسے work کرتا ہے
- 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 کیسے work کرتا ہے
UMA کا Optimistic Oracle (OO) Polymarket کے لیے dispute resolution layer ہے۔ ہر market resolution OO سے گزرتی ہے؛ زیادہ تر uncontested ہوتی ہیں اور خود بخود settle ہو جاتی ہیں۔ Contested ones - disputes - 24-72 hour voting period کو trigger کرتی ہیں جس کے دوران UMA token holders outcome decide کرتے ہیں۔
Lifecycle یہ ہے: Polymarket کا resolver ایک price propose کرتا ہے (0 = NO won، 1 = YES won)۔ 2-hour challenge window کے بعد، اگر کوئی dispute نہ کرے تو price final ہو جاتی ہے اور CTF contract payouts distribute کرتا ہے۔ اگر کوئی dispute کرے تو market voting window میں چلا جاتا ہے؛ UMA holders votes cast کرتے ہیں، majority win کرتی ہے۔
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 تک limit کرنے کے لیے 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 سے زیادہ ہو، ان میں small markets کے مقابلے میں dispute rate 4x ہوتا ہے۔ زیادہ capital at stake = challenge کرنے کی زیادہ incentive۔
- Ambiguous wording: کوئی بھی market جس میں "or similar," "officially confirmed," یا compound conditions (date AND specific outcome) ہوں، اس کی dispute rate زیادہ ہوتی ہے۔
- Past disputes on the same event: اگر پہلے کوئی proposal پہلے ہی dispute ہو چکی ہو اور دوبارہ proposed کی گئی ہو، تو دوسری proposal عموماً normal rate سے 2-3x زیادہ dispute ہوتی ہے۔
Bot ان features سے "dispute probability" score compute کر سکتا ہے اور resolution کے قریب threshold سے اوپر والے markets میں positions لینے سے بچ سکتا ہے۔
Pre-dispute price asymmetry
Likely dispute سے پہلے کے hours میں market price اکثر asymmetric movement دکھاتی ہے: جس side کو proposer نے YES کہا ہو وہ نیچے drift کرتی ہے (کیونکہ traders کو fear ہوتا ہے کہ dispute اسے flip کر دے گی)، اور دوسری side اوپر drift کرتی ہے۔
اگر آپ کے پاس اس بارے میں directional view ہے کہ dispute کس طرف resolve ہوگی، تو یہ ایک tradeable window ہے۔ Risk یہ ہے: اگر dispute نہ ہو، تو challenge window بغیر مسئلے کے close ہونے پر asymmetry reverse ہو جاتی ہے اور prices proposed direction کی طرف snap back کر جاتی ہیں۔
سچ یہ ہے: زیادہ تر pre-dispute asymmetry trades losing trades ہوتے ہیں کیونکہ زیادہ تر challenges original proposal کے حق میں resolve ہوتے ہیں۔ یہ strategy صرف تب کام کرتی ہے جب آپ کے پاس اس بات کی specific information ہو کہ یہ dispute کیوں sustained رہنے کا امکان رکھتی ہے۔
Post-dispute trade setups
Dispute file ہونے کے بعد market 24-72 hours تک "limbo" میں trade کرتی ہے - یعنی معلوم ہے کہ dispute ہے، مگر outcome vote سے طے ہونا ہے۔ دو setups موجود ہیں۔
UMA consensus کی طرف convergence: اگر dispute resolution کا signal early مل جائے (مثلاً کوئی prominent UMA voter public طور پر کسی ایک side لے لے)، تو price اسی resolution کی طرف move کرتی ہے۔ UMA Discord / Twitter signals + price action دیکھنے والا bot اس move کو 30-60% وقت پکڑ سکتا ہے۔
Volatility farming: limbo periods میں spreads وسیع ہوتے ہیں۔ ایک patient market maker voting window کے دوران اندر اور باہر rotate ہونے والے متعدد traders سے spread tax earn کر سکتا ہے۔ Inventory risk high ہوتا ہے؛ size accordingly رکھیں۔
دونوں کے لیے اس genuine possibility کے ساتھ comfortable ہونا ضروری ہے کہ resolution آپ کی position کے خلاف بھی ہو سکتی ہے۔ Dispute-period inventory کو زیادہ سے زیادہ half-size سمجھیں۔
Disputed markets میں کب trade NOT کرنا چاہیے
تین situations ایسی ہیں جہاں dispute trade default طور پر غلط ہوتی ہے۔
- آپ کے پاس UMA-specific view نہیں ہے۔ اگر آپ کی only edge یہ ہے کہ "اصل proposal مجھے درست لگتی ہے،" تو آپ کے پاس original proposer پر کوئی edge نہیں - اور dispute filer اس کے برعکس سوچتا ہے۔ Voting outcome ایک coin flip ہے جس کی آپ predict نہیں کر سکتے۔
- Dispute ambiguous wording پر ہو۔ UMA voters عموماً question کی strict reading کے ساتھ side لیتے ہیں۔ اگر market میں "by January 31" لکھا تھا اور event February 1 کو ہوئی، تو UMA NO resolve کرے گا چاہے trader population کی intuition کچھ بھی ہو۔
- آپ dispute سے پہلے inventory hold کر رہے ہیں۔ Limbo سے گزرنے کے لیے existing position میں مزید add کرنا capital-destruction کا classic pattern ہے۔ Hold کریں یا exit کریں، کبھی add نہ کریں۔
Code: UMA proposed/disputed events کو subscribe کرنا
Reference: UMA OO events کے لیے WebSocket subscription، Polymarket requester کے مطابق filtered۔
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 action لینا high-risk ہے؛ bot کا کام عموماً event کو human reviewer تک پہنچانا ہوتا ہے۔
