Questo articolo è un riepilogo di Maker Protection. Per i dettagli tecnici completi, incluso il comportamento specifico per REST, WebSocket e FIX, consulta la guida per sviluppatori di Maker Protection.
Maker Protection è un ritardo breve e fisso applicato agli ordini che potrebbero sottrarre liquidità su mercati Kraken Derivatives selezionati. Offre agli ordini maker in attesa una finestra temporale per reagire alle nuove informazioni prima che un ordine in ingresso possa essere eseguito contro di essi. Maker Protection è attivo dal 24 settembre 2026.
Su un mercato con Maker Protection, qualsiasi azione su un ordine che potrebbe sottrarre liquidità viene trattenuta per una breve finestra prima di raggiungere il matching engine. I posizionamenti post-only e tutte le cancellazioni non vengono mai trattenuti.
Ritardo: 20 ms al lancio, mai superiore a 100 ms. Il ritardo è pubblicato per ogni mercato come makerProtectionMillis.
Mercati: Solo mercati Derivatives (futures) selezionati. Il mercato spot non è interessato.
Uniformità: Il comportamento è identico su REST, WebSocket e FIX.
Equità: Il ritardo si applica in modo uguale a ogni cliente. Non sono previste esenzioni per singolo account.
Come evitarlo: Invia l'ordine come post-only. Un ordine limit senza post-only viene trattenuto anche se sarebbe rimasto nel book, perché il ritardo dipende dal tipo di ordine, non dall'esito.
Un ordine trattenuto si posiziona in coda al momento del rilascio, non al momento della ricezione.
La fonte ufficiale è il campo makerProtectionMillis su GET /instruments e GET /trading/instruments. Se un mercato non ha Maker Protection, il campo viene omesso del tutto: considera un campo assente e un valore pari a zero come equivalenti, ovvero nessun ritardo.
Al lancio, il 24 settembre 2026, erano coperti 59 mercati.
I 10 mercati perpetui lineari più liquidi sono esclusi, per non rallentare il flusso taker attivo sui principali asset.
Ogni perpetuo quotato dopo il 24 settembre 2026 ha Maker Protection fin dal lancio.
Le aggiunte vengono annunciate su status.kraken.com prima di ogni finestra di manutenzione.
Azione | Ritardato? |
|---|---|
Ordine limit, IOC, FOK o di mercato | Sì |
Ordine post-only | No |
Modifica di un ordine che può rimanere nel book e assorbire liquidità | Sì |
Modifica di un ordine post-only in book | No |
Inserimento di stop, take-profit o trailing stop | No |
L'ordine generato dall'attivazione di uno stop o take-profit | Sì, a meno che l'ordine generato non sia post-only |
Gruppo di ordini con un parent non-post-only | Sì |
Gruppo di ordini collegato a un ordine esistente | No |
Cancella, cancella tutto, cancella tutto dopo | No |
Anche i block trade e altri flussi fuori book sono esenti.
Nell'API pubblica non esiste uno stato di ordine «in attesa». Maker Protection si manifesta come latenza aggiuntiva sugli ordini aggressivi. Vale la pena tenere conto di queste caratteristiche in fase di integrazione:
La validazione avviene al rilascio. Margine, price collar e stato del mercato vengono verificati alla scadenza del ritardo, non al momento dell'invio. Un ordine valido all'invio può comunque essere rifiutato.
La finestra viene sempre completata. Se la liquidità che rendeva il tuo ordine aggressivo scompare durante la finestra, l'ordine attende comunque la scadenza del ritardo. Gli ordini in attesa non vengono rivalutati.
Gli ordini vengono rilasciati in sequenza. Le attese sono gestite con logica First in, First Out (FIFO): un ordine successivo non può superare uno precedente.
Il ritardo è «almeno» pari alla finestra configurata. Gli ordini attivati da un trigger stop o take-profit vengono rilasciati al prossimo evento elaborato dal matching engine: su un mercato poco attivo, l'attesa può essere sensibilmente superiore alla finestra configurata.
Non misurare il ritardo. Leggi invece makerProtectionMillis: il valore può essere modificato in qualsiasi momento.
Un ordine in attesa non è ancora nel book e non è garantito che vi arrivi. Durante la finestra, un ordine può essere influenzato da eventi indipendenti dalla tua attività di trading:
Il mercato è sospeso: l'ordine viene rifiutato con marketSuspended.
Il tuo account viene de-rischiato o liquidato: l'ordine viene rifiutato con CANCELLED_WHILE_HELD.
Il margine o i price collar si muovono contro di te: l'ordine può essere rifiutato al rilascio.
Modifichi la leva o la modalità di margine: la modifica viene rifiutata finché hai richieste in attesa. Riprova dopo che le attese sono state rilasciate.
Se ricevi un rifiuto circa una finestra dopo l'invio di un ordine, nella maggior parte dei casi la causa non è un ordine malformato. Controlla lo stato restituito.
Puoi cancellare un ordine mentre è in attesa e le cancellazioni non subiscono mai ritardi. Tuttavia, una cancellazione non può annullare un'aggressione già avviata. Cancellare un ordine ne elimina il diritto di restare nel book, ma non l'obbligo di eseguire il trade.
Un ordine in attesa cancellato può comunque essere eseguito. Se il mercato si muove a tuo favore durante la finestra, l'ordine consuma la liquidità disponibile al momento del rilascio. Non reinserire l'ordine dopo una cancellazione andata a buon fine.
L'esito dipende dal tipo di richiesta in attesa:
Ordine limit: la cancellazione viene confermata e l'ordine viene rilasciato come immediate-or-cancel. Viene eseguito per quanto possibile e l'eventuale residuo viene scartato. Ricevi due risposte: quella della cancellazione e quella dell'ordine stesso, dopo circa una finestra. Se l'ordine non può essere eseguito al rilascio, REST v3 restituisce iocWouldNotExecute.
Ordine IOC, FOK o market: non c'è nulla da convertire, quindi la cancellazione restituisce ORDER_NOT_FOUND e l'ordine viene comunque eseguito al rilascio.
Modifica di un ordine in attesa nel book: durante la finestra l'ordine originale rimane attivo al prezzo precedente. La cancellazione viene assorbita e, al rilascio, la modifica viene riscritta in modo che l'ordine venga riprezzato e non possa più restare nel book.
Gruppo di ordini: un gruppo con un ordine padre in attesa non può essere annullato durante la finestra temporale e diventa attivo al rilascio. Annullalo una volta che è attivo.
Dead Man's Switch (cancelallordersafter): un ordine in attesa viene convertito nello stesso modo. Lo switch non revoca un ordine in attesa.
Se vuoi che non rimanga nulla nel book e che nessun nuovo ordine venga eseguito, attendi il termine della finestra (al massimo 100 ms) e poi annulla.
Quando un ordine in attesa viene rilasciato, annulla sempre qualsiasi ordine in attesa nel book che gli corrisponde, indipendentemente dalla strategia di self-trade configurata sul tuo account. Questo vale per l'intero albero degli account, incluso l'account principale, gli account fratelli e i sotto-account.
Il tuo ordine in attesa nel book viene annullato con la motivazione CANCELLED_BY_SELF_TRADE e l'ordine rilasciato viene eseguito.
Gli ordini FOK e le RFQ sono un'eccezione: la strategia configurata si applica normalmente.
Gli ordini che non sono mai stati in attesa non sono interessati.
Se utilizzi REJECT_TAKER per proteggere i tuoi ordini in attesa nel book su un mercato con Maker Protection, tale protezione non si applica ai tuoi ordini rilasciati.
Attese simultanee. Puoi avere al massimo 250 richieste in attesa contemporaneamente. Una richiesta oltre il limite viene rifiutata e segnalata come se avessi raggiunto il limite di ordini (tooManyOrders su REST v3, TOO_MANY_ORDERS su REST v4, ORDER_LIMIT_EXCEEDED su market data e SBE). Il limite si riferisce al numero di attese attive contemporaneamente, non alla velocità di invio degli ordini. È condiviso tra l'account principale e i suoi sotto-account; è possibile riprovare in sicurezza una volta che le attese precedenti sono state rilasciate.
Limiti dell'account definiti all'apertura dell'attesa. Per evitare che le impostazioni dell'account vengano modificate durante la finestra temporale, alcuni limiti vengono stabiliti all'apertura dell'attesa anziché al rilascio:
Limite di ordini aperti: se hai raggiunto il limite, l'ordine viene ammesso ma convertito in modo da non poter restare nel book.
Posizione massima: il budget viene riservato per l'ordine al momento dell'invio. Un ordine rifiutato in quel momento rimane rifiutato anche se liberi budget in seguito; il budget riservato non è disponibile per gli ordini successivi, che vengono rifiutati con MAX_POSITION_EXCEEDED.
ID ordine cliente: un'attesa riserva il proprio ID ordine cliente per la durata della finestra. Riutilizzarlo per un altro ordine viene rifiutato immediatamente con clientOrderIdAlreadyExist. Attendi il termine della finestra prima di riutilizzare un ID, oppure gestisci gli annullamenti in volo tramite ID ordine.
Un batch non viene messo in attesa come unità singola. La finestra temporale inizia alla prima istruzione che preleva liquidità nel batch.
Le istruzioni precedenti alla prima istruzione aggressiva vengono inviate immediatamente.
La prima istruzione aggressiva e tutte quelle successive attendono insieme il termine della finestra.
Gli annullamenti vengono sempre inviati immediatamente. Un annullamento inserito dopo l'ordine a cui è destinato acquisisce l'attesa di quell'ordine all'interno dello stesso batch. Uno inserito prima non può farlo.
Per garantire che un'istruzione passiva raggiunga il book senza ritardo, inseriscila prima di qualsiasi istruzione aggressiva nel batch.
REST. La connessione rimane aperta per la durata del ritardo e la risposta riporta l'esito finale. Imposta il timeout lato client in modo che sia ampiamente superiore alla finestra temporale. Poiché la finestra non supera mai 100 ms, un unico budget di timeout copre tutti i mercati. Se invii processBefore su un ordine aggressivo, il valore deve tenere conto del ritardo; altrimenti l'ordine viene rifiutato ogni volta con wouldProcessAfterSpecifiedTime.
WebSocket. Nessun dato viene pubblicato mentre un ordine è in attesa. Ricevi i consueti eventi open_orders e fills una volta rilasciato l'ordine, con un ritardo pari a circa una finestra temporale.
FIX. Il gateway invia un ExecutionReport informativo quando una richiesta è in attesa: Pending New (39=A) per un inserimento, o Pending Replace (39=E) per una modifica. Il report è puramente informativo e non rappresenta uno stato definitivo. Un inserimento in attesa non ha ancora un OrderID, quindi ClOrdID è l'unico riferimento disponibile per l'ordine durante la finestra. La conferma effettiva arriva al rilascio.
Se una delle gambe di un gruppo di ordini è in attesa nel momento in cui la gamba opposta viene eseguita, la gamba trattenuta non viene rimossa ed entrambe le gambe possono diventare live. È in corso una correzione.
Sui mercati con Maker Protection, verifica le tue esecuzioni dopo ogni esecuzione di una gamba dello stesso gruppo di ordini, invece di dare per scontato che una gamba abbia annullato l'altra.
Maker Protection è attiva sui mercati di lancio nell'ambiente UAT cliente dal 27 agosto 2026, con la stessa finestra di 20 ms e il limite di 250 hold presenti in produzione. Contatta il tuo account manager per ottenere l'accesso all'ambiente UAT. Ti consigliamo di testare:
L'annullamento durante un hold e la gestione di un ordine che viene comunque eseguito in seguito
L'annullamento durante una modifica trattenuta
Un ordine in attesa nel book annullato da un ordine rilasciato, anche con REJECT_TAKER impostato
La gestione di tooManyOrders durante l'inserimento di un ordine e il relativo nuovo tentativo
Il riutilizzo dell'ID ordine cliente all'interno di una finestra
L'ordinamento delle istruzioni in un batch e i timeout lato cliente superiori al makerProtectionMillis del mercato