Případová studie · Algoritmické obchodování
Polymarket Bot
Šest souběžných trading strategií, jedna sjednocená vrstva řízení rizika — navrženo pro obchodování na predikčních trzích na úrovni protokolu
Zakázkový algoritmický trading engine pro Polymarket, decentralizovaný predikční trh na síti Polygon. Šest nezávislých strategií — copy trading, interní arbitráž, korelace s Binance, momentum, mean reversion a mispricing v nelikvidním order booku — běží souběžně v jediném asynchronním Python procesu s odděleným bankroll managementem pro každou strategii.
Written by Ing. Hlib Yarovyi, Founder · Published
Typ
Interní nástroj
Platforma
Polymarket (Polygon)
Strategie
6 souběžně běžících
Technologický stack
Python · asyncio · CLOB SDK · Docker
Od signálu k objednávce
< 1 sekunda
Problém
Polymarket je decentralizovaný predikční trh postavený na Polygonu, kde obchodníci nakupují a prodávají podíly v binárních výsledcích — YES nebo NO — u otázek sahajících od výsledků voleb přes cenové cíle kryptoměn až po geopolitické události. Na rozdíl od tradičních finančních trhů jsou predikční trhy strukturálně neefektivní: často mají nízkou likviditu, účastní se jich hlavně retailoví obchodníci, kteří drží pozice spíše kvůli narativu než kvůli pravděpodobnosti, a jejich ceny se mohou výrazně odchylovat od implikovaných pravděpodobností odvoditelných z externích datových zdrojů.
Tyto neefektivity jsou časově omezené. Jak predikční trhy dozrávají a roste účast institucionálních hráčů, ceny se sbližují a výhoda mizí. Okno pro získávání alfy pomocí systematických strategií je úzké — což znamená, že technická otázka nezní jen „dokážeme postavit strategie, které fungují“, ale také „dokážeme je postavit dost rychle a provozovat dost spolehlivě na to, abychom využili výhodu, která existuje právě teď“.
Systém musel dělat několik věcí současně: monitorovat externí signály (on-chain aktivitu na Polygonu a cenové feedy z Binance), detekovat interní chybné ocenění trhu, provádět příkazy přes Polymarket CLOB API, spravovat pozice napříč více současně otevřenými trhy a oddělit kapitál jednotlivých strategií tak, aby jeden špatný obchod neovlivnil ostatní. To vše v jediném Python procesu s latencí pod jednu sekundu od signálu k odeslané objednávce.
Neexistovalo pro to žádné hotové řešení. Polymarket CLOB API je poměrně slabě zdokumentované, on-chain integrace vyžaduje správu peněženek specifickou pro Polygon a práci s EIP-712 podpisy a logika strategií je ze své podstaty proprietární. Celý stack bylo nutné vybudovat od nuly.
Výzvy
Autentizace CLOB: EIP-712 na úrovni protokolu
Polymarket CLOB používá dvouvrstvý autentizační mechanismus: API klíč (L1) v kombinaci se zprávami podepsanými peněženkou (L2) pomocí EIP-712 typed data podpisů. Nastavit podpisové schéma naprosto přesně — správný domain separator, správné pořadí polí, správné kódování — nebylo triviální. Jediný chybný byte v podpisovém payloadu vede k tichému selhání autentizace bez užitečné chybové hlášky. Implementace musela přesně odpovídat specifikaci protokolu a být ověřena vůči zdrojovému kódu SDK od Polymarketu dříve, než bylo možné zadat jedinou objednávku.
Souběžné spouštění strategií bez vzájemného rušení
Šest strategií běžících současně na překrývajících se trzích vytváří problém se sdílením zdrojů. Dvě strategie se mohou nezávisle rozhodnout vstoupit do stejného trhu ve stejný okamžik — a tím zdvojnásobit zamýšlenou expozici, narazit na rate limity nebo vytvořit konfliktní signály pro správu pozice. Asynchronní architektura potřebovala sdílenou vrstvu stavu, která strategiím umožní dělat nezávislá rozhodnutí, ale zároveň zabrání tomu, aby si nevědomky lezly do stejných pozic nebo překračovaly limity expozice na úrovni trhu.
Latence copy tradingu při sledování potvrzených bloků na Polygonu
Monitorovat konkrétní peněženky na Polygonu kvůli copy trading signálům znamená volit mezi dvěma profily latence: sledovat mempool pro nepotvrzené transakce (rychlejší, ale signál není potvrzený a nemusí se nikdy zapsat do řetězce), nebo sledovat potvrzené bloky (pomalejší, ale spolehlivé). Pro většinu trhů na Polymarketu — které se pohybují v horizontu hodin či dnů, nikoliv sekund — bylo sledování po potvrzení správným kompromisem. Strategie byla navržena podle latence, kterou skutečně měla, ne podle latence, kterou by si přála mít.
Mispricing v nelikvidním order booku: signál vs. omezení likvidity
Široký bid-ask spread na Polymarketu může znamenat dvě velmi odlišné věci: trh je chybně oceněný a představuje skutečnou výhodu, nebo je oceněný správně, ale jen nelikvidní, a spread odráží cenu za poskytování likvidity, nikoliv chybu v ocenění. Rozlišit tyto dva případy algoritmicky — pomocí hloubky order booku, historického chování spreadu a konzistence implikovaných pravděpodobností — bylo hlavní intelektuální výzvou strategie pro nelikvidní trhy.
Jak to funguje
Asynchronní event loop: jeden proces, šest strategií
Celý engine běží v jediném Python asyncio event loopu. Každá strategie je implementována jako asynchronní coroutine s vlastním životním cyklem — spuštění, polling signálů, exekuce objednávek a monitoring pozic — a běží souběžně, aniž by blokovala ostatní. Sdílený state manager sleduje otevřené pozice, čekající objednávky a alokaci kapitálu pro jednotlivé strategie napříč celým portfoliem. Tato architektura udržuje nízkou latenci a minimální spotřebu zdrojů, zároveň ale umožňuje strategiím koexistovat bez režie spojené s koordinací.
Copy trading: monitoring on-chain peněženek
Strategie copy tradingu monitoruje sadu cílových adres peněženek na Polygonu a sleduje jejich pozice na Polymarketu parsováním on-chain transakčních dat z potvrzených bloků. Když cílová peněženka otevře novou pozici, systém tento obchod zrcadlí na úrovni CLOBu — odešle odpovídající objednávku během několika sekund od potvrzené transakce. Strategie cílí na trhy, kde je relevantní časový horizont signálu v řádu hodin, nikoliv sekund, takže latence po potvrzení je přijatelným kompromisem ve prospěch spolehlivosti signálu oproti spekulaci z mempoolu.
Korelace s Binance: cenový pohyb jako predikční signál
Velké směrové pohyby na Binance — významné změny ceny BTC nebo ETH či kaskády likvidací — korelují s pravděpodobností vyhodnocení u části otázek na Polymarketu (trhy na cenové úrovně, cíle ke konci měsíce). Strategie sledující Binance odebírá cenové feedy, detekuje pohyby nad nastaveným prahem, identifikuje sadu dotčených trhů na Polymarketu a vstupuje do pozic odrážejících novou implikovanou pravděpodobnost. Velikost pozice zohledňuje sílu korelace i čas zbývající do vyhodnocení trhu.
Interní arbitráž: YES + NO < 1,00 USD
Každý binární trh na Polymarketu má teoretické omezení: cena podílů YES plus cena podílů NO se musí rovnat 1,00 USD. Když je likvidita fragmentovaná nebo dočasně rozhozená, může se toto omezení porušit — a vzniká arbitrážní příležitost, kdy nákup YES i NO za aktuální ceny přináší výplatu vyšší než náklady. Arbitrážní scanner průběžně monitoruje aktivní trhy, počítá součet nejlepších ask cen pro oba výsledky a vstupuje do obou nohou ve chvíli, kdy se objeví dostatečný rozdíl. Riziko exekuce — tedy že se mezera uzavře mezi první a druhou nohou — je započítáno do minimálního požadovaného spreadu.
Strategie založené na mikrostruktuře order booku
Čtyři strategie cílí přímo na dynamiku order booku. Momentum strategie identifikuje trhy vykazující konzistentní směrový pohyb ceny a vstupuje ve směru trendu. Mean reversion strategie vstupuje proti velkým dočasným odchylkám od nedávné cenové historie trhu. Strategie volume-spike využívá abnormální tok objednávek jako předstihový indikátor blížícího se pohybu ceny. Strategie thin-book detekuje trhy, kde bid-ask spread implikuje rozdělení pravděpodobností, které není konzistentní s dostupnými externími informacemi — vstupuje na přesněji oceněnou stranu a čeká na konvergenci.
Rozpočty rizika pro každou strategii zvlášť
Každá strategie pracuje s oddělenou alokací kapitálu. Ztrátová série jedné strategie nesnižuje kapitál dostupný ostatním — neexistuje sdílený drawdown, který by zhoršoval celý systém. Velikost pozic v rámci každé strategie je kalibrována podle historické spolehlivosti signálů a profilu likvidity trhu. Globální omezení zároveň zastropovávají celkovou expozici na jeden trh bez ohledu na to, kolik strategií se do něj nezávisle rozhodlo vstoupit, čímž se předchází koncentračnímu riziku při souběžném spuštění korelovaných rozhodnutí.
Fáze vývoje
Systém byl vyvíjen ve třech navazujících fázích. Každá fáze přinesla funkční a nasazený engine ještě před přidáním další vrstvy strategií — což umožnilo ověřit základní architekturu v reálném provozu dříve, než se rozšířil rozsah projektu.
Fáze 1
Jádro enginu a autentizace
Asynchronní Python architektura, integrace s Polymarket CLOB, implementace EIP-712 podpisů L1/L2, pipeline pro exekuci objednávek, nasazení v Dockeru a základní sledování stavu pozic
Fáze 2
Signální strategie
Copy trading pomocí monitoringu on-chain peněženek na Polygonu, strategie korelace s cenami na Binance a interní scanner arbitráže YES+NO — vše běžící souběžně se sdíleným state managerem
Fáze 3
Vrstva mikrostruktury
Momentum, mean reversion, volume-spike a thin-book strategie; dokončení rozpočtů rizika pro jednotlivé strategie a kontrol expozice na úrovni celého portfolia
Výkon systému
Strategií běžících souběžně v jediném asynchronním procesu, každá s odděleným kapitálem a nezávislou logikou signálů
Latence od detekce události po odeslání objednávky do CLOBu napříč všemi typy strategií
Dostupnost během produkčního období — engine běžel nepřetržitě i přes výpadky API a zahlcení sítě Polygon bez ručního zásahu
Časté otázky
Proč právě Polymarket a ne centralizovaná burza?
Polymarket je strukturálně méně efektivní než zavedené kryptoburzy. Jeho uživatelskou základnu tvoří převážně retail, trhy mají nižší likviditu a ceny se mohou výrazně odchylovat od implikovaných pravděpodobností odvoditelných z externích dat. Právě tato neefektivita představuje výhodu. Centralizované burzy jsou hluboce likvidní a silně arbitrované — okno pro systematickou alfu je tam užší a vyžaduje výrazně větší kapitál pro konkurenceschopný přístup.
Jak může copy trading fungovat bez přístupu k privátním strategiím jiných traderů?
Každý obchod na Polymarketu je on-chain transakcí na Polygonu. Adresy peněženek jsou veřejné a aktiva, která drží, jsou viditelná v reálném čase. Monitorováním sady peněženek, jejichž historické obchodní chování naznačuje skutečnou informační výhodu — ne jen náhodnou odchylku — systém zrcadlí jejich vstupy na úrovni CLOBu během několika sekund od potvrzené transakce. Není potřeba žádná proprietární informace; blockchain je veřejný a auditovatelný záznam každé otevřené pozice.
Je interní arbitráž YES+NO skutečně bezriziková?
Teoreticky ano — pokud se obě nohy vyplní současně za kotované ceny. V praxi je rizikem exekuce: Polymarket CLOB nepodporuje atomické víceúsekové objednávky, takže obě nohy se odesílají postupně. Pokud se první noha vyplní, ale druhá ne — protože se mezitím pohnul trh — pozice už není arbitráží. Strategie vstupuje pouze tehdy, když je cenová mezera dostatečně velká na to, aby zůstala zisková i v případě, že se druhá noha vyplní za horší cenu.
Jakým typům operací nejvíce pomáhá zakázkový trading systém tohoto typu?
Jakékoli operaci, která má vyvinuté proprietární trading signály, ale chybí jí infrastruktura pro jejich spolehlivou exekuci ve větším měřítku. Systém není samotná strategie — je to infrastruktura, která umožňuje strategie spouštět, testovat a iterovat bez nutnosti pokaždé znovu budovat exekuční vrstvu. Pro trading operace, kde úzkým hrdlem nejsou nápady, ale spolehlivost exekuce a provozní režie, je zakázkový asynchronní engine s kvalitní vrstvou řízení rizika správným nástrojem.
Lze tento systém upravit i pro jiné predikční trhy nebo třídy aktiv?
Ano, s jasně ohraničeným vývojovým úsilím. Jádro architektury — asynchronní běh strategií, sdílený stav, rozpočty rizika a správa životního cyklu objednávek — není specifické jen pro Polymarket. Specifická je integrace s CLOBem a on-chain komponenty. Přizpůsobení pro jiný predikční trh (Kalshi, Manifold, Limitless) vyžaduje výměnu integrační vrstvy při zachování strategického a risk frameworku. Přizpůsobení pro jinou třídu aktiv vyžaduje kompletní novou integraci API a dat, ale strukturální principy se přenášejí přímo.
Zakázková automatizace pro komplexní a datově náročné workflow
Algoritmické obchodování je jen jedním příkladem oblasti, kde hotové nástroje končí na hranici obecného řešení a skutečná hodnota začíná až za ní. Pokud vaše operace závisí na vlastní logice signálů, proprietárních datových zdrojích nebo orchestraci více systémů, kterou žádný existující produkt neřeší, navrhujeme a vyvíjíme infrastrukturu, která ji udělá spolehlivou, auditovatelnou a škálovatelnou.
Get in touch →