Evitare ordini duplicati crypto con un controllo API più solido
Chi usa un bot o un'integrazione API può vedere una risposta mancante proprio nel momento più delicato: la richiesta di acquisto o vendita è partita, ma la connessione scade prima che il client riceva la conferma. Inviare subito la stessa richiesta sembra una soluzione rapida, ma può creare due ordini. Evitare ordini duplicati crypto richiede una procedura di verifica, non un semplice nuovo tentativo.
Perché un timeout non prova che l'ordine sia fallito
Una richiesta attraversa il client, la rete, l'API dell'exchange e il motore di matching. Il timeout può verificarsi dopo l'accettazione dell'ordine, durante la risposta o mentre il sistema sta aggiornando lo storico. Il programma vede un errore di trasporto, mentre l'exchange può aver già registrato l'ordine. Per questo bisogna distinguere tra rifiuto esplicito, risposta persa e stato ancora sconosciuto.
Prima di ritentare, salva l'orario, il mercato, il lato, la quantità, il prezzo, il tipo di ordine e l'identificativo della richiesta. Un log completo rende possibile una ricerca successiva e impedisce che una funzione di retry trasformi un problema di rete in una posizione doppia.
Evitare ordini duplicati crypto con un client order ID
Molti exchange permettono di associare alla richiesta un identificativo scelto dal client, spesso chiamato client order ID o con un nome simile. Genera un valore unico per ogni intenzione operativa, non per ogni tentativo di trasmissione. Se il processo ritenta la stessa intenzione dopo un timeout, deve riutilizzare lo stesso identificativo e non crearne uno nuovo.
L'ID dovrebbe collegarsi a un record locale che contiene mercato, direzione, quantità, limite, strategia e timestamp. Non inserire dati sensibili nell'identificativo. Conserva inoltre la risposta dell'exchange quando arriva e marca il record come eseguito, rifiutato, cancellato o ancora da verificare. La documentazione ufficiale di ogni piattaforma stabilisce formato, lunghezza, unicità e comportamento dell'ID: non assumere che la regola sia identica ovunque.
La sequenza corretta dopo una risposta assente
- Blocca il retry automatico per quella intenzione e conserva il payload originale.
- Interroga lo stato dell'ordine usando l'identificativo client, se l'exchange lo supporta.
- Controlla anche gli eseguiti recenti e il saldo disponibile, perché un ordine può essere parzialmente riempito.
- Invia una nuova richiesta solo se la piattaforma conferma che la prima non esiste o è stata rifiutata.
- Registra l'esito e fai scattare un alert se lo stato resta sconosciuto oltre la soglia stabilita.
La ricerca dello stato deve essere idempotente quanto l'invio. Un retry con un nuovo ID prima di aver completato questa sequenza non è una protezione: è una seconda intenzione operativa.
Separare rete, API e motore di matching
Non tutti gli errori hanno lo stesso significato. Un errore DNS o una connessione interrotta indica che la risposta non è arrivata; un codice di validazione indica invece che l'exchange ha esaminato la richiesta. Un rate limit richiede attesa e backoff, mentre una firma non valida richiede correzione del client. Classificare l'errore prima del retry evita di ripetere una richiesta non valida o di bombardare l'endpoint.
Usa un backoff con limite massimo e jitter, ma non trattarlo come conferma dell'esito. Dopo ogni pausa, effettua prima una lettura dello stato. I websocket possono ridurre la latenza degli aggiornamenti, ma non devono essere l'unica fonte: in caso di disconnessione, ricostruisci lo stato con una richiesta REST e confronta l'ultimo aggiornamento ricevuto.
Testare la protezione senza mettere a rischio capitale
Prima dell'uso reale, prova timeout simulati, risposte duplicate, riavvio del processo, messaggi websocket fuori ordine e riempimenti parziali. Usa un ambiente di prova quando disponibile e poi una quantità minima su un mercato liquido. Verifica che due retry della stessa intenzione producano al massimo un ordine riconoscibile e che un nuovo ordine legittimo riceva un ID diverso.
Imposta anche un limite di esposizione giornaliero e un interruttore manuale. Se il saldo o il numero di ordini non coincide con il registro locale, sospendi l'invio e fai una riconciliazione. Un sistema di esecuzione prudente preferisce restare fermo davanti a uno stato incerto piuttosto che raddoppiare una posizione.
Checklist prima di attivare un retry
- Il payload originale è stato salvato senza modifiche?
- Il client order ID è legato all'intenzione e viene riutilizzato?
- Hai consultato stato, eseguiti e saldo prima di un nuovo invio?
- L'errore è classificato e il rate limit viene rispettato?
- Il limite di esposizione blocca il bot se la riconciliazione fallisce?
Gli exchange cambiano endpoint, campi e regole: consulta sempre la documentazione ufficiale prima di aggiornare il codice. Le criptovalute sono volatili e rischiose; questo articolo è informativo, non è consulenza finanziaria e non garantisce esecuzioni o risultati. Ridurre i duplicati migliora il controllo operativo, ma non elimina il rischio di mercato, liquidità o controparte.
Continua con le guide di esecuzione
Per approfondire i controlli su esecuzione e gestione del rischio, esplora l'hub CryptoSigy dedicato a rischio ed esecuzione e leggi le altre guide crypto in italiano.
