Polymarket Bot Tutorial · Chapter 18 of 32
Bot prediksi sengketa UMA di Polymarket: mendeteksi proposal Optimistic Oracle, memprediksi kemungkinan dispute, memanfaatkan asimetri harga sebelum dan sesudah dispute, serta menghindari spiral kematian market yang disengketakan.
Apa yang dibahas di chapter ini
Optimistic Oracle (OO) milik UMA menyelesaikan market Polymarket, dan dispute menciptakan anomali harga sebelum dan sesudah terjadi. Pola yang bisa ditradingkan ada di kedua sisi dispute, tetapi strateginya kompleks secara operasional dan sudah membuat lebih banyak bot rugi daripada untung. Chapter ini adalah playbook yang jujur.
- Cara kerja UMA Optimistic Oracle
- Mendeteksi proposal on-chain
- Prediktor dispute (volume, ambiguity, sejarah)
- Asimetri harga sebelum dispute
- Setup trade pasca-dispute
- Kapan TIDAK perlu trade market yang dipersengketakan
- Kode: subscribe ke event UMA proposed/disputed
Cara kerja UMA Optimistic Oracle
Optimistic Oracle (OO) milik UMA adalah layer penyelesaian dispute untuk Polymarket. Setiap market resolution melewati OO; sebagian besar tidak diperdebatkan dan settle secara otomatis. Yang diperebutkan - dispute - memicu voting period 24-72 jam di mana pemegang token UMA memutuskan hasilnya.
Alurnya: resolver Polymarket mengajukan harga (0 = NO menang, 1 = YES menang). Setelah challenge window 2 jam, jika tidak ada yang dispute, harga difinalkan dan kontrak CTF mendistribusikan payout. Jika ada yang dispute, market masuk ke voting window; pemegang UMA memberikan suara, mayoritas menang.
Untuk bot, event yang relevan adalah ProposePrice (proposal masuk, challenge window dibuka) dan DisputePrice (dispute diajukan, periode voting dimulai). Subscribe ke event ini untuk melacak state penyelesaian market secara real time.
Mendeteksi proposal on-chain
Contract UMA OO di Polygon memancarkan event ProposePrice dengan parameter (requester, identifier, timestamp, ancillaryData, proposer, proposedPrice). Filter berdasarkan known requester address milik Polymarket untuk membatasi ke proposal yang relevan.
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}")Field ancillaryData adalah JSON yang di-encode dalam hex dan menjelaskan pertanyaan market. Dengan mendekodenya, Anda mendapatkan market identifier yang bisa dicocokkan dengan open positions Anda.
Prediktor dispute (volume, ambiguity, sejarah)
Tiga sinyal sebelum dispute berkorelasi dengan dispute aktual yang terjadi kemudian.
- Total volume: market dengan volume seumur hidup > $1M dipersengketakan pada laju 4x lebih tinggi daripada market kecil. Semakin besar modal yang dipertaruhkan = semakin besar insentif untuk challenge.
- Ambiguous wording: market apa pun dengan frasa seperti "or similar," "officially confirmed," atau kondisi gabungan (tanggal DAN hasil spesifik) memiliki tingkat dispute yang lebih tinggi.
- Past disputes pada event yang sama: jika proposal sebelumnya sudah didispute dan diajukan ulang, proposal kedua didispute pada laju 2-3x normal.
Bot dapat menghitung skor "probabilitas dispute" dari fitur-fitur ini dan menghindari mengambil posisi di market yang skornya melewati ambang batas dekat waktu resolution.
Asimetri harga sebelum dispute
Dalam beberapa jam sebelum dispute yang kemungkinan besar terjadi, harga market sering menunjukkan pergerakan asimetris: sisi yang disebut proposer sebagai YES turun (karena trader khawatir dispute akan membalik hasil), sedangkan sisi lainnya naik.
Jika Anda punya view arah tentang bagaimana dispute akan terselesaikan, ini adalah jendela yang bisa ditradingkan. Risikonya: jika dispute tidak terjadi, asimetri akan berbalik ketika challenge window berakhir tanpa insiden dan harga kembali ke arah proposal.
Jujur: sebagian besar trade asimetri pra-dispute adalah trade rugi karena kebanyakan challenge diselesaikan sesuai proposal awal. Strategi ini hanya bekerja jika Anda punya informasi spesifik tentang mengapa dispute ini kemungkinan besar akan dipertahankan.
Setup trade pasca-dispute
Setelah dispute diajukan, market diperdagangkan selama 24-72 jam dalam kondisi "limbo" - sudah diketahui disengketakan, hasil menunggu voting. Ada dua setup.
Convergence ke konsensus UMA: jika sinyal penyelesaian dispute muncul lebih awal (misalnya, voter UMA yang menonjol secara publik mengambil satu sisi), harga bergerak menuju resolusi itu. Bot yang memantau sinyal UMA Discord / Twitter + price action bisa menangkap ini 30-60% dari waktu.
Volatility farming: periode limbo memiliki spread yang lebar. Market maker yang sabar dapat memperoleh spread tax dari beberapa trader yang bergantian masuk dan keluar selama voting window. Risiko inventory tinggi; atur ukuran posisi dengan hati-hati.
Keduanya memerlukan kesiapan menghadapi kemungkinan nyata bahwa resolusi akan berlawanan dengan posisi Anda. Perlakukan inventory pada periode dispute sebagai setengah ukuran paling banyak.
Kapan TIDAK perlu trade market yang dipersengketakan
Tiga situasi di mana trade dispute salah secara default.
- Anda tidak punya view khusus UMA. Jika satu-satunya edge Anda adalah "proposal awal terlihat benar menurut saya," Anda tidak punya edge atas proposer awal - dan pengaju dispute berpikir sebaliknya. Hasil voting adalah coin flip yang tidak bisa Anda prediksi.
- Dispute terjadi pada wording yang ambigu. Voter UMA umumnya berpihak pada pembacaan ketat terhadap pertanyaan. Jika market mengatakan "by January 31" dan event terjadi pada 1 Februari, UMA akan menyelesaikan NO terlepas dari intuisi populasi trader.
- Anda memegang inventory dari sebelum dispute. Menambah posisi yang sudah ada untuk "average down" selama limbo adalah pola klasik penghancuran modal. Tahan atau exit, jangan pernah menambah.
Kode: subscribe ke event UMA proposed/disputed
Referensi: subscription WebSocket ke event UMA OO, difilter berdasarkan 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)Pola kerjanya: subscribe, decode, alert. Bertindak atas dispute secara algoritmik berisiko tinggi; tugas bot biasanya adalah menampilkan event tersebut kepada reviewer manusia.
