Bot pro obchodování Ano a Ne: rozlišujte stranu, cenu a poplatky

Přiřazení stran bota Ano a Ne začíná identifikátory

Ukládejte výslovně identifikátor kontraktu a každý identifikátor výsledku. Označení jako Ano má význam pouze v konkrétním kontraktu. Dva sousední trhy mohou oba mít výsledek Ano a přitom odkazovat na různé prahy, data nebo zdroje. Přiřazení by mělo propojovat podmínku strategie s přesným výsledkem, který vykonavatel odešle, s verzovaným odkazem na pravidla vysvětlujícím vztah.

Držte nákup a prodej jako samostatná pole akce. Nákup přidává vybranou pozici a spotřebovává požadované peníze nebo zajištění podle skutečných mechanismů účtu. Prodej snižuje nebo jinak mění pozici podle modelu podporovaného místem obchodování. Nepředpokládejte neomezený prodej nakrátko ani to, že ekonomický doplněk lze vždy vyjádřit stejnou provozní akcí.

Například doporučení koupit 120 jednotek Ne by mělo v záznamu pokynu zůstat nákupem Ne. Systém může také počítat jeho ekvivalentní směrovou expozici vůči Ano pro analýzu rizika, ale tento odvozený pohled nesmí nahrazovat skutečnou identitu objednávky. Pokud jej adaptér potichu převede na prodej Ano, může vytvořit pokyn, který účet nemůže podpořit, nebo jinou cestu peněz, než schválila riziková kontrola.

Starší průvodce automatickým nákupem podílů Ano a Ne na Polymarket nabízí kontext výběru výsledku. Robustní test přiřazení by měl záměrně používat podobné názvy kontraktů a opačné strany. Cílem je dokázat, že bot vybírá schválený výsledek a akci, nikoli jen vytváří věrohodně vypadající cenu.

Rozlišujte pozorované a odvozené nabídky

Místo obchodování může hlásit obě knihy výsledků přímo nebo poskytovat podobu údajů, z níž se odvozuje prodejní nabídka opačné strany. Bot by měl toto přiřazení zdokumentovat a zachovat původní pozorování. Odvozená nabídka by měla určovat zdrojovou stranu, cenu, množství a časové razítko, které ji podporují. To umožňuje posuzovateli prozkoumat převod, když skutečná akce účtu vypadá překvapivě.

Dokumentace knihy objednávek Kalshi popisuje pole nákupních nabídek Ano a Ne s komplementárními vztahy prodejních nabídek. Ve standardním jednodolarovém příkladu nákupní nabídka Ano 0,33 $ odpovídá prodejní nabídce Ne 0,67 $. Tento vztah může poskytnout vstup výpočtu nákupu Ne, ale nečiní každou zobrazenou hodnotu Ano vhodným vstupem. Střed nebo starý poslední obchod nejsou totéž jako aktuální nákupní nabídka opačné strany.

Zachovávejte hloubku spolu s cenou. Pokud zdrojová nákupní nabídka podporuje jen 40 jednotek, odvozená prodejní nabídka podporuje toto množství na této úrovni, nikoli neomezený nákup. Dodatečné množství vyžaduje další úrovně a nový výpočet průměrných nákladů. Adaptér odvozující správnou cenu, ale připojující nesprávné množství stále může vytvořit nepřesné doporučení.

Související průvodce softwarem pro obchodování kurzů zkoumá normalizovaná data obecněji. Užitečný interní formát by měl označovat typ a původ pozorování. Normalizace činí hodnoty porovnatelnými jen při zachování skutečností potřebných k jejich výkladu; odstranění informací o straně nebo času může činit čistou datovou strukturu méně pravdivou než surovou odpověď.

Zachovávejte přesnost ceny a množství

Zacházejte s cenami a množstvími podle zdokumentovaných jednotek a povolené přesnosti aktuálního místa obchodování. Nepředpokládejte, že každý trh používá celé centy nebo celé kontrakty. Desetinný řetězec představující dolary by neměl být čten jako celé číslo centů a množstevní pole by nemělo být zaokrouhlováno jen proto, že uživatelské rozhraní zobrazuje méně číslic. Adaptér potřebuje výslovné převodní pravidlo s testy na příslušných hranicích.

Používejte výpočty vhodné pro peníze a požadovanou přesnost. Binární reprezentace s plovoucí desetinnou čárkou mohou vytvářet malé artefakty zaokrouhlení, takže implementace by měla tam, kde je to vhodné, používat ověřený desetinný přístup nebo přístup s pevnou desetinnou čárkou. Důležitým požadavkem je deterministický převod a zaokrouhlování podle skutečných pravidel místa obchodování. Konkrétní programátorská technika nestačí, pokud její výstup nebyl prověřen vůči podporovaným cenám a množstvím.

Bot by měl rozlišovat zaokrouhlování zobrazení a objednávky. Zobrazení ceny na dvě desetinná místa kvůli čitelnosti neopravňuje k odeslání této zaokrouhlené hodnoty, pokud se skutečný povolený nebo zamýšlený limit liší. Stejně tak množství objednávky snížené kvůli splnění kroku by se mělo odrazit v oprávnění a výpočtu expozice. Tiché zaokrouhlování může měnit ekonomiku nebo ponechat neočekávanou zbytkovou pozici.

Starší pojednání o obchodním API Kalshi pomáhá určit potřebu adaptérů specifických pro místo obchodování. Přejímací testy by měly zahrnovat hodnoty blízko povolených kroků, minimálních množství a limitů účtu. Bot fungující jen pro známá kulatá čísla neprokázal, že umí správně zachovat celý rozsah podporovaných vstupů.

Účtování poplatků bota Ano a Ne začíná před odesláním

Odhadujte poplatky pro skutečnou uvažovanou stranu, cenu, množství a roli při provedení pomocí aktuálních podmínek konkrétního trhu. Ukládejte odhad odděleně od konečného poplatku vykázaného účtem. Odhad poskytuje podklad pro oprávnění; skutečný poplatek určuje konečný záznam. Rozdíl poplatku by měl být vysvětlitelný bez přepsání původního doporučení, jako by mělo dokonalou znalost budoucnosti.

Předpokládejte, že fiktivní bot navrhuje nákup 120 jednotek Ne za dosažitelnou prodejní nabídku 0,67 $. Cena nákupu je 80,40 $. Předpokládejte odhadované pořizovací poplatky 1,60 $, což vytváří celkový závazek 82 $. Při uvedené běžné výplatě výhra Ne vyplácí 120 $ a vytváří zisk 38 $, zatímco prohra Ne vytváří ztrátu 82 $. Tato čísla by měla být zobrazena s předpoklady místo obecného procenta zisku.

Oprávnění účtu by mělo rezervovat maximální povolené pořizovací náklady a dostatečnou rezervu na poplatky. Pokud se objednávka může provádět přes několik úrovní až do cenového stropu, používejte příslušný maximální závazek místo pouze první pozorované prodejní nabídky. Poplatky se také mohou chovat odlišně při částečných vyplněních nebo změně rolí provedení, takže pravidla by měla zohledňovat skutečný sazebník místo předpokladu univerzální částky na jednotku.

Aktuální dokumentace poplatků Polymarket používá parametry konkrétních trhů. To je důvod ověřit příslušný sazebník, nikoli kopírovat jednu výchozí hodnotu do každého bota. Hypotetických 1,60 $ výše je výukový vstup a nepopisuje poplatek jmenovaného místa obchodování pro toto množství nebo cenu.

Úplný záznam objednávky propojuje záměr s podklady

Záznamy objednávek bota Ano a Ne by měly zachovávat doporučení, oprávnění, pokus o odeslání, identitu objednávky u místa obchodování a následná vyplnění. Doporučení vysvětluje, proč byla akce zvažována. Oprávnění ohraničuje, co účet smí dělat. Záznam odeslání dokládá, co bylo posláno. Vyplnění dokládají, co změnilo účet. Oddělené zachování těchto fází usnadňuje hledání chyb.

Každý pokus potřebuje trvalou identitu. Pokud se odpověď ztratí, bot může prošetřit tento pokus místo vytvoření nové nevysvětlené objednávky. Ukládejte s pokusem původní stranu, akci, množství a cenový limit. Proces obnovy by je neměl muset rekonstruovat z pozdějšího snímku pozice nebo vzpomínky obsluhy na označení v přehledu.

Záznamy vyplnění potřebují stabilní identifikátory provedení, skutečná množství, ceny a poplatky. Opakované doručení jednoho vyplnění by nemělo zvýšit pozici dvakrát. Částečně vyplněná objednávka by měla zachovat nevyplněný závazek, dokud není dokončena, odmítnuta nebo zrušena s dostatečnými podklady. Rizikový pohled účtu závisí na potvrzených jednotkách i na jednotkách, které ještě mohou přibýt.

Bot pro obchodování binárních trhů používá tyto záznamy k udržování omezené expozice a účetnictví vypořádání. Adaptér Ano a Ne přidává konkrétní odpovědnost: každý záznam musí zachovat, který výsledek byl držen a která akce jej vytvořila nebo snížila. Správné množství na nesprávné straně stále vytváří nesprávnou možnou výplatu.

Výstup musí používat nákupní nabídku držené strany

Pokračujte s fiktivním nákupem Ne s celkovými náklady 82 $. Předpokládejte, že účet později zvažuje prodej všech 120 jednotek Ne za dosažitelnou nákupní nabídku 0,63 $. Hrubý výnos z prodeje by byl 75,60 $. S předpokládaným výstupním poplatkem 1,20 $ by čistý výnos byl 74,40 $, což oproti pořizovacím nákladům vytváří ztrátu 7,60 $. Výpočet používá nákupní nabídku Ne, protože účet prodává Ne.

Přímé použití prodejní nabídky Ano jako ceny prodeje by bez příslušného přezkoumaného převodu bylo chybné. Bot by měl získat nebo odvodit cenu skutečné akce, ověřit dostupné množství a použít aktuální odhad poplatku. Sdílená pomocná funkce nazvaná získat cenu je nebezpečná, pokud volající nemohou určit, zda potřebují prodejní nabídku pro nákup, nákupní nabídku pro prodej nebo referenci bez provedení.

Doporučení výstupu by také mělo uvádět, zda uzavírá celou držbu nebo jen část. Prodej 60 ze 120 jednotek ponechává 60 jednotek Ne s podmíněnou výplatou. Bot by neměl kontrakt označit za uzavřený bez pozice jen proto, že byl přijat výstupní pokyn. Potvrzená vyplnění prodeje určují zbývající množství a případný otevřený zbytek zůstává součástí budoucího možného stavu účtu.

Související článek o botu pro obchodování kurzů vysvětluje normalizaci formátů kurzů před hodnocením. Tento převod nenahrazuje výběr strany knihy podle akce. Správně převedená cena pro nákup strany je stále nesprávným vstupem výpočtu toho, co by účet obdržel jejím prodejem.

Limity zohledňující stranu potřebují scénářový výklad

Rizikové limity mohou používat množství, peněžní závazek nebo možné ztráty, ale přiřazení držby ke scénářům musí respektovat kontrakt. U přesně doplňkových stran jedné standardní binární otázky mohou stejná množství Ano a Ne podle uvedených pravidel tvořit párovou výplatu. Nerovná množství ponechávají zbytkovou expozici. Napříč různými kontrakty zdánlivé vyrovnání Ano a Ne nemusí existovat vůbec.

Předpokládejte, že účet drží 120 jednotek Ne a 80 jednotek Ano ve stejném fiktivním kontraktu. Podle jednoduchého modelu 80 jednotek tvoří páry a 40 jednotek Ne zůstává směrových. Pokud vyhraje Ano, účet obdrží 80 $; pokud vyhraje Ne, obdrží 120 $. Pořizovací náklady a poplatky určují čistý výsledek každého případu. Čisté množství záporných 40 může shrnovat směrový rozdíl, ale nemělo by nahrazovat hrubou držbu ani historii peněz.

Hrubá množství jsou provozně důležitá, protože prodej nebo správa každé strany mohou vyžadovat oddělené akce a držené jednotky. Rizikový přehled zobrazující jen čistou expozici může skrývat objem kapitálu vázaný do obou stran. Může také znejasnit, které objednávky zůstávají aktivní a schopné změnit rovnováhu. Udržujte hrubou držbu, párované množství a zbytkovou expozici dostupné pro přezkum.

Starší průvodce API bota Polymarket nabízí kontext záznamů účtu specifických pro výsledek. Bot by měl vysvětlovat každou odvozenou čistou míru pomocí skutečných pozic a ověřených vztahů výplat. Rizikový model se stává nespolehlivým, pokud je pohodlné číslo se znaménkem považováno za důkaz vyrovnání, které podmínky kontraktu nepodporují.

Neznámé objednávky musí zachovat původní stranu

Pokud požadavek na nákup Ne překročí časový limit, bot by jej měl zachovat jako nejistý nákup Ne s původním množstvím a nákladovou hranicí. Neměl by reagovat odesláním prodeje Ano jen proto, že obě akce mohou ve zjednodušeném modelu ekonomicky souviset. Taková změna zavádí novou akci účtu a může vyžadovat jiné držené jednotky, oprávnění a zacházení s penězi.

Prošetřete původní pokus pomocí podporovaných záznamů objednávek a účtu. Pokud se částečně vyplnil, zahrňte potvrzené jednotky Ne a zachovejte případný nevyřešený zbytek. Pokud byl odmítnut, uvolněte příslušnou nevyužitou rezervaci. Pokud zůstává otevřený, rozhodněte, zda jej podle aktuální strategie zachovat nebo zrušit. Tato rozhodnutí by měla používat původní identitu a skutečné podklady účtu.

Souběh rušení a provádění může měnit rovnováhu stran. Předpokládejte potvrzených 50 jednotek Ne při žádosti o stažení a vyplnění dalších 15 před dokončením zrušení. Pozice je 65 jednotek Ne, nikoli 50. Pokud bot již odeslal vyrovnání podle dřívějšího množství, výsledné portfolio potřebuje nové ověření a sladění. Systém by jej neměl vtlačovat do zamýšlené čisté expozice úpravou souhrnného pole.

Testujte tyto případy se záměrně nesouměrným počátečním účtem, například malou držbou Ano a větším požadavkem nákupu Ne. To usnadňuje odhalení chyb stran oproti testu začínajícímu nulou v každém poli. Očekávaný výsledek by měl stanovovat hrubou držbu, peníze a možnou výplatu, nikoli jen konečné množství se znaménkem.

Ověřujte a slaďujte poplatky a vypořádání bez ztráty auditní stopy

Po provedení nahraďte odhadované poplatky ve výpočtech výkonnosti skutečnými poplatky účtu při zachování původního odhadu pro přezkum. Pokud je v příkladu výstupu později potvrzen dodatečný pořizovací poplatek 0,20 $, celkové pořizovací náklady rostou z 82 $ na 82,20 $. Při stejném čistém výnosu z prodeje 74,40 $ se ztráta stává 7,80 $. Úprava by měla mít identifikovatelný zdroj a čas.

Při vypořádání používejte konečné zbývající množství na každé straně. Zcela prodaná pozice Ne nemá zbývající výplatu Ne, i když se původní předpověď později ukáže správná. Částečně prodaná pozice vypořádává jen ponechané jednotky. Konečná účetní kniha by měla propojovat oficiální výsledek, držená množství, připsané částky a případné výjimečné zacházení stanovené kontraktem.

Rozlišujte změněnou předpověď a účetní opravu. Nový odhad nemění již zaplacené peníze a úprava poplatku nemění výsledek, na který se kontrakt ptá. Záznamy bota by měly dovolovat zachycení obou změn bez narušení druhé. Toto oddělení pomáhá posuzovateli rozumět rozdílu projektované hodnoty a konečné výkonnosti.

Pokud se účet nepodaří ověřit a sladit, zachovejte rozdíl a omezte dotčenou novou aktivitu do jeho pochopení. Nevysvětlený rozdíl by neměl být skryt v kategorii ostatních zisků nebo ztrát jen pro uzavření případu. Malé rozdíly mohou odhalit opakovaný problém převodu jednotek nebo duplicitních vyplnění, který by při větší velikosti byl významný.

Porovnávejte odhadované a skutečné poplatky podle akce

Přezkum poplatků by měl určovat, zda rozdíl pocházel z ceny, množství, role při provedení nebo nesprávného sazebníku. Předpokládejte, že bot odhadl poplatek plně okamžitého nákupu, ale část objednávky před vyplněním čekala v knize. Skutečné zacházení závisí na aktuálních pravidlech místa obchodování a trhu. Účetní kniha by měla zachovat zařazení každého vyplnění místo přiřazení stejné role každé jednotce podle původního záměru.

Porovnání také potřebuje shodnou jednotku. Poplatek vyjádřený peněžní částkou by neměl být přímo porovnáván s procentem maximální výplaty nebo rezervou na jednotku. Každou míru výslovně převeďte a zachovejte původní vykázanou hodnotu. To pomáhá odlišit skutečnou chybu modelu nákladů od zobrazení používajícího jiné jmenovatele.

Pokud byl odhad konzervativní a skutečné poplatky nižší, uvolněte nevyužitou rezervu až poté, co příslušné záznamy rozhodnutí podporují. Nevykazujte nevyužitou rezervu jako příjem. Šlo o kapacitu zadrženou pro možný náklad, nikoli peníze vydělané obchodováním. Toto rozlišení brání zlepšování zdánlivé výkonnosti bota jen proto, že původní odhad byl záměrně opatrný.

Otestujte adaptér čtyřmi akcemi a dvěma výsledky

Užitečná přejímací sada zahrnuje nákup Ano, prodej Ano, nákup Ne a prodej Ne tam, kde každou akci dovoluje skutečný účet. U každé ověřte vybranou stranu knihy, množství, peněžní účinek a zbývající držbu. Potom použijte oba běžné výsledky rozhodnutí a potvrďte výslednou výplatu. To pokrývá důležitější chování než opakované předvádění jednoho úspěšného nákupu Ano.

Přidejte testy odvozené nabídky opačné strany, nedostatečné hloubky, změny poplatku a opožděného vyplnění. Očekávané záznamy by měly zachovat surové pozorování i normalizovaný výklad. Pokud převod používá jednu minus nákupní nabídku opačné strany, ověřte přiřazení ceny i množství. Pokud trh používá jemnější kroky, zahrňte hodnoty, které by při předpokladu celých centů selhaly.

Dokončený bot by měl pro každou akci umožnit jednoduché vyjádření: tento účet koupil nebo prodal toto množství tohoto výsledku za tyto skutečné ceny, podle tohoto oprávnění, s těmito poplatky a touto zbývající expozicí výplatě. Tato jasnost je účelem automatizace zohledňující stranu. Udržuje pravděpodobnostní výpočty softwaru propojené s pozicemi a peněžními toky, které účet skutečně vlastní.