En bot for hendelseskontrakter er et program som knytter informasjon om en hendelse til en kontrollert handelsflyt. Det viktigste utformingsspørsmålet er ikke hvor raskt det kan sende inn en ordre. Det er hvordan programmet vet hva som skjedde, hva det har lov til å gjøre, og når kontoposten er pålitelig nok til å fortsette. Et raskt system som forveksler spørsmålene, kan gjøre en beskjeden avgjørelse til en utilsiktet posisjon.

Arkitekturen bør bevare en kjede fra dokumentasjon til kontotilstand. En offentlig observasjon støtter en anbefaling. En anbefaling kan bestå eller ikke bestå en risikoavgjørelse. En godkjent instruks kan produsere et ordreforsøk som kan gi utførelser. Utførelsene må senere stemme med kontoens posisjoner og saldoer. Denne artikkelen beskriver kjeden gjennom oppdiktede eksempler, uten å anta at hver handelsplass tilbyr identiske ordretyper eller at et fungerende program fastslår en lønnsom strategi.

En bot for hendelseskontrakter trenger et kontraktsregister

Begynn med et uttrykkelig register over kontraktene boten kan vurdere. Lagre handelsplasskontekst, markedsidentifikator, utfallsidentifikatorer, oppgjørsenhet og regelreferanse. Legg til hendelsestid, handelsfrist og kilden navngitt i kontrakten. Registeret bør skille en første publisering fra en revidert verdi og beholde koblingsversjonen som ble brukt for hver avgjørelse.

Denne posten er mer presis enn et søkeresultat med en markedstittel. Et automatisert søk kan oppdage en kandidatkontrakt, men oppdagelse bør ikke stilltiende godkjenne handel. To markeder kan dele en overskrift og samtidig bruke ulike terskler eller observasjonsvinduer. En kobling gjennomgått av et menneske eller en testet regelmatchingsprosess må fastslå at dataene boten mottar, besvarer spørsmålet kontrakten gjøres opp etter.

Behandle en koblingsendring som en meningsfull systemhendelse. Hvis et tidligere gjenkjent felt blir utilgjengelig, bør boten ikke velge et felt med lignende navn bare fordi det holder arbeidsflyten i gang. Hvis en kontraktspresisering kommer, bevar den gamle tolkningen og registrer gjennomgangen av den nye informasjonen. Historikken trengs for å forstå hvorfor en tidligere posisjon ble åpnet under forutsetninger som senere kan endres.

Den eldre veiledningen om API for boter i prediksjonsmarkeder hjelper lesere med å identifisere forbindelsen mellom kontraktsidentifikatorer og kontohandlinger. Et register er ikke bare en programmeringsbekvemmelighet. Det er grensen som hindrer at et signal for én hendelse rutes til en overflatisk lignende, men økonomisk annerledes posisjon.

Hold observasjon atskilt fra tolkning

Observasjonslaget registrerer hva en kilde rapporterte, og når systemet mottok det. Det bør ikke umiddelbart gjøre hver oppdatering til et handelssignal. Bevar kildetidsstempel, mottakstidsstempel, identifikator og nøyaktig relevant verdi. Hvis en melding gjentas, merk den som samme observasjon fremfor en andre uavhengig bekreftelse. Hvis meldinger kommer i feil rekkefølge, bevar rekkefølgeinformasjonen fremfor å overskrive en nyere observasjon med en eldre.

Tolkningslaget avgjør hva observasjonen betyr for kontrakten. En rapport om at en indeks er lik 100,3, kan støtte Ja for en terskel over 100,2, men bare hvis rapporten gjelder riktig publisering, felt og avrundingsbehandling. En overskrift om at indeksen slo forventningene, er utilstrekkelig når kontrakten spør om en absolutt verdi. Et tolkeprogram må hente ut det kontraktsrelevante faktumet fremfor en generell positiv eller negativ stemning.

Noen inndata støtter et sannsynlighetsanslag fremfor en direkte faktisk fastsettelse. Programmet bør merke resultatet som prognose og beholde usikkerheten. En sikkerhetsverdi returnert av en språkmodell eller klassifikator er ikke automatisk en kalibrert sannsynlighet for at kontrakten utbetaler. Hvis tolkningen krever en ny rettslig eller faktisk vurdering, kan systemet sende den til gjennomgang uten å gi modellen fullmakt til å opprette eksponering.

En nyttig diagnosevisning viser den opprinnelige observasjonen ved siden av den avledede påstanden. Når en operatør stiller spørsmål ved en avgjørelse, bør vedkommende kunne undersøke forbindelsen uten å rekonstruere den fra et prisdiagram. Dette gjør også kildefeil lettere å isolere: En utdatert observasjon, feil uthenting og en rimelig, men mislykket prognose er ulike problemer som krever ulike rettelser.

Definer beslutningsfullmakten til boten for hendelseskontrakter

Anbefalingstrinnet foreslår en handling med kontrakt, side, mengde, prisgrense og begrunnelse. Godkjenningstrinnet avgjør om forslaget passer kontoens gjeldende begrensninger. Trinnene bør være atskilt selv i et lite program. En strategi kan anbefale kjøp mens kontoen allerede er ved hendelsesgrensen, en annen ordre er uavklart eller markedsstrømmen er blitt for gammel til å støtte foreslått pris.

En godkjenningspost bør navngi grensene den kontrollerte. Disse kan omfatte maksimal anskaffelseskostnad, maksimal hendelseseksponering, maksimalt antall åpne ordrer og et krav om at kontraktskoblingen forblir oppdatert. Resultatet er en avgrenset tillatelse med utløp, ikke en ubestemt instruks om å fortsette å prøve til ønsket mengde er oppnådd. Hvis forhold endres før innsending, bør gjennomføreren be om en ny avgjørelse eller avvise handlingen.

For eksempel anbefaler en oppdiktet strategi 100 Ja-enheter med en kjøpsgrense på $0,56 og en ytterligere reserve på $2 til avgifter. Kontoens risikokontroll tillater høyst $60 i forpliktelse til denne hendelsen. Foreslått maksimal forpliktelse er $58, så den passer den bestemte begrensningen. Den kan fortsatt bryte en annen begrensning, som en uavklart ordre i samme marked eller et manglende tidsstempel fra offisiell kilde.

Skillet blir særlig viktig når en bot utfører flere oppgaver. En undersøkelsesmodul kan legge kontrakter til en overvåkingsliste, men bør ikke få handelstillatelse bare fordi den deler prosess med gjennomføreren. En varslingsmodul kan varsle en person om en uvanlig spread, men varslet godkjenner ingen ny strategi. Uttrykkelige tillatelser hindrer at nyttige observasjoner blir utilsiktede kontoinstrukser.

Reserver eksponering før noe sendes

Eksponeringsreservasjon i en bot for hendelseskontrakter hindrer at flere samtidige avgjørelser bruker samme kapasitet. Når en instruks godkjennes, reserver maksimal tillatt kostnad og relevant hendelseseksponering før innsending. Behold reservasjonen mens ordren er åpen eller utfallet usikkert. Frigjør bare delen som autoritative poster fastslår ikke lenger kan gjennomføres.

Anta at den oppdiktede ordren på 100 enheter begynner å utføres. Førti enheter utføres til $0,54 og koster $21,60 før avgifter. Seksti enheter forblir åpne med en grense på $0,56 og representerer opptil $33,60 i ytterligere kjøpskostnad. Med gebyrreserven på $2 beholdt er samlet forpliktelse $57,20. Den lavere prisen på utført del reduserer forpliktelsen fra opprinnelig $58, men den ikke utførte delen er fortsatt en mulig fremtidig posisjon.

Hvis kontoens relevante kontantbudsjett er $100, etterlater denne forenklede reservasjonen $42,80 ubundet. Den etterlater ikke $78,40 bare fordi bare $21,60 er brukt så langt. Det større tallet ville ignorere den åpne ordren og kunne la en annen strategi bruke penger som allerede trengs til en mulig utførelse. Virkelige implementeringer må også avstemme faktiske gebyrer og eventuell plattformspesifikk reservasjonsatferd.

Bruk én felles eksponeringsoversikt på tvers av strategier som handler samme konto. Separate programmer med uavhengige tellere kan hver tro kontoen har rikelig kapasitet. Den eldre diskusjonen om automatisering av handel i prediksjonsmarkeder gir kontekst for å koordinere ansvaret. Reservasjonssystemet bør svikte konservativt når det ikke kan fastslå om en annen instruks fortsatt kan gjennomføres.

Modeller ordrer som tilstander, ikke suksessmeldinger

En ordreforespørsel kan være forberedt, innsendt, bekreftet mottatt, hvilende, delvis utført, fullført, avvist, kansellert eller usikker. Dette er begrepsmessige tilstander, ikke en påstand om at hvert API bruker akkurat disse navnene. Koble faktiske handelsplassvar til en dokumentert lokal modell. Bevar opprinnelig svar sammen med tolkningen slik at en adapterfeil kan undersøkes senere.

Et vellykket nettverkssvar kan fastslå at en forespørsel ble akseptert uten å fastslå at tiltenkt mengde ble utført. Omvendt kan et nettverkstidsavbrudd skje etter at handelsplassen aksepterte en ordre. Boten må unngå å behandle hver suksess som en fullført posisjon og hvert tidsavbrudd som et avslag. Ordreidentifikatorer, utførelsesposter og kontoøyeblikksbilder gir ulik dokumentasjon om hva som faktisk skjedde.

Gjeldende Polymarket-dokumentasjon om ordrelivsløp skiller ordre- og handelstilstander. Skillet illustrerer hvorfor én lokal boolsk verdi kalt fullført er utilstrekkelig. En implementering må følge tilstandene til den konkrete handelsplassen og produktet, inkludert eventuelle mellomliggende gjennomførings- eller oppgjørstilstander som fortsatt er uavklart etter at en match rapporteres.

Gjennomføreren bør også bevare den opprinnelige godkjente instruksen. Hvis en ordre utføres til bedre pris, bør den resulterende posisjonen fortsatt kunne spores til samme tillatelse. Hvis gjenværende mengde trenger høyere pris, er det en ny avgjørelse som krever godkjenning etter strategireglene. Å øke en grense stille for å fullføre målet gjør en kontrollert gjennomfører til en ugransket strategikomponent.

Gjenopprettingstilstander i boten for hendelseskontrakter hindrer duplisert eksponering

Vurder en innsending der svaret aldri når boten. Den lokale posten vet at et forsøk ble sendt, men vet ikke om det ble en ordre. Riktig neste tilstand er usikker. Behold eksponeringsreservasjonen og undersøk handelsplassen med støttede identifikatorer og kontoposter som kan avklare forsøket. Ikke opprett en ny ordre bare fordi første svar mangler.

Anta at opprinnelig instruks forespurte 100 enheter. Kontoposter avslører senere 40 utført og 60 fortsatt åpne. Boten ber om kansellering av resten, men ytterligere 15 enheter utføres før kanselleringen trer i kraft. Avstemt posisjon er 55 enheter, med 45 enheter ikke lenger åpne når kanselleringen er bekreftet. Hvis boten hadde antatt at det opprinnelige forsøket mislyktes og sendt en ny ordre på 100 enheter, kunne tiltenkt eksponering ha blitt vesentlig overskredet.

Gjenoppretting bør være varig på tvers av prosessomstarter. Skriv forsøksidentifikator og reservasjon før eller som del av den kontrollerte innsendingsflyten, etter systemets konsistensutforming. Ved omstart undersøker du uavklarte forsøk før nye anbefalinger for samme eksponering aksepteres. En ren programstart innebærer ikke en ren konto. Handelsplassen kan fortsatt ha ordrer opprettet av forrige prosess.

Veiledningen om automatisering av hendelseskontrakter utvider skillet til undersøkelses- og gjennomgangsflyten rundt. Gjenoppretting er ikke bare en teknisk detalj for sjeldne avbrudd. Den er del av strategiens eksponeringskontroll fordi kontoen kan endres mens det lokale systemet er frakoblet, starter på nytt eller venter på svar.

Bygg en avstemmingssløyfe uavhengig av strategien

En avstemmingsprosess sammenligner lokale forventninger med autoritative kontoposter. Den bør kjøre selv når intet nytt signal genereres. Sammenlign åpne ordrer, utførte mengder, posisjoner, avgifter og tilgjengelige saldoer med konsistente identifikatorer og observasjonstider. Et avvik bør gi et uttrykkelig unntak fremfor å korrigeres stilltiende slik at historikken om hvordan den lokale modellen ble feil, viskes ut.

Skill vanlige tidsforskjeller fra uforklarte avvik. En utførelsesoppdatering kan komme før tilsvarende saldooppdatering, avhengig av handelsplassens rapporteringsvei. Systemet kan tillate en dokumentert midlertidig tilstand mens det venter på et konsistent øyeblikksbilde. Men et avvik som varer utover forventet prosess, bør blokkere ny eksponering innenfor berørt omfang til det er forklart. Omfanget kan være ett marked, én konto eller hele gjennomføreren.

Avstemmingsposten bør si hvilke observasjoner som støtter dagens posisjon. En operatør bør kunne se at 55 enheter kommer fra to utførelser på 40 og 15, ikke fra en utledet forskjell mellom avrundede saldoer. Behold gebyrjusteringer separat slik at en kontantendring ikke forveksles med en endring i kontraktsmengde. Etter avgjørelse knytter du utbetalingen til faktisk gjenværende posisjon og endelig kontraktsresultat.

Lesere som bygger mot et kontogrensesnitt, kan bruke den eldre diskusjonen om en handelsbot for Kalshi-API til å organisere påkrevde poster. Prinsippet er uavhengig av implementeringsspråk: Strategien foreslår hva som bør skje, mens avstemming fastslår hva som skjedde. Ingen av funksjonene bør få erstatte manglende dokumentasjon med egne forventninger.

Bygg en avstemmingssløyfe uavhengig av strategienSubmission timeoutFind orderFind fillsKeep reservationResume after proofTRADING FIELD NOTESEDUCATIONAL RESOURCE
En usikker innsending forblir en aktiv risiko til autoritative ordre- og kontoposter avklarer den.

Gi systemer med flere ben og prisstilling ytterligere grenser

En retningsbot kan ofte uttrykke eksponeringen gjennom én posisjon. Et system med flere ben må spore om tiltenkt kombinasjon er fullført, og hva som gjenstår hvis bare noen ordrer gjennomføres. En mulig arbitrasje i hendelseskontrakter avhenger av forenlige utbetalinger og gjennomførbar handel. Boten bør representere hvert ben og samlede mulige utfall fremfor å registrere et par som fullført når første ordre aksepteres.

Reserver kapasitet til uferdige ben og definer maksimal tid eller vilkår for å forbli uparet. Hvis andre ben blir utilgjengelig, trenger systemet en forhåndsdefinert reaksjon i samsvar med kontoens tapsgrenser. Reaksjonen kan omfatte kansellering av ikke utførte ordrer, reduksjon av første posisjon eller bevaring av en avgrenset eksponering for gjennomgang. Den bør ikke anta at enhver sikring til enhver pris automatisk er bedre enn en ordnet avgjørelse.

Et prisstillingssystem møter en annen utfordring: Begge sider kan forbli aktive mens utførelser endrer beholdningen. En markedsskaper for hendelseskontrakter trenger derfor beholdningsbevisste tillatelser og en pålitelig oversikt over utestående pristilbud. En prisoppdatering som erstatter en gammel ordre, må ta hensyn til ethvert intervall der begge instrukser kan forbli aktive. Systemets tillatte brutto- og nettoeksponering bør gjenspeile muligheten.

Disse utvidelsene illustrerer hvorfor en generell kjøp-eller-selg-funksjon ikke er en fullstendig botarkitektur. Ulike strategier trenger ulike representasjoner av ufullført arbeid. Fellesgrunnlaget er uttrykkelig fullmakt, bevart ordreidentitet og avstemming; det strategispesifikke laget beskriver hvilke kombinasjoner av utførelser som er akseptable, og hvilken dokumentasjon som kreves før neste handling.

Følg klokkene som styrer en avgjørelse

En bot bør bevare flere klokker fordi de besvarer ulike spørsmål. Hendelseskildens tidsstempel beskriver når informasjonen ble publisert. Mottakstidsstempelet beskriver når den lokale prosessen fikk den. Ordreboktidsstempelet beskriver markedstilstanden som ble brukt i anbefalingen. Godkjenningstidsstempelet beskriver når kontoen godkjente en handling. Å slå disse sammen til ett tidsfelt kan skjule en utdatert observasjon bak en fersk behandlingshendelse.

Anta at en kildeobservasjon ble publisert klokken 9:00, nådde innsamleren klokken 9:01 og ble spilt av på nytt etter omstart klokken 9:10. Gjenspillingen er ny for den omstartede prosessen, men den underliggende dokumentasjonen er ti minutter gammel. En ferskhetsregel bare basert på lokal innsettingstid kunne la boten behandle observasjonen som aktuell. Bevar opprinnelige tider og merk gjenspillingen uttrykkelig slik at regelen evaluerer faktumet den er laget for å begrense.

Klokkesammenligninger trenger også en regel for manglende eller inkonsistente verdier. Hvis en kilde ikke gir pålitelig publiseringstid, bør systemet ikke finne på en. Det kan bruke en dokumentert reserve med strammere tillatelse eller holde tilbake handlinger som krever sterkere tidsdokumentasjon. Målet er å synliggjøre tidsusikkerhet i beslutningsposten fremfor å la et presist tidsstempel antyde kunnskap systemet ikke har.

Test med hendelser som endrer kontoen

En nyttig testsamling fokuserer på betydningsfulle overganger. Simuler svartidsavbrudd etter aksept, delvis utførelse under kansellering, et utdatert markedsøyeblikksbilde og omstart med en uavklart ordre. Kontroller at boten bevarer riktig reservasjon og nekter handlinger som kan overstige grensene. En test som bare bekrefter at en funksjon returnerer verdien som tilordnes inni den, gir lite dokumentasjon om disse virkelige feilforløpene.

Bruk et lite sett gjenspillbare hendelser med kjente forventede poster. For eksemplet på 100 enheter bør testen ende med 55 utført og 45 kansellert, uten en andre innsending på 100 enheter. Kontantmodellen bør gjenspeile faktiske utførelsespriser og avgifter fremfor opprinnelig maksimalanslag. En annen test kan bevisst utelate en utførelseshendelse og kreve at avstemming gjenfinner den manglende gjennomføringen fra en kontoforespørsel.

Test også harmløs inaktivitet. Når prognosen er utilgjengelig, kontraktskoblingen uavklart eller kontotilstanden inkonsistent, kan riktig resultat være ingen ordre. Et system evaluert bare på vellykkede innsendinger kan belønne aktivitet og overse avgjørelsene som hindrer uønsket eksponering. Registrer hvorfor en handling ble avvist slik at operatører kan skille en bevisst pause fra en ubemerket feil.

Boten er først klar for bredere bruk når postene gjør vanlig drift og gjenoppretting forståelige. En operatør bør kunne identifisere gjeldende kontrakt, dokumentasjon, tillatelse, åpne forpliktelser og bekreftet posisjon uten å gjette. Gjennomsiktigheten fastslår ingen handelsfordel, men gjør programmets atferd etterprøvbar og gir strategien et pålitelig grunnlag å evalueres på.

Fortsett å lære

Utforsk alle ressurser