Un bot di trading perpetual Hyperliquid gestisce esposizione a derivati tramite ordini, esecuzioni e collaterale. Acquistare un perpetual non significa acquisire il corrispondente token spot da prelevare. Il valore della posizione cambia con il contratto e i suoi requisiti operativi includono margine, funding e possibilità di liquidazione. Tali caratteristiche rendono insufficiente, da solo, un flusso d’inventario spot.

Un’automazione affidabile parte da una descrizione persistente del cambiamento previsto della posizione. Verifica poi strumento e conto, controlla le risorse applicabili, invia un’azione delimitata e riconcilia cosa sia effettivamente accaduto. La strategia dovrebbe continuare a comprendere i propri obblighi quando un ordine viene eseguito solo in parte, un annullamento si sovrappone a un’operazione o il processo si riavvia.

Questa è formazione generale sui meccanismi perpetual, non un’affermazione che un software particolare li supporti. Tutti gli esempi numerici sono ipotetici e omettono complessità soltanto dove esplicitamente indicato. Non viene raccomandato alcun livello di leva, tasso di funding o rendimento atteso.

Definire il ciclo degli ordini del bot perpetual Hyperliquid

Il ciclo parte da un cambiamento previsto dell’esposizione con segno: per esempio aumentare un long, ridurre uno short o chiudere una quantità specifica. L’intenzione dovrebbe identificare strumento, conto, dimensione massima, vincolo di prezzo e versione della politica. Un’etichetta generica di acquisto non descrive completamente l’obiettivo economico.

Mantieni distinguibili gli esiti di invio, accettazione, permanenza nel book, esecuzione parziale, completamento e annullamento. Le evidenze esatte dell’API determinano quali etichette si applichino. Una risposta riuscita del trasporto non dimostra da sola che l’intera quantità prevista sia diventata una posizione.

La panoramica sull’esecuzione Hyperliquid spiega l’importanza di selezionare ambiente e conto corretti. Per i perpetual, collega tale quadro a un registro delle posizioni anziché sostituirlo con un saldo spot. Il registro deve conservare sia l’esposizione attuale sia quella aggiuntiva che potrebbero creare gli ordini residui attivi.

Risolvere contratto e sede di trading esatti

Un simbolo di asset può comparire in più prodotti o contesti di mercato. Il bot dovrebbe risolvere identificatore effettivo del perpetual, sede o deployment pertinente, asset di quotazione o collaterale e precisione supportata di dimensione e prezzo. Un ticker familiare non basta a costruire correttamente un ordine.

L’attuale documentazione Hyperliquid distingue perpetual gestiti dai validatori e mercati HIP-3, tra altri ambienti dell’ecosistema. Parametri del contratto e relazioni disponibili del collaterale dovrebbero provenire dai metadati effettivi del mercato. Non applicare universalmente un parametro ricordato di uno strumento a ogni contratto con un nome simile.

Conserva i metadati usati per autorizzare ogni azione. Se una configurazione di mercato cambia, la vecchia registrazione dovrebbe restare interpretabile. Una ricerca successiva può spiegare il comportamento attuale senza riprodurre le condizioni in cui era stato preparato un ordine precedente. Tale differenza conta nell’indagine di un rifiuto o di una quantità inattesa.

Leggere la modalità attiva del conto

L’attuale documentazione raggiungibile dal sito ufficiale Hyperliquid descrive configurazioni di conto standard, unified e portfolio margin. Le loro relazioni tra saldi e collaterale differiscono. Un bot dovrebbe leggere la modalità attiva anziché presumere che risorse spot e perpetual siano sempre isolate o sempre condivise.

Nelle configurazioni unified e portfolio margin, la vista documentata dei saldi e gli importi trattenuti possono estendersi ad attività che un rapporto soltanto spot o per singolo DEX non catturerebbe correttamente. Una strategia può quindi vedere un’opportunità locale interessante mentre il conto più ampio ha già impegnato le risorse necessarie a sostenerla.

Tratta la modalità del conto come parte del contratto operativo. Un cambiamento di modalità può alterare l’interpretazione di saldi e limiti anche quando resta attiva la stessa strategia. Riconcilia il conto dopo tale cambiamento prima di autorizzare nuova esposizione da ipotesi appartenenti alla configurazione precedente.

Separare i limiti della strategia dal margine dell’exchange

L’accettazione di un ordine da parte di un exchange non stabilisce che rientri nella politica di rischio dell’utente. Il requisito di margine della piattaforma e l’esposizione massima consentita della strategia rispondono a domande diverse. Un limite interno prudente può rifiutare un ordine che il conto ha tecnicamente collaterale sufficiente a inserire.

In un esempio fittizio semplificato, tre unità di un perpetual lineare a 200 creano 600 di esposizione nozionale. Se l’esempio alloca 120 di margine, la leva tra nozionale e margine all’ingresso è cinque volte. Un movimento avverso del prezzo del dieci per cento crea una perdita di prezzo di sessanta unità prima di commissioni e funding, consumando metà del margine illustrativo.

Questo calcolo non è una formula del prezzo di liquidazione. La liquidazione effettiva dipende da strumento, modalità del margine, stato del conto e requisiti di mantenimento. L’esempio mostra perché una piccola allocazione di collaterale non renda piccola la posizione economica. Dimensione della posizione e perdita consentita necessitano di propri limiti espliciti.

Scegliere il comportamento dell’ordine coerente con l’intenzione

Un limite specifica un confine di prezzo, mentre la validità temporale determina cosa accada alle quantità non eseguite immediatamente. L’attuale documentazione degli ordini Hyperliquid distingue comportamento passivo, immediate-or-cancel e post-only. L’adattatore dovrebbe conservare la combinazione prevista dall’utente anziché tradurre ogni richiesta in un unico valore predefinito.

Un ordine immediate-or-cancel può essere eseguito parzialmente e lasciare annullato il residuo. Un’istruzione post-only mira a evitare un’esecuzione immediata come taker; non garantisce che un ordine passivo venga eseguito successivamente o sia redditizio. La distinzione conta nella stima sia dell’esposizione sia dei costi di esecuzione.

La guida alla gestione delle API Hyperliquid spiega perché gli esiti vadano interpretati per azione. La strategia dovrebbe reagire al risultato accettato per l’ordine effettivo. Non dovrebbe dedurre una posizione completa dal fatto che una richiesta contenesse la quantità desiderata.

Conservare l’intenzione decimale durante la costruzione

Vincoli di prezzo e dimensione dovrebbero conservare la precisione prevista dalla decisione della strategia fino all’azione firmata. Arrotondamenti disinvolti possono ampliare l’esposizione, spostare un limite attraverso lo spread o produrre una richiesta non valida. La direzione corretta dell’arrotondamento dipende dal confine rappresentato dal valore.

Per esempio, un importo massimo consentito d’acquisto non dovrebbe essere arrotondato verso l’alto soltanto per una preferenza di visualizzazione. Un’istruzione di chiusura dovrebbe essere controllata rispetto alla posizione attuale e all’incremento supportato di quantità. L’interfaccia può mostrare un numero più breve mentre la registrazione persistente conserva il valore esatto autorizzato.

La validazione dovrebbe avvenire prima della firma. Se una quantità non può essere rappresentata entro le regole attuali del mercato, il sistema dovrebbe produrre un rifiuto esplicito o una quantità ridotta giustificata separatamente. Adeguare tacitamente i valori dopo l’autorizzazione rende difficile stabilire se l’azione eseguita corrisponda ancora alla politica dell’utente.

Tenere separato il firmatario dal conto di trading

Un agente delegato può firmare azioni per un conto senza essere il conto di cui si devono interrogare posizioni e saldi. La documentazione ufficiale degli API wallet evidenzia tale distinzione. Leggere l’indirizzo dell’agente come se detenesse il conto di trading può produrre un risultato vuoto e la falsa impressione che non esista esposizione.

Memorizza identità del firmatario e identità del conto economico in campi diversi. La registrazione dell’ordine dovrebbe identificare anche ogni sottoconto applicabile o altro ambito supportato. Ciò impedisce che un controllo riuscito di autenticazione venga scambiato per conferma che la strategia operi sul portafoglio previsto.

Coordina i requisiti di nonce del protocollo per autorità di firma. Il modello di nonce delle azioni firmate HyperCore non dovrebbe essere sostituito con una sequenza presunta di transazioni EVM. Più processi che condividono un firmatario necessitano di una struttura coordinata, mentre un’autorità di firma separata richiede una propria gestione di permessi e ciclo di vita.

Trattare un invio senza risposta come irrisolto

Una risposta persa lascia una domanda sull’azione originaria. Non stabilisce che l’azione sia fallita o che un nuovo ordine sia sicuro. Conserva intenzione persistente e identificatori disponibili dell’ordine prima dell’invio esterno affinché il recupero possa indagare la stessa richiesta economica.

Usa evidenze attuali di conto e ordine per determinare se l’azione abbia creato un ordine passivo, sia stata eseguita, rifiutata o resti ignota. Un identificatore client dell’ordine può aiutare a correlare le registrazioni, ma non dovrebbe essere descritto come garanzia universale che ogni payload ripetuto non abbia effetti aggiuntivi. Segui il comportamento documentato dell’endpoint effettivo.

Finché l’esito è irrisolto, conserva la disponibilità appropriata di risorse ed esposizione. Liberarla immediatamente può consentire a un altro processo di autorizzare una seconda posizione. L’obiettivo del recupero è stabilire cosa il conto potrebbe già detenere, non semplicemente ottenere una risposta riuscita da una nuova richiesta.

Costruire l’esposizione da esecuzioni e ordini residui

Quantità richiesta, quantità eseguita e residuo aperto sono valori separati. Se un ordine ipotetico richiede cinque unità e ne esegue due seguite da mezza unità, il cambiamento della posizione è 2,5 e la quantità richiesta residua è 2,5 finché non viene stabilito lo stato finale dell’ordine.

La revisione del rischio del conto dovrebbe includere sia l’esposizione attuale di 2,5 unità sia il possibile effetto di tale residuo. Una richiesta di annullamento può mirare a rimuovere quest’ultimo, ma la registrazione non dovrebbe cancellarlo prima che lo stato accettato dell’ordine confermi cosa sia accaduto.

Deduplica le evidenze di esecuzione quando i flussi riproducono dati o le query storiche si sovrappongono. Contare due volte la stessa esecuzione di mezza unità sovrastimerebbe la posizione e può portare a un’azione di chiusura sovradimensionata. Conserva un’identità stabile dell’esecuzione e riconcilia i totali con la vista autorevole del conto anziché presumere che ogni messaggio ricevuto descriva una nuova operazione.

Progettare uscite reduce-only per il bot perpetual Hyperliquid

Le uscite reduce-only di un bot di trading perpetual Hyperliquid dovrebbero esprimere l’intenzione di ridurre una posizione esistente senza aprire esposizione nella direzione opposta. Le opzioni attuali degli ordini includono tale controllo. È utile quando un’altra azione potrebbe aver cambiato la posizione prima che l’uscita raggiunga l’esecuzione.

Supponi che un conto fittizio fosse long di tre unità alla preparazione dell’uscita, ma un’altra vendita autorizzata lo abbia ridotto a una. Una vendita non vincolata di tre potrebbe chiudere il long residuo e creare uno short di due unità. Un vincolo reduce-only applicato correttamente affronta tale inversione indesiderata, secondo le regole effettive di accettazione ed esecuzione dell’exchange.

Reduce-only non garantisce che un’uscita si completi o ottenga un prezzo particolare. L’ordine può comunque incontrare liquidità insufficiente di abbinamento, parametri non validi o altre condizioni di rifiuto. Il bot deve riconciliare la posizione residua dopo il tentativo anziché trattare la presenza dell’opzione come prova che il rischio sia scomparso.

Distinguere un trigger d’uscita da un’esecuzione d’uscita

Una condizione stop o take profit può attivare un ordine senza completare una cessione. Riferimento del trigger, condizione di prezzo, tipo d’ordine risultante e dimensione dovrebbero essere espliciti. Scelte diverse creano compromessi diversi tra controllo del prezzo e probabilità di esecuzione in condizioni mutevoli.

Un limite attivato può restare ineseguito se il mercato supera il suo intervallo accettabile. Un’uscita orientata al mercato può affrontare un’esecuzione peggiore del livello osservato del trigger. Nessuna dovrebbe essere presentata come perdita massima garantita o profitto realizzato garantito.

Segui la posizione attraverso attivazione ed esecuzioni successive. Se si chiude soltanto una parte, la quantità residua richiede ancora gestione. Il controllore delle uscite dovrebbe considerare anche attività manuali o azioni di un’altra strategia affinché vecchie dimensioni dei trigger non diventino tacitamente incoerenti con il conto attuale.

Gestire l’annullamento come una corsa con il mercato

Un ordine può essere eseguito mentre una richiesta di annullamento è in transito. La registrazione finale corretta può quindi contenere un’esecuzione parziale e un residuo annullato. Questi esiti sono compatibili; l’annullamento non rimuove retroattivamente l’operazione già avvenuta.

Quando sostituisci un ordine, determina cosa resti della vecchia istruzione prima di decidere la dimensione della sostituzione. Una quantità desiderata locale e il residuo attuale dell’exchange possono divergere durante tale intervallo. Trattare la sostituzione come un ordine estraneo a dimensione piena può creare esposizione eccessiva.

La guida al recupero operativo Hyperliquid spiega perché gli obblighi necessitino di una responsabilità chiara. Un componente dovrebbe decidere come vecchio ordine, esecuzioni intermedie e revisione proposta si combinino. Più processi che riparano indipendentemente lo stesso annullamento possono produrre più incertezza del ritardo originario.

Tenere separata la contabilità del funding del bot perpetual Hyperliquid

Il funding è un componente di flusso di cassa dell’esposizione perpetual, distinto dal guadagno o dalla perdita causati dai prezzi d’ingresso e uscita. L’attuale documentazione sul funding descrive pagamenti tra detentori long e short e usa un nozionale basato sull’oracle nel calcolo del pagamento. Non sostituirlo con un mark visualizzato senza verificare la convenzione effettiva.

Per un intervallo fittizio, due unità a un prezzo oracle di 500 rappresentano 1.000 di nozionale per il funding. Un tasso di pagamento ipotizzato di 0,01% produce un pagamento di 0,1. Sei intervalli identici totalizzerebbero 0,6, ma tassi, prezzi e dimensioni reali delle posizioni possono cambiare tra le osservazioni.

Il tasso d’esempio è inventato e non prevede una direzione del pagamento. Registra accrediti e addebiti effettivi dalle evidenze del conto, collegati al periodo e alla posizione pertinenti. Una previsione del funding può informare una decisione, ma non equivale a funding già guadagnato o pagato.

Tenere separata la contabilità del funding del bot perpetual HyperliquidOpen PositionsWorking OrdersCollateralFundingUnresolved ActionsTRADING FIELD NOTESEDUCATIONAL RESOURCE
Tutte e cinque le registrazioni influenzano una revisione coerente del conto; nessuna può essere dedotta affidabilmente dal solo grafico del prezzo.

Riconciliare risultati di prezzo, commissioni e funding

Mantieni separati i componenti prima di calcolare il risultato netto. In una posizione lunga ipotetica semplificata, due unità entrate a 500 e uscite a 520 producono quaranta di guadagno lordo di prezzo. Se i costi di trading registrati totalizzano tre e il funding netto è un addebito di 1,2, il risultato è 35,8 prima di ogni altro costo applicabile.

Un movimento redditizio del prezzo può quindi coesistere con un guadagno minore del conto e un esito di prezzo piatto può comunque perdere denaro dopo i costi. Il registro dovrebbe rendere visibili tali differenze anziché forzare tutti i cambiamenti del saldo in un unico numero di operazione realizzata.

Usa gli asset effettivi di collaterale e commissioni riportati per mercato e conto pertinenti. Se occorre una conversione nella valuta di rendicontazione, conserva momento della valutazione e quantità originarie. Cambiamenti del valore dell’asset di rendicontazione non dovrebbero essere scambiati per miglioramento dell’esecuzione della strategia perpetual stessa.

Mantenere un registro delle chiusure parziali

Un’uscita parziale dovrebbe allocare coerentemente le condizioni economiche della posizione conservando l’esposizione residua. Considera un long inventato di due unità aperto a 500. Chiudere 0,75 a 510 crea 7,5 di guadagno di prezzo. Le restanti 1,25 chiuse successivamente a 498 perdono 2,5, lasciando cinque di guadagno lordo di prezzo sull’intera posizione.

Se le commissioni combinate sono 1,8 e il funding è un addebito di 0,4, il risultato netto completo è 2,8. Riportare soltanto la prima cessione redditizia sovrastimerebbe sostanzialmente l’esito. Riportare come chiusa l’intera posizione di due unità dopo quella prima esecuzione cancellerebbe anche il rischio residuo.

I metodi del conto possono differire nel modo di presentare ingresso medio e componenti realizzati, quindi la ricostruzione locale dovrebbe seguire la convenzione documentata e riconciliarsi con il conto. Conserva esecuzioni sottostanti e flussi di cassa anche quando il rapporto rivolto all’utente presenta un riepilogo più semplice.

Monitorare il margine senza inventare un cuscinetto fisso di liquidazione

Il rischio di liquidazione dipende da esposizione attuale, relazioni del collaterale e regole di mantenimento. Una distanza percentuale da un vecchio prezzo d’ingresso non è una misura completa. Altre posizioni, funding e cambiamenti del valore del conto possono influenzare le risorse disponibili nella configurazione attiva del margine.

Usa evidenze attuali pertinenti del conto e parametri dello strumento. Una stima calcolata dovrebbe dichiarare le proprie ipotesi e non essere mostrata come garanzia che la liquidazione non possa avvenire prima di un certo prezzo. Cambiamenti rapidi e prezzi di riferimento diversi possono rendere fuorviante un confine semplicistico.

La strategia dovrebbe definire cosa faccia quando le evidenze richieste sul margine non sono disponibili. Continuare ad aggiungere esposizione perché l’ultimo margine di sicurezza registrato sembrava comodo può aggravare l’incertezza. Sospendere nuovo rischio mantenendo osservazione e gestione autorizzata della posizione è diverso dal presumere che una posizione aperta sia diventata sicura soltanto perché il bot è in pausa.

Ricostruire il conto prima di riprendere dopo un riavvio

L’avvio dovrebbe recuperare intenzioni persistenti, identificatori degli ordini accettati, residui aperti, esecuzioni, eventi di funding e trasferimenti pertinenti. Dovrebbe poi confrontare tale ricostruzione con lo stato attuale del conto. Una connessione sana da sola non stabilisce che la strategia conosca i propri obblighi esistenti.

L’attività manuale deve essere inclusa. Se l’utente ha ridotto una posizione mentre il processo era offline, il bot non dovrebbe ripristinare automaticamente la vecchia dimensione per farla coincidere con la memoria locale obsoleta. Il cambiamento esterno del conto è un’evidenza che lo stato operativo è cambiato e potrebbe richiedere una nuova decisione della politica.

Riprendi nuovi ingressi soltanto quando le registrazioni richieste li supportano. Differenze inspiegate dovrebbero restare visibili con un ambito definito d’indagine. Sovrascrivere silenziosamente il registro locale con un unico totale attuale può nascondere esecuzioni duplicate, costi mancanti o un ordine annullato che è stato eseguito parzialmente prima di scomparire dall’elenco degli ordini aperti.

Provare un’uscita interrotta

Un’esercitazione fittizia utile parte da un long di tre unità e una richiesta reduce-only di chiuderne due. La connessione cade dopo l’invio. Durante l’interruzione, vengono eseguite 1,5 unità e l’ordine residuo di mezza unità viene successivamente annullato. La posizione corretta risultante è un long di 1,5 unità, supponendo nessun’altra attività.

Il processo di recupero dovrebbe trovare sia l’esecuzione sia il residuo annullato. Non dovrebbe presumere che le due unità previste siano state chiuse né reinviare una nuova uscita di due unità soltanto perché mancava la risposta originaria. Ogni ulteriore riduzione dovrebbe basarsi sulla posizione attuale di 1,5 unità e sulla politica attiva.

Estendi l’esercitazione riproducendo lo stesso messaggio di esecuzione. L’esposizione dovrebbe restare invariata dopo la deduplicazione. Questo scenario testa insieme diversi confini importanti: identità persistente, esecuzione parziale, annullamento, riavvio e protezione contro un’inversione involontaria. Il test riesce quando il conto finale è spiegato, non quando ogni richiesta risponde velocemente.

Valutare l’automazione dalla posizione che lascia

Un bot perpetual dovrebbe essere giudicato dalla correttezza delle registrazioni di posizione e risorse durante funzionamento ordinario e interrotto. Richieste veloci sono utili soltanto quando l’applicazione può identificare il conto, interpretare ogni esito e spiegare l’esposizione residua.

Esamina insieme tentativi completati e irrisolti. Registra quanto spesso la strategia abbia richiesto recupero, quali ipotesi siano cambiate e se i limiti interni abbiano retto durante la concorrenza. Mantieni le prestazioni di trading separate dalla correttezza operativa affinché un movimento favorevole del mercato non nasconda un ciclo difettoso degli ordini.

Un bot di trading perpetual Hyperliquid comprensibile collega un’intenzione delimitata alle esecuzioni effettive, riconosce il funding come flusso di cassa autonomo e gestisce le uscite rispetto alle posizioni attuali. Tali discipline non possono rimuovere il rischio dei derivati, ma danno all’utente una base coerente per decidere cosa il conto possa fare in seguito.

Continua a imparare

Esplora tutte le risorse