Il software di trading automatizzato di criptovalute dovrebbe essere specificato attraverso comportamenti osservabili. Un requisito come eseguire efficientemente sembra utile, ma non indica a un revisore che cosa debba fare il programma quando una quotazione scade, i fondi sono già riservati o la risposta a un invio scompare. Un requisito verificabile nomina input, transizione consentita ed evidenze che stabiliscono il risultato.
Questa guida sviluppa un test di accettazione dell’automazione attento ai costi usando un conto spot fittizio. I numeri sono inventati per rendere riproducibile la contabilità. Non rappresentano un tariffario attuale o un rendimento atteso. L’obiettivo è determinare se il software rispetti le proprie regole dichiarate e conservi lo stato del conto. Superare tale test dimostra il comportamento operativo, non la redditività della strategia di trading.
I requisiti del software di trading automatizzato di criptovalute iniziano dagli invarianti
Un invariante è una condizione che dovrebbe rimanere vera attraverso eventi ordinari e guasti. Un esempio utile è che il contante totale impegnato non debba superare le risorse disponibili autorizzate. Un altro è che la stessa intenzione durevole non debba creare un ordine aggiuntivo soltanto perché un evento viene consegnato due volte. Queste affermazioni sono più forti di una raccolta di schermate del percorso ideale perché valgono in tutto il flusso.
Scrivi invarianti in un linguaggio esaminabile da un revisore. Il sistema deve identificare il conto prima di riservare capitale. Un esito sconosciuto dell’ordine deve mantenere la propria riserva. Una nuova configurazione non deve riscrivere la motivazione collegata a un’intenzione precedente. Ogni affermazione dovrebbe identificare quali evidenze mostrerebbero una violazione. Se nessuna osservazione possibile può smentire un requisito, probabilmente è troppo vago per l’accettazione.
La precedente guida al ciclo di vita del trading automatizzato separa configurazione, osservazione e attività del conto. Usa queste fasi nell’assegnazione dei requisiti. Un componente della strategia può proporre un’azione, ma un componente indipendente di rischio decide se rispetti i limiti del conto. Tenere separate queste responsabilità rende più facile spiegare perché un’osservazione apparentemente attraente non abbia portato all’esecuzione.
Definisci precisamente il conto fittizio
Ipotizza che un conto inizi con 2.000 unità di quotazione e nessuna posizione nell’asset selezionato. Di tale saldo, 200 unità sono riservate come cuscinetto operativo e 300 sono già impegnate in un’altra intenzione attiva. La nuova decisione inizia quindi con 1.500 unità di capacità secondo la politica dichiarata. Queste categorie dovrebbero rimanere distinguibili in ogni schermata ed esportazione.
La nuova strategia propone di acquistare al massimo 80 unità dell’asset a un prezzo limite di 10 unità di quotazione ciascuna. Per questo esercizio, ipotizza una commissione di trading di un decimo dell’uno percento addebitata nell’asset di quotazione e una spesa di esecuzione di 2 unità modellata separatamente. La nuova riserva massima è 800 più 0,80 più 2, cioè 802,80 unità di quotazione. I costi effettivi della piattaforma devono essere verificati separatamente.
Registra il caso predisposto come input di test immutabile. Includi identificatore del conto, identità dell’asset, identità della quotazione, saldi iniziali, impegni esistenti e ipotesi sulle commissioni. Una schermata del risultato finale non basta per riprodurre il test. Un revisore successivo deve sapere quali risorse fossero disponibili prima della nuova decisione e quali costi fossero inclusi nel budget di autorizzazione.
Specifica che cosa il segnale possa proporre
Il segnale dovrebbe produrre una proposta contenente motivo, timestamp delle evidenze ed esposizione richiesta. Non dovrebbe creare un saldo, alterare le autorizzazioni del conto o presumere che un ordine sia stato eseguito. Nel caso fittizio, il segnale propone l’acquisto di 80 unità perché è soddisfatta una condizione osservativa dichiarata in anticipo. L’esercizio di accettazione non deve affermare che tale condizione abbia valore predittivo.
Una proposta dovrebbe identificare la versione delle evidenze usata per calcolarla. Se l’osservazione sottostante viene rivista, conserva la proposta originale e crea una nuova valutazione anziché sostituire silenziosamente la cronologia. Questo conta quando si esamina perché il sistema abbia agito. Una decisione non può essere valutata equamente rispetto a informazioni divenute disponibili soltanto dopo l’autorizzazione.
La guida all’automazione delle criptovalute spiega come dividere un ampio obiettivo di automazione in responsabilità circoscritte. Applica qui tale divisione: il segnale propone, il livello di rischio controlla, il livello delle riserve impegna capacità e il livello di esecuzione tenta l’azione consentita. I nomi possono differire fra implementazioni, ma le responsabilità dovrebbero rimanere visibili nel record di accettazione.
L’autorizzazione deve includere il budget completo
Il controllo del rischio confronta la riserva massima di 802,80 unità con la capacità disponibile di 1.500 unità. Secondo la politica fittizia, la proposta rientra e lascia 697,20 unità disponibili per altra nuova attività. Un test dovrebbe verificare entrambi i numeri. Controllare soltanto che il nozionale richiesto di 800 sia inferiore al saldo totale ometterebbe commissioni, cuscinetto operativo e impegno precedente.
Definisci se l’accantonamento per le commissioni sia un limite rigido o una stima. Se l’esecuzione effettiva può superare il budget autorizzato, il software richiede un altro vincolo applicabile o una regola di rifiuto. Definire stimato un costo non concede autorità illimitata. Il record di accettazione dovrebbe spiegare che cosa accada se la quotazione finale o la spesa di transazione superano l’ipotesi usata durante l’autorizzazione.
Verifica anche un valore limite. Aumenta l’importo proposto finché la riserva supererebbe la capacità di una piccola quantità. Il risultato atteso è un rifiuto documentato o una nuova proposta esplicitamente consentita dalla politica. Un ridimensionamento silenzioso non è automaticamente accettabile perché cambia la decisione originale. Se il ridimensionamento è supportato, regole e importo risultante dovrebbero far parte del requisito dichiarato.
Il software di trading automatizzato di criptovalute richiede identità durevoli
Assegna alla decisione un identificatore dell’intenzione prima dell’invio. L’identificatore dovrebbe collegare osservazione originale, autorizzazione del conto, riserva di capitale e tentativi risultanti di esecuzione. Un identificatore separato dell’ordine o transazione può apparire dopo che la richiesta raggiunge il sistema di esecuzione. Conserva entrambi affinché l’applicazione distingua la propria decisione durevole da una rappresentazione esterna di tale decisione.
Consegna due volte lo stesso evento di input durante il test. La seconda consegna dovrebbe trovare l’intenzione esistente, non riservare altre 802,80 unità. È una condizione importante di accettazione perché molti sistemi di dati possono riconsegnare eventi dopo una riconnessione. Il trasporto duplicato non equivale a una seconda opportunità economica e il conto non dovrebbe dedurre una nuova autorizzazione dalla sola consegna ripetuta.
La precedente guida al coordinamento multi-wallet è utile quando sono coinvolti più processi dei conti. L’identità di un’intenzione deve avere un ambito sufficientemente attento da evitare confusione fra conti impedendo comunque lavoro duplicato nel conto previsto. Un’etichetta globalmente unica è utile, ma il requisito reale è coerenza di titolarità e interpretazione lungo tutto il flusso.
Modella un’esecuzione parziale senza perdere il residuo
Supponiamo ora che l’ordine ipotetico esegua 50 unità a 9,90. Il costo nozionale è 495. Al tasso ipotizzato, la commissione dell’esecuzione è 0,495. Se la spesa di esecuzione di 2 unità viene sostenuta per questo tentativo, la parte completata ha consumato 497,495 unità di quotazione. Il conto ha acquisito 50 unità, non le 80 originariamente richieste.
Le restanti 30 unità sono ancora associate all’ordine attivo. Il loro nozionale massimo è 300 al prezzo limite e la commissione massima ipotizzata è 0,30. Mantieni una riserva di 300,30 unità per tale residuo secondo il modello di costo di questo esercizio. La differenza fra riserva originale e costi completati più riserva rimanente è 5,005 unità, riflettendo prezzo di esecuzione migliorato e commissione inferiore sulla quantità eseguita.
Il test dovrebbe verificare esplicitamente la politica di rilascio. Alcuni sistemi mantengono l’intera riserva originale fino al completamento per semplicità. Altri rilasciano gradualmente capacità eccedente confermata. Entrambi gli approcci richiedono una specifica chiara. Il requisito critico è che il sistema non rilasci mai denaro ancora necessario per un residuo attivo o irrisolto e non tratti mai una quantità ineseguita come asset posseduto.
La cancellazione è una richiesta con un proprio esito
Dopo l’esecuzione parziale, la strategia richiede la cancellazione delle restanti 30 unità. Tale richiesta non dimostra istantaneamente che l’ordine sia scomparso. Il sistema di esecuzione può confermare la ricezione prima di riportare uno stato finale e durante l’intervallo può verificarsi un’altra esecuzione. Lo scenario di accettazione dovrebbe includere tale possibilità anziché presumere che la cancellazione sia una gomma sincrona.
Per il caso base, stabilisci che la cancellazione sia confermata senza ulteriori esecuzioni. La riserva residua di 300,30 unità può quindi essere rilasciata. Il conto conserva le 50 unità acquisite e il costo completato di 497,495 unità. L’impegno non collegato di 300 unità e il cuscinetto operativo di 200 unità rimangono invariati. Un residuo cancellato non annulla l’acquisto precedente né le spese sostenute.
Aggiungi una seconda variante nella quale altre cinque unità vengono eseguite prima che la cancellazione si completi. Il sistema deve incorporare tali unità e i costi effettivi prima di determinare l’importo finale rilasciato. Il risultato atteso dovrebbe essere calcolato dalle nuove evidenze di esecuzione, non dal momento in cui l’operatore ha premuto annulla. Questa variante verifica se l’implementazione segua eventi economici anziché intenzioni dell’interfaccia.
Presenta nuovi clienti e guadagna USDC
Presenta nuovi clienti e guadagna USDCIl nostro programma di affiliazione paga in tempo reale.
Metti alla prova un esito sconosciuto dell’invio
Uno scenario di ripristino del trading automatizzato dovrebbe interrompere la comunicazione immediatamente dopo l’invio. L’infrastruttura di test registra che la richiesta può aver raggiunto il sistema di esecuzione, mentre l’applicazione non riceve alcuna risposta definitiva. Lo stato richiesto è irrisolto, con riserva conservata. Non dovrebbe essere creato un nuovo ordine economico soltanto perché la chiamata originale ha restituito un errore o è andata in timeout.
Il ripristino cerca l’esito esistente usando qualunque riferimento durevole supportato dall’integrazione. Può esaminare cronologia del conto, ordini aperti o stato della transazione. La specifica dovrebbe descrivere quali evidenze siano sufficienti per classificare il tentativo come accettato, respinto, completato o ancora sconosciuto. Dovrebbe anche descrivere come venga sottoposta ad attenzione superiore l’incertezza quando le fonti disponibili discordano o rimangono incomplete.
La guida al bot di arbitraggio crypto mostra perché un invio irrisolto abbia conseguenze particolarmente importanti quando un’altra gamba può essere stata eseguita. Lo stesso principio si applica a questo esempio di ordine singolo. Un timeout cambia ciò che l’applicazione sa. Non cambia necessariamente ciò che il conto esterno ha fatto, quindi il test di accettazione deve tenere separati questi due fatti.
Misura i costi senza trasformare una stima in un fatto
Dopo la riconciliazione, sostituisci i costi stimati di esecuzione con gli importi osservati conservando la stima originale per confronto. Questo permette a un revisore di vedere se il modello di budget fosse prudente, accurato o incompleto. Un solo campo sovrascritto da stima a valore effettivo distrugge tali evidenze e rende più difficile migliorare le ipotesi future di costo.
Nel caso fittizio di esecuzione parziale, il costo totale osservato è 497,495 unità sotto le ipotesi dichiarate. Dividerlo per 50 dà 9,9499 unità di quotazione per unità di asset acquisita quando la spesa fissa viene allocata a quell’acquisto. Il prezzo medio di negoziazione rimane 9,90. Entrambi i numeri possono essere utili, ma dovrebbero avere etichette diverse perché uno include costi e l’altro no.
La guida al software di arbitraggio crypto esplora perché questa distinzione conti quando uno spread apparente è piccolo. Per l’accettazione, il comportamento importante è una contabilità riproducibile. Il software non dovrebbe alternare misure lorde e comprensive dei costi secondo quale appaia migliore. Una definizione stabile permette al revisore di confrontare economia attesa e record effettivo del conto.
Verifica evidenze obsolete e configurazione mutevole
Crea un caso nel quale l’osservazione scada fra proposta e autorizzazione. Il comportamento atteso dovrebbe essere un nuovo controllo, un rifiuto o un’altra transizione esplicitamente consentita. L’applicazione non dovrebbe interpretare l’esistenza di un segnale un tempo valido come autorità permanente. Il limite di età delle evidenze deve appartenere alla regola decisionale e comparire nel record di rifiuto.
Poi cambia la configurazione della strategia mentre un’intenzione è in sospeso. L’intenzione esistente dovrebbe rimanere associata alla versione che l’ha autorizzata salvo modifica attraverso un processo documentato di emendamento. Una nuova configurazione può governare decisioni future senza riscrivere il passato. È particolarmente importante quando un revisore cerca successivamente di riprodurre perché il sistema abbia impegnato un importo specifico.
Un test utile distingue archiviazione della configurazione e attivazione. Salvare un limite rivisto non significa necessariamente che ogni componente in esecuzione lo abbia adottato. Il software dovrebbe esporre la versione attiva e il punto in cui la modifica entra in vigore. Altrimenti un operatore può credere in vigore una restrizione mentre un processo continua a usare un insieme precedente di autorizzazioni.
Includi casi negativi che insegnino qualcosa
I test negativi dovrebbero mirare a modalità di guasto significative. Un’identità di asset non supportata, una risorsa di transazione esaurita, un’istantanea obsoleta del conto e un budget sovraimpegnato verificano ciascuno un confine diverso. Una grande raccolta di input non validi quasi identici può produrre un conteggio impressionante di test senza migliorare la fiducia nel comportamento economico del sistema.
Per ogni caso negativo, specifica che cosa debba rimanere invariato. Una proposta respinta non dovrebbe acquisire un identificatore di ordine attivo, consumare un’allocazione di trading o apparire come operazione completata. Può comunque creare un record di audit e un costo operativo, secondo il punto in cui avviene il rifiuto. La distinzione dovrebbe essere esplicita affinché il test non confonda conservazione delle evidenze e attività non autorizzata sul conto.
La precedente scheda di valutazione delle evidenze per il software di trading offre una struttura utile di valutazione. Applicala a comportamenti dimostrati anziché a copertura rivendicata. Un test fallito è informazione preziosa quando identifica un requisito chiaribile o un difetto di implementazione correggibile prima di un uso più ampio.
Riproduci il risultato dal registro
Alla fine della sessione di accettazione, esporta il registro e ricostruisci il conto senza affidarti all’applicazione dal vivo. Il revisore dovrebbe identificare saldo iniziale di 2.000 unità, riserve separate, 50 unità acquisite, costo completato e residuo rilasciato. Ogni conclusione dovrebbe rimandare a un evento registrato o un’ipotesi dichiarata.
Questa ricostruzione verifica più della contabilità. Rivela se il software conservi la cronologia e se le etichette degli eventi significhino ciò che dichiarano. Un evento inviato non dovrebbe essere contato come esecuzione. Una richiesta di cancellazione non dovrebbe essere contata come cancellazione confermata. Un aggiornamento della valutazione non dovrebbe cambiare il numero di unità dell’asset possedute. Il registro dovrebbe mantenere tali distinzioni anche dopo che l’interfaccia le semplifica.
Un revisore dovrebbe anche poter identificare lacune. Se una spesa di esecuzione è indisponibile, l’esportazione dovrebbe indicare che la contabilità dei costi è incompleta anziché inserire zero. Mancante è uno stato diverso da zero misurato. Conservare tale distinzione permette al titolare del conto di valutare i limiti pratici del risultato senza inventare precisione.
Registra l’accettazione senza rivendicare il successo della strategia
Un rapporto di accettazione dovrebbe nominare insieme dei requisiti, casi di test predisposti, versione del software e risultati osservati. Dovrebbe identificare limiti rimanenti e condizioni nelle quali un risultato richiederebbe un nuovo test. Un cambiamento nei significati degli ordini, nelle autorizzazioni del conto o nella gestione dei costi può invalidare un risultato precedente di accettazione anche se le impostazioni visibili della strategia rimangono uguali.
Superare questi scenari stabilisce che il sistema si comporti coerentemente con il flusso specificato. Non stabilisce che il segnale preveda prezzi futuri o che l’allocazione selezionata sia appropriata per una persona particolare. Sono domande separate di ricerca e decisione. Tenerle separate impedisce che una dimostrazione tecnicamente riuscita diventi un’affermazione economica non supportata.
Il risultato pratico è un piccolo pacchetto ripetibile di evidenze: requisiti, input fittizi, transizioni attese, record osservati e aritmetica riconciliata. Con tale pacchetto, un altro revisore può capire che cosa sia stato chiesto al software e perché il risultato conti come superamento o fallimento. È una base più solida per l’automazione della fiducia costruita da una dimostrazione senza interruzioni.
Conserva la differenza fra orologio del test e orologio del mercato
Un caso riproducibile dovrebbe controllare esplicitamente il tempo. Il test deve sapere quando sia avvenuta un’osservazione, quando sia diventata disponibile all’applicazione e quando sia stata valutata l’azione proposta. Possono essere tre momenti diversi. Se una riproduzione usa un valore storico corretto prima che tale correzione arrivasse originariamente, può far apparire la decisione meglio informata di quanto potesse esserlo qualunque operatore reale.
Usa la stessa distinzione nel simulare interruzioni. Fai avanzare l’orologio del test trattenendo un aggiornamento del conto, poi verifica che la politica sullo stato obsoleto si attivi al confine previsto. Riprendi il flusso con eventi in ritardo e controlla se l’applicazione conservi le loro ore originali. Questo esercizio può scoprire un sistema che etichetta come aggiornata una vecchia osservazione soltanto perché ricevuta dopo la riconnessione.
Infine, conserva l’ordine degli eventi che condividono un timestamp visualizzato. Secondi arrotondati possono nascondere la sequenza fra esecuzione, richiesta di cancellazione e aggiornamento del saldo. Un riferimento durevole di sequenza o un record temporale più preciso aiuta a riprodurre il risultato. L’accettazione dovrebbe stabilire su quali evidenze di ordinamento si basi l’implementazione e come si comporti quando tali evidenze sono incomplete.