Bot pro API Polymarket potřebuje jasnou odpověď na obtížnou provozní otázku: co má udělat, když odeslal objednávku, ale nikdy neobdržel použitelnou odpověď? Objednávka mohla být odmítnuta, přijata, částečně provedena nebo dokončena. Místní vypršení časového limitu tyto možnosti nerozlišuje.
Návrh počítající s touto nejistotou mění architekturu. Bot potřebuje trvalé záznamy před přenosem, ohraničenou pravomoc nad novou expozicí a proces obnovy, který prošetří původní záměr. Musí také nadále pozorovat účet, když přestal vytvářet nové objednávky. Pozastavení rozhodování a ztráta viditelnosti jsou různé činnosti.
Tento průvodce popisuje vzdělávací návrh pro kontext mezinárodní platformy Polymarket. Polymarket US má samostatná rozhraní účtu a obchodního místa. Všechny zdejší limity, množství, ceny a scénáře selhání jsou vymyšlené příklady. Návrh neprokazuje, že má obchodní strategie výhodu, ani neopravňuje ke skutečné činnosti na účtu.
Definujte ohraničeného bota pro API Polymarket
Ohraničený bot pro API Polymarket má výslovné meze oprávnění: který účet může používat, které kontrakty smí zvažovat, jaké typy objednávek může vytvářet a kolik expozice smí přidat. Tyto meze by měly být vynutitelné mimo předpovědní komponentu, aby chybný signál nemohl jednoduše prohlásit, že se na něj nevztahují.
Vymyšlený bot může pozorovat všechny trhy ve výzkumném seznamu, ale navrhovat objednávky pouze pro dva schválené kontrakty. Může mít limit třiceti podílů na událost a samostatný maximální nákupní závazek. Šíře pozorování neznamená odpovídající obchodní pravomoc.
Starší průvodce API bota Polymarket vysvětluje schopnosti a způsoby selhání. Používejte toto rozlišení při návrhu bota: přístup k údajům, vytváření objednávek, rušení a operace peněženky jsou samostatné schopnosti. Funkce patří do programu pouze tehdy, když je její účel a hranice autorizace jasná.
Oddělujte předpověď od vykonavatele
Předpovědní komponenta by měla vytvářet návrh obsahující kontrakt, směr, požadované množství, maximální náklady a konec platnosti odůvodnění. Neměla by přímo držet neomezenou podpisovou pravomoc. Samostatná rozhodovací brána může návrh ověřit vůči současnému stavu účtu a provozním limitům.
Toto oddělení je užitečné i tehdy, když celý systém provozuje jeden člověk. Umožňuje prověřit chování programu: návrh vysvětluje, proč byl obchod zvažován, zatímco brána vysvětluje, zda byl povolen. Odmítnutý návrh zůstává součástí výzkumného záznamu bez vytvoření objednávky.
Vykonavatel by měl přijímat pouze plně specifikovaný autorizovaný pokyn. Neměl by improvizovat větší množství nebo širší cenu jen proto, že první pokus nebyl vyplněn. Tyto změny mění ekonomické rozhodnutí a vyžadují nové ověření vůči účtu a současným podkladům strategie.
Zachovejte jeden ekonomický záměr napříč pokusy
Ekonomický záměr popisuje požadovanou změnu účtu, zatímco pokus o přenos popisuje jednu snahu sdělit pokyn. Jejich zaměňování je častým zdrojem duplicit. Vypršení časového limitu následované novým požadavkem by se nemělo automaticky stát druhým nezávislým přáním nakoupit stejné množství.
Přiřaďte záměru stabilní místní identifikátor a zaznamenejte schválené podmínky. Propojte s tímto záměrem každý požadavek, odpověď, identifikátor objednávky a pozorování obchodu, pokud je vztah známý. Pokud jej pozdější pokyn nahrazuje, zaznamenejte tento vztah výslovně místo přepisování staré historie.
Průvodce obchodováním přes API Kalshi poskytuje srovnání ověřování a slaďování účtu v jiném kontextu API. Obecné rozlišení záměru a pokusu je přenositelné, ale dostupné mechanismy vyhledávání a zpracování duplicit se liší. Bot musí ověřit skutečná pravidla fungování obchodního místa, místo aby předpokládal univerzální idempotentní funkci.
Nejprve zapište trvalý deník záměrů
Trvalý deník záměrů musí existovat předtím, než činnost může dosáhnout obchodního místa. Jinak může pád po přenosu ponechat aktivní objednávku bez místního vysvětlení. Trvalé uložení po přijetí odpovědi je pro toto konkrétní okno selhání příliš pozdní.
Zaznamenávejte účet, kontrakt, stranu, množství, cenový limit, dobu platnosti, verzi strategie, výsledek autorizace a rezervaci. Přidejte identitu požadavku nebo odkaz na podepsanou objednávku potřebný pro obnovu, aniž byste v běžných protokolech odhalovali tajné údaje. Deník by měl umožnit čtení historie po restartu procesu.
Záznam v deníku není důkazem, že byla objednávka odeslána. Uchovávejte samostatné fáze připraveno, přenos zahájen a odpověď pozorována. Tyto fáze pomáhají zúžit nejistotu, i když nemohou odstranit každou nejednoznačnost kolem síťové hranice. Poctivým stavem obnovy může stále být neznámý stav, dokud nejsou získány podklady účtu.
Rezervujte kapacitu atomicky
Dva návrhy mohou přijít krátce po sobě a oba vidět stejný zdánlivě dostupný rozpočet. Pokud je každý schválen nezávisle před zaznamenáním kterékoli rezervace, může jejich společná expozice překročit limit. Brána účtu potřebuje jednu konzistentní operaci, která kapacitu zkontroluje a rezervuje.
Předpokládejte vymyšlený limit třiceti podílů na událost. Účet drží dvanáct a existující aktivní objednávka může přidat osm. Do limitu se vejde pouze dalších deset podílů. Pokud dva nové návrhy žádají každý deset a oba čtou stejnou starou momentku stavu, schválení obou by umožnilo celkem čtyřicet podílů.
Sdílený záznam rezervací tomuto souběhu brání. Druhý návrh musí vidět první rezervaci nebo počkat na zjištění jejího výsledku. Samostatné pracovní procesy, strategie ani uživatelská rozhraní nevytvářejí samostatnou ekonomickou kapacitu, pokud používají stejný účet a limit události.
Zachovávejte rezervace během nejistoty
Odeslání s neznámým výsledkem se stále může stát expozicí. Uvolnění jeho rezervace jen proto, že místnímu požadavku vypršel časový limit, umožňuje jinému návrhu utratit stejnou kapacitu. Zachovávejte konzervativní závazek, dokud původní záměr není vyřešen nebo zdokumentovaná pravidla neurčí bezpečnou alternativu.
V příkladu třiceti podílů spotřebovává nejisté odeslání deseti podílů zbývající kapacitu pro nové vstupy. Bot může pokračovat ve čtení tržních údajů, ověřování a slaďování účtu a zpracování činností snižujících riziko, které jeho pravidla povolují. Neměl by považovat neznámé množství za nulu jen proto, aby zůstal aktivní.
Toto chování by mělo být operátorovi viditelné. Jasný stav, například deset podílů rezervováno do ověření a sladění odeslaného požadavku, vysvětluje, proč jsou nové návrhy pozastaveny. Bez tohoto vysvětlení může operátor bota restartovat nebo rezervaci odstranit a nechtěně tak zmařit kontrolu, která účet chránila.
Používejte současné nastavení účtu a peněženky
Bot musí před prováděním ověřit současného podepisujícího, peněženku účtu, oprávnění a schválení pro obchodování. Staré příklady mohou předpokládat jiné uspořádání peněženky nebo klientské rozhraní. Úspěšný přístup k veřejným údajům neověřuje soukromou obchodní cestu.
Dokumentace peněženek a ověřování Polymarket je současným referenčním zdrojem pro nastavení konkrétního účtu. Uchovávejte tajné materiály v autorizovaném podpisovém prostředí odděleně od běžných aplikačních protokolů a výzkumných záznamů. Obnova by měla spoléhat na identifikátory a podklady účtu, nikoli na odhalování přihlašovacích údajů při ladění neúspěšného požadavku.
Ukládejte verzi klienta a nastavení vedle provozních záznamů. Pokud aktualizace změní sestavování požadavků nebo výklad odpovědí, měl by bot před obnovením své pravomoci projít příslušnými případy obnovy. Kompatibilita je chování, které je třeba ověřit, nikoli vlastnost vyplývající ze známého názvu balíčku.
Diagnostikujte místo selhání
Neúspěšný pracovní postup se může zastavit před autorizací, před přenosem, po přenosu nebo během ověřování a slaďování záznamů. Tato místa mají různé důsledky. Místně odmítnutý návrh nevytváří žádnou objednávku. Požadavek, jehož přenos nikdy nezačal, lze případně bezpečně zopakovat pod stejným záměrem. Požadavek s neznámým vzdáleným výsledkem potřebuje prošetření.
Zaznamenávejte dostatek informací o načasování a stavu k rozlišení těchto případů, aniž byste předstírali větší znalost, než podporují podklady. Provozní protokol může uvádět, že klient v určitou dobu začal odesílat a poté ztratil spojení. Nemůže pouze z této místní chyby vyvodit, že obchodní místo nikdy bajty nepřijalo.
Používejte kategorie chyb, které vedou ke konkrétním činnostem. Selhání ověření vyvolává prověření přihlašovacích údajů nebo účtu. Neplatné cenové kroky vyvolávají prověření omezení trhu. Odeslání s neznámým výsledkem vyvolává ověření a sladění účtu. Obecná obsluha opakující vše ignoruje rozdíl mezi opravou požadavku a neúmyslným zdvojením platného požadavku.
Prošetřujte pomocí podkladů objednávek a obchodů
Obnova po odeslání s neznámým výsledkem by měla hledat podklady spojené s původním záměrem pomocí identifikátorů a rozhraní podporovaných obchodním místem. Současné otevřené objednávky, jednotlivé záznamy objednávek a obchody účtu mohou odpovídat na různé části otázky. Chybějící položka v jednom seznamu není vždy dostatečným důkazem, že nedošlo k žádnému provedení.
Průvodce správou objednávek Polymarket popisuje ověřená načtení pro sledování objednávek a obchodů účtu. Bot by měl spojovat příslušné podklady se svým trvalým deníkem. Měl by také uchovávat čas dotazu a případné omezení pokrytí, například neúplné stránkování nebo odpojený datový proud.
Po zjištění stavu aktualizujte společně rezervaci i záznam pozice. Aktivní objednávka si ponechává odpovídající závazek. Potvrzené odmítnutí jej může uvolnit. Provedení mění držby a náklady. Pokud podklady zůstávají protichůdné, udržujte nejistotu výslovnou a směrujte případ odpovědnému operátorovi.
Doporučujte a vydělávejte USDC
Doporučujte a vydělávejte USDCNáš partnerský program vyplácí v reálném čase.
Nevyvozujte odmítnutí z prázdného seznamu otevřených objednávek
Objednávka, která se zcela vyplnila, už nemusí být mezi otevřenými objednávkami. Okamžitá objednávka, jejíž nevyplněné množství bylo zrušeno, také nemusí zanechat žádnou čekající položku. Pohled pouze na seznam otevřených objednávek proto může chybně klasifikovat dokončené nebo částečné provedení jako požadavek, který nikdy neexistoval.
Než bot rozhodne, že původní záměr neměl žádný účinek, musí prověřit ostatní relevantní záznamy. To je zvlášť důležité, pokud byl požadavek při odeslání okamžitě obchodovatelný. Zmizení aktivního zbytku neznamená nepřítomnost získaných podílů.
Užitečný pohled operátora odděluje tři otázky: zda je objednávka stále aktivní, zda došlo k nějakým obchodům a zda byly výsledné změny účtu ověřeny a sladěny. Jejich rozlišení brání tomu, aby se vizuálně prázdný panel objednávek považoval za důkaz, že účet nemá žádnou pozici.
Správně ověřujte a slaďujte okamžitá částečná plnění
Typ objednávky určuje osud nevyplněného množství. Současná dokumentace Polymarket definuje FAK jako vyplnění dostupného množství a zrušení zbytku. Částečné provedení FAK zanechává pozici, ale neponechává zbývající požadované podíly čekající v knize.
Ve vymyšleném případě vede požadavek FAK na deset podílů ke čtyřem provedeným podílům za 0,43 $ a šesti zrušeným. Nákupní cena je 1,72 $ před poplatky. Po zjištění provedení a stavu zbytku by měl bot zaznamenat čtyři podíly a uvolnit rezervaci spojenou s ostatními šesti podle skutečných podkladů účtu.
Čekající objednávka deseti podílů se čtyřmi provedenými a šesti aktivními je jiná. Zachovává možnou budoucí expozici. Stavový model bota by neměl používat jeden obecný částečný stav jako náhradu za provedené množství i konečný nebo pokračující stav zbytku.
Zpracovávejte souběh rušení s plněním
Požadavek na zrušení se může překrývat s plněním. Bot by měl počítat s ověřením a sladěním obou, místo aby předpokládal, že jeho záměr zrušit okamžitě odstranil expozici. Úspěšné zrušení se může vztahovat na zbývající množství až po dalším provedení.
Předpokládejte, že při zahájení rušení vypadá šest podílů jako aktivních a před odstraněním zbytku se provedou další dva. Bot musí tyto dva přidat k pozici a uvolnit pouze závazek, který skutečně skončil. Náhradní návrh by měl používat výsledný stav účtu, nikoli množství viditelné před souběhem.
Starší průvodce botem pro automatické obchodování Polymarket rozebírá chování při pozastavení a restartu. Rušení je jednou součástí tohoto procesu, nikoli univerzálním návratem do výchozího stavu. Zastavení nových rozhodnutí, stažení zrušitelných objednávek a ověření a sladění existujících pozic jsou samostatné povinnosti, které mohou být dokončeny v různých časech.
Používejte jednu autoritativní cestu odesílání
Více pracovních procesů může pomáhat sbírat údaje nebo vyhodnocovat nezávislé hypotézy, ale odesílání objednávek potřebuje koordinovanou pravomoc. Pokud dva vykonavatelé mohou jednat podle stejného záměru bez sdíleného mechanismu převzetí, mohou jej oba po restartu nebo opožděné zprávě přenést.
Zvolte jasné pravidlo odpovědnosti aktivního vykonavatele a zviditelněte její změny. Nový pracovní proces by neměl předpokládat, že starší pracovní proces skončil, jen proto, že se opozdil signál jeho aktivity. Potřebuje mechanismus bránící oběma souběžně používat stejnou pravomoc nebo pravidlo pozastavení do zjištění odpovědnosti.
Smyslem není přidávat složitost pro ni samotnou. Bot v jediném procesu může používat jednoduchý návrh, pokud je chování při restartu výslovně určeno. S růstem systému zachovávejte stejnou ekonomickou záruku: jeden schválený záměr se nesmí změnit ve více nezávislých objednávek, protože několik komponent věří, že odpovídají za jeho dokončení.
Před pokračováním po restartu obnovte stav
Restart by měl začít pozorováním a ověřováním a slaďováním záznamů. Načtěte nevyřešené záměry, prověřte současné objednávky a obchody, ověřte identitu účtu a porovnejte obnovené držby s místním záznamem. Nová expozice by měla počkat, dokud nejsou příslušné nesrovnalosti vyřešeny nebo výslovně ošetřeny podle provozních pravidel.
Nepřehrávejte každý nedokončený záznam deníku jako novou objednávku. Některé nedokončené záznamy mohou odpovídat vzdáleným provedením, jejichž odpovědi se ztratily. Jiné možná nikdy neopustily proces. Cesta obnovy je musí klasifikovat podle podkladů, místo aby chybějící místní příznak dokončení považovala za svolení k opětovnému přenosu.
Průvodce botem pro API Kalshi popisuje akceptační případy jiného obchodního místa. Používejte toto srovnání k zpřesnění otázek obnovy a zároveň oddělujte identifikátory a chování požadavků konkrétních obchodních míst. Stejný scénář selhání může v různých rozhraních vyžadovat různá vyhledávání.
Udržujte pozorování aktivní při pozastavení rozhodování
Bot, který pozastaví nové vstupy, by obvykle měl pokračovat ve čtecích operacích potřebných k porozumění svému účtu. Vypnutí všech komponent může ztížit vyřešení nejistého stavu a ponechat operátora bez aktuálních informací o aktivních objednávkách nebo pozicích.
Definujte provozní režimy podle schopností. Režim pouze pro pozorování může obnovovat tržní údaje a údaje účtu. Režim ověřování a slaďování může prošetřovat předchozí činnosti. Režim rušení může při autorizaci povolit konkrétní operace snižující riziko. Obchodní režim může v rámci svých limitů vytvářet novou expozici.
Každý režim by měl mít jasné podmínky vstupu a výstupu. Samotná obnova sítě by neměla automaticky obnovit obchodování, pokud zůstávají nevyřešené záměry. Naopak výpadek výzkumného zdroje nemusí bránit ověřování a slaďování účtu přes zdravé soukromé rozhraní. Podrobné hranice schopností pomáhají botovi zůstat užitečným bez překročení pravomoci.
Umožněte podle zpráv operátorovi jednat
Operátor by měl obdržet stručné vysvětlení nevyřešeného stavu: účet, kontrakt, původní záměr, možnou expozici, poslední ověřené podklady a další krok šetření. Samotný výpis zásobníku volání nevysvětluje ekonomický následek selhání.
Nežádejte operátora o volbu mezi opakováním a ignorováním bez kontextu. Dostupné činnosti mohou zahrnovat dotaz na původní objednávku, kontrolu obchodů účtu, zachování pozastavení nebo předání rozporného záznamu k vyššímu řešení. Bot by měl uchovávat účinek každé činnosti v deníku.
Prověření platformy může pomoci toto rozhraní uspořádat. Průvodce obchodní platformou Polymarket odděluje řízení účtu, tvorbu ceny a vypořádání. Tyto rozdíly by měly zůstat viditelné během selhání, kdy si čtenář obzvlášť snadno splete fungující obrazovku tržních údajů s plně ověřeným a sladěným obchodním účtem.
Testujte selhání na síťové hranici
Užitečná akceptační zkouška přerušuje proces v několika místech: po trvalém uložení záměru, během přenosu, po vzdáleném přijetí, ale před místním uložením odpovědi, a po příchodu plnění, ale před aktualizací pohledu na pozici. Každé přerušení by mělo vést k obnovitelnému nebo výslovně nevyřešenému stavu.
Očekávaným výsledkem není vždy automatické pokračování. Některé případy by měly skončit pozastavením, protože dostupné podklady nedokážou bezpečně určit stav účtu. Test by měl ověřit, že bot zachovává rezervace, vyhýbá se duplicitní expozici a poskytuje operátorovi dostatek informací k šetření.
Zahrnujte do přehrání duplicitní i opožděné zprávy. Opětovné zpracování již známého obchodu by nemělo přidat jeho množství dvakrát. Opožděné odmítnutí by mělo být spojeno se správným požadavkem místo přepsání jiného úspěšného záměru. Tyto případy testují model záznamů smysluplněji než opakované odesílání běžných objednávek za ideálních podmínek.
Prověřujte ekonomický záznam bota
Provozní metriky by měly zahrnovat stáří nevyřešených záměrů, prodlevu ověřování a slaďování, duplicitní pozorování a nesrovnalosti rezervací. Samotná úspěšnost požadavků může vypadat zdravě, zatímco záznam účtu je chybný. Malý počet nejistých odeslání může být důležitější než tisíce úspěšných veřejných načtení.
Starší průvodce API bota pro predikční trhy poskytuje širší architektonický pohled. Prověřujte bota na jeho hranicích: jaké podklady vstoupily, jaká pravomoc byla udělena, jaký pokyn odešel a jaký stav účtu se vrátil. Tyto hranice určují, kde selhání změnilo význam nebo překročilo rozsah.
Oddělujte vyhodnocení strategie. Bot může věrně provádět špatnou strategii a slibnou předpověď může podkopat nespolehlivé provedení. Ekonomický deník umožňuje prozkoumat obě otázky, aniž by se každý výsledek připisoval nejviditelnější komponentě nebo poslední chybové zprávě.
Udržujte bota pro API Polymarket v mezích jeho podkladů
Dobře ohraničený bot ví, kdy má dost podkladů k jednání a kdy má dost podkladů pouze k šetření. Jeho trvalý deník propojuje jeden záměr s jeho pokusy, objednávkami a obchody. Jeho rezervace zohledňují možnou expozici, dokud se nejistota nevyřeší.
Začněte úzkou sadou oprávnění a úplným postupem obnovy. Ověřte nastavení účtu proti současné dokumentaci, koordinujte pravomoc k odesílání a testujte přerušení před rozšířením rozsahu. Zajistěte vysvětlitelnost pozastavení a zachovejte dostupné pozorování potřebné k jejich vyřešení.
Výsledkem je program, jehož chování lze rekonstruovat při běžném provozu i selhání. Nemění nejisté předpovědi na jisté výsledky. Zpřesňuje však provozní tvrzení: bot by měl provádět pouze ohraničené činnosti, o jejichž provedení byl oprávněn se pokusit, a poté zjistit, co se skutečně stalo, než účet považuje za připravený k dalšímu rozhodnutí.