Polymarket Bot Tutorial · Rozdział 15 z 32
Boty microstructure dla sports na Polymarket: przewaga w trakcie meczu, błędna wycena wynikająca ze scoreline, tag NBA (745) i tag Tennis (864), źródła live data oraz wzorce execution dla high-frequency sports markets.
Co obejmuje ten rozdział
Sports markets są najstabilniej aktywnym segmentem niepolitycznym na Polymarket. Boty, które działają, mieszczą się w dwóch prostych kategoriach: pre-game line-catchers, które handlują po ustaleniu linii, oraz in-game microstructure bots, które reagują na ruch w order book podczas gry. Ten rozdział obejmuje oba podejścia wraz z konkretnymi tag IDs, sources danych i latency budget, które odnoszą się do każdego z nich.
Sports markets są najruchliwszym segmentem niepolitycznym na Polymarket. Skuteczny execution pattern łączy live-score feed (ESPN, PandaScore) z sygnałami microstructure order book. W tym rozdziale omawiamy, co działa konkretnie dla NFL, NBA, soccer i tennis, oraz gdzie esports różni się od reszty.
To jest rozdział 15 naszej 32-częściowej serii o budowie Polymarket trading bota. Temat omawiamy szczegółowo w sekcjach poniżej. Treść główna dla każdej sekcji jest tworzona i publikowana rozdział po rozdziale; odpowiedzi FAQ i references są już kompletne i odzwierciedlają produkcyjne doświadczenie z prowadzenia naszego własnego trader.
- Dlaczego sports markets są tradeable
- Pre-game vs in-game (różne boty)
- Zweryfikowane tag IDs (745 NBA, 864 Tennis)
- Źródła danych: ESPN, official APIs, on-screen
- Latency budget dla in-game
- Pułapka 0.99 / 0.01
- Code: subskrypcja games book i reakcja
Dlaczego sports markets są tradeable
Sports markets rozliczają się w określonych ramach czasowych (od godzin do dni), mają publiczne live data i przyciągają ciągły order flow podczas meczów. Wszystkie trzy elementy są konieczne, aby rynek był tradeable — rynkom politycznym brakuje „defined timeframe”, rynkom pogodowym brakuje „continuous flow”, a mało znanym turniejom brakuje „public live data”.
Populacja traderów na sports markets jest też bardziej zróżnicowana niż np. na rynkach wyborczych. Casual sports bettors wyceniają emocjonalnie; informed traders korygują cenę w stronę fair value w trakcie meczu. Różnica między tymi dwiema grupami to edge bota.
Dystrybucja volume jest nierówna: NFL Sunday może przerzucić setki milionów dolarów przez sports markets na Polymarket; wtorkowy mecz Saudi Pro League może wygenerować mniej niż 50 tys. USD. Dopasuj skalę strategii do tego, gdzie faktycznie jest aktywność.
Pre-game vs in-game (różne boty)
Dwa fundamentalnie różne projekty bota.
Pre-game line-catcher: skanuje rynki, które właśnie zostały otwarte, identyfikuje błędnie wycenione linie względem twojego modelu albo względem liczby z bardziej sharp venue, składa FOK buy. Trzyma do in-play, czasem aż do resolution. Speed: minuty, nie sekundy. Edge: model + line-shopping.
In-game microstructure: subskrybuje order book konkretnego live game przez WebSocket, reaguje na imbalance signals + score events w ciągu sekund. Speed: sekundy, nie minuty. Edge: latency + czytanie order flow.
Te dwa podejścia prawie nie dzielą kodu. Mają inne risk profiles, inne data sources i inne exit strategies. Bot próbujący robić oba zwykle nie robi dobrze żadnego; wybierz jeden.
Zweryfikowane tag IDs (745 NBA, 864 Tennis)
Production tag IDs zweryfikowane w maju 2026 dla głównych kategorii sports. Używaj ich, aby efektywnie filtrować wywołania /events.
| Sport / League | Tag ID | Tag slug | Uwagi |
|---|---|---|---|
| NBA | 745 | nba | highest volume Oct-Jun |
| NFL | 450 | nfl | peak Sun/Mon Sep-Feb |
| Tennis (all) | 864 | tennis | year-round, tournament cadence |
| Soccer (general) | 1059 | soccer | combine with sub-tags below |
| EPL | 739 | epl | |
| UCL | 2186 | uefa-champions-league | |
| Esports (all) | 702 | esports | LoL+CS2+Valorant+Dota |
| MLB | 1245 | mlb | peak Apr-Oct |
| NHL | 823 | nhl | peak Oct-Jun |
Tag IDs są stabilne między latami. Dodawane są nowe tagi (Saudi Pro League, IPL), ale stare tagi nie są ponumerowywane od nowa.
Źródła danych: ESPN, official APIs, on-screen
W tradycyjnych sports bezpłatne ESPN scoreboard API pokrywa wszystko, czego potrzebujesz: scores, period/clock, win-probability, czasem shot location. Bez klucza; ograniczenie tylko na poziomie IP. Wzorzec endpointa: https://site.api.espn.com/apis/site/v2/sports/<sport>/<league>/scoreboard.
Dla esports ESPN nie ma coverage. Opcje: PandaScore (30-60 USD/mies., standard branżowy), HLTV (tylko CS2, możliwe do scrapowania, bez API), Liquipedia (prowadzona przez społeczność, możliwa do scrapowania, wolniejszy update cadence).
On-screen feeds (płacenie za TV stream i OCR-odczyt scorebug) działają, ale operacyjnie są ciężkie. Polecane tylko wtedy, gdy masz strategię wymagającą aktualizacji co mniej niż 3 sekundy w sporcie, którego żadne API nie obsługuje w czasie rzeczywistym.
Latency budget dla in-game
End-to-end latency budget dla reaktywnego bota in-game.
- Score event happens: t=0
- Source feed reflects: t+3-15s (ESPN: ~10s; PandaScore: ~3s)
- Your bot reads the feed: t+10-16s
- Bot decides action: +50ms
- FOK order placed: +200-500ms
- Matched at CLOB: +300-1000ms (network + matching)
Łącznie: 11-17 sekund. Najszybsze profesjonalne firmy osiągają 3-5 sekund end-to-end dzięki płatnym premium feeds i co-located VPS. Retail boty działające na standard hosts i darmowym ESPN są po wolniejszej stronie.
Strategie, które wymagają mniej niż 5 sekund, nie są wykonalne dla retail. Strategie, które działają w oknie 10-17 sekund, to: line-catching po score, fading overreactions, late-game certainty plays.
Pułapka 0.99 / 0.01
Najczęstsza porażka in-play sports bota: kupowanie heavy favorite po 0.99 na minutę przed końcem, z oczekiwaniem łatwego +1¢. Z trzech powodów to się nie sprawdza.
Po pierwsze, 1% implied probability underdoga nie jest zerem — późne comebacki zdarzają się z niebanalną częstotliwością. Wygrana pewna na 99.5%, grana 200 razy, daje jedną stratę pełnego position size.
Po drugie, spread przy 0.99/0.01 oznacza, że płacisz 99c za share, zyskujesz 1c przy sukcesie, tracisz 99c przy rzadkim odwróceniu. Risk-reward jest brutalny.
Po trzecie, bot używający GTC sell na 0.999 prawie nigdy nie zostanie zmatchowany — nie ma kupujących po tej cenie. Pozycja jedzie do resolution. Jeśli wygrywa, zarobiłeś 1c. Jeśli nastąpi reversal, tracisz 99c.
To realna strata pieniędzy ponoszona przez builderów, którzy nie policzyli matematyki. Trzymaj się z dala od rynków wycenionych powyżej 0.95, chyba że twoja strategia została specjalnie zbudowana pod profile redemption-arbitrage.
Code: subskrypcja games book i reakcja
Reference: subskrybuj WebSocket konkretnego NBA game, loguj book updates, uruchamiaj FOK na sygnał imbalance.
import websocket, json
THRESHOLD = 0.5 # imbalance level to trigger
def on_message(ws, message):
msg = json.loads(message)
if msg.get("event_type") != "book": return
bids = msg.get("bids", [])
asks = msg.get("asks", [])
bid_depth = sum(float(b["price"]) * float(b["size"]) for b in bids[:5])
ask_depth = sum(float(a["price"]) * float(a["size"]) for a in asks[:5])
total = bid_depth + ask_depth
if total < 100: return # too illiquid
imb = (bid_depth - ask_depth) / total
if abs(imb) > THRESHOLD:
print(f"signal imb={imb:.2f} bid={bid_depth:.0f} ask={ask_depth:.0f}")
# fire FOK here
ws = websocket.WebSocketApp(
"wss://ws-subscriptions-clob.polymarket.com/ws/market",
on_open=lambda ws: ws.send(json.dumps({"type":"Market","markets":["<CONDITION_ID>"]})),
on_message=on_message
)
ws.run_forever()Production additions: cooldown między zagraniami, per-token inventory cap, kill przy stale book (brak wiadomości przez 30s).
