Hyperliquid-bot: arkitektur och handelskontroller

Arkitekturen för en Hyperliquid-bot börjar med omfattningen

Skriv ett driftskontrakt på ett stycke innan indikatorer väljs. Det bör identifiera produkt, konto, behöriga tillgångar, informationskällor, maximala befogenheter och villkor som avbryter åtgärder. ”Handla intressanta token” är inget driftskontrakt. ”Bedöm en namngiven uppsättning spotpar som stöds med dokumenterade observationer, ett fast tilldelningstak och inga överföringsbefogenheter” ligger mycket närmare.

Omfattningen definierar också vad programmet inte kan härleda. Ett tokensaldo bevisar inte att kontot kan sälja hela beloppet till visat pris. En marknadsbeteckning fastställer inte vilken underliggande tillgång som handlas. Att ett konto ser tomt ut kan tyda på att fel adress tillfrågades snarare än att medel försvann.

Guiden till tillgångsidentitet förklarar varför namn behöver auktoritativa identifierare. En bot bör lagra både den läsbara beteckningen och de exakta identifierare som behövs av dess valda gränssnitt. Människovänliga namn hör hemma på skärmen; exakta identiteter hör hemma i varje beslutspost.

Ett derivatmandat tillför granskningen av perpetualpositioner, där säkerheter, finansiering och skyddsordertillstånd blir löpande åtaganden.

Dela upp systemet i ansvarsområden

En användbar arkitektur skiljer observation, beslut, godkännande, exekvering och avstämning åt. Observation samlar belägg. Beslut föreslår en åtgärd. Godkännande kontrollerar om åtgärden ryms inom kontots gränser. Exekvering kommunicerar den godkända instruktionen. Avstämning avgör det resulterande tillståndet. Ansvarsområdena kan köras i en applikation utan att slås samman till en funktion.

Betrakta en prisuppdatering som kommer medan en tidigare order är olöst. Observationskomponenten kan acceptera uppdateringen omedelbart. Beslutskomponenten kan föreslå en justering. Godkännandet kan avvisa ytterligare utgifter tills den tidigare åtgärden är förstådd. Följden bevarar snabb respons utan att låta färska data skriva över ett olöst åtagande.

En tydlig gräns gör också fel möjliga att diagnostisera. Om en marknadsobservation är inaktuell är ändrad signeringskod irrelevant. Om en order är giltig men överskrider en tilldelningsgräns kommer upprepade prisfrågor inte att godkänna den. Varje komponent bör förklara beläggen bakom sitt aktuella resultat.

Upprätthåll ett marknadsregister

Ett marknadsregister dokumenterar instrumentet som systemet tror sig kunna använda. För ett spotpar omfattar detta bas- och noteringsidentiteter, formateringsregler, relevant miljö och tidpunkten då informationen verifierades. Behandla posten som ett versionshanterat beroende snarare än en samling namn inklistrade i konfigurationen.

När metadata ändras behöver befintliga planer granskas. En order som förberetts enligt en uppsättning precisionsregler bör inte tyst ärva en annan vid inskickning. Bevara ursprungsplanen, läs in nya metadata och avgör om en ersättningsplan fortfarande är giltig. Det skapar en förklarlig övergång i stället för en dold redigering.

Registret bör också identifiera marknader som inte stöds. En begärd symbol utan verifierad motsvarighet hör hemma i ett otillgängligt tillstånd, inte i det närmast liknande instrumentet. Att avvisa en tvetydig begäran är användbart beteende, särskilt när spekulativa tokennamn avsiktligt liknar varandra.

Behandla observationer som daterade belägg

Varje observation behöver en källa och en tidpunkt. Registrera helst när källan säger att händelsen inträffade, när applikationen tog emot den och när strategin bedömde den. De tre tidpunkterna besvarar olika frågor. En snabb bedömning kan ändå använda gamla data, och ett nyligt mottagande kan innehålla fördröjd information.

Definiera en aktualitetsregel för varje indata. Orderbok, kontoinnehav och strategikonfiguration behöver inte dela en allmängiltig tidsgräns. En historisk indikator kan förändras långsamt medan ett föreslaget exekveringspris snabbt blir föråldrat. En grön anslutningsindikator kan inte uttrycka alla dessa förhållanden.

En hypotetisk detektor kan exempelvis observera en kvalificerande signal klockan 12:00:00 men få kontotillstånd som senast kontrollerades klockan 11:58:00. Signalens aktualitet reparerar inte kontoosäkerheten. Godkännandet bör kräva relevanta kontobelägg innan medel reserveras för en ny åtgärd.

Riskkontroller för en Hyperliquid-bot hör hemma före signering

Riskkontroller för en Hyperliquid-bot bör bedöma hela den föreslagna åtgärden, inte bara strategins entusiasm. Förslaget bör omfatta instrumentidentitet, sida, storlek, prisgräns, förväntade kostnader, konto och skäl. Om något obligatoriskt fält saknas eller är tvetydigt saknar systemet en fullständig begäran att godkänna.

Skilj en hård gräns från en preferens. En maximal kontotilldelning är en hård gräns. En preferens för snävare spread kan rangordna annars godtagbara kandidater. Att väga samman dem till en poäng kan låta en attraktiv signal kompensera för ett oacceptabelt utgiftsbelopp, vilket motverkar syftet med en gräns.

Guiden till automationskontroller utforskar åtskillnaden mer ingående. Håll auktoritativa gränser utanför modellen eller indikatorn som föreslår affärer. En strategiändring bör inte få tillstånd att öka sin egen budget bara för att den genererade ett annat konfidensvärde.

Reservera resurser för olösta åtgärder

Tillgängliga resurser motsvarar inte alltid ett nyligen visat saldo. Vissa medel kan vara bundna till öppna order, väntande åtgärder eller en annan strategi som delar kontot. En intern reservationsbok förhindrar att applikationen lovar samma kapacitet två gånger medan åtagandena förblir olösta.

Anta att ett illustrativt konto tillåter 500 noteringsenheter i automatiserad exponering. En strategi har 300 enheter investerade och en annan har en order på 150 enheter vars utfall är okänt. En tredje begäran på 100 enheter bör inte godkännas bara för att den osäkra ordern saknas på en fördröjd skärm. Systemet måste beakta det olösta åtagandet.

Reservationer behöver en ägare, ett belopp, en relaterad åtgärd och ett frigöringsvillkor. Frigör dem när auktoritativa belägg stöder det nya tillståndet, inte när en nätverksbegäran når sin tidsgräns. En tidsgräns förändrar vad applikationen vet. Den återför inte nödvändigtvis det som marknaden redan har gjort.

Gör avsikten till en beständig post

Spara avsikten innan en åtgärd överförs. Posten kopplar strategibeslutet till konto, instrument, konfigurationsversion, godkännanderesultat och exekveringsbegäran. Den är referenspunkten för återställning när en process avslutas efter att ha skickat men innan ett svar har registrerats.

Använd separata identifierare för den ekonomiska avsikten och kommunikationsförsöken. Ett avsett köp kan generera en ursprunglig begäran, en statusfråga och ett senare annulleringsförsök. Det är inte tre oberoende köp. Omvänt bör två skilda godkända köp inte slås samman bara för att beloppen är lika.

En beständig avsiktspost hjälper också operatören att besvara en enkel fråga: varför agerade systemet? Svaret bör hänvisa till belägg som fanns vid beslutstidpunkten. Att beräkna om en indikator senare och presentera det värdet som det ursprungliga skälet skulle skriva om historiken som undersöks.

Håll signeringsbefogenheter snäva och synliga

Signeraren omsätter godkända data till en auktoriserad åtgärd. Den bör inte vara en allmän tjänst som accepterar godtyckliga instruktioner från varje del av gränssnittet. Verifiera vilka konton, miljöer och åtgärdstyper varje anropare får begära och bevara relationen mellan godkännandebeslutet och den signerade nyttolasten.

Hantering av autentiseringsuppgifter och handelslogik har olika felsätt. Ett felaktigt formaterat pris bör ge ett valideringsfel, inte exponera en hemlighet i en diagnostikdump. Ett frånkopplat konto bör inte få programmet att tyst byta till ett annat konto med liknande beteckning. Loggar kan innehålla offentliga identifierare och felkategorier utan privat signeringsmaterial.

En operatör bör kunna se vilka befogenheter som är aktiva och hur de återkallas. Att stoppa en skrivbordsprocess är användbart men ersätter inte förståelse av eventuella stående behörigheter som getts till externa tjänster eller delegerade signerare.

Tolka utfall på rätt nivå

Lyckad kommunikation, accepterad åtgärd, placerad order, delvis exekvering och fullständig exekvering beskriver olika händelser. En välutformad adapter visar skillnaderna i stället för att pressa samman dem till ett enda booleskt framgångsvärde. Strategin reagerar då på vad som faktiskt skedde snarare än på skenet av ett normalt svar.

Betrakta en påhittad order på 100 token som förvärvar 35 och lämnar återstoden ofylld. Kontot har nu en position på 35 token. Systemet kan inte hantera den som vare sig noll eller 100. Senare exitbeslut och tillgängligt utgiftsutrymme bör använda observerad kvantitet, inklusive tillämpliga avgiftseffekter.

Lagra råsvaret tillräckligt säkert för felsökning tillsammans med en normaliserad tolkning. Om en framtida parserrättning förändrar tolkningen finns ursprungliga belägg kvar. Det är mer användbart än att enbart behålla ett meddelande om att affären lyckades.

Avstämning är en löpande process

Avstämning jämför lokala avsikter med observerade kontofakta. Den bör undersöka öppna order, slutförda avslut, saldon och oförklarade förändringar. Syftet är inte att tvinga kontot att motsvara den lokala databasen. Syftet är att upptäcka vilken bild som är ofullständig och uppdatera posten med belägg.

Manuell handel skapar en vanlig avvikelse. Om användaren säljer en position genom ett annat gränssnitt måste den automatiserade strategin känna igen det ändrade innehavet innan en annan försäljning förbereds. Den externa åtgärden bör visas som en extern justering, inte som ett fiktivt avslut tillskrivet botens tidigare signal.

Guiden till handelsjournaler beskriver hur poster stöder meningsfull granskning. Håll olösta skillnader synliga. Att dölja dem bakom en nyberäknad totalsumma kan förenkla skärmen men ta bort informationen som behövs för att förhindra nästa felaktiga åtgärd.

Återställning av en Hyperliquid-bot efter omstart

Återställning av en Hyperliquid-bot efter omstart börjar med observation, inte med att skicka det senaste kommandot igen. Läs in beständiga avsikter, återskapa reservationer och hämta aktuellt kontotillstånd. Klassificera sedan varje ofullständig åtgärd som fortfarande öppen, slutförd, annullerad, avvisad eller olöst enligt tillgängliga belägg.

Föreställ dig en process som stannar direkt efter att en order accepterats. Vid omstart säger den lokala posten fortfarande att inskickning pågår. Att skicka ett köp till skulle förvandla en loggningslucka till ytterligare exponering. En återställningsrutin bör undersöka den befintliga avsikten och relaterad orderinformation innan den avgör om någon ny instruktion är motiverad.

Återställning måste också beakta konfigurationsändringar. En strategi som inaktiverades medan applikationen var offline bör inte starta om automatiskt under en äldre sparad inställning. Den auktoritativa aktuella policyn bör avgöra vad som får återupptas; den gamla policyn förblir en del av den historiska förklaringen till befintliga positioner.

Definiera vad varje stoppkontroll gör

”Stopp” kan betyda att stoppa signalinsamling, stoppa öppnande av positioner, annullera öppna order, stoppa alla nya signerade åtgärder eller försöka minska innehavet. Detta är olika kontroller med olika konsekvenser. Namnge dem korrekt så att en operatör vet om befintliga order och innehav förblir aktiva.

En annulleringsbegäran är inte en slutförd likvidering. Att annullera ett vilande köp kan minska framtida exponering medan en redan fylld position finns kvar. Att inaktivera nya entréer kan på samma sätt lämna exithantering igång. Det kan vara önskvärt men bör vara ett uttryckligt läge snarare än en oavsiktlig sidoeffekt.

Testa lägena med konstruerade scenarier. Verifiera med en öppen order, ett befintligt innehav och en olöst begäran vad varje stoppkommando förändrar och vad det lämnar orört. Det resulterande beteendet bör motsvara beteckningen innan någon förlitar sig på kontrollen under en stressande händelse.

Mät driftsystemet, inte bara vinsten

En användbar instrumentpanel rapporterar tid med inaktuella indata, avvisade förslag, olösta åtgärder, avstämningsskillnader och återställningstid. Måtten förklarar om automationen beter sig som avsett. Vinst ensam kan inte skilja en sund process från ett tursamt utfall tillsammans med dolda driftsfel.

Följ frekvenser med deras nämnare. Tre avvisade order av fem förslag betyder något annat än tre av fem tusen. Skilj avvisanden orsakade av giltiga skyddsgränser från fel orsakade av felaktig formatering eller otillgängliga tjänster. De förra kan visa policytillämpning; de senare kan avslöja ett fel.

En liten incidentlogg ger diagram sammanhang. Registrera när konfigurationen ändrades, anslutningen försämrades eller manuell kontoaktivitet skedde. Utan sådana anteckningar kan en analytiker tillskriva en resultatförändring handelssignalen när den faktiska orsaken var ett driftsförhållande.

Bygg en testbar beslutsväg

Testning bör pröva hela vägen från observation till avstämt tillstånd och samtidigt kontrollera vad testet får göra. Börja med inspelade eller syntetiska observationer och granska föreslagna åtgärder. Testa sedan svarshantering och kontotillståndsövergångar utan att anta att simulerad framgång förutsäger ett framtida avslut.

Ta avsiktligt med negativa fall: en inaktuell orderbok, en saknad marknad, en delvis fylld order, en duplicerad händelse, ett fördröjt svar och en omstart vid varje övergång. En attraktiv demonstration av normalfallet säger lite om hur applikationen beter sig när två händelser kommer i oväntad ordning.

Översikten över systemdrift ger en bredare driftsram. Varje misslyckat scenario bör ge ett begripligt tillstånd och en definierad återställningsväg. Ett test som enbart undertrycker felet bevisar varken korrekt redovisning eller en säker nästa åtgärd.

Bedöm förändringar utan att skriva om baslinjen

Versionshantera strategin, gränserna, marknadsregistret och exekveringsadaptern som används under varje observationsperiod. Annars kan en förändring av resultaten inte hänföras tillförlitligt. Ett nytt signaltröskelvärde och en ny avgiftsparser som införs samtidigt skapar två möjliga förklaringar till en skillnad i uppmätta utfall.

Använd en skriftlig ändringshypotes. Förbättrat avvisande av inaktuella data kan exempelvis minska antalet entréförsök och öka andelen med fullständiga belägg. Mät dessa avsedda effekter direkt i stället för att bedöma förändringen enbart efter en kort periods avkastning.

Behåll avvisade kandidater när en ändring utvärderas. Jämförelse av enbart slutförda affärer kan dölja om det ändrade systemet helt enkelt slutade delta under svåra förhållanden. Det kan vara lämpligt beteende men bör vara synligt i analysen snarare än misstas för en universellt starkare signal.

Spela upp ett beslut utan att upprepa affären

Återuppspelning innebär att bedöma sparade belägg igen samtidigt som granskningsprocessen förhindras från att skapa en ny marknadsåtgärd. En användbar uppspelningsmiljö har inga aktiva handelsbefogenheter. Den kan återskapa förslaget, jämföra det med det registrerade beslutet och förklara skillnader orsakade av en ändrad regel eller parser. Att hålla gränsen uttrycklig förhindrar att en analytisk övning blir ännu en exekveringssession.

Bevara observationsordningen liksom observationerna själva. Om en saldouppdatering kom efter en prissignal ger en uppspelning som lägger den före signalen strategin information som den inte ursprungligen hade. Det kan få ett bristfälligt beslut att se rimligt ut i efterhand. Markera osäkerheten där leveranstidpunkten är osäker i stället för att välja följden som ger det mest attraktiva resultatet.

Följ kostnaden genom huvudboken

Betrakta ett illustrativt köp av 40 token för 80 noteringsenheter med en separat förvärvskostnad på 0,08 enheter. Senare säljs 15 token för 33 enheter med en försäljningskostnad på 0,03 enheter. Med en enkel proportionell kostnadsillustration bär den sålda delen 30,03 enheter i förvärvskostnad, vilket lämnar 2,94 enheter i realiserad vinst på delen. Återstående 25 token är fortfarande innehav, inte realiserade intäkter.

Beräkningen är ingen rekommendation av skattemetod eller något påstående om aktuella avgifter. Den visar varför systemet behöver kvantiteter, intäkter och kostnader tillsammans. Att visa hela mottagandet på 33 enheter som vinst skulle överdriva resultatet; att visa det ursprungliga innehavet på 40 token efter den delvisa exiten skulle överdriva innehavet. En uttrycklig huvudbok gör båda felen möjliga att upptäcka innan en senare strategi använder fel tillgängligt saldo.

En praktisk arkitekturgranskning

En läsare som granskar en Hyperliquid-bot kan följa en representativ åtgärd genom sex frågor. Vilken observation utlöste den? Vilket instrument och konto riktade den sig mot? Vilken regel godkände dess storlek? Vad överfördes? Vad genomfördes faktiskt? Hur skulle systemet återställas om svaret hade förlorats?

Om något svar förlitar sig på en skärmbeteckning i stället för en beständig post behöver konstruktionen undersökas mer. Om systemet kan besvara alla sex blir det möjligt att bedöma strategikvalitet separat från exekveringskorrekthet. Skillnaden gör jämförelser mer användbara och felsökning mycket mindre spekulativ.

Målet med arkitekturen är inte ständig handel. Det är kontrollerat beteende under vanliga, exceptionella och osäkra förhållanden. Ett system som kan förklara varför det avstod från en åtgärd, bevara ett olöst resultat och återuppta först efter avstämning är lättare att driva än ett som enbart verkar sysselsatt dygnet runt.