Algoritmo di trading su Solana: seguire una regola dall’inizio alla fine

L’esempio svolto di un algoritmo di trading su Solana richiede uno scopo

Lo scopo di R1 è produrre una proposta esaminabile di riduzione parziale per una posizione già gestita dal flusso operativo. Non scopre nuovi token, non deduce le intenzioni dei trader e non sceglie un intero portafoglio. Questo ambito ristretto mantiene l'esempio concentrato sulla relazione tra le osservazioni e un solo tipo di azione.

L'algoritmo utilizza un mint di token fisso e un'interpretazione di mercato supportata. Osserva preventivi per vendere esattamente 100 token in cambio di un asset di quotazione identificato. Ogni confronto usa la stessa direzione e la stessa quantità. Un preventivo per acquistare 100 token o venderne una quantità diversa non entra nel riferimento come se fosse equivalente.

La precedente guida all'architettura dei bot di trading su Solana separa osservazione, strategia, autorizzazione e riconciliazione. R1 rispetta questi confini. L'attivazione di una regola è una decisione proposta, mentre il risultato sul conto richiede evidenze dalle fasi successive.

Specifica il pacchetto di osservazione

Ogni pacchetto di osservazione contiene l'identità del mint, l'asset di quotazione, la quantità in ingresso, l'importo atteso in uscita, l'orario di osservazione, l'ambito della fonte o del percorso e lo stato dell'interpretazione. Specifica inoltre quali costi siano già riflessi nell'importo in uscita. Il pacchetto dovrebbe essere memorizzato prima di diventare un dato in ingresso alla regola.

Per R1, l'importo in uscita è un preventivo di vendita specifico per la quantità, non un prezzo generale del token. Ciò avvicina maggiormente il confronto alla quantità di riduzione prevista, pur lasciando incertezza sull'esecuzione. Un preventivo è un'evidenza delle condizioni in un momento, non una garanzia di un risultato successivo sul conto.

Il pacchetto richiede un orario di disponibilità chiaro. Un preventivo recuperato dalla cronologia dopo il termine decisionale non può entrare in una riproduzione come se fosse stato noto prima. La traccia delle evidenze del singolo algoritmo parte da ciò che il sistema poteva effettivamente esaminare quando la regola è stata eseguita.

Definisci una finestra di riferimento completata

R1 confronta l'ultimo preventivo idoneo con la media degli importi in uscita di tre precedenti osservazioni completate, selezionate secondo una pianificazione fissa. La pianificazione e la politica di aggiornamento fanno parte della versione della regola. Non vengono scelte successivamente per rendere favorevole il riferimento.

Tutte e tre le osservazioni di riferimento devono soddisfare gli stessi requisiti di identità, quantità, direzione e supporto. Se una manca o non è valida, in questo esempio R1 si astiene. Non accorcia silenziosamente il riferimento e non sostituisce il valore mancante con l'ultimo preventivo.

Un algoritmo più complesso potrebbe utilizzare un altro calcolo, ma la specifica richiederebbe la stessa chiarezza. Il punto non è che tre osservazioni costituiscano un modello predittivo solido. Il punto è che un piccolo calcolo fisso rende facile esaminare il confine dei dati in ingresso e mostra come i dati mancanti modifichino la decisione.

Fissa la cadenza di esame per l’esempio

Per questa specifica svolta, immagina esami programmati ogni cinque minuti. Un esame delle 10:00 utilizza come riferimento i pacchetti di preventivo registrati alle 09:45, 09:50 e 09:55, più un ultimo preventivo separato per l'esame corrente. Ogni pacchetto deve aver rispettato un limite di aggiornamento di un minuto quando è stato accettato al proprio orario di esame; l'ultimo pacchetto deve ancora rispettare quel limite al momento della decisione corrente.

Questi intervalli sono impostazioni illustrative, non frequenze di trading raccomandate. Rendono riproducibile l'esempio e impediscono all'implementazione di selezionare le tre osservazioni storiche che producono un riferimento conveniente. Se un pacchetto programmato non era disponibile, si applica la regola di R1 sui dati mancanti, anziché risalire più indietro senza un cambiamento esplicito di versione.

Esprimi la condizione di attivazione in linguaggio semplice

R1 propone una riduzione quando l'ultimo importo in uscita idoneo supera di almeno il 5% la media dei tre importi di riferimento. La soglia è scelta soltanto a fini illustrativi. Secondo questa regola, l'uguaglianza è sufficiente e il calcolo utilizza i valori registrati non arrotondati prima della formattazione per la visualizzazione.

La condizione descrive una variazione relativa dei ricavi preventivati per la stessa quantità di 100 token. Non afferma che l'intera posizione possa essere venduta al tasso implicito né che sia prevedibile un ulteriore movimento del prezzo. Sarebbero domande diverse, che richiedono evidenze diverse.

La guida ai segnali di trading su Solana spiega perché un rilevamento o una previsione non costituiscano automaticamente un vantaggio economico. L'attivazione di R1 è semplicemente una corrispondenza definita tra un evento e una proposta. La sua utilità richiederebbe una valutazione separata degli esiti, dei costi e del comportamento alternativo che sostituisce.

Calcola a mano l’attivazione

Supponi che gli importi fittizi in uscita del riferimento siano cinquanta, cinquantadue e cinquantuno unità di quotazione. La loro media è cinquantuno. L'ultimo importo in uscita è cinquantaquattro. L'aumento relativo è tre diviso cinquantuno, circa il 5,88%, quindi la condizione numerica di attivazione è soddisfatta con la soglia del 5% di R1.

Il calcolo dovrebbe essere memorizzato insieme agli identificatori dei dati in ingresso. Un revisore può così riprodurlo senza aver bisogno della pagina corrente del mercato. Se un dato viene corretto successivamente, conserva la decisione originale e registra in che cosa differisca il calcolo corretto, anziché riscrivere silenziosamente il risultato precedente.

Questa aritmetica non dimostra che la vendita proposta sia vantaggiosa. Stabilisce soltanto che le osservazioni registrate soddisfano la condizione di attivazione specificata. Le fasi successive verificano se la posizione esista, se la quantità sia disponibile, se il preventivo rimanga aggiornato e se l'azione rispetti la politica del conto.

L’esame della regola dell’algoritmo di trading su Solana include l’idoneità

R1 opera soltanto su una posizione gestita con almeno 300 token disponibili prima della riduzione proposta di 100 token. L'esempio lascia quindi almeno 200 token dopo una riduzione riuscita. Questa regola sulla quantità è illustrativa e appartiene alla definizione della strategia, non è una raccomandazione universale di dimensionamento.

La regola richiede inoltre un'interpretazione supportata del token e del mercato, un riferimento completo, un'ultima osservazione aggiornata e l'assenza di un intento di riduzione irrisolto che prenoti gli stessi token. Se un requisito non è soddisfatto, il risultato indica la motivazione dell'astensione anziché restituire un punteggio zero fuorviante.

L'esame della regola di un algoritmo di trading su Solana dovrebbe verificare questi requisiti prima di esaminare il calcolo della soglia. Un risultato matematicamente corretto del 5,88% non può compensare un mint sbagliato, evidenze obsolete o token indisponibili. L'idoneità determina se il calcolo sia significativo per l'azione prevista.

Mantieni la proposta entro il confine dell’autorità

Quando R1 si attiva, crea una proposta per ridurre la posizione di 100 token. La proposta include la versione della regola, i riferimenti alle evidenze, la quantità, il contesto corrente del preventivo e la scadenza. Non firma né invia autonomamente una transazione.

Un passaggio separato di autorizzazione verifica la politica del conto e lo stato corrente. Il conto può rifiutare la proposta perché un'altra azione ha prenotato token, l'autorità è indisponibile o il percorso proposto esula dall'ambito consentito. Il rifiuto è un esito valido anche quando la regola di osservazione di R1 era soddisfatta.

La guida al sistema di trading su Solana spiega la responsabilità persistente di queste registrazioni. Mantenere separate proposta e autorizzazione consente a un revisore di distinguere un'astensione della strategia da un rifiuto del conto. Questi esiti implicano miglioramenti diversi e non dovrebbero essere compressi in un conteggio generico di operazioni non effettuate.

Ricontrolla il preventivo prima di un tentativo

Il preventivo che ha attivato R1 può scadere prima che l'azione sia pronta per l'invio. Il flusso operativo dovrebbe ottenere evidenze correnti e applicare una politica dichiarata per le variazioni rilevanti. Un'attivazione precedente non dimostra che l'importo in uscita originariamente osservato sia ancora disponibile.

Se il nuovo preventivo non soddisfa più i termini della proposta, l'azione può essere rifiutata o rinviata a una rivalutazione. La politica dovrebbe spiegare se la condizione originale di attivazione debba essere ancora soddisfatta oppure se il tentativo sia governato da un limite di esecuzione autorizzato separatamente. L'esempio non lascia questa scelta a una decisione estemporanea del processo esecutore.

Conserva separatamente il preventivo che ha attivato la regola e quello successivo di esecuzione. La loro differenza è un'evidenza utile del ritardo e della fattibilità. Sostituire il preventivo originale con quello successivo renderebbe più difficile spiegare perché l'algoritmo si sia attivato inizialmente.

Prenota i token per la riduzione autorizzata

Supponi che il conto abbia 500 token disponibili quando viene autorizzata la proposta di 100 token. Il flusso operativo prenota la quantità proposta, così che un'altra regola di uscita non possa presumere indipendentemente che tutti i 500 siano ancora disponibili. Se l'azione si completa come previsto, rimangono 400 token prima di considerare qualsiasi variazione del conto non collegata.

La prenotazione persiste durante il periodo di esito irrisolto del tentativo secondo la politica di riconciliazione. Può essere svincolata quando scade una proposta non inviata o quando evidenze adeguate accertano un esito che ne consente lo svincolo. Il pianificatore non dovrebbe svincolarla soltanto perché inizia un altro intervallo.

La precedente guida al coordinamento tra take profit e stop loss su Solana tratta le condizioni di uscita concorrenti. R1 è una possibile fonte di una proposta di riduzione. La sua implementazione deve cooperare con ogni altra fonte tramite la registrazione condivisa della posizione, anziché gestire i token in isolamento.

Registra l’invio come un tentativo

Il componente di esecuzione registra l'intento autorizzato e il conseguente tentativo di transazione. Conserva l'identità e gli orari necessari per seguirne l'esito. Una risposta di invio riuscita non è di per sé una vendita riconciliata; la documentazione sendTransaction di Solana esplicita questa distinzione. Documentazione Solana sull'invio.

Se la risposta è incerta, il flusso operativo dovrebbe indagare sul tentativo esistente. Non dovrebbe eseguire nuovamente R1 e creare un nuovo intento di vendita soltanto perché la richiesta precedente non ha restituito uno stato finale comodo. La proposta originale e i token prenotati restano parte dello stato del conto.

Questa separazione migliora anche la ricerca. Una proposta generata dall'attivazione, una proposta autorizzata e una riduzione completata sono conteggi diversi. La fattibilità operativa dell'algoritmo può essere valutata soltanto quando la registrazione conserva le transizioni e le motivazioni per cui alcune proposte non diventano mai variazioni del conto.

Riconcilia la posizione dopo l’esito

Una volta accertato l'esito della transazione secondo la politica scelta, confronta l'effetto sul conto con l'intento. Registra la quantità ridotta, i ricavi, i costi e i token gestiti rimanenti. Se il risultato differisce dalle aspettative, conserva la discrepanza e risolvila prima che le azioni dipendenti presumano uno stato privo di problemi.

La posizione non dovrebbe essere indicata come interamente chiusa dopo una riduzione di 100 token da 500. Rimane aperta con la quantità riconciliata. Uno stato di tentativo completato e uno stato di posizione chiusa descrivono oggetti diversi e dovrebbero restare distinti nell'interfaccia e nell'esportazione.

La posizione rimanente influisce anche sulla valutazione successiva di R1. La regola dovrebbe utilizzare i token attualmente disponibili, includendo altre prenotazioni e variazioni esterne. Copiare la quantità originale di 500 token in ogni proposta futura violerebbe proprio la condizione di idoneità stabilita dalla specifica.

Definisci quando la regola può attivarsi nuovamente

Senza una politica di riarmo, R1 potrebbe emettere un'altra riduzione ogni volta che osserva la stessa condizione persistente. Decidi se l'algoritmo consenta riduzioni ripetute, attenda che la condizione si chiuda o richieda un nuovo episodio di riferimento prima che possa aprirsi un'altra proposta.

In questa specifica illustrativa, un episodio di attivazione può avere soltanto un intento di riduzione aperto. Dopo la risoluzione dell'intento, prima che possa iniziare un altro episodio R1 richiede un nuovo esame completo il cui ultimo importo in uscita non superi il riferimento idoneo di oltre il 2%. Tale ripristino chiude la vecchia condizione; un esame successivo deve soddisfare nuovamente la soglia di apertura del 5% per creare un nuovo episodio. I requisiti sui token e sull'autorità continuano ad applicarsi indipendentemente.

Ciò impedisce alle osservazioni ripetute di diventare accumuli accidentali di intenti di uscita. Definisce inoltre l'unità di ricerca: un episodio ha una condizione di apertura, un esito della proposta e una chiusura o un ripristino. Il conteggio delle notifiche e quello delle osservazioni possono così essere separati dal numero di decisioni effettive dell'algoritmo.

Verifica un caso con riferimento incompleto

Rimuovi l'osservazione centrale del riferimento mantenendo l'ultimo importo in uscita a cinquantaquattro. Secondo R1, l'esito atteso è l'astensione perché il riferimento richiesto di tre osservazioni è incompleto. Il sistema non dovrebbe fare la media di cinquanta e cinquantuno e affermare che la regola originale sia stata comunque eseguita.

La registrazione dovrebbe identificare il dato mancante e conservare l'ultima osservazione valida per la ricerca successiva. Una volta arrivata l'osservazione mancante, il sistema può ricostruire il calcolo precedente, ma si tratta di un risultato retrospettivo. Non diventa un segnale che fosse disponibile in tempo reale al momento della decisione originale.

Questo caso verifica il confine informativo anziché l'aritmetica. Un programma può calcolare correttamente una media violando comunque la regola tramite l'uso di dati incompleti o arrivati in ritardo. Una verifica significativa controlla che i dati in ingresso fossero idonei prima di controllare il risultato numerico.

Verifica un caso con preventivo obsoleto e disponibilità di token modificata

Mantieni poi completo il riferimento, ma rendi l'ultimo preventivo più vecchio del limite di aggiornamento di R1. L'esito atteso è l'astensione o la scadenza della proposta, a seconda della fase. Una schermata appena visualizzata non dovrebbe aggiornare l'età del preventivo sottostante.

Ripristina poi un preventivo aggiornato riducendo i token disponibili al di sotto di 300 mediante una variazione esterna controllata. La condizione numerica di attivazione può essere ancora soddisfatta, ma l'idoneità della posizione viene meno. La registrazione dovrebbe identificare la condizione sulla quantità, anziché fingere che il segnale sia scomparso perché il mercato è cambiato.

Questi casi mostrano perché le regole di osservazione e lo stato del conto debbano restare collegati. Lo stesso pacchetto di mercato può produrre esiti consentiti diversi quando cambiano i token disponibili o l'autorità. Non è un'incoerenza: è il comportamento previsto di un flusso operativo algoritmico completo con prerequisiti espliciti.

Confronta R1 con un’alternativa definita

Per valutare l'utilità di R1, scegli un comportamento di riferimento con le stesse ipotesi di conto, osservazione e costo. L'alternativa potrebbe essere una riduzione fissa programmata o l'assenza di riduzioni fino a un successivo esame dichiarato in anticipo. La scelta dovrebbe corrispondere alla domanda di ricerca ed evitare il senno di poi.

La guida agli algoritmi di trading su Solana sviluppa confronti equi tra regole. R1 non dovrebbe ricevere preventivi più favorevoli, un budget maggiore o un orizzonte di uscita diverso dall'alternativa, a meno che tale differenza non faccia esplicitamente parte dello studio.

Il confronto dovrebbe includere le riduzioni proposte ma non eseguite, i token rimanenti e i costi. Guardare soltanto alle riduzioni completate può nascondere i casi in cui la regola si è attivata ma l'azione era impraticabile. Un percorso completo del conto è più informativo di una raccolta di esempi riusciti isolati.

Blocca la regola prima di un esame successivo

La specifica finale di R1 include l'universo considerato, la quantità del preventivo, la selezione del riferimento, la soglia, l'idoneità, la scadenza, il riarmo, il passaggio all'autorizzazione e la contabilizzazione degli esiti. Blocca questa definizione completa prima di esaminare un periodo di valutazione successivo. Cambiare anche un solo prerequisito nascosto può modificare sostanzialmente il risultato.

La precedente guida al flusso di ricerca su Solana spiega perché contino i termini temporali e le regole fisse. Se il periodo successivo rivela un difetto o un risultato poco interessante, documenta la revisione come R2 e identifica quali evidenze siano state utilizzate per sceglierla.

Una regola rivista dopo aver esaminato una finestra di valutazione non dovrebbe mantenere l'affermazione secondo cui quella stessa finestra avrebbe validato indipendentemente la versione rivista. La registrazione può comunque essere un'evidenza utile per lo sviluppo. Una gestione onesta delle versioni conserva ciò che la ricerca ha appreso senza far apparire la regola finale come selezionata in anticipo.

Scomponi l’esame degli esiti

Esamina se R1 abbia ricevuto evidenze complete, calcolato correttamente l'attivazione, prodotto la proposta prevista, superato l'autorizzazione, raggiunto un esito accertato del tentativo e riconciliato la posizione. Un fallimento in ciascuna fase ha un significato diverso. Una formula corretta non dimostra la correttezza del flusso operativo completo.

Valuta poi separatamente la questione economica: che cosa ha modificato la riduzione rispetto all'alternativa definita, dopo i costi e lungo lo stesso percorso del conto? La risposta può essere favorevole, sfavorevole o inconcludente. L'interpretabilità dell'algoritmo non ne garantisce il valore.

Un rapporto utile può quindi affermare che l'implementazione corrispondeva alla specifica mentre la strategia non ha raggiunto l'obiettivo di ricerca. Può anche individuare un difetto operativo prima di formulare qualsiasi affermazione economica. Mantenere separate queste conclusioni indirizza il miglioramento verso la fase effettivamente indicata dalle evidenze.

Conserva un esempio completo per le modifiche future

Conserva la sequenza svolta dei preventivi di cinquanta, cinquantadue, cinquantuno e cinquantaquattro, con il calcolo atteso del 5,88% e i relativi casi di idoneità. Aggiungi le registrazioni della proposta, dell'autorizzazione, del tentativo e della riconciliazione provenienti da un'esecuzione controllata. Si crea così un riferimento compatto per le successive modifiche dell'implementazione.

Il riferimento dovrebbe includere gli esiti senza azioni oltre al percorso riuscito. Le versioni future possono essere verificate rispetto alle differenze previste, conservando i confini che dovrebbero restare stabili. Un esame di regressione è più utile quando verifica un comportamento significativo anziché limitarsi a rispecchiare l'implementazione più recente.

Un algoritmo di trading su Solana diventa esaminabile quando la sua catena completa è esplicita. Una regola semplice può dimostrare questa disciplina: le evidenze osservate entrano in un calcolo fisso, l'idoneità ne limita l'uso, l'autorità controlla l'azione e la riconciliazione del conto ne accerta la conseguenza. La stessa chiarezza rimane preziosa quando l'algoritmo finale è più complesso.