En bot til begivenhedskontrakter er et program, som forbinder information om en begivenhed med en kontrolleret handelsarbejdsgang. Dets vigtigste designspørgsmål er ikke, hvor hurtigt det kan indsende en ordre. Det er, hvordan programmet ved, hvad der skete, hvad det må gøre, og hvornår dets kontoregistrering er troværdig nok til at fortsætte. Et hurtigt system, som forveksler spørgsmålene, kan gøre en beskeden beslutning til en utilsigtet position.

Arkitekturen bør bevare en kæde fra dokumentation til kontotilstand. En offentlig observation understøtter en anbefaling. En anbefaling kan bestå eller afvises i en risikobeslutning. En godkendt instruks kan producere et ordreforsøg, som kan producere udførelser. Disse udførelser skal senere stemme overens med kontoens positioner og saldi. Artiklen beskriver kæden gennem fiktive eksempler uden at antage, at hvert handelssted tilbyder identiske ordretyper, eller at et fungerende program fastslår en rentabel strategi.

En bot til begivenhedskontrakter kræver et kontraktregister

Begynd med et udtrykkeligt register over de kontrakter, botten må overveje. Gem handelsstedskontekst, markedsidentifikator, udfaldsidentifikatorer, afregningsenhed og regelreference. Tilføj begivenhedstidspunkt, handelsfrist og kilden navngivet i kontrakten. Registret bør skelne en første offentliggørelse fra en revideret værdi og bevare den tilknytningsversion, som blev brugt til hver beslutning.

Registreringen er mere præcis end et søgeresultat med en markedstitel. En automatiseret søgning kan opdage en kandidatkontrakt, men opdagelse bør ikke stiltiende godkende handel. To markeder kan dele en overskrift og samtidig bruge forskellige tærskler eller observationsvinduer. En menneskeligt gennemgået tilknytning eller en testet regelmatchningsproces skal fastslå, at de data, botten modtager, besvarer det spørgsmål, kontrakten afregner.

Behandl en tilknytningsændring som en meningsfuld systemhændelse. Hvis et tidligere genkendt felt bliver utilgængeligt, bør botten ikke vælge et tilsvarende navngivet felt, blot fordi det holder arbejdsgangen kørende. Hvis en kontraktpræcisering fremkommer, skal den gamle fortolkning bevares, og gennemgangen af den nye information registreres. Historikken kræves for at forstå, hvorfor en tidligere position blev åbnet under antagelser, som senere kan ændres.

Den ældre vejledning til et bot-API til forudsigelsesmarkeder hjælper læsere med at identificere forbindelsen mellem kontraktidentifikatorer og kontohandlinger. Et register er ikke blot en programmeringsbekvemmelighed. Det er grænsen, som forhindrer et signal for én begivenhed i at blive sendt til en overfladisk lignende, men økonomisk anderledes position.

Hold observation adskilt fra fortolkning

Observationslaget registrerer, hvad en kilde rapporterede, og hvornår systemet modtog det. Det bør ikke straks omdanne hver opdatering til et handelssignal. Bevar kildetidsstempel, modtagelsestidsstempel, identifikator og den præcise relevante værdi. Hvis en besked gentages, skal den mærkes som samme observation frem for en anden uafhængig bekræftelse. Hvis beskeder ankommer i forkert rækkefølge, skal rækkefølgeinformationen bevares frem for at overskrive en nyere observation med en ældre.

Fortolkningslaget afgør, hvad observationen betyder for kontrakten. En rapport om, at et indeks er lig med 100,3, kan understøtte Ja for en tærskel over 100,2, men kun hvis rapporten vedrører korrekt offentliggørelse, felt og afrundingsbehandling. En overskrift om, at indekset slog forventningerne, er utilstrækkelig, når kontrakten spørger om en absolut værdi. En parser skal udtrække den kontraktrelevante oplysning frem for generel positiv eller negativ stemning.

Nogle input understøtter et sandsynlighedsestimat frem for en direkte faktisk afgørelse. Programmet bør mærke resultatet som en prognose og bevare usikkerheden. En tillidsværdi returneret af en sprogmodel eller klassifikationsmodel er ikke automatisk en kalibreret sandsynlighed for kontraktens udbetaling. Hvis fortolkningen kræver en ny juridisk eller faktisk vurdering, kan systemet sende den til gennemgang uden at give modellen beføjelse til at skabe eksponering.

En nyttig diagnosevisning viser den oprindelige observation ved siden af den afledte påstand. Når en operatør stiller spørgsmål ved en beslutning, bør forbindelsen kunne undersøges uden rekonstruktion fra et prisdiagram. Det gør også kildefejl lettere at isolere: En forældet observation, et forkert udtræk og en rimelig, men mislykket prognose er forskellige problemer med forskellige nødvendige reparationer.

Definér beslutningsbeføjelse for botten til begivenhedskontrakter

Anbefalingsstadiet foreslår en handling med kontrakt, side, mængde, prisgrænse og begrundelse. Godkendelsesstadiet afgør, om forslaget passer til kontoens aktuelle begrænsninger. Stadierne bør være separate, selv i et lille program. En strategi kan anbefale køb, mens kontoen allerede er ved sin begivenhedsgrænse, mens en anden ordre er uafklaret, eller mens markedsstrømmen er blevet for gammel til at understøtte den foreslåede pris.

En godkendelsesregistrering bør navngive de kontrollerede grænser. De kan omfatte maksimal erhvervelsesomkostning, maksimal begivenhedseksponering, maksimalt antal åbne ordrer og et krav om aktuel kontrakttilknytning. Resultatet er en afgrænset tilladelse med udløb, ikke en ubegrænset instruks om fortsatte forsøg, indtil den ønskede mængde er opnået. Hvis forhold ændres før indsendelse, bør udføreren anmode om en ny beslutning eller afvise handlingen.

Eksempelvis anbefaler en fiktiv strategi 100 Ja-enheder med en købsgrænse på 0,56 $ og en yderligere gebyrreserve på 2 $. Kontoens risikokontrol tillader højst 60 $ i forpligtelse for begivenheden. Den foreslåede maksimale forpligtelse er 58 $, så den passer til netop denne begrænsning. Den kan stadig blive afvist af en anden begrænsning, såsom en uafklaret ordre på samme marked eller et manglende tidsstempel fra den officielle kilde.

Forskellen bliver især vigtig, når en bot udfører flere opgaver. Et forskningsmodul kan føje kontrakter til en overvågningsliste, men bør ikke få handelstilladelse, blot fordi det deler proces med udføreren. Et beskedmodul kan gøre en person opmærksom på et usædvanligt spænd, men alarmen godkender ikke en ny strategi. Udtrykkelige tilladelser forhindrer nyttige observationer i at blive utilsigtede kontoinstrukser.

Reservér eksponering, før noget sendes

Eksponeringsreservation i en bot til begivenhedskontrakter forhindrer flere samtidige beslutninger i at bruge samme kapacitet. Når en instruks godkendes, skal dens maksimalt tilladte omkostning og relevante begivenhedseksponering reserveres før indsendelse. Bevar reservationen, mens ordren er åben, eller dens udfald er usikkert. Frigiv kun den del, som autoritative registreringer fastslår ikke længere kan udføres.

Antag, at den fiktive ordre på 100 enheder begynder at blive udført. Fyrre enheder udføres til 0,54 $ og koster 21,60 $ før gebyrer. Tres enheder forbliver åbne med en grænse på 0,56 $ og repræsenterer op til 33,60 $ i yderligere købsomkostning. Med gebyrreserven på 2 $ bevaret er den samlede forpligtelse 57,20 $. Den lavere pris på den udførte del reducerer forpligtelsen fra de oprindelige 58 $, men den uudførte del er stadig en mulig fremtidig position.

Hvis kontoens relevante kontantbudget er 100 $, efterlader denne forenklede reservation 42,80 $ uden forpligtelse. Den efterlader ikke 78,40 $, blot fordi kun 21,60 $ er brugt indtil videre. Det større tal ville ignorere den åbne ordre og kunne tillade en anden strategi at forbruge penge, som allerede kræves til en mulig udførelse. Virkelige implementeringer skal også afstemme faktiske gebyrer og eventuel platformspecifik reservationsadfærd.

Brug én fælles eksponeringsvisning på tværs af strategier, som handler samme konto. Separate programmer med uafhængige tællere kan hver tro, at kontoen har rigelig kapacitet. Den ældre gennemgang af automatisering af handel på forudsigelsesmarkeder giver baggrund for koordinering af ansvaret. Reservationssystemet bør fejle forsigtigt, når det ikke kan fastslå, om en anden instruks stadig kan udføres.

Modellér ordrer som tilstande, ikke succesbeskeder

En ordreanmodning kan være forberedt, indsendt, kvitteret, hvilende, delvist udført, fuldført, afvist, annulleret eller usikker. Det er begrebsmæssige tilstande, ikke en påstand om, at hvert API bruger præcis de navne. Knyt det faktiske handelssteds svar til en dokumenteret lokal model. Bevar det oprindelige svar sammen med fortolkningen, så en adapterfejl senere kan undersøges.

Et vellykket netværkssvar kan fastslå, at en anmodning blev accepteret, uden at fastslå, at den tilsigtede mængde blev udført. Omvendt kan netværkstimeout ske, efter at handelsstedet accepterede en ordre. Botten skal undgå at behandle enhver succes som en fuldført position og enhver timeout som en afvisning. Ordreidentifikatorer, udførelsesregistreringer og kontoøjebliksbilleder leverer forskellig dokumentation om, hvad der faktisk skete.

Aktuel dokumentation om Polymarkets ordrelivscyklus skelner ordre- og handelstilstande. Forskellen illustrerer, hvorfor én lokal boolesk værdi kaldet fuldført er utilstrækkelig. En implementering skal følge tilstandene hos sit konkrete handelssted og produkt, herunder eventuelle mellemliggende udførelses- eller afregningstilstande, som forbliver uafklarede efter rapportering af et match.

Udføreren bør også bevare den oprindelige godkendte instruks. Hvis en ordre udføres til en bedre pris, bør den resulterende position fortsat kunne spores til samme tilladelse. Hvis den resterende mængde kræver en højere pris, er det en ny beslutning, som kræver godkendelse efter strategiens regler. Stiltiende forhøjelse af en grænse for at fuldføre målet omdanner en kontrolleret udfører til en strategikomponent uden gennemgang.

Genopretningstilstande i en bot til begivenhedskontrakter forhindrer duplikeret eksponering

Betragt en indsendelse, hvis svar aldrig når botten. Den lokale registrering ved, at et forsøg blev sendt, men ved ikke, om det blev en ordre. Den korrekte næste tilstand er usikker. Bevar eksponeringsreservationen, og undersøg handelsstedet med de understøttede identifikatorer og kontoregistreringer, som kan afklare forsøget. Skab ikke en ny ordre, blot fordi første svar mangler.

Antag, at den oprindelige instruks anmodede om 100 enheder. Kontoregistreringer afslører senere 40 udførte og 60 stadig åbne. Botten anmoder om annullering af resten, men yderligere 15 enheder udføres, før annulleringen træder i kraft. Den afstemte position er 55 enheder med 45 enheder ikke længere åbne, når annulleringen bekræftes. Hvis botten havde antaget, at det oprindelige forsøg mislykkedes, og indsendt endnu en ordre på 100 enheder, kunne den tilsigtede eksponering være overskredet betydeligt.

Genopretning bør være holdbar på tværs af procesgenstarter. Skriv forsøgsidentifikatoren og reservationen før eller som del af den kontrollerede indsendelsesarbejdsgang efter systemets konsistensdesign. Undersøg ved genstart uafklarede forsøg, før nye anbefalinger for samme eksponering accepteres. En ren programstart indebærer ikke en ren konto. Handelsstedet kan stadig holde ordrer skabt af den tidligere proces.

Vejledningen til automatisering af begivenhedskontrakter udvider forskellen til den omgivende forsknings- og gennemgangsarbejdsgang. Genopretning er ikke kun en teknisk detalje til sjældne driftsafbrydelser. Den er en del af strategiens eksponeringskontrol, fordi kontoen kan ændre sig, mens det lokale system er afbrudt, genstarter eller venter på et svar.

Udform en afstemningsløkke uafhængig af strategien

En afstemningsproces sammenligner lokale forventninger med autoritative kontoregistreringer. Den bør køre, selv når intet nyt signal genereres. Sammenlign åbne ordrer, udførte mængder, positioner, gebyrer og tilgængelige saldi med konsistente identifikatorer og observationstider. En uoverensstemmelse bør producere en udtrykkelig undtagelse frem for stiltiende rettelse på en måde, som sletter historikken om, hvordan den lokale model blev forkert.

Adskil almindelige tidsforskelle fra uforklarede uoverensstemmelser. En udførelsesopdatering kan ankomme før den tilsvarende saldoopdatering afhængigt af handelsstedets rapporteringsvej. Systemet kan tillade en dokumenteret midlertidig tilstand, mens det venter på et konsistent øjebliksbillede. Men en uoverensstemmelse, som består ud over den forventede proces, bør blokere ny eksponering inden for det berørte omfang, indtil den forklares. Omfanget kan være ét marked, én konto eller hele udføreren.

Afstemningsregistreringen bør angive, hvilke observationer der understøtter den aktuelle position. En operatør bør kunne se, at 55 enheder kommer fra to udførelser på 40 og 15, ikke fra en udledt forskel mellem afrundede saldi. Bevar gebyrjusteringer separat, så en kontantændring ikke forveksles med en ændring i kontraktmængde. Forbind efter afgørelse udbetalingen med den faktiske resterende position og det endelige kontraktresultat.

Læsere, som bygger mod en kontogrænseflade, kan bruge den ældre gennemgang af en handelsbot til Kalshi API til at organisere de krævede registreringer. Princippet er uafhængigt af implementeringssprog: Strategien foreslår, hvad der bør ske, mens afstemning fastslår, hvad der skete. Ingen funktion bør have lov til at erstatte manglende dokumentation med egne forventninger.

Udform en afstemningsløkke uafhængig af strategienSubmission timeoutFind orderFind fillsKeep reservationResume after proofTRADING FIELD NOTESEDUCATIONAL RESOURCE
En usikker indsendelse forbliver en aktuel risiko, indtil autoritative ordre- og kontoregistreringer afklarer den.

Giv systemer med flere delhandler og kursstillelse yderligere grænser

En retningsbestemt bot kan ofte udtrykke sin eksponering gennem én position. Et system med flere delhandler skal følge, om den tilsigtede kombination er fuldstændig, og hvad der består, hvis kun nogle ordrer udføres. En kandidat til arbitrage med begivenhedskontrakter afhænger af kompatible udbetalinger og mulig udførelse. Botten bør repræsentere hver delhandel og de samlede mulige udfald frem for at registrere et par som fuldført, når første ordre accepteres.

Reservér kapacitet til uafsluttede delhandler, og definér en maksimal tid eller betingelse for at forblive uparret. Hvis anden delhandel bliver utilgængelig, kræver systemet en foruddefineret reaktion forenelig med kontoens tabsgrænser. Reaktionen kan omfatte annullering af uudførte ordrer, reduktion af den første position eller bevarelse af en afgrænset eksponering til gennemgang. Den bør ikke antage, at enhver afdækning til enhver pris automatisk er at foretrække frem for en ordnet beslutning.

Et kursstillingssystem møder en anden udfordring: Begge sider kan forblive aktive, mens udførelser ændrer beholdningen. En market maker for begivenhedskontrakter kræver derfor beholdningsbevidste tilladelser og en pålidelig visning af udestående kurser. En kursopdatering, som erstatter en gammel ordre, skal tage højde for ethvert interval, hvor begge instrukser kan forblive aktive. Systemets tilladte brutto- og nettoeksponering bør afspejle muligheden.

Udvidelserne illustrerer, hvorfor en generel køb-eller-sælg-funktion ikke er en fuldstændig botarkitektur. Forskellige strategier kræver forskellige repræsentationer af uafsluttet arbejde. Det fælles grundlag er udtrykkelig beføjelse, bevaret ordreidentitet og afstemning; det strategispecifikke lag beskriver, hvilke kombinationer af udførelser der er acceptable, og hvilken dokumentation der kræves før næste handling.

Følg de tidsangivelser, som styrer en beslutning

En bot bør bevare flere tidsangivelser, fordi de besvarer forskellige spørgsmål. Begivenhedskildens tidsstempel beskriver, hvornår informationen blev offentliggjort. Modtagelsestidsstemplet beskriver, hvornår den lokale proces fik den. Bogtidsstemplet beskriver markedstilstanden brugt til anbefalingen. Godkendelsestidsstemplet beskriver, hvornår kontoen godkendte en handling. Sammenlægning i ét tidsfelt kan skjule en forældet observation bag en nylig behandlingshændelse.

Antag, at en kildeobservation blev offentliggjort klokken 9:00, nåede indsamleren klokken 9:01 og blev genafspillet efter genstart klokken 9:10. Genafspilningen er ny for den genstartede proces, men den underliggende dokumentation er ti minutter gammel. En aktualitetsregel baseret alene på lokalt indsættelsestidspunkt kan lade botten behandle observationen som aktuel. Bevar de oprindelige tider, og mærk genafspilningen udtrykkeligt, så reglen vurderer det forhold, den blev udformet til at begrænse.

Tidssammenligninger kræver også en politik for manglende eller inkonsistente værdier. Hvis en kilde ikke leverer et troværdigt offentliggørelsestidspunkt, bør systemet ikke opfinde et. Det kan bruge en dokumenteret reserveprocedure med strammere tilladelse eller tilbageholde handlinger, som kræver stærkere tidsdokumentation. Målet er at synliggøre tidsmæssig usikkerhed i beslutningsregistreringen frem for at lade et præcist udseende tidsstempel antyde viden, systemet ikke har.

Test med hændelser, som ændrer kontoen

Et nyttigt testsæt fokuserer på betydningsfulde overgange. Simulér svartimeout efter accept, en delvis udførelse under annullering, et forældet markedsøjebliksbillede og en genstart med en uafklaret ordre. Verificér, at botten bevarer den rette reservation og afviser handlinger, som kan overskride dens grænser. En test, som blot bekræfter, at en funktion returnerer den værdi, den får tildelt internt, giver sparsom dokumentation om disse virkelige fejlveje.

Brug et lille sæt hændelser, som kan genafspilles, med kendte forventede registreringer. For eksemplet på 100 enheder bør testen slutte med 55 udførte og 45 annullerede uden en anden indsendelse på 100 enheder. Kontantmodellen bør afspejle de faktiske udførelsespriser og gebyrer frem for det oprindelige maksimale estimat. En anden test kan bevidst udelade en udførelseshændelse og kræve, at afstemning genfinder den manglende udførelse gennem en kontoforespørgsel.

Test også harmløs inaktivitet. Når prognosen er utilgængelig, kontrakttilknytningen er uafklaret, eller kontotilstanden er inkonsistent, kan det korrekte resultat være ingen ordre. Et system evalueret alene på vellykkede indsendelser kan belønne aktivitet og samtidig overse de beslutninger, som forhindrer uønsket eksponering. Registrér, hvorfor en handling blev afvist, så operatører kan skelne en bevidst pause fra en ubemærket fejl.

Botten er først klar til bredere brug, når dens registreringer gør almindelig drift og genopretning forståelige. En operatør bør kunne identificere den aktuelle kontrakt, dokumentation, tilladelse, åbne forpligtelser og bekræftede position uden at gætte. Den gennemsigtighed fastslår ikke en handelsfordel, men gør programmets adfærd mulig at gennemgå og giver strategien et pålideligt grundlag at blive evalueret på.

Lær mere

Udforsk alle ressourcer