For å utføre Kalshi-handler automatisk trenger et program mer enn et signal og tillatelse til å sende forespørsler. Det trenger regler for utførelse som angir hvilken kontrakt som skal handles, hvor stor eksponering som tillates, hvilke priser som er akseptable, og hva som skal gjøres når kontoutfallet avviker fra den opprinnelige planen.
Utførelseskvalitet handler delvis om å oppnå en akseptabel pris, men også om å vite hva som skjedde. En rimelig utførelse kan fortsatt være driftsmessig problematisk hvis boten dupliserer den etter et tidsavbrudd eller overser en aktiv restordre.
Denne veiledningen følger en godkjent beslutning om en hendelseskontrakt i et prediksjonsmarked gjennom kontroller, innsending og rekonstruksjon. Den gjelder ikke andre produkttyper hos Kalshi. Talleksemplene er illustrerende, og API-ets gjeldende virkemåte bør alltid kontrolleres mot den relevante offisielle referansen.
Definer instruksjonen før Kalshi-handler utføres automatisk
Instruksjonen bør uttrykke en økonomisk hensikt uavhengig av et bestemt forespørselsformat. Identifiser kontrakten, ønsket retning, maksimal tilleggsmengde, prisgrense og grunnen til at handlingen fortsatt er gyldig. Oppgi også når autorisasjonen utløper.
En retningsbetegnelse som kjøp er ufullstendig uten et utfall og en kontokontekst. Implementasjonen må oversette den tiltenkte eksponeringen til plattformens gjeldende representasjon og deretter kontrollere at den oversatte handlingen får den tiltenkte økonomiske virkningen.
Maksimal tilleggsmengde er forskjellig fra en ønsket sluttposisjon. Hvis kontoen allerede eier ti kontrakter og målet er 80, vil et kjøp av ytterligere 80 overskride målet. En målbasert instruksjon må trekke fra bekreftede beholdninger og ta hensyn til relevante aktive ordre.
Behold beslutningens identitet selv om systemet gjør flere tekniske forsøk på å gjennomføre den. Nye forsøk, endringer og kanselleringsforsøk bør fortsatt kunne spores tilbake til den økonomiske autorisasjonen som begrunnet dem.
Veiledningen om algoritmisk handel i prediksjonsmarkeder skiller strategiregler fra implementasjon. En utførelsesinstruksjon er broen mellom dem: konkret nok til å begrense en handling, men tydelig nok til at en kontrollør forstår den uten å dekode en nettverksmelding.
Kontroller markedsstatus før automatisk utførelse
Utfør Kalshi-handler automatisk med markedsstatuskontroller som skiller den valgte kontrakten fra børsen som helhet. En fungerende forbindelse beviser ikke at det konkrete markedet for tiden godtar den tiltenkte handlingen.
Kontroller markedets gjeldende handelstilstand, relevante stengetid og ethvert forhold som gjør strategiens autorisasjon ugyldig. En kontrakt kan fortsatt gjenkjennes og leses etter at den normale handelsmuligheten er over. At kontrakten blir funnet, er ikke i seg selv tillatelse til å sende en ordre.
Børsen som helhet kan også pålegge begrensninger. Kalshis dokumentasjon om vedlikehold og pauser skiller mellom ulike avbruddstilstander. Utførelseslogikken bør følge funksjonene som faktisk er tilgjengelige i den relevante tilstanden, fremfor å bruke ett udifferensiert tilkoblingsflagg.
Kontrollen er en fersk observasjon, ikke en lås på fremtidig atferd. Markedstilstanden kan endres mellom validering og innsending. Utfallet av forespørselen må derfor tolkes selv om de foregående kontrollene ble bestått.
Lagre grunnen når et forslag avvises lokalt. Foreldet informasjon, et stengt marked og utilstrekkelige ressurser krever ulike oppfølgingshandlinger. En tydelig avvisningsregistrering hjelper eieren med å forstå hvorfor automatiseringen ikke handlet, uten å oppmuntre til blinde gjentakelser mot et utilgjengelig marked.
Bruk prisgrenser ved automatisk utførelse
Utfør Kalshi-handler automatisk med prisgrenser som beskriver høyeste akseptable kjøpspris eller laveste akseptable salgspris for den tiltenkte eksponeringen. En prisgrense beskytter én dimensjon ved forespørselen; den garanterer verken utførelse eller et gunstig resultat.
Bruk priser som er tilgjengelige for den ønskede transaksjonen. Det høyeste kjøpsbudet er et tilbud om å kjøpe, ikke automatisk en pris en annen kjøper kan anskaffe samme utfall til. En midtpris er en nyttig oppsummering i enkelte analyser, men kan ikke nødvendigvis handles til.
Tenk på en hypotetisk kjøpsinstruksjon for opptil 80 kontrakter med maksimalpris på 43 cent. De synlige salgstilbudene omfatter 25 til 41 cent, 35 til 42 cent og ytterligere 20 til 44 cent. Bare de første 60 oppfyller prisgrensen.
Samlet kjøpsbeløp ville vært 10 dollar og 25 cent pluss 14 dollar og 70 cent, altså 24 dollar og 95 cent før kostnader. De resterende 20 er ikke akseptable bare fordi strategien opprinnelig ønsket 80.
Strategiveiledningen for prediksjonsmarkeder forklarer hvorfor verdi avhenger av pris og kostnader. Utførelseslaget bevarer denne vurderingen ved å nekte å tøye den godkjente grensen bare for å kunne rapportere en fullført mengde.
Velg hva en uutført rest skal gjøre
Ordrens gyldighetsregler avgjør om uutført mengde kan forbli aktiv eller skal opphøre under den valgte utførelsesbetingelsen. Denne avgjørelsen hører hjemme i reglene før innsending, fordi den endrer hvor lenge kontoen er eksponert for fremtidige utførelser.
En hvilende ordre kan vente på likviditet, men kan bli utført etter at den opprinnelige informasjonen er blitt mindre nyttig. Regler om umiddelbar utførelse kan unngå en langvarig restordre og samtidig akseptere at bare deler av, eller ingenting av, den ønskede mengden anskaffes.
En alt-eller-ingenting-betingelse har et annet formål: Den kan kreve at hele den forespurte mengden er tilgjengelig etter ordrens regler. Den lover ikke at betingelsen blir oppfylt, og gjør ikke en senere uavhengig ordre til del av samme transaksjon.
Les alternativene som støttes nå, i referansen for opprettelse av hendelsesordre. Kjente betegnelser fra en annen børs eller en eldre klient bør ikke settes inn uten at den nøyaktige betydningen og gyldige kombinasjoner er kontrollert.
Forskjellen har betydning i eksemplet med 80 kontrakter. Ett regelsett kan ende med 60 utførte og ingen aktiv rest, mens et annet kan la 20 stå klare til senere utførelse. Begge kan overholde prisgrensen på 43 cent, men de skaper ulike løpende forpliktelser.
Reserver ressurser til hele den autoriserte forespørselen
Før innsending må du ta hensyn til ressursene forespørselen kan bruke dersom den utføres fullt ut innenfor grensene. Å telle bare de billigste synlige kontraktene kan undervurdere forpliktelsen en aktiv ordre har tillatelse til å skape senere.
I det illustrerende eksemplet med en forespørsel om 80 kontrakter og et tak på 43 cent er maksimalt kjøpsbeløp 34 dollar og 40 cent før utgifter. En antatt utgiftsreserve på 60 cent ville øke regelsettets reserverte beløp til 35 dollar. Dette er pedagogiske forutsetninger, ikke gjeldende gebyrvilkår.
Den synlige muligheten med 60 kontrakter kan koste mindre, men en gjenværende ordre kan fortsatt ha betydning. Ressurser som er reservert for denne muligheten, bør ikke samtidig autorisere en annen strategi til å bruke samme beløp.
Skill tilgjengelige kontoressurser fra en lokal prognose for tilgjengelighet. En annen ordre, manuell handling eller kontooppdatering kan endre hva som fortsatt kan brukes. Reservasjonslogikken bør kombinere bekreftet kontodokumentasjon med programmets utestående forpliktelser.
En avvist forespørsel bør frigjøre den lokale reservasjonen først når utfallet er tilstrekkelig forstått. Et usikkert tidsavbrudd kan fortsatt representere en akseptert ordre. Hvis hele budsjettet straks legges tilbake i den tilgjengelige potten, kan neste instruksjon derfor binde mer enn kontoen har dekning for.
Kontroller om aktive ordre er i konflikt
En konto kan inneholde flere strategier eller manuelle ordre i samme kontrakt. En ny forespørsel bør vurderes mot disse eksisterende forpliktelsene fremfor som om den var den eneste aktiviteten på plattformen.
Motstående ordre kan føre til utilsiktet handel mellom egne ordre eller bruke kapasitet på måter strategien ikke forventet. Ordre i samme retning kan bygge opp eksponering utover en tilsynelatende grense per ordre. Det relevante spørsmålet er hva kontoen kan eie etter at alle tillatte ordre har fått virke.
Bruk plattformens støttede kontroller for å hindre handel med seg selv der det passer, men ikke behandle dem som en erstatning for samordning. En plattformkontroll kan endre utførelsesatferden uten å avgjøre hvilken av to strategier som skal disponere det tilgjengelige risikobudsjettet.
Eieren bør definere om strategier kan konkurrere om samme kontrakt, dele en sentral fordelingsmekanisme eller kreve enerett til kontrollen. Dette styringsvalget påvirker hvordan utførelseslaget godkjenner en ny instruksjon og løser konflikter.
En nyttig gjennomgangsregistrering identifiserer de aktive ordrene som ble vurdert da forespørselen ble godkjent. Hvis kontoen senere overstiger forventet eksponering, hjelper denne dokumentasjonen med å skille en foreldet observasjon fra en fordelingsregel som aldri tok hensyn til de samlede forpliktelsene.
Send en identifisert hensikt fremfor et anonymt forsøk
Lagre den godkjente hensikten varig før forespørselen sendes. Identifikatoren bør knytte sammen beslutningen, den tekniske forespørselen og eventuell dokumentasjon av ordren som oppstår. Ellers kan et prosessavbrudd etterlate en aktiv ordre uten en varig forklaring på hvorfor den finnes.
Bruk den dokumenterte mekanismen for klientordreidentitet konsekvent. Den nøyaktige virkemåten må hentes fra API-et, og bør ikke beskrives som en universell garanti for at vilkårlig gjentatte forespørsler aldri kan skape duplisert økonomisk aktivitet.
En beslutning om nytt forsøk må skille et forsøk som sikkert mislyktes ved validering, fra et med ukjent resultat. Det første kan tillate en korrigert forespørsel under samme økonomiske regler. Det andre krever avstemming før en ny handling autoriseres.
Registrer nok kontekst til å rekonstruere forsøket, inkludert kontoomfang, kontrakt, tiltenkt mengde og prisgrense. Sensitive tilgangsopplysninger hører ikke hjemme i ordinære aktivitetslogger selv når diagnostikk av forespørsler er nyttig.
Veiledningen om API-er for boter i prediksjonsmarkeder beskriver hvordan et klientgrensesnitt kan bevare disse betydningene. Det viktige resultatet er en varig kobling fra eierens autorisasjon til hvert forsøk som gjøres på eierens vegne.
Tolk svaret uten å utvide betydningen
Et vellykket svar er dokumentasjon om forespørselen i tråd med endepunktets dokumenterte struktur. Det bør ikke opphøyes til en påstand om at hele den ønskede posisjonen er anskaffet, med mindre de rapporterte faktaene dokumenterer dette resultatet.
Gjeldende svarfelt kan omfatte identifikatorer, utførte mengder og en restmengde uten å returnere alle detaljene som trengs til kontoregnskapet. Klienten bør beholde svaret og hente den ytterligere dokumentasjonen som trengs for å forklare ordrens senere tilstand.
En umiddelbar avvisning bør bevare årsaken. En feilformatert forespørsel, et ressursproblem og et utilgjengelig marked er ulike feil. Å sende en uendret forespørsel gjentatte ganger kan sløse med kapasitet og gjøre problemet mindre tydelig uten å øke sjansen for et gyldig resultat.
En transportfeil er igjen noe annet. Boten vet kanskje ikke om plattformen behandlet forespørselen. Den interne tilstanden bør være ukjent fremfor avvist eller utført til ytterligere dokumentasjon avklarer tvetydigheten.
Reglene for utførelse bør definere hvilke fakta i svaret som tillater hver neste handling. Dette hindrer en generell håndterer for vellykkede svar i å frigjøre budsjett, starte en ny ordre eller erklære strategien fullført før de faktiske kontofølgene er kjent.
Avstem utførelsene ved automatisk Kalshi-handel
Utfør Kalshi-handler automatisk med avstemming av utførelser som kan rekonstruere hva som faktisk ble handlet. Hver unik utførelse bidrar med mengde og kontantvirkninger, mens ordreoppsummeringer gir ytterligere dokumentasjon om samlet utførelse og gjenværende forpliktelser.
Ikke legg sammen gjentatte kumulative totaler som om de var nye utførelser. Hvis én observasjon viser 25 utførte og en senere viser 60, er totalen 60, ikke 85. Inkrementelle hendelser og kumulative øyeblikksbilder trenger ulike oppdateringsregler.
Fjern duplikater av inkrementelle hendelser ved hjelp av de dokumenterte identitetene, og bevar koblingene til ordrene. En ny tilkobling kan levere informasjon som allerede er sett. Å behandle den to ganger ville skape en falsk posisjon og forvrenge det tilsynelatende kontantresultatet.
I det løpende eksemplet gir 25 kontrakter til 41 cent og 35 til 42 cent totalt 60 anskaffede kontrakter med en gjennomsnittspris på omtrent 41,58 cent før utgifter. Antatte faktiske utgifter på 30 cent øker totalkostnaden til 25 dollar og 25 cent.
Hvis kontoen startet med ti kontrakter i samme retning og ingen annen aktivitet fant sted, eier den nå 70. Dette posisjonsresultatet er forskjellig fra både de forespurte 80 tilleggskontraktene og de 60 kontraktene som ble utført gjennom akkurat denne instruksjonen.
Bruk tidsstempler til å forklare tilsynelatende motstrid
Et ordresvar, en strøm av utførelser og et kontoøyeblikksbilde kan beskrive ulike tidspunkter. Et avvik betyr ikke automatisk at én kilde er feil, men bør heller ikke ignoreres bare fordi konsistens over tid er forventet.
Behold tidsstemplene og omfanget for hver observasjon. Et saldoøyeblikksbilde fra før en ny utførelse kan ikke motbevise utførelsen. En senere kumulativ ordreregistrering kan omfatte aktivitet som den lokale strømmen ennå ikke har levert.
Kalshi dokumenterer et endepunkt for tidsstempler på brukerdata som bidrar til å identifisere hvor ferske bestemte kontodata er. Slik dokumentasjon kan hjelpe avstemmingen, men gjør ikke hvert separat hentede svar til ett atomisk kontoøyeblikksbilde.
Velg en uttrykkelig gjenopprettingsmetode for hull. Programmet kan trenge gjeldende ordretilstand, relevante utførelser og en ny avlesning av posisjonen, med nødvendig håndtering av sideinndeling eller historisk omfang. Én tom side bør ikke automatisk fastslå at historikken er tom.
La uavklarte forskjeller forbli synlige, og begrens avhengige handlinger ved behov. Målet er en forklarlig kontotilstand, ikke en visning som alltid tvinger de nyeste observasjonene til å samsvare ved å forkaste ubeleilig dokumentasjon.
En bredere veiledning om automatisering av Kalshi-hendelseskontrakter skiller også kontoobservasjonstidspunkter fra publiseringsplaner, handelsslutt og milepæler for avgjørelse av utfallet.
Kanseller en rest uten å slette utførelsene
En kanselleringsforespørsel gjelder den uutførte delen av en ordre når kanselleringen trer i kraft. Den reverserer ikke en transaksjon som allerede er fullført, og restmengden kan endres mens forespørselen er underveis.
Anta at eksempelordren har 60 utførte og 20 fortsatt aktive når kansellering forespørres. Hvis fem til blir utført før kanselleringen lykkes, kan sluttresultatet være 65 utførte og 15 kansellerte. Kontoen må bevare de fem ekstra utførelsene.
Posisjonen ville da være 75 kontrakter dersom den startet med ti og ingen annen aktivitet fant sted. En rapport som beholdt den tidligere posisjonen på 70 kontrakter, ville undervurdere eksponeringen selv om selve kanselleringen lyktes.
Hvis kanselleringen ikke kan bekreftes, behold den mulige resten i risikoregistreringen. At en lokal knapp går fra aktiv til stoppet, dokumenterer ikke at plattformen fjernet ordren. Grensesnittet bør skille den forespurte handlingen fra det bekreftede resultatet.
Etter en bekreftet kansellering må den endelige utførte mengden og enhver gjenværende kontoforpliktelse avstemmes. Dette avslutter ordrens livsløp og bevarer samtidig posisjonens livsløp, som kan fortsette til et senere salg eller oppgjør.
Kontroller på nytt før en ordre erstattes eller forbedres
En uutført ordre kan friste programmet til å jage markedet ved stadig å forbedre prisen. Denne atferden endrer økonomien i den opprinnelige beslutningen og bør kreve uttrykkelige regler fremfor å oppstå i en løkke for nye forsøk.
Vurder prognosen, gjeldende markedsinformasjon, restmengden og kontoeksponeringen på nytt før enhver erstatning. En pris som var akseptabel tidligere, kan være lite attraktiv etter ny informasjon selv om den endelig ville gitt en utførelse.
Mengdeendringer trenger også presis betydning. En endring kan beskrive en revidert grense for samlet utført mengde, mens en reduksjonsoperasjon kan beskrive den aktive resten. Klienten bør bruke definisjonen til den gjeldende operasjonen fremfor et generelt størrelsesfelt som deles av alle handlinger.
En kanseller-og-erstatt-sekvens kan innebære en periode der utfallet av den gamle ordren er usikkert. Hvis erstatningen sendes før denne usikkerheten er løst, kan begge bidra med utførelser. Reglene må ta hensyn til den samlede mulige eksponeringen.
Registrer grunnen til hver økonomisk endring. En erstatning som skyldes en ny prognose, er forskjellig fra en som skyldes utålmodighet med en uutført ordre. Dette skillet hjelper med å identifisere om den observerte handelsatferden faktisk følger den godkjente strategien.
Bevar kunnskap om ordre gjennom pause og omstart
En lokal omstart bør ikke nullstille den økonomiske verdenen. Ordre som plattformen allerede har akseptert, og posisjoner som allerede eies, kan overleve prosessen som opprettet dem. Gjenoppretting starter med å rekonstruere disse forpliktelsene.
Last inn uavklarte hensiktsregistreringer, undersøk gjeldende kontodokumentasjon og identifiser eventuelle hull før nye innsendinger aktiveres. En tom liste i minnet er bare dokumentasjon på at prosessen nettopp har startet, ikke på at kontoen mangler aktive ordre.
En markedspause krever lignende disiplin. Fastslå hva som fortsatt eies, hvilke ordrevirkninger som er kjent, og hvilke handlinger som er tilgjengelige nå. Når aktiviteten gjenopptas, vurder det opprinnelige signalet på nytt fremfor automatisk å gjenta alle tidligere utsatte forespørsler.
Veiledningen om automatisert handel i prediksjonsmarkeder behandler observasjon og gjenoppretting som løpende ansvar. Utførelseskontroll har nytte av samme tilnærming: Boten bør fortsatt kunne forklare forpliktelsene sine selv når den ikke får opprette nye.
Å gjenopprette forbindelsen kan være et nødvendig gjenopprettingstrinn, men er ikke tilstrekkelig autorisasjon til å handle. Kontoregistreringen, gjeldende markedsforhold og reglene for utførelse må samsvare før en ny instruksjon kan fortsette.
Vurder utførelsen uten å belønne uønskede handler
En gjennomgang av utførelsen bør spørre om boten fulgte de godkjente grensene og rapporterte resultatet nøyaktig. En høy utførelsesandel alene kan belønne atferd som betaler for mye, venter for lenge eller bygger opp mer eksponering enn planlagt.
Sammenlign faktisk mengde og gjennomsnittlig kjøpsbeløp med de tillatte prisene som var tilgjengelige på beslutningstidspunktet, og anerkjenn begrensningene ved å rekonstruere historiske ordrebøker. Et vist pristilbud beviser ikke at samme likviditet ville forblitt tilgjengelig for enhver hypotetisk ordre.
Mål uavklarte forespørsler, foreldede observasjoner, kappløp ved kansellering og håndtering av dupliserte hendelser sammen med prisutfallene. Disse driftsfaktaene kan forklare hvorfor en strategis rapporterte posisjon avvek fra den tiltenkte selv når selve prognosen var rimelig.
Gjennomgå beslutninger som med rette ikke førte til handel. Å avvise et utløpt signal eller en ordre utenfor prisgrensen kan være vellykket utførelseskontroll. Å behandle all inaktivitet som feil presser systemet til å overstyre sine egne begrensninger.
Evnen til å utføre Kalshi-handler automatisk vises derfor best gjennom en fullstendig forklaring: hva som ble autorisert, hva som ble forsøkt, hva som ble utført, hva som gjensto, og hvordan den endelige kontotilstanden ble bekreftet. Denne forklaringen gjør automatiseringen mulig å vurdere uten å forveksle rask innsending med et kontrollert økonomisk resultat.
Relaterte veiledninger og regneeksempler
- Automatisert bot for Kalshi-prediksjonsmarkeder: Tydelige krav — Koble adgangskontroller til hele den automatiserte arbeidsflyten for prediksjoner.
- Automatisert Kalshi-handel: Gjennomfør den daglige syklusen — Koble markedsdata, daglig drift, ordreregistreringer og endelig oppgjør.