Collegare un bot di trading all’API WEEX: checklist del rischio in 12 punti

Collegare un bot di trading all’API WEEX è una decisione sulle autorizzazioni, sui limiti di frequenza e sulla gestione dei guasti, e la maggior parte delle perdite dei bot deriva dal fatto che uno dei tre aspetti viene trascurato. La checklist seguente copre tutti i dodici elementi da confermare prima che un bot esegua il primo ordine reale: come sono definiti e vincolati i permessi della chiave API, come il bot gestisce il limite di peso per IP e il limite di ordini per account di WEEX, cosa accade quando l’orologio va fuori sincrono o la connessione cade, come fermarlo e se sta ancora utilizzando una versione dell’API esistente dopo il 30 settembre. Ogni punto indica cosa controllare, perché è importante nello specifico su WEEX e come verificare che sia completato. Esegui prima l’intero elenco sull’account demo; gli endpoint simulati dell’API futures rendono l’operazione semplice.

Controlli della chiave e dei permessi (1–4)

1. La chiave ha esattamente l’ambito necessario al bot. Le chiavi WEEX sono impostate per impostazione predefinita su Read Only e possono avere un ambito di trading Spot o Futures/Contract. Un bot grid spot riceve Spot; un bot per i perpetual riceve Futures/Contract; nessuno dei due riceve entrambi. WEEX non offre un ambito per i prelievi, eliminando lo scenario peggiore, ma una chiave di trading sul mercato sbagliato può comunque perdere denaro che non intendevi esporre. Verifica completata: l’elenco dei permessi della chiave mostra un solo ambito di trading.

2. La chiave è vincolata all’IP del bot. Per un bot gestito autonomamente, vincolala all’indirizzo statico del VPS. Per una piattaforma di bot ospitata, vincolala agli indirizzi IP pubblicati dalla piattaforma per il traffico in uscita; se una piattaforma non può fornire un elenco stabile, è un motivo per rivalutarla, non per lasciare aperta la chiave. La documentazione WEEX descrive le chiavi non vincolate come un rischio di sicurezza. Verifica completata: una chiamata di prova da qualsiasi altro IP viene rifiutata.

3. La chiave è dedicata a questo bot. Una chiave per bot e per macchina, tra i 10 gruppi consentiti da WEEX. Quando qualcosa va storto vorrai revocare un bot senza fermare gli altri e avere una cronologia degli ordini che indichi quale bot ha fatto cosa. Verifica completata: il nome della chiave identifica bot e host.

4. Secret e passphrase sono conservati in un archivio di segreti. Non nel codice sorgente del bot, non in uno screenshot e non nella chat dell’assistenza della piattaforma. La passphrase non può essere recuperata, quindi va conservata insieme alla SecretKey. Verifica completata: un nuovo clone del repository del bot non contiene credenziali.

Controlli dei limiti e dell’orologio (5–7)

5. Il bot legge gli header dei limiti di WEEX. La maggior parte degli endpoint REST è limitata per IP in base al peso; l’invio degli ordini è limitato per account nel bucket ORDERS. Il superamento di uno dei due limiti restituisce HTTP 429 e impone un ban di 10 secondi. Le risposte includono X-USED-WEIGHT e X-REMAINING-WEIGHT per gli endpoint con peso e X-ORDER-COUNT e X-ORDER-REMAINING per gli endpoint degli ordini, con intervalli di secondo, minuto, ora e giorno. Un bot che rallenta quando il budget residuo è basso evita il ban; un bot che riprova dopo un 429 lo prolunga. Verifica completata: i log mostrano che il bot si limita prima del 429 e che un 429 attiva una pausa anziché un ciclo di retry.

6. Più bot sullo stesso IP condividono un unico budget. Poiché il limite di peso è per IP, tre bot sullo stesso VPS competono per la stessa disponibilità, mentre ciascuno ha un proprio budget di ordini per account solo se opera con account diversi. Verifica completata: hai sommato la frequenza di polling di ogni processo sull’host e questa rientra nel budget IP con margine.

7. L’orologio dell’host è sincronizzato. WEEX rifiuta le richieste il cui timestamp differisce di oltre 30 secondi dall’ora del server. La deriva dell’orologio produce errori di autenticazione intermittenti che sembrano problemi della chiave e, peggio, può lasciare un bot incapace di annullare gli ordini già piazzati. Verifica completata: NTP è attivo e il bot recupera l’ora del server all’avvio e dopo ogni rifiuto del timestamp.

Controlli degli ordini e dei guasti (8–10)

8. Gli ordini sono idempotenti. Ogni richiesta d’ordine contiene un newClientOrderId generato in modo deterministico dal segnale, quindi un retry dopo un timeout non può causare una doppia esecuzione. WEEX accetta client ID da 1 a 36 caratteri appartenenti a un set limitato. Verifica completata: terminare il bot durante una richiesta e riavviarlo non crea un ordine duplicato.

9. Il bot si riconcilia con l’exchange, non con la propria memoria. Dopo ogni riconnessione o riavvio, il bot interroga posizioni e ordini aperti su WEEX e li considera la verità. Un bot che si fida del proprio registro interno dopo un crash coprirà una posizione che non esiste più o ne lascerà aperta una che crede chiusa. Verifica completata: un riavvio forzato durante una posizione aperta produce lo stato corretto entro un ciclo di polling.

10. Esiste un kill switch che hai davvero testato. Due livelli. Nel bot: dimensione massima della posizione, perdita giornaliera massima e frequenza massima degli ordini; il superamento di ciascuno ferma il trading e annulla gli ordini aperti. Fuori dal bot: sai che eliminare la chiave API nella pagina API Management di WEEX lo ferma istantaneamente e lo hai fatto una volta sulla demo per vedere il comportamento del bot quando la chiave muore. Verifica completata: entrambi i livelli sono stati attivati deliberatamente e il bot si è fermato correttamente.

Controlli della piattaforma e del ciclo di vita (11–12)

11. Il bot utilizza una versione corrente dell’API. La documentazione dell’API futures di WEEX indica V2 come in fase di dismissione il 30 settembre e V3 come versione corrente. Una piattaforma ospitata o un vecchio connettore open source che punta ancora agli endpoint V2 smetterà di funzionare, potenzialmente con posizioni aperte. Verifica completata: ogni endpoint chiamato dal bot è un percorso V3, oppure la piattaforma ha confermato per iscritto che il suo connettore WEEX è V3.

12. L’intero elenco è stato superato sulla demo. L’API futures di WEEX espone endpoint simulati, tra cui POST /capi/v3/sim/order e GET /capi/v3/sim/balance, che usano la stessa autenticazione e firma del mercato reale e regolano le operazioni in SUSDT demo. Esegui il bot abbastanza a lungo da osservare un riavvio, un avviso di limite, l’attivazione di uno stop-loss e la revoca di una chiave. Verifica completata: il bot ha completato almeno una settimana intera in demo con un log degli errori pulito, e il passaggio al live consiste in una modifica di configurazione da /sim/ ai percorsi live più la sostituzione della chiave, verificata da una persona.

Piattaforma ospitata o costruita in proprio: dove cambiano i rischi

La checklist vale per entrambe, ma cambiano i punti deboli.

Una piattaforma di bot ospitata ti solleva dagli aspetti tecnici (limiti di frequenza, riconciliazione e migrazione della versione) e li sostituisce con il rischio di controparte: la tua chiave è conservata sulla sua infrastruttura e una violazione esporrebbe ogni chiave in suo possesso. Riduci il rischio vincolando la chiave agli indirizzi pubblicati, usando il minimo ambito e ruotandola ogni volta che smetti di usare la piattaforma. Prima di collegarti, chiedi due cose: pubblicano IP in uscita stabili e il loro connettore WEEX è su V3?

Un bot costruito in proprio elimina la controparte e ti lascia tutti gli aspetti tecnici dell’elenco. Gli elementi che vengono saltati sono 7, 8, 9 e 10, perché contano solo in caso di guasto, e l’account demo è il luogo in cui questi guasti costano poco. Dedica più tempo al kill switch che alla strategia.

Cosa osservano gli operatori esperti

Due schemi spiegano la maggior parte dei collassi dei bot che non erano fallimenti della strategia. Il primo è il ciclo silenzioso di retry: un problema di rete, un 429, un exponential backoff mai implementato e un bot che martella l’endpoint degli ordini durante un ban di 10 secondi mentre l’annullamento dello stop-loss resta in coda. Il secondo è la chiave obsoleta: un bot ritirato mesi fa la cui chiave Futures/Contract non è mai stata eliminata, ancora valida e ancora non vincolata. Il punto 5 previene il primo; il punto 3, insieme a un audit trimestrale di API Management, previene il secondo. Non serve ingegno, solo farlo.

FAQ

1. È sicuro collegare un bot di trading all’API WEEX?

È sicuro nella misura in cui la chiave è limitata a un mercato, vincolata all’IP, dedicata al bot e il bot gestisce limiti, deriva dell’orologio, idempotenza e riconciliazione. Le chiavi WEEX non possono effettuare prelievi, eliminando il risultato peggiore ma non le perdite di trading.

2. Quale permesso API serve a un bot su WEEX?

Un bot spot richiede l’ambito di trading Spot; un bot futures richiede Futures/Contract. I bot di solo monitoraggio necessitano di Read Only. Non abilitare mai entrambi gli ambiti di trading sulla stessa chiave.

3. Cosa succede se il mio bot supera i limiti di WEEX?

L’API restituisce HTTP 429 e impone un ban di 10 secondi. Gli endpoint degli ordini sono limitati per account; la maggior parte degli altri endpoint è limitata per IP in base al peso. Leggi gli header X-USED-WEIGHT e X-ORDER-COUNT per rimanere sotto il limite.

4. Posso testare un bot su WEEX senza denaro reale?

Sì. Gli endpoint simulati dell’API futures sotto /capi/v3/sim/ usano l’autenticazione live e regolano le operazioni in fondi demo; il terminale demo permette di osservare gli ordini del bot in tempo reale.

5. Cos’è la dismissione dell’API WEEX V2?

La documentazione API di WEEX indica V2 come in fase di dismissione il 30 settembre e V3 come versione corrente. Bot e piattaforme che puntano ancora agli endpoint V2 devono migrare prima di quella data.

6. Come fermo subito un bot?

Elimina la sua chiave API nella pagina API Management di WEEX; il bot perde immediatamente l’accesso. Poi annulla gli ordini aperti e controlla manualmente le posizioni. Costruisci anche un kill switch interno affinché il bot possa fermarsi da solo in caso di perdita o superamento della dimensione.

Avvertenza sui rischi

Il trading automatizzato tramite l’API di un exchange combina rischio di mercato e rischio operativo. Le posizioni futures con leva possono essere liquidate rapidamente e un bug del bot, un guasto di rete, un ban per i limiti, una deriva dell’orologio o una chiave API trapelata possono inserire ordini o non riuscire ad annullarli causando perdite che nessun essere umano avrebbe scelto, senza possibilità di annullamento. Le piattaforme di bot di terze parti aggiungono rischio di controparte per le credenziali API. I prezzi delle criptovalute sono volatili e potresti perdere parte o tutto il capitale controllato da un bot. Comportamento, limiti e tempistiche delle versioni dell’API WEEX sono descritti a settembre 2026 e possono cambiare; nulla di quanto riportato costituisce consulenza finanziaria.