Kalshi-bot: lær arbeidsflyten for hendelseskontrakter

Hva en Kalshi-bot for hendelseskontrakter faktisk gjør

En Kalshi-bot for hendelseskontrakter har tre ulike oppgaver: å observere, beslutte og handle. Observasjon betyr å samle informasjon om hendelsen, kontrakten og kontoen. Beslutning betyr å bruke regler på informasjonen. Handling betyr å be om en ordre eller en annen støttet kontooperasjon. En god utforming holder oppgavene tilstrekkelig adskilt til at hver av dem kan undersøkes.

Anta at hendelsen gjelder om en publisert måleverdi overstiger en angitt terskel. En observasjon kan være en nylig publisert undersøkelse. Beslutningen kan være at undersøkelsen endrer den anslåtte sannsynligheten fra 48 % til 53 %. Handlingen er ikke automatisk å kjøpe. Programmet trenger fortsatt riktig kontrakt, en akseptabel tilbudt pris, tilstrekkelige ressurser og tillatelse innenfor grensene sine.

Skillet er viktig når informasjonen er riktig, men handelen er dårlig. En prognose på 53 % rettferdiggjør ikke å betale 58 cent for en enkel YES-kontrakt som utbetaler én dollar, bare fordi hendelsen er blitt mer sannsynlig. Et anslag må sammenlignes med kostnaden ved å få den tilsvarende eksponeringen.

En bot kan også være nyttig uten å legge inn nye handler. Den kan identifisere kontrakter som venter på gjennomgang, kontrollere at registrerte utførelser stemmer med posisjonene, eller varsle operatøren om en ukjent regelendring. Disse oppgavene har andre fullmaktsbehov enn ordreinnsending. Å gi alle komponenter full handelsfullmakt øker konsekvensene av en utilsiktet feil.

Det bredere rammeverket for boter i prediksjonsmarkeder forklarer hvorfor regler og oppgjør hører hjemme i handelsprosessen. På en bestemt handelsplass blir samme resonnement til kontodisiplin: Enhver foreslått handling bør besvare hva som handles, hvorfor nå, hvor mye og under hvilke betingelser planen blir ugyldig.

Les kontrakten før du leser prisen

En kort markedstittel gjør det enklere å orientere seg, men er ingen fullstendig spesifikasjon. De fullstendige reglene bestemmer det målte utfallet, den relevante perioden, kilden som bekrefter det, og behandlingen av uvanlige omstendigheter. Kalshi forklarer forskjellen mellom et sammendrag og hele kontrakten i veiledningen om regelsammendrag.

For et automatisk system er den viktige oppgaven å gjøre denne lesingen om til en registrering som kan kontrolleres. Lagre nøyaktig markedsidentitet, betydningen av YES, observasjonsvinduet og uavklarte spørsmål. Hvis et menneske ikke har avklart en tvetydighet, bør boten ikke i det stille fylle hullet med sin egen foretrukne tolkning.

Tenk på to hypotetiske kontrakter om det samme månedlige tallet. Den ene viser til den først publiserte verdien, mens den andre viser til en senere revisjon. Én prognose kan informere begge, men utbetalingene trenger ikke samsvare. Å behandle dem som utskiftbare kan skape en posisjon som oppfører seg annerledes enn handleren hadde tenkt.

Tidsgrenser fortjener samme omtanke. En betingelse som observeres på et hvilket som helst tidspunkt i en periode, er forskjellig fra en betingelse målt ved slutten. En hendelse ved midnatt i én tidssone kan tilhøre en annen dato et annet sted. Programmet trenger en uttrykkelig konvensjon fremfor operativsystemets lokale standardtid.

En praktisk registrering for opptak av kontrakter angir også hva som fører til avvisning. Eksempler er manglende regler, en ukjent kilde, en terskel som ikke kan tolkes, eller en kontrakt utenfor den tiltenkte produktfamilien. Avvisninger bevarer strategiens betydning. De er ikke tapte muligheter som automatisk bør overstyres når en pris ser attraktiv ut.

Skill en prognose fra en prisbasert sannsynlighet

En kontraktspris omtales ofte som en implisitt sannsynlighet. Det kan være nyttig, men bør ikke få programmet til å behandle en vist pris som en fullstendig sannsynlighetsmodell. Pristilbud avhenger av tilgjengelige kjøpere og selgere, posisjonsbegrensninger, prisforskjell mellom kjøp og salg, mengde og tidspunkt. Siste handel kan også være gammel.

For en enkel binær kontrakt som utbetaler én dollar ved YES, innebærer et eget anslag på 60 % sannsynlighet en forventet utbetaling på 60 cent per kontrakt før kostnader. Hvis den gjennomførbare kjøpsprisen er 55 cent, er forskjellen fem cent. Denne forskjellen er et anslag basert på prognosen, ikke penger som allerede er tjent.

Anta nå at modellusikkerheten antyder et rimelig sannsynlighetsintervall fra 51 % til 64 %. Det samme kjøpet ser gunstig ut ved øvre grense og ugunstig ved nedre. En konservativ regel kan kreve at handelen fortsatt er akseptabel med et mindre optimistisk anslag. En annen regel kan redusere mengden når prognoseusikkerheten øker.

Det viktige er at regelen angis før resultatet. Å bytte mellom anslag først etter å ha sett om en handel vant, hindrer meningsfull vurdering. Lagre prognosen, tidspunktet, kilden og prisen som ble brukt i beslutningen. Sammenlign senere prognosen med utfallene uten å erstatte det opprinnelige anslaget.

Unngå å forveksle treffsikkerhet med lønnsomhet. Et program som kjøper svært sannsynlige utfall til nesten hele utbetalingen, kan vinne ofte og likevel tjene for lite på vinnerne til å dekke sporadiske tap og kostnader. Omvendt kan en strategi ha mange tapende handler og fortsatt ha gunstig regnestykke under antakelsene sine. Registreringen må vise både utfallsfordelingen og beløpene som ble betalt.

Bygg en kontoarbeidsflyt for en Kalshi-bot

En kontoarbeidsflyt for en Kalshi-bot begynner med en kontooversikt som skiller tilgjengelige ressurser fra forpliktelser. Kontanter, åpne ordrer, eksisterende posisjoner og uoppgjorte resultater henger sammen, men ingen av dem erstatter de andre fullt ut. En ordre som ikke er utført, kan fortsatt ha betydning fordi den kan utføres mens en annen beslutning tas.

Se for deg en konto med 200 dollar allokert til en liten undersøkelsesstrategi. Den eier allerede kontrakter som kostet 24 dollar, og to hvilende ordrer kan kreve ytterligere 18 dollar hvis de matches fullt ut. Et nytt forslag som koster 20 dollar, vurderes ikke bare opp mot de opprinnelige 200. Strategien må ta hensyn til gjeldende forpliktelser og tapskonsentrasjonen den nye eksponeringen skaper.

Kontoregistreringen bør også skille en tiltenkt ordre fra en godtatt ordre og fra en utførelse. Intensjonen finnes lokalt før innsending. Aksept dokumenterer at handelsplassen anerkjente forespørselen. En utførelse er en økonomisk transaksjon. Å behandle det første vellykkede svaret som bevis for at hele den ønskede posisjonen finnes, fører til feil oppfølgingshandlinger.

Delvise utførelser gjør skillet synlig. Hvis ønsket kjøp er 40 kontrakter og 12 utføres, eier kontoen 12, ikke 40. Hvis resten av ordren forblir aktiv, finnes fortsatt mulig eksponering fra ytterligere 28. Programmet bør kunne vise begge fakta uten å slå dem sammen til én misvisende status.

Arbeidsflyten for automatisk handel i prediksjonsmarkeder utvikler denne bredere driftssløyfen. En første Kalshi-implementering kan ha et smalt omfang, men trenger fortsatt en pålitelig sammenheng mellom beslutninger, godtatte forespørsler, utførelser og endelig kontotilstand.

Følg én hypotetisk posisjon gjennom kontoen

Tenk på et illustrerende kjøp av 50 YES-kontrakter til 40 cent hver. Kjøpsbeløpet er 20 dollar. Anta samlede inngangskostnader på 50 cent i øvelsen. Dette er ingen påstand om gjeldende Kalshi-gebyrer. Registrert anskaffelseskostnad er dermed 20 dollar og 50 cent.

Senere selger programmet 20 av kontraktene til 55 cent hver og får antatte salgskostnader på 20 cent. Bruttoinnbetalingen er 11 dollar og nettoinnbetalingen 10 dollar og 80 cent. Med proporsjonal kostnadsfordeling i dette opplæringseksemplet bærer den solgte delen 20/50 av de opprinnelige 20 dollar og 50 cent, eller 8 dollar og 20 cent.

Den realiserte gevinsten på salget er 2 dollar og 60 cent. De gjenværende 30 kontraktene bærer 12 dollar og 30 cent i fordelt anskaffelseskostnad. Deres gjeldende markedsverdi er et separat mål. Den bør ikke legges til realisert fortjeneste som om kontraktene allerede var solgt.

Hvis den gjenværende enkle binære YES-posisjonen gjøres opp til én dollar per kontrakt uten ytterligere antatte kostnader, mottar den 30 dollar. Samlede nettoinnbetalinger fra salg og oppgjør er 40 dollar og 80 cent. Trekker man fra de opprinnelige 20 dollar og 50 cent, blir samlet gevinst 20 dollar og 30 cent.

Hvis YES i stedet gjøres opp til null, er totalresultatet de 10 dollar og 80 cent fra det tidligere salget minus opprinnelig kostnad, et tap på 9 dollar og 70 cent. Å selge en del av posisjonen endret gjenværende risiko. Det garanterte ikke et lønnsomt totalutfall. En kontojournal bør gjøre begge mulige forløp enkle å forstå før hendelsen avgjøres.

Sett risikogrenser for Kalshi-boten i økonomiske størrelser

Risikogrenser for en Kalshi-bot bør beskrive beløp kontoen kan tape, ikke bare antallet forespørsler programmet sender. En grense på ti ordrer sier lite hvis én ordre er mye større enn de andre. Antall kontrakter trenger også kontekst fordi en pris på 15 cent og en pris på 85 cent gir ulike kjøpskostnader for samme enkle binære mengde.

Begynn med en maksimal allokering til strategien og del deretter grensen i mindre kontroller. Et markedstak avgrenser én kontrakt. Et hendelsestak dekker relaterte kontrakter. Et kildetak gjelder flere posisjoner som avhenger av samme publisering eller resultatmyndighet. Disse kontrollene besvarer ulike spørsmål og bør ikke erstattes av én bred saldokontroll.

Korrelasjon kan få tilsynelatende diversifiserte posisjoner til å oppføre seg likt. En strategi kan eie flere kontrakter med ulike titler som alle taper når samme økonomiske tall overrasker i én retning. Å bare se på antallet markeder kan skjule denne felles eksponeringen. Skriv ned noen rimelige hendelsesscenarioer og beregn den samlede virkningen.

Åpne ordrer hører hjemme i scenarioene. Hvis en bot allerede eier 25 kontrakter og har kjøpstilbud på 25 til, gir en kjøpsgrense basert bare på utførte posisjoner rom for utilsiktet for stor mengde. Usikre innsendinger krever også midlertidig kapasitet til utfallene er avklart. Ellers kan en nettverksforsinkelse få de samme pengene til å se tilgjengelige ut to ganger.

En stoppregel bør si hva som skjer etter at en grense nås. Å pause nye innganger, be om kansellering av aktive ordrer og fortsette kontoavstemming er ulike handlinger. Å bare avslutte prosessen kan etterlate ordrer på handelsplassen og fjerne nettopp observatøren som trengs for å oppdage senere utførelser.

Skill testing fra dokumentasjon på et fortrinn

Testing kan vise at et program anvender reglene sine riktig. Den kan ikke alene vise at reglene har et lønnsomt fortrinn. En vellykket test av et kjøp, et delvis salg og en omstart fastslår nyttige tekniske fakta, men validerer ikke prognosen som begrunnet kjøpet.

Begynn med kontrollerte eksempler der forventede resultater er kjent. Gi regnskapssystemet scenarioet med 50 kontrakter ovenfor og kontroller regnestykket. Endre salgsmengden, legg til en utførelse og kontroller at gjenværende beholdning og kostnader endres sammen. Dette er mer opplysende enn å se et instrumentpanel vise en rimelig saldo.

Test deretter tilfeller som bør føre til ingen handel. Gi programmet et gammelt pristilbud, en ukjent kontraktsregel, en mengde over taket eller et kontosvar som ikke kan tolkes. Resultatet bør være en forklart avvisning. En bot som bare demonstrerer vellykkede innganger, har ikke demonstrert at grensene virker.

Registrerte markedsobservasjoner kan deretter støtte en simulert beslutningsstudie. Bevar rekkefølgen informasjonen ble tilgjengelig i. Unngå at senere oppgjørsinformasjon påvirker tidligere beslutninger. Ta med handler som ville blitt avvist eller stått uutført, fremfor å telle hvert attraktivt historisk pristilbud som et fullført kjøp.

Kalshis dokumentasjon for demomiljøet beskriver fiktive midler og påpeker at demoatferd kan avvike fra virkelige markeder. Det gjør miljøet nyttig for tilkoblings- og arbeidsflytøvelser, mens reell gjennomføringskvalitet forblir et separat spørsmål. En gunstig demosaldo bør ikke presenteres som en prognose for virkelige resultater.

Vit hva som krever menneskelig vurdering

Noen grenser håndteres bedre gjennom gjennomgang enn med stadig mer komplisert automatisering. En vesentlig regelendring, et ukjent oppgjørsunntak eller et avvik som ikke forklares av kjente utførelser, kan kreve at en person avgjør om strategien fortsatt gjelder. Programmet bør gjøre gjennomgangen enklere ved å bevare relevant dokumentasjon.

En nyttig gjennomgangspakke inneholder kontraktsidentitet, gjeldende og tidligere godkjente regelbeskrivelser, kontoavviket og de siste handlingene. Den bør utelate hemmeligheter. En operatør som prøver å forstå et problem, trenger beslutningsregistreringer og tidsstempler, ikke en privatnøkkel limt inn i en støttemelding.

Veiledningen om API-er for handel i prediksjonsmarkeder forklarer grensen mellom offentlige observasjoner og autentiserte kontohandlinger. I en første implementering bidrar et smalt skille til å sikre at en feil i datainnsamlingen ikke direkte kan autorisere en større handel.

Menneskelig gjennomgang har også en kapasitetsgrense. En strategi som gir hundrevis av uforklarte varsler daglig, er ikke godt overvåket bare fordi den har en varslingsfunksjon. Velg et markedsutvalg og en handelsfrekvens eieren kan forstå. Gjentatte ignorerte advarsler bør føre til omarbeiding av arbeidsflyten, ikke en lengre varslingsliste.

Før utvidelse bør eieren kunne forklare én fullstendig handel fra opprinnelig prognose til endelig kontoresultat. Forklaringen bør tåle en delvis utførelse, en kansellert rest og et forsinket oppgjør. Evnen til å gjenskape en vanlig posisjon er grunnlaget for å forstå uvanlige hendelser senere.

Hold finansiering adskilt fra handelsresultater

En kontosaldo kan stige uten at strategien tjener noe. Et nytt innskudd er mer finansiering, mens oppgjørsinnbetalinger inkluderer tilbakeføring av penger som opprinnelig ble bundet i en vinnende posisjon. En bot som merker enhver økning som fortjeneste, vil villede eieren selv om hver enkelt ordreregistrering er riktig.

Vedlikehold separate registreringer av eksterne kontantbevegelser og intern handelsaktivitet. Anta at en konto starter med 100 dollar, mottar et innskudd på 50 dollar og slutter med 142 dollar etter at alle posisjoner er lukket. Uten andre justeringer er handelsresultatet et tap på åtte dollar, ikke en gevinst på 42 dollar. Innskuddet endret tilgjengelig kapital, ikke strategiens kvalitet.

Samme skille er viktig ved vurdering av et uttak. Å ta ut penger reduserer kontosaldoen uten nødvendigvis å representere et handelstap. Hold innskudd, uttak, gebyrer, realiserte resultater og uavklarte posisjoner synlige som separate kategorier før et sammendrag lages.

Velg et rapporteringsintervall som passer strategien. En dagsrapport kan vise utestående forpliktelser og kjente kostnader og samtidig erkjenne at noen utfall fortsatt er uavklarte. Den bør ikke tvinge enhver åpen posisjon inn i en endelig gevinst eller et tap bare for å gi et pent dagstall. Ærlig regnskapsføring lar usikkerheten være synlig til relevant dokumentasjon kommer.

Bruk en kort beslutningsregistrering til å vurdere fremdrift

En kortfattet beslutningsregistrering kan gjøre en enkel bot mer nyttig enn et mye mer komplisert system med dårlig dokumentasjon. Bevar kontrakt, observasjonstidspunkt, prognose, tilbudt pris, foreslått mengde, godkjenningsresultat og endelig handling for hver mulighet. Legg til grunnen når reglene avstår fra handel.

Gjennomgå registreringene i grupper. Hvis de fleste avvisningene skyldes uklare regler, trenger opptaksprosessen oppmerksomhet. Hvis godkjente muligheter forsvinner før ordrene kommer, kan gjennomføringstiden være begrensningen. Hvis utførelsene skjer som tiltenkt, men prognosene er gjennomgående optimistiske, er problemet undersøkelseskvalitet. Hvert problem krever sin egen reaksjon.

Skill kontrollerbare feil fra vanlig usikkerhet. En riktig gjennomført tapende kontrakt er ikke nødvendigvis en programvarefeil. Å kjøpe feil kontrakt, overskride en godkjent mengde eller miste dokumentasjonen som trengs for å forklare en saldo, er en driftsfeil selv om handelen tilfeldigvis vinner. Fortjeneste bør ikke viske ut en prosessfeil.

En nyttig første milepæl er derfor beskjeden og konkret: Boten kan forklare hver handling, hver utestående forpliktelse og hvert oppgjorte resultat innenfor det lille mandatet sitt. Utvidelse blir et bevisst valg støttet av dokumentasjon om den eksisterende arbeidsflyten. Hastighet, flere markeder og mer avanserte prognoser kan deretter vurderes opp mot en prosess som allerede er forståelig.

Relaterte veiledninger og gjennomarbeidede eksempler

• Handelsprogramvare for Kalshi: gjør beslutninger etterprøvbare — Definer programvarekrav for bevarte data, oppgraderinger og hendelsesundersøkelser.
• Beste handelsbot for Kalshi: sammenlign dokumentasjonen — Sammenlign verktøy for hendelseskontrakter med demonstrert atferd og tydelige avveininger.