Polymarket Bot Tutorial · Bölüm 18 / 32
Polymarket’te UMA dispute prediction botları: Optimistic Oracle proposals’larını tespit edin, dispute olasılığını tahmin edin, dispute öncesi ve sonrası fiyat asimetrisini değerlendirin ve disputed market ölüm sarmallarından kaçının.
Bu bölüm neleri kapsıyor
UMA'nın Optimistic Oracle'ı Polymarket marketlerini çözer ve disputes, tetiklenmeden önce ve sonra fiyat anomalileri yaratır. Trade edilebilir pattern'lar dispute'un her iki tarafında da vardır, ancak strateji operasyonel olarak karmaşıktır ve beslediğinden daha fazla botu yakmıştır. Bu bölüm dürüst playbook'tur.
- UMA Optimistic Oracle nasıl çalışır
- On-chain bir proposal nasıl tespit edilir
- Dispute predictor'lar (volume, ambiguity, history)
- Dispute öncesi fiyat asimetrisi
- Dispute sonrası trade setup'ları
- Disputed market'lerde ne ZAMAN trade edilmemeli
- Code: UMA proposed/disputed event'lerine subscribe olma
UMA Optimistic Oracle nasıl çalışır
UMA'nın Optimistic Oracle'ı (OO), Polymarket için dispute resolution layer'dır. Her market çözümü OO üzerinden geçer; çoğu itirazsızdır ve otomatik olarak settle olur. İtiraz edilenler - disputes - 24-72 saatlik bir voting period tetikler; bu süre boyunca UMA token holder'ları sonucu belirler.
Lifecycle şöyle işler: Polymarket'in resolver'ı bir price önerir (0 = NO kazandı, 1 = YES kazandı). 2 saatlik challenge window'dan sonra kimse dispute etmezse price finalize edilir ve CTF contract payout'ları dağıtır. Eğer biri dispute ederse market voting window'a girer; UMA holder'ları vote kullanır, çoğunluk kazanır.
Bir bot için ilgili event'ler ProposePrice (proposal girildi, challenge window açıldı) ve DisputePrice (dispute açıldı, voting period başladı) event'leridir. Market resolution state'ini gerçek zamanlı izlemek için bunlara subscribe olun.
On-chain bir proposal nasıl tespit edilir
Polygon üzerindeki UMA OO contract'ı, (requester, identifier, timestamp, ancillaryData, proposer, proposedPrice) parametreleriyle bir ProposePrice event'i emit eder. İlgili proposal'larla sınırlamak için Polymarket'in bilinen requester address'i ile filtreleyin.
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'ı, market sorusunu açıklayan hex-encoded JSON'dur. Bunu decode etmek, açık pozisyonlarınızla cross-reference edebileceğiniz market identifier'ını verir.
Dispute predictor'lar (volume, ambiguity, history)
Dispute öncesi üç sinyal, daha sonra gerçekleşen gerçek disputes ile korelasyon gösterir.
- Total volume: lifetime volume'u > $1M olan market'ler, küçük market'lere göre 4 kat daha fazla dispute edilir. Daha fazla sermaye riskte = itiraz etmek için daha fazla teşvik.
- Ambiguous wording: içinde "or similar", "officially confirmed" ya da bileşik koşullar (date AND specific outcome) bulunan herhangi bir market'te dispute oranı yükselir.
- Same event üzerinde geçmiş disputes: daha önceki bir proposal zaten dispute edilip yeniden önerildiyse, ikinci proposal normal oranın 2-3 katı dispute edilir.
Bir bot, bu özelliklerden bir "dispute probability" skoru hesaplayabilir ve resolution'a yakın eşik üstündeki market'lerde pozisyon almaktan kaçınabilir.
Dispute öncesi fiyat asimetrisi
Muhtemel bir dispute'dan önceki saatlerde market fiyatı çoğu zaman asimetrik hareket gösterir: proposer'ın YES olarak adlandırdığı taraf aşağı sürüklenir (çünkü trader'lar dispute'un bunu ters çevireceğinden korkar), diğer taraf yukarı sürüklenir.
Dispute'un hangi yöne çözüleceği konusunda yönlü bir görüşünüz varsa, bu trade edilebilir bir penceredir. Risk şu: dispute gerçekleşmezse, challenge window sorunsuz kapandığında asimetri tersine döner ve fiyatlar proposed direction'a geri sıçrar.
Dürüst olayım: pre-dispute asimetri trade'lerinin çoğu kayıp trade'dir, çünkü çoğu challenge orijinal proposal lehine sonuçlanır. Strateji yalnızca bu dispute'un neden sürdürüleceğine dair spesifik bilginiz varsa çalışır.
Dispute sonrası trade setup'ları
Dispute açıldıktan sonra market 24-72 saat boyunca "limbo"da trade olur - disputed olduğu bilinir, sonuç oylanacaktır. İki setup vardır.
UMA consensus'a convergence: dispute resolution erken sinyal verirse (örneğin önde gelen bir UMA voter açıkça bir tarafı desteklerse), fiyat o resolution'a doğru hareket eder. UMA Discord / Twitter sinyallerini ve price action'ı izleyen bir bot bunu zamanın %30-60'ında yakalayabilir.
Volatility farming: limbo dönemlerinde spread'ler geniştir. Sabırlı bir market maker, voting window boyunca girip çıkan çok sayıda trader üzerinden spread tax kazanabilir. Inventory risk yüksektir; boyutu buna göre ayarlayın.
Her ikisi de, position'ınıza ters bir resolution ihtimaline gerçek anlamda rahat olmayı gerektirir. Dispute-period inventory'yi en fazla yarım boyutta tutun.
Disputed market'lerde ne ZAMAN trade edilmemeli
Dispute trade'inin varsayılan olarak yanlış olduğu üç durum.
- UMA'ya özgü bir görüşünüz yoksa. Tek edge'iniz "orijinal proposal bana doğru görünüyor" ise, orijinal proposer'a karşı bir üstünlüğünüz yoktur - üstelik dispute açan taraf da bunun tersini düşünüyordur. Voting outcome, tahmin edemeyeceğiniz bir coin flip'tir.
- Dispute ambiguous wording üzerindeyse. UMA voter'ları genel olarak strict-reading-of-the-question tarafını tutar. Market "by January 31" dediyse ve event 1 Şubat'ta olduysa, trader topluluğunun sezgisine bakmaksızın UMA NO ile resolve eder.
- Dispute öncesinden inventory tutuyorsanız. Limbo boyunca "average down" yapmak için mevcut pozisyona ekleme yapmak, klasik capital-destruction pattern'ıdır. Tutun ya da çıkın, asla eklemeyin.
Code: UMA proposed/disputed event'lerine subscribe olma
Referans: Polymarket requester'ı ile filtrelenmiş UMA OO event'lerine WebSocket subscription.
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 şu: subscribe ol, decode et, alert ver. Disputes üzerinde algoritmik olarak işlem yapmak yüksek risklidir; bot'un görevi genellikle event'i bir insan reviewer'a göstermektir.
