En Polymarket-API-bot trenger et tydelig svar på et vanskelig driftsspørsmål: Hva bør den gjøre når den sendte en ordre, men aldri mottok et brukbart svar? Ordren kan ha blitt avslått, akseptert, delvis utført eller fullført. Et lokalt tidsavbrudd skiller ikke mellom mulighetene.
Å utforme for usikkerheten endrer arkitekturen. Boten trenger varige registreringer før overføring, avgrenset fullmakt over ny eksponering og en gjenopprettingsprosess som undersøker opprinnelig hensikt. Den må også fortsette å observere kontoen når den har sluttet å opprette nye ordrer. Å sette beslutninger på pause og å miste innsyn er forskjellige handlinger.
Denne veiledningen beskriver et opplæringsdesign for den internasjonale Polymarket-konteksten. Polymarket US har separate konto- og handelsplassgrensesnitt. Alle grenser, mengder, priser og feilscenarioer her er oppdiktede eksempler. Designet fastslår ikke at en handelsstrategi har en fordel, og godkjenner ingen reell kontohandling.
Definer en avgrenset Polymarket-API-bot
En avgrenset Polymarket-API-bot har uttrykkelige tillatelsesgrenser: hvilken konto den kan bruke, hvilke kontrakter den kan vurdere, hvilke ordretyper den kan opprette, og hvor mye eksponering den kan tilføre. Grensene bør kunne håndheves utenfor prognosekomponenten, slik at et feilaktig signal ikke bare kan erklære seg unntatt.
En oppdiktet bot kan observere alle markeder i en forskningsliste, men bare foreslå ordrer for to godkjente kontrakter. Den kan ha en grense på tretti andeler per hendelse og en separat maksimal kjøpsforpliktelse. Bred observasjon innebærer ikke tilsvarende handelsfullmakt.
Den eldre veiledningen om Polymarkets bot-API forklarer evner og feilmodi. Bruk skillet i botdesignet: datatilgang, ordreopprettelse, kansellering og lommebokoperasjoner er separate evner. En funksjon hører hjemme i programmet bare når formål og autorisasjonsgrense er tydelige.
Skill prognosen fra utføreren
Prognosekomponenten bør produsere et forslag med kontrakt, retning, ønsket mengde, maksimalkostnad og utløp for resonnementet. Den bør ikke direkte ha ubegrenset signeringsfullmakt. En separat beslutningskontroll kan kontrollere forslaget mot gjeldende kontotilstand og driftsgrenser.
Skillet er nyttig selv når én person driver hele systemet. Det gjør programatferden mulig å undersøke: forslaget forklarer hvorfor en handel ble vurdert, mens kontrollen forklarer om den var tillatt. Et avslått forslag forblir i forskningsregistreringen uten å opprette en ordre.
Utføreren bør bare akseptere en fullt angitt, godkjent instruks. Den bør ikke improvisere større mengde eller videre prisgrense fordi første forsøk ikke ble utført. Endringene endrer den økonomiske beslutningen og krever ny validering mot kontoen og strategiens gjeldende dokumentasjon.
Bevar én økonomisk hensikt gjennom flere forsøk
En økonomisk hensikt beskriver ønsket kontoendring, mens et transportforsøk beskriver ett forsøk på å kommunisere en instruks. Sammenblanding er en vanlig kilde til duplisering. Et tidsavbrudd fulgt av en ny forespørsel bør ikke automatisk bli et andre uavhengig ønske om å kjøpe samme mengde.
Gi hensikten en stabil lokal identifikator og registrer godkjente vilkår. Knytt hver forespørsel, hvert svar, hver ordreidentifikator og hver handelsobservasjon til hensikten når forholdet er kjent. Hvis en senere instruks erstatter den, registreres forholdet uttrykkelig fremfor å overskrive gammel historikk.
Veiledningen om API-handel på Kalshi gir en sammenligning av kontoavstemming i en annen API-kontekst. Det generelle skillet mellom hensikt og forsøk kan overføres, men tilgjengelige mekanismer for oppslag og duplikathåndtering er forskjellige. En bot må kontrollere faktisk handelsplasssemantikk fremfor å anta en universell idempotensfunksjon.
Skriv den varige hensiktsjournalen først
Den varige hensiktsjournalen må finnes før en handling kan nå handelsplassen. Ellers kan et krasj etter overføring etterlate en aktiv ordre uten lokal forklaring. Varig lagring etter at et svar er mottatt, er for sent for akkurat dette feilvinduet.
Registrer konto, kontrakt, side, mengde, prisgrense, levetid, strategiversjon, godkjenningsresultat og reservasjon. Legg til forespørselsidentiteten eller referansen til signert ordre som trengs for gjenoppretting, uten å avsløre hemmeligheter i vanlige logger. Journalen bør støtte lesing av historikken etter omstart.
En journalregistrering beviser ikke at en ordre ble sendt. Bevar separate trinn for klargjort, overføring startet og svar observert. Trinnene hjelper til med å snevre inn usikkerheten, men kan ikke fjerne all tvetydighet rundt en nettverksgrense. Den ærlige gjenopprettingstilstanden kan fortsatt være ukjent til kontodokumentasjon hentes.
Reserver kapasitet atomisk
To forslag kan komme tett på hverandre og begge se samme tilsynelatende tilgjengelige budsjett. Hvis hvert godkjennes uavhengig før noen reservasjon er registrert, kan samlet eksponering overstige grensen. Kontokontrollen trenger én konsekvent operasjon som kontrollerer og reserverer kapasitet.
Anta en oppdiktet hendelsesgrense på tretti andeler. Kontoen holder tolv, og en eksisterende aktiv ordre kan tilføre åtte. Bare ti ytterligere andeler passer grensen. Hvis to nye forslag hver ber om ti og begge leser samme gamle øyeblikksbilde, ville godkjenning av begge tillate førti andeler totalt.
En delt reservasjonsregistrering hindrer kappløpet. Det andre forslaget må se første reservasjon eller vente til utfallet er fastslått. Separate arbeidsprosesser, strategier eller brukergrensesnitt skaper ikke separat økonomisk kapasitet når de bruker samme konto og hendelsesgrense.
Bevar reservasjoner under usikkerhet
En ukjent innsending kan fortsatt bli eksponering. Å frigjøre reservasjonen bare fordi lokal forespørsel fikk tidsavbrudd, lar et annet forslag bruke samme kapasitet. Bevar en konservativ forpliktelse til opprinnelig hensikt er avklart eller en dokumentert regel fastslår et trygt alternativ.
I eksemplet med tretti andeler bruker en usikker innsending på ti andeler opp gjenværende kapasitet for nye innganger. Boten kan fortsette å lese markedsdata, avstemme kontoen og behandle risikoreduserende handlinger reglene tillater. Den bør ikke behandle ukjent mengde som null bare for å forbli aktiv.
Atferden bør være synlig for operatøren. En tydelig status som «ti andeler reservert i påvente av innsendingsavstemming» forklarer hvorfor nye forslag er satt på pause. Uten forklaringen kan en operatør starte boten på nytt eller fjerne reservasjonen og utilsiktet sette kontrollen som beskyttet kontoen, ut av spill.
Bruk gjeldende konto- og lommebokoppsett
Boten må kontrollere gjeldende signatar, kontolommebok, tillatelser og handelsgodkjenninger før den kan utføre. Gamle eksempler kan anta en annen lommebokordning eller et annet klientgrensesnitt. Vellykket offentlig datatilgang validerer ikke den private handelsveien.
Polymarkets dokumentasjon for lommebøker og autentisering er gjeldende referanse for kontospesifikt oppsett. Hold hemmelig materiale i det autoriserte signeringsmiljøet, separat fra vanlige applikasjonslogger og forskningsregistreringer. Gjenoppretting bør bygge på identifikatorer og kontodokumentasjon, ikke på å avsløre tilgangsopplysninger for å feilsøke en mislykket forespørsel.
Lagre klientversjon og konfigurasjon sammen med driftsregistreringer. Hvis en oppgradering endrer forespørselskonstruksjon eller svartolkning, bør boten bestå relevante gjenopprettingstilfeller før fullmakt gjenopptas. Kompatibilitet er atferd som skal kontrolleres, ikke en egenskap som følger av et kjent pakkenavn.
Diagnostiser hvor feilen skjedde
En mislykket arbeidsflyt kan stoppe før godkjenning, før overføring, etter overføring eller under avstemming. Stedene har forskjellige følger. Et lokalt avslått forslag oppretter ingen ordre. En forespørsel der overføring aldri startet, kan trygt forsøkes på nytt under samme hensikt. En forespørsel med ukjent eksternt resultat trenger undersøkelse.
Registrer nok tids- og tilstandsinformasjon til å skille tilfellene uten å late som om dokumentasjonen støtter mer enn den gjør. Driftsloggen kan si at klienten begynte å sende på et bestemt tidspunkt og så mistet forbindelsen. Den kan ikke konkludere med at handelsplassen aldri mottok bytene bare ut fra lokal feil.
Bruk feilkategorier som leder til bestemte handlinger. Autentiseringsfeil utløser gjennomgang av legitimasjon eller konto. Ugyldige prisintervaller utløser gjennomgang av markedsbegrensninger. Ukjent innsending utløser kontoavstemming. En generisk håndterer som prøver alt på nytt, ignorerer forskjellen mellom å rette en forespørsel og utilsiktet duplisere en gyldig.
Undersøk gjennom ordre- og handelsdokumentasjon
Gjenoppretting etter ukjent innsending bør lete etter dokumentasjon knyttet til opprinnelig hensikt med identifikatorene og grensesnittene handelsplassen støtter. Gjeldende åpne ordrer, individuelle ordreregistreringer og kontohandler kan besvare ulike deler av spørsmålet. Et manglende element i én liste er ikke alltid nok bevis for at ingen gjennomføring skjedde.
Polymarkets veiledning om ordreforvaltning beskriver autentiserte lesinger for å spore ordrer og kontohandler. Boten bør kombinere relevant dokumentasjon med den varige journalen. Den bør også bevare spørretid og eventuelle dekningsbegrensninger, som ufullstendig sideinndeling eller en frakoblet strøm.
Når tilstanden er fastslått, oppdateres reservasjon og posisjonsregistrering sammen. En aktiv ordre beholder passende forpliktelse. Et bekreftet avslag kan frigjøre den. En utførelse endrer beholdninger og kostnader. Hvis dokumentasjonen fortsatt er motstridende, holdes usikkerheten uttrykkelig og saken sendes til ansvarlig operatør.
Henvis og tjen USDC
Henvis og tjen USDCPartnerprogrammet vårt betaler i sanntid.
Ikke utled avslag fra en tom liste over åpne ordrer
En ordre som ble fullt utført, finnes kanskje ikke lenger blant åpne ordrer. En umiddelbar ordre der uutført mengde ble kansellert, kan også etterlate ingen hvilende oppføring. Å bare se på listen over åpne ordrer kan derfor feilklassifisere en fullført eller delvis gjennomføring som en forespørsel som aldri eksisterte.
Boten må undersøke andre relevante registreringer før den avgjør at opprinnelig hensikt ikke hadde noen virkning. Dette er særlig viktig når en forespørsel kunne matches ved innsending. At en aktiv rest forsvinner, innebærer ikke fravær av anskaffede andeler.
En nyttig operatørvisning skiller tre spørsmål: om en ordre fortsatt er aktiv, om noen handler fant sted, og om resulterende kontoendringer er avstemt. Å holde spørsmålene adskilt hindrer at et visuelt tomt ordrepanel behandles som bevis for at kontoen er uten posisjon.
Avstem umiddelbare delvise utførelser riktig
Ordretype avgjør skjebnen til uutført mengde. Gjeldende Polymarket-dokumentasjon definerer FAK som utførelse av tilgjengelig mengde og kansellering av resten. En delvis FAK-gjennomføring etterlater en posisjon, men ikke gjenværende etterspurte andeler hvilende i ordreboken.
I et oppdiktet tilfelle gir en FAK-forespørsel på ti andeler fire utførte andeler til $0,43 og seks kansellerte. Kjøpsprisen er $1,72 før gebyrer. Etter at utførelsen og reststatusen er fastslått, bør boten registrere fire andeler og frigjøre reservasjonen knyttet til de andre seks, betinget av faktisk kontodokumentasjon.
En hvilende ordre på ti andeler med fire utførte og seks aktive er forskjellig. Den beholder mulig fremtidig eksponering. Botens tilstandsmodell bør ikke bruke én generisk delvis-status som erstatning for både utført mengde og restens endelige eller fortsatte tilstand.
Håndter kanselleringskappløpet
En kanselleringsforespørsel kan overlappe med en utførelse. Boten bør forvente å avstemme begge fremfor å anta at kanselleringshensikten umiddelbart fjernet eksponering. En vellykket kansellering kan gjelde gjenværende mengde etter at mer gjennomføring allerede har skjedd.
Anta at seks andeler virker aktive når kansellering begynner, og ytterligere to utføres før resten fjernes. Boten må legge de to til posisjonen og frigjøre bare forpliktelsen som faktisk endte. Et erstatningsforslag bør bruke resulterende kontotilstand, ikke mengden synlig før kappløpet.
Den eldre veiledningen om en automatisk handelsbot for Polymarket drøfter pause- og omstartsatferd. Kansellering er én del av prosessen, ikke en universell nullstilling. Å stoppe nye beslutninger, trekke tilbake kansellerbare ordrer og avstemme eksisterende posisjoner er separate ansvar som kan fullføres på ulike tidspunkter.
Bruk én autoritativ innsendingsvei
Flere arbeidsprosesser kan hjelpe med datainnsamling eller evaluering av uavhengige hypoteser, men ordreinnsending trenger samordnet fullmakt. Hvis to utførere kan handle på samme hensikt uten en delt mekanisme for å kreve ansvar, kan begge overføre den etter en omstart eller forsinket melding.
Velg en tydelig ansvarsregel for aktiv utfører og gjør ansvarsendringer synlige. En ny arbeidsprosess bør ikke anta at en eldre har stoppet bare fordi en livstegnsmelding er sen. Den trenger en mekanisme som hindrer begge i å bruke samme fullmakt samtidig, eller regler som setter pause til ansvaret er fastslått.
Poenget er ikke å tilføre kompleksitet for dens egen skyld. En bot med én prosess kan bruke et enkelt design så lenge omstartsatferden er uttrykkelig. Når systemet vokser, bevares samme økonomiske garanti: én godkjent hensikt må ikke bli flere uavhengige ordrer fordi flere komponenter tror de har ansvar for å fullføre den.
Bygg tilstanden på nytt før fortsettelse etter omstart
En omstart bør begynne med observasjon og avstemming. Last uavklarte hensikter, undersøk gjeldende ordrer og handler, kontroller kontoidentitet og sammenlign gjenopprettede beholdninger med lokal registrering. Ny eksponering bør vente til relevante avvik er avklart eller uttrykkelig håndtert etter driftsreglene.
Ikke spill av hver uferdig journalregistrering som en ny ordre. Noen uferdige registreringer kan tilsvare eksterne utførelser der svarene gikk tapt. Andre kan aldri ha forlatt prosessen. Gjenopprettingsveien må klassifisere dem med dokumentasjon fremfor å behandle et manglende lokalt fullføringsflagg som tillatelse til å overføre igjen.
Veiledningen om en Kalshi-API-bot beskriver akseptansetilfeller for en annen handelsplass. Bruk sammenligningen til å skjerpe gjenopprettingsspørsmålene og hold samtidig handelsplasspesifikke identifikatorer og forespørselsatferd adskilt. Samme feilscenario kan kreve forskjellige oppslag i ulike grensesnitt.
Hold observasjon aktiv mens beslutninger er satt på pause
En bot som setter nye innganger på pause, bør vanligvis fortsette leseoperasjonene som trengs for å forstå kontoen. Å deaktivere hver komponent kan gjøre en usikker tilstand vanskeligere å avklare og etterlate operatøren uten aktuell informasjon om aktive ordrer eller posisjoner.
Definer driftsmoduser etter evner. En ren observasjonsmodus kan oppdatere markeds- og kontodata. En avstemmingsmodus kan undersøke tidligere handlinger. En kanselleringsmodus kan tillate bestemte risikoreduserende operasjoner hvis de er godkjent. En handelsmodus kan skape ny eksponering innenfor grensene.
Hver modus bør ha tydelige inn- og utgangsvilkår. Nettverksgjenoppretting alene bør ikke automatisk gjenopprette handel hvis uavklarte hensikter gjenstår. Omvendt trenger et driftsavbrudd i en forskningskilde ikke hindre kontoavstemming gjennom et velfungerende privat grensesnitt. Finkornede evnegrenser hjelper boten å forbli nyttig uten å overstige fullmakten.
Gjør operatørmeldinger anvendelige
En operatør bør få en kortfattet forklaring av uavklart tilstand: konto, kontrakt, opprinnelig hensikt, mulig eksponering, sist kontrollert dokumentasjon og neste undersøkelsessteg. Et stakkspor alene forklarer ikke feilens økonomiske konsekvens.
Unngå å be operatøren velge mellom å prøve igjen og ignorere uten kontekst. Tilgjengelige handlinger kan inkludere å spørre etter opprinnelig ordre, kontrollere kontohandler, opprettholde pausen eller eskalere en motstridende registrering. Boten bør bevare virkningen av hver handling i journalen.
En plattformgjennomgang kan hjelpe med å organisere grensesnittet. Veiledningen om en handelsplattform for Polymarket skiller kontokontroll, prisdannelse og oppgjør. Skillene bør forbli synlige under feil, når en leser særlig lett kan forveksle en fungerende markedsdataskjerm med en fullt avstemt handelskonto.
Test feil ved nettverksgrensen
En nyttig akseptanseøvelse avbryter prosessen på flere punkter: etter varig lagring av hensikt, under overføring, etter ekstern aksept men før lokal svarlagring, og etter at en utførelse kommer men før posisjonsvisningen oppdateres. Hvert avbrudd bør gi en gjenopprettbar eller uttrykkelig uavklart tilstand.
Forventet resultat er ikke alltid automatisk fortsettelse. Noen tilfeller bør ende med pause fordi tilgjengelig dokumentasjon ikke trygt kan fastslå kontotilstanden. Testen bør kontrollere at boten bevarer reservasjoner, unngår dobbel eksponering og gir operatøren nok informasjon til å undersøke.
Inkluder duplikate og forsinkede meldinger i avspillingen. Ny behandling av en allerede kjent handel bør ikke legge til mengden to ganger. Et sent avslag bør knyttes til riktig forespørsel fremfor å overskrive en annen vellykket hensikt. Tilfellene tester registreringsmodellen mer meningsfullt enn gjentatt innsending av vanlige ordrer under ideelle forhold.
Gjennomgå botens økonomiske registrering
Driftsmål bør inkludere alder på uavklarte hensikter, avstemmingsforsinkelse, duplikatobservasjoner og reservasjonsavvik. Forespørslers suksessrate alene kan se sunn ut mens kontoregistreringen er feil. Et lite antall usikre innsendinger kan bety mer enn tusenvis av vellykkede offentlige lesinger.
Den eldre veiledningen om bot-API for prediksjonsmarkeder gir et bredere arkitekturperspektiv. Gjennomgå boten ved grensene: hvilken dokumentasjon kom inn, hvilken fullmakt ble gitt, hvilken instruks gikk ut, og hvilken kontotilstand kom tilbake? Grensene identifiserer hvor en feil endret betydning eller overskred omfanget.
Hold strategievaluering separat. En bot kan gjennomføre en dårlig strategi trofast, og en lovende prognose kan undergraves av upålitelig gjennomføring. Den økonomiske journalen lar begge spørsmål undersøkes uten at hvert resultat tilskrives den mest synlige komponenten eller nyeste feilmeldingen.
Hold Polymarket-API-boten innenfor dokumentasjonen
En godt avgrenset bot vet når den har nok dokumentasjon til å handle, og når den bare har nok til å undersøke. Den varige journalen knytter én hensikt til forsøkene, ordrene og handlene. Reservasjonene tar hensyn til mulig eksponering til usikkerheten er avklart.
Begynn med et snevert tillatelsessett og et fullstendig gjenopprettingsforløp. Kontroller kontooppsett mot gjeldende dokumentasjon, samordne innsendingsfullmakt og test avbrudd før omfanget utvides. Gjør pauser forklarlige og hold observasjonen som trengs for å avklare dem, tilgjengelig.
Resultatet er et program der atferden kan rekonstrueres under vanlig drift og feil. Det gjør ikke usikre prognoser til sikre utfall. Det gjør driftskravet presist: boten bør bare gjennomføre de avgrensede handlingene den hadde tillatelse til å forsøke, og så fastslå hva som faktisk skjedde før kontoen behandles som klar for en ny beslutning.