Et kryptohandelssystem består av ansvarsområder som er knyttet sammen. Det observerer markeder, tolker dokumentasjon, foreslår handlinger, kontrollerer tillatelser, forsøker utførelse og forklarer kontoen etterpå. Ansvaret kan ligge i én applikasjon eller flere tjenester, men betydningen av hvert ansvarsområde bør fortsatt være tydelig atskilt.
Utformingen blir enklere å vurdere når hvert trinn besvarer et klart spørsmål. Hva ble observert? Hvorfor foreslo strategien en handling? Hvilke ressurser ble autorisert? Hva ble faktisk sendt? Hva viser uavhengig kontodokumentasjon nå? Et system som ikke kan besvare ett av spørsmålene, har et hull selv om grensesnittet viser et polert resultatdiagram.
Denne veiledningen utvikler en konseptuell arkitektur for spothandel med hypotetiske eksempler. Den legger vekt på samsvar og ansvarlighet fremfor programvaremerker eller lovet avkastning. Målet er å knytte beslutninger til kontovirkninger og samtidig bevare usikkerheten mellom et innsendt forsøk og et avstemt utfall.
Arkitekturen i et kryptohandelssystem begynner med tilstand
Tilstand er informasjonen systemet bygger på for å avgjøre hva som kan skje videre. Skill mellom markedstilstand, kontotilstand og regeltilstand. En aktuell markedsobservasjon fastslår ikke tilgjengelige kontoressurser, og en tilgjengelig saldo fastslår ikke tillatelse til å bruke den.
Markedstilstanden omfatter observasjoner og tidspunktene deres. Kontotilstanden omfatter beholdninger, aktive ordrer, ventende forsøk og reserverte ressurser. Regeltilstanden omfatter aktive grenser, tillatte eiendeler, driftsvinduer og versjonene av reglene som gjelder nå.
Ved å holde oversiktene atskilt unngår man praktiske, men ugyldige snarveier. En strategi bør ikke utlede fullmakt fra en sum i et kontrollpanel, og en utførelsesadapter bør ikke utlede strategiens hensikt fra en nylig prisendring. Hvert ansvarsområde bruker tilstanden som er relevant for sitt spørsmål.
Veiledningen til systemansvar på Solana gir et nettverksspesifikt eksempel. En generell arkitektur for et kryptohandelssystem bør bevare det samme skillet og samtidig tilpasse betydningen av kontoer og transaksjoner til det valgte miljøet.
Gi observasjoner en identitet og en klokke
En observasjonsregistrering bør forklare hva som kom, hvorfra og når. Bevar kildeidentifikatorer, kildetid der den finnes, lokal mottakstid og råverdiene som trengs for å forstå senere omforminger. Da blir forsinket eller gjentatt levering mulig å skille fra en ny markedshendelse.
Ikke overskriv den eneste kopien av en tidligere observasjon når en kilde sender en rettelse. Den korrigerte verdien kan passe for en aktuell visning, mens den opprinnelige fortsatt trengs for å forklare en historisk beslutning. Begge kan beholdes med et tydelig forhold mellom dem.
En innsamlingskomponent bør skille manglende informasjon fra en gyldig nullverdi. En frakoblet datastrøm beviser ikke at volumet forsvant eller at en saldo ble tom. Å erstatte informasjon med praktiske standardverdier kan gjøre et tilgjengelighetsproblem til et misvisende markeds- eller kontosignal.
Observasjonens identitet hjelper også med duplikatkontroll. To leveringer kan vise til én underliggende hendelse. Systemet kan beholde begge mottaksregistreringene for feilsøking og samtidig bare la én hendelse oppfylle et bestemt inngangsvilkår.
Normaliser uten å viske ut betydningen
Normalisering gjør kildespesifikke felt om til en felles representasjon. Den bør bevare eiendelsidentitet, mengdeenheter, tidspunkter og usikkerhet, samtidig som informasjonen blir enklere å bruke i påfølgende regler. Et felles skjema er bare nyttig hvis det beholder skillene som påvirker beslutninger.
En spoteiendel og et derivat som viser til den samme eiendelen, er for eksempel ulike instrumenter. Et token på ett nettverk og en representasjon med lignende navn et annet sted kan kreve ulik utførelse og regnskapsføring. Visningsetikettene bør ikke avgjøre om registreringene slås sammen.
Behold finansielle mengder med tilstrekkelig nøyaktighet for de støttede kontooperasjonene. Visningsformatering kan avrunde for lesbarhet, men ressurs- og utførelsesløpene bør bruke den riktige underliggende presisjonen. Avrunding er en dokumentert omforming, ikke en tilfeldig bivirkning av tallvisning.
Markedssammenligningen for kryptohandelsboter hjelper med å fastslå hvilke instrumentskiller som er viktige. Normalisering bør gjøre forskjellene uttrykkelige fremfor å flate dem ut i en universell registrering som skjuler atferd som ikke støttes.
La strategiene produsere forslag
En strategi tolker observasjoner etter en definert regel og gir et forslag eller en begrunnelse for å avstå. Forslaget bør identifisere den tilsiktede eiendelen, retningen, det forespurte beløpet, dokumentasjonen, regelversjonen og utløpet. Det forklarer hensikten og er ikke en instruksjon som omgår andre kontroller.
Skillet lar den samme forskningslogikken vurderes uten utførelsesfullmakt. Det gir også en menneskelig gjennomleser noe konkret å undersøke. Personen kan forstå hvilke vilkår som ble oppfylt, og hvilke forutsetninger som fortsatt gjelder, før en avgrenset handling autoriseres.
Resultater om å avstå fortjener også registreringer. En strategi kan avvise en hendelse fordi mønsteret ikke holdt, dokumentasjonen var utdatert eller eiendelen ikke ble støttet. Dette er ulike utfall som bidrar til å forklare både dekning og atferd i drift.
Et forslag kan være gyldig som strategiresultat og samtidig avvises av kontoreglene. Ved å bevare skillet unngår man at ressursgrenser forveksles med svikt i handelshypotesen, eller at et signal forveksles med tillatelse.
Samle ressursreservasjonene på ett sted
Flere strategier kan dele en konto og samtidig ha separate begrunnelser for handling. De trenger likevel én sammenhengende oversikt over forpliktede ressurser. Uten den kan hver strategi uavhengig se den samme saldoen som tilgjengelig og autorisere overlappende pengebruk.
På en hypotetisk konto med 800 enheter kapital etter kontoreglene er 250 enheter tildelt posisjoner, 150 et uavklart forsøk og 50 driftsreserver. Den gjenværende uforpliktede kapasiteten er 350 enheter. To forslag på 200 enheter hver kan ikke begge godkjennes fullt ut etter disse reglene.
Reservasjoner bør være varige og knyttet til hensikter. Frigivelse krever dokumentasjon på at forpliktelsen er avsluttet eller ikke lenger kan gi den relevante kontovirkningen. En manglende kvittering er ikke alene tilstrekkelig dokumentasjon.
Veiledningen til samordning av flere strategier utdyper problemet med delt kapital. Systemutformingen bør gjøre eierskapet til ressursene synlig selv når én bruker driver alle strategiene. Samtidige programvareoppgaver konkurrerer fortsatt om de samme midlene.
Hold autorisering uavhengig av forslagets kvalitet
Autorisering kontrollerer om en foreslått handling passer eierens tillatelser og kontogrenser. Den bør kontrollere konto, eiendel, største forpliktelse, støttet rute og gjeldende kontrolltilstand. Et forslag med høy vurdering får ikke unntak fra grensene.
Autoriseringsregistreringen bør kunne sammenlignes med den faktiske handlingen som klargjøres for utførelse. Menneskelesbare sammendrag hjelper ved gjennomgang, men nøyaktige identifikatorer og mengder trengs fortsatt for å oppdage feil destinasjon, bytte av eiendel eller en utilsiktet økning av størrelsen.
Endringer i fullmakter trenger sin egen registrering. Å heve en grense eller aktivere et nytt marked endrer hva systemet kan gjøre. Det bør ikke skje som en usynlig følge av å redigere en strategietikett eller oppdatere en visningsinnstilling.
Ved en arkitekturgjennomgang bør du spørre hva som skjer hvis strategien gir en feilformet eller for stor forespørsel. Ønsket utfall er en tydelig avvisning ved autoriseringsgrensen, med tilstrekkelig dokumentasjon til å finne årsaken. Atferden viser at kontrollene ikke avhenger av at hver tidligere komponent oppfører seg perfekt.
Uttrykk støttede handlinger gjennom adaptere
En adapter uttrykker en autorisert handling med betydningene destinasjonen støtter. På en handelsplass med ordrer omfatter det de relevante ordreparameterne og mengdereglene. For en nettverksrute omfatter det instruksjonene eller kontraktsamhandlingen som trengs for å utføre den avgrensede handlingen.
Adapteren bør oppgi tilfeller som ikke støttes. Den må ikke i det stille erstatte en utilgjengelig instruksjon med vesentlig annen økonomisk atferd bare for å få et vellykket svar. Omforminger som avrunding, ruteendringer eller beløpsreduksjoner trenger definert tillatelse.
En bot for en kryptohandelsplattform kan plassere noe adapteransvar inne i en plattform, mens en ekstern tilkobling plasserer det i en separat integrasjon. Systemet trenger fortsatt dokumentasjon på at den oversatte handlingen samsvarer med den godkjente hensikten.
Registrer de innsendte parameterne sammen med autoriseringen. Da kan avstemming og gjennomgang identifisere om et avvik begynte ved strategiutvalg, ressursgodkjenning, oversettelse eller utførelse. Én samlet loggmelding kan ikke pålitelig bevare grensene.
Journalfør forsøket før nettverkskallet
En varig journal bør finnes før et eksternt svar kan bli tvetydig. Den registrerer hensikten, autoriseringen og forsøksidentiteten. Hvis prosessen stopper etter at en forespørsel er sendt, kan gjenopprettingen da undersøke det eksisterende forsøket fremfor å anta at ingen handling fant sted.
Skill en hensikt fra forsøkene som følger den. Én hensikt kan kreve flere tekniske overføringer eller en kontrollert erstatning, men hendelsene bør fortsatt være knyttet sammen. Å opprette en ny hensikt for hvert nytt forsøk kan mangedoble eksponeringen og samtidig få hver enkelt registrering til å se legitim ut.
Definer tilstander ut fra kunnskapen som finnes. Klargjort, innsendt, observert, delvis fullført, avvist og uavklart beskriver ulik dokumentasjon. Et enkelt suksessflagg kan ikke vise om kontoen fortsatt kan endres som følge av en tidligere forespørsel.
Veiledningen til automatisert handel med krypto sammenligner disse livsløpsspørsmålene på tvers av sentraliserte ruter og ruter på kjeden. De nøyaktige identifikatorene varierer, men varig kontinuitet mellom den autoriserte hensikten og de eksterne forsøkene er fortsatt et grunnkrav.
Behandle ukjente utfall som eget arbeid
Et ukjent utfall er en tilstand som krever undersøkelse, ikke en generell feil som kan forkastes. Systemet vet nok til å bevare et forsøk, men ikke nok til å frigi ressursene eller fastslå en posisjon. Begrensningen bør vises tydelig.
Undersøkelsen bruker ordre- eller transaksjonsregistreringer som passer destinasjonen, og aktuelle kontoobservasjoner. Svaret bør tolkes etter handelsplassen eller nettverket fremfor etter én universell tidsavbruddsregel. Ulike destinasjoner kan ha ulike regler for varighet og erstatning.
Den offisielle dokumentasjonen for innsending på Solana gir et avgrenset eksempel: En akseptert RPC-innsending er forskjellig fra bekreftelse. Et system bør derfor unngå å utlede fullført kontotilstand fra innsendingskvitteringen alene.
Uavhengig arbeid kan fortsette mens undersøkelsen pågår. Innsamling av offentlige markedsdata og historisk rapportering kan fortsatt være nyttig. Handlinger som avhenger av omstridte midler eller usikre posisjoner, kan måtte vente. Denne målrettede begrensningen gir mer informasjon enn enten å ignorere tvetydigheten eller å skjule hele applikasjonen bak én feilskjerm.
Kontoavstemming i et kryptohandelssystem
Kontoavstemming i et kryptohandelssystem knytter hensikter til faktiske beholdninger og forpliktelser. Sammenlign de forventede virkningene av hvert forsøk med autoritativ kontodokumentasjon, inkludert mengder, gebyrer, aktive ordrer og gjenværende posisjonsmengder. Avstemming kan bekrefte et forventet resultat eller identifisere et avvik som trenger gjennomgang.
Manuelle handlinger må være synlige i prosessen. Hvis noen overfører midler eller delvis selger en posisjon utenfor automatiseringen, bør journalen ikke automatisk tilskrive endringen til den siste bothandlingen. Tilskrivning krever dokumentasjon.
Velg tydelige regler for foreløpige observasjoner og observasjoner med sterkere støtte. En tidlig kontovisning kan være nyttig i drift, mens senere dokumentasjon underbygger en mer avklart registrering. Grensesnittet bør merke skillene fremfor å antyde at alle resultater har samme sikkerhet.
Avstemming oppdaterer også reservasjoner. En delutførelse kan gjøre en del av en reservasjon om til posisjonseksponering og samtidig la resten være forpliktet til en aktiv ordre. Å lukke hele reservasjonen ved første utførelse ville feilaktig fremstille både tilgjengelige ressurser og løpende forpliktelser.
Bygg posisjonsvisninger fra kontohendelser
En posisjonsvisning bør bygges fra bekreftede anskaffelser, salg, overføringer og kostnader. Den trenger kontinuitet i mengdene og en dokumentert metode for å fordele kostnader. En vist sum er en visning av historikken, ikke en erstatning for den.
I et hypotetisk eksempel anskaffer en konto tolv enheter, selger fem og overfører to til et annet sted. Sju enheter er igjen etter salget og fem etter overføringen, forutsatt at ingen andre mengdeendringer skjer. Et system som rapporterer sju etter overføringen, mangler en kontohendelse selv om handelshistorikken ellers er korrekt.
Skill verdsetting fra mengde. Et aktuelt markedsanslag kan endres mens antallet enheter forblir det samme. Hvis en priskilde blir utilgjengelig, kan systemet fortsatt rapportere den sist avstemte mengden med en uttrykkelig begrensning for verdsettingen.
Skillet gir grunnlag for mer ærlig resultatanalyse. Realiserte salgsinntekter, urealiserte anslag, transaksjonskostnader og eksterne kontantstrømmer besvarer ulike spørsmål. Å samle dem i én uforklart prosent gjør det vanskelig å forstå hva strategien faktisk bidro med.
Gjør endringer i kontroller observerbare
Kontroller definerer hvilke ansvarsområder som kan handle. En pause kan blokkere nye forslag, nye autoriseringer eller nye innsendinger og samtidig beholde observasjon og avstemming. Omfanget bør være uttrykkelig, fordi handlinger som allerede er akseptert et annet sted, kan fortsette etter en lokal pause.
Registrer hvem som endret en kontroll, når endringen trådte i kraft, og hvilket arbeid den påvirket. En godkjenning gitt før en pause kan fortsatt kreve ny vurdering hvis reglene sier at pausen blokkerer senere innsending. Implementasjonen bør håndheve den valgte grensen konsekvent.
Gjenopptakelse bør gjenopprette tilliten til den nødvendige tilstanden. Avstem uavklarte forsøk, oppdater utdatert dokumentasjon og kontroller aktive tillatelser på nytt før gamle køforslag behandles. Forslagets opprinnelige utløp bør ikke forlenges bare fordi applikasjonen var satt på pause.
Veiledningen til vurdering av automatiseringsprogramvare gjør kontrollkravene om til akseptansetilfeller. Definer forventet atferd først ved arkitekturgjennomgangen, slik at den valgte implementasjonen kan vurderes mot en meningsfull standard.
Utform omstart som en vanlig inngangsvei
En omstart begynner med ufullstendig lokal oversikt med mindre varige registreringer gjenopprettes. Last inn uavklarte hensikter, forsøk, reservasjoner og konfigurasjonsversjoner før nye markedshendelser vurderes. Aktuelle saldoer alene kan ikke forklare hvilke tidligere handlinger som fortsatt kan endre kontoen.
Bygg avledede visninger på nytt der det er praktisk, men bevar dokumentasjonen som ikke trygt kan gjenskapes. En visningsbuffer kan rekonstrueres fra journalen. Et uregistrert signert forsøk kan være umulig å skille fra en handling som aldri ble sendt.
Test omstart på flere punkter i livsløpet. Stopp etter at forslaget er opprettet, etter autorisering, etter innsending og under avstemming. Forventet resultat er en sammenhengende neste handling uten duplisert fullmakt, ikke bare en applikasjon som starter vellykket.
Gjenoppretting bør også oppdage eksterne endringer gjort under nedetid. Kontoen er ikke frosset mens prosessen er borte. Kombinasjonen av varig lokal hensikt og aktuell kontodokumentasjon er det som lar systemet gjenopprette en tilstand som kan forklares.
Overvåk ansvarsområder fremfor én statuslampe
Et system kan være delvis tilgjengelig. Markedsdata kan være aktuelle mens kontoavstemming er forsinket, og rapportering kan virke mens signering med hensikt er deaktivert. Overvåkingen bør vise hvilket ansvarsområde som er berørt, og hvilke beslutninger som avhenger av det.
Mål varigheter mellom meningsfulle hendelser. Fra mottatt observasjon til forslag, fra forslag til autorisering og fra innsending til avstemt utfall beskriver ulike forsinkelseskilder. Ett bredt hastighetstall skjuler trinnet som faktisk begrenser arbeidsflyten.
Bruk sammenkoblingsidentifikatorer slik at en gjennomleser kan følge én hensikt gjennom systemet uten at hemmeligheter eksponeres. Logger bør bevare beslutningskontekst, grenser og resultattilstander, men utelate privat signeringsmateriale og unødvendige personopplysninger.
Ansvarsgrensene i et kryptohandelssystem blir nyttige i drift når et varsel peker mot den berørte grensen. Et varsel om utdaterte inndata bør navngi kilden og den blokkerte avhengigheten. Et varsel om et kontoavvik bør identifisere den uavklarte dokumentasjonen. Da blir responsen forholdsmessig og forståelig.
Uttrykket autonom handelsagent for krypto reiser et spørsmål på porteføljenivå: Hvordan deler flere beslutninger kapital og forblir ansvarlige overfor ett konsekvent mandat?
Vurder systemet med invarianter
En invariant er et vilkår som bør forbli sant gjennom vanlige og ugunstige hendelsesforløp. Eksempler er å holde samlede forpliktelser innenfor det tillatte budsjettet, bevare én hensikt gjennom gjentatt levering og utlede kontoutfall fra dokumentasjon fremfor pristilbud.
Bruk vilkårene til å gjennomgå realistiske scenarioer. To konkurrerende strategier tester eierskapet til reservasjoner. En duplisert hendelse tester identitet. Et bortkommet svar tester journalen. Et manuelt delsalg tester avstemming. En pauset applikasjon som mottar en gammel godkjenning, tester kontrollomfanget.
Et system kan ha komponenter kalt risikostyrer og avstemmingskomponent og likevel bryte vilkårene. Navn og diagrammer er nyttige beskrivelser, men dokumentasjonen ligger i atferden som et konkret hendelsesforløp gir.
Dokumenter gjenstående begrensninger som en del av utformingen. En sammenhengende arkitektur kan ikke fjerne markedsusikkerhet, men kan gjøre systemets egen usikkerhet synlig. Synligheten lar kontoeieren forstå hva som er kjent, hva som fortsatt er uavklart, og hvilken handling den aktuelle dokumentasjonen faktisk tillater.
En siste invariant gjelder eierskap etter overlevering. Hvis en person tar kontroll over en uavklart hensikt, bør den automatiserte prosessen registrere overgangen og unngå å erstatte den samme handlingen uavhengig. Personen kan deretter tilføre ny kontodokumentasjon til den felles journalen. Det hindrer en velment manuell gjenoppretting og en automatisk gjenopprettingsrutine i å konkurrere seg frem til duplisert eksponering. Systemet forblir ansvarlig fordi det er uttrykkelig hvem som aktivt eier den neste beslutningen.