Polymarket Bot Tutorial · Rozdział 18 z 32
Boty do przewidywania sporów UMA na Polymarket: wykrywaj propozycje Optimistic Oracle, przewiduj prawdopodobieństwo sporu, wykorzystuj asymetrię cen przed i po sporze oraz unikaj spiral śmierci na rynkach ze спорami.
Co obejmuje ten rozdział
Optimistic Oracle (OO) od UMA rozstrzyga rynki Polymarket, a spory tworzą anomalie cenowe przed ich wybuchem i po nim. Handlowalne wzorce istnieją po obu stronach sporu, ale strategia jest operacyjnie złożona i spaliła więcej botów, niż nakarmiła. Ten rozdział to uczciwy playbook.
To jest rozdział 18 z naszej 32-częściowej serii o budowie trading bota dla Polymarket. Szczegółowo omawiamy ten temat w sekcjach poniżej. Treść główna dla każdej sekcji jest pisana i publikowana rozdział po rozdziale; odpowiedzi FAQ i referencje są już kompletne i odzwierciedlają doświadczenie produkcyjne z uruchamiania naszego własnego tradera.
- Jak działa UMA Optimistic Oracle
- Wykrywanie propozycji on-chain
- Predyktory sporu (volume, ambiguity, history)
- Asymetria cen przed sporem
- Układy transakcyjne po sporze
- Kiedy NIE handlować rynkami ze спорami
- Code: subskrypcja zdarzeń UMA proposed/disputed
Jak działa UMA Optimistic Oracle
Optimistic Oracle (OO) od UMA to warstwa rozstrzygania sporów dla Polymarket. Każde rozliczenie rynku przechodzi przez OO; większość nie jest kwestionowana i rozlicza się automatycznie. Te sporne — disputes — uruchamiają 24-72-godzinny okres głosowania, podczas którego posiadacze tokenów UMA decydują o wyniku.
Cykl życia: resolver Polymarket proponuje cenę (0 = wygrało NO, 1 = wygrało YES). Po 2-godzinnym oknie na zgłoszenie sprzeciwu, jeśli nikt nie złoży sporu, cena zostaje ostatecznie zatwierdzona, a kontrakt CTF wypłaca środki. Jeśli ktoś zgłosi spór, rynek wchodzi w okno głosowania; posiadacze UMA oddają głosy, wygrywa większość.
Dla bota istotne są zdarzenia ProposePrice (propozycja została zgłoszona, otwiera się okno sprzeciwu) oraz DisputePrice (spór został złożony, zaczyna się okres głosowania). Subskrybuj je, aby śledzić stan rozliczenia rynku w czasie rzeczywistym.
Wykrywanie propozycji on-chain
Kontrakt UMA OO na Polygon emituje zdarzenie ProposePrice z parametrami (requester, identifier, timestamp, ancillaryData, proposer, proposedPrice). Filtruj po znanym adresie requester Polymarket, aby ograniczyć się do istotnych propozycji.
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}")Pole ancillaryData to zakodowany hexem JSON opisujący pytanie rynkowe. Jego dekodowanie daje identyfikator rynku, który możesz zestawić ze swoimi otwartymi pozycjami.
Predyktory sporu (volume, ambiguity, history)
Trzy sygnały przed sporem korelują z późniejszymi faktycznymi disputes.
- Total volume: rynki z wolumenem życia > $1M są kwestionowane 4x częściej niż małe rynki. Więcej kapitału na szali = większa motywacja do zakwestionowania.
- Ambiguous wording: każdy rynek z frazami typu "or similar", "officially confirmed" albo złożonymi warunkami (data AND konkretny wynik) ma podwyższone rates sporów.
- Past disputes on the same event: jeśli wcześniejsza propozycja była już kwestionowana i zgłoszona ponownie, druga propozycja jest kwestionowana 2-3x częściej niż zwykle.
Bot może obliczyć score „dispute probability” na podstawie tych cech i unikać zajmowania pozycji na rynkach powyżej ustalonego progu blisko rozliczenia.
Asymetria cen przed sporem
W godzinach poprzedzających prawdopodobny spór cena rynku często porusza się asymetrycznie: strona wskazana przez proponującego jako YES spada (bo traderzy obawiają się, że spór ją odwróci), a druga strona rośnie.
Jeśli masz kierunkowy pogląd, w którą stronę spór się rozstrzygnie, to jest to okno do handlu. Ryzyko: jeśli spór nie nastąpi, asymetria odwraca się, gdy okno sprzeciwu zamyka się bez komplikacji, a ceny wracają do proponowanego kierunku.
Uczciwie: większość transakcji na asymetrii przed sporem jest stratna, ponieważ większość challenge'y kończy się na korzyść pierwotnej propozycji. Ta strategia działa tylko wtedy, gdy masz konkretne informacje, dlaczego spór najpewniej zostanie podtrzymany.
Układy transakcyjne po sporze
Po złożeniu sporu rynek handluje przez 24-72 godziny w stanie „limbo” — wiadomo, że jest sporny, ale wynik dopiero ma zostać przegłosowany. Istnieją dwa setupy.
Zbieżność do konsensusu UMA: jeśli rozstrzygnięcie sporu zostanie zasygnalizowane wcześnie (np. znany voter UMA publicznie opowiada się po jednej stronie), cena przesuwa się w kierunku tego wyniku. Bot śledzący sygnały z UMA Discord / Twitter + price action może wyłapać to w 30-60% przypadków.
Volatility farming: okresy limbo mają szerokie spread'y. Cierpliwy market maker może zarabiać na spread tax od wielu traderów wchodzących i wychodzących w trakcie okna głosowania. Ryzyko inventory jest wysokie; dobieraj size odpowiednio.
Oba podejścia wymagają komfortu z realną możliwością rozstrzygnięcia przeciwko twojej pozycji. Traktuj inventory w okresie sporu jako najwyżej połowę normalnego size.
Kiedy NIE handlować rynkami ze спорami
Trzy sytuacje, w których trade na sporze jest z definicji błędny.
- Nie masz stanowiska specyficznego dla UMA. Jeśli jedyną twoją przewagą jest „pierwotna propozycja wydaje mi się poprawna”, nie masz przewagi nad oryginalnym proposerem — a osoba zgłaszająca spór uważa odwrotnie. Wynik głosowania to rzut monetą, którego nie potrafisz przewidzieć.
- Spór dotyczy niejednoznacznego brzmienia. Voterzy UMA zazwyczaj opowiadają się za ścisłym odczytaniem pytania. Jeśli rynek mówił „do 31 stycznia”, a zdarzenie miało miejsce 1 lutego, UMA rozstrzygnie NO niezależnie od intuicji traderów.
- Masz inventory zbudowane przed sporem. Dokładanie do istniejącej pozycji, by „uśredniać w dół” w limbo, to klasyczny wzorzec niszczenia kapitału. Trzymaj albo zamknij pozycję, nigdy nie dokładaj.
Code: subskrypcja zdarzeń UMA proposed/disputed
Reference: subskrypcja WebSocket do zdarzeń UMA OO, filtrowana po requesterze 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)Wzorzec jest prosty: subskrybuj, dekoduj, alarmuj. Działanie algorytmiczne na disputes jest obarczone wysokim ryzykiem; zadaniem bota jest zwykle przekazanie zdarzenia do ludzkiego review.
