Maker Protection

Zuletzt aktualisiert: 30. September 2026

Dieser Artikel bietet eine Zusammenfassung von Maker Protection. Die vollständige technische Dokumentation – einschließlich protokollspezifischem Verhalten für REST, WebSocket und FIX – findest du im Maker Protection Developer Guide.

Maker Protection ist eine kurze, feste Verzögerung, die auf Orders angewendet wird, die auf ausgewählten Kraken Derivatives-Märkten Liquidität abnehmen könnten. Sie gibt ruhenden Maker-Orders ein kurzes Zeitfenster, um auf neue Informationen zu reagieren, bevor eine eingehende Order gegen sie handeln kann. Maker Protection ist seit dem 24. September 2026 aktiv.

Was ist Maker Protection?

Auf einem Markt mit Maker Protection wird jede Order-Aktion, die Liquidität abnehmen könnte, kurzzeitig zurückgehalten, bevor sie die Matching Engine erreicht. Post-only-Platzierungen und alle Stornierungen werden nie zurückgehalten.

•
Verzögerung: 20 ms zum Start, maximal jedoch 100 ms. Die Verzögerung wird pro Markt als makerProtectionMillis veröffentlicht.
•
Märkte: Ausschließlich ausgewählte Derivatives-Märkte (Futures). Spot ist nicht betroffen.
•
Konsistenz: Das Verhalten ist auf REST, WebSocket und FIX identisch.
•
Fairness: Die Verzögerung gilt gleichmäßig für alle Kunden. Es gibt keine kontobasierten Ausnahmen.
•
So vermeidest du sie: Sende die Order als Post-only. Eine Limit-Order ohne Post-only wird zurückgehalten, auch wenn sie im Orderbuch ruhen würde – denn die Verzögerung richtet sich nach dem Order-Typ, nicht nach dem Ergebnis.

Eine zurückgehaltene Order nimmt ihren Platz in der Warteschlange ein, wenn sie freigegeben wird – nicht zum Zeitpunkt des Eingangs.

Welche Märkte haben Maker Protection?

Die maßgebliche Quelle ist das Feld makerProtectionMillis unter GET /instruments und GET /trading/instruments. Hat ein Markt keine Maker Protection, wird das Feld vollständig weggelassen – ein fehlendes Feld und ein Wert von null bedeuten dasselbe: keine Verzögerung.

•
Zum Start am 24. September 2026 waren 59 Märkte abgedeckt.
•
Die 10 liquidesten linearen Perpetual-Märkte sind ausgeschlossen, damit aktiver Taker-Flow in den Hauptmärkten nicht verlangsamt wird.
•
Jedes Perpetual, das nach dem 24. September 2026 gelistet wird, verfügt ab dem Start über Maker Protection.
•
Ergänzungen werden vor jedem Wartungsfenster auf status.kraken.com angekündigt.

Welche Orders werden verzögert?

Aktion	Verzögert?
Limit-, IOC-, FOK- oder Market-Order	Ja
Post-only-Order	Nein
Änderung einer Order, die im Orderbuch liegen und Liquidität nehmen kann	Ja
Änderung einer ruhenden Post-only-Order	Nein
Stop-, Take-Profit- oder Trailing-Stop-Platzierung	Nein
Die Order, die ein Stop- oder Take-Profit-Trigger auslöst	Ja, es sei denn, die ausgelöste Order ist Post-only
Order-Gruppe mit neuem Elternteil ohne Post-only-Flag	Ja
Order-Gruppe, die an eine bestehende Order angehängt wird	Nein
Stornierung, Alle stornieren, Alle-stornieren-nach	Nein

Block Trades und andere Off-Book-Flows sind ebenfalls ausgenommen.

So funktioniert die Verzögerung

In der öffentlichen API gibt es keinen Status „gehalten" für Orders. Maker Protection äußert sich als zusätzliche Latenz bei aggressiven Orders. Die folgenden Eigenschaften solltest du beim Design berücksichtigen:

•
Validierung erfolgt bei Freigabe. Margin, Preis-Collars und Marktstatus werden beim Ablauf der Verzögerung geprüft, nicht beim Einreichen. Eine zum Einreichungszeitpunkt gültige Order kann dennoch abgelehnt werden.
•
Das vollständige Zeitfenster wird immer abgewartet. Verschwindet die Liquidität, die deine Order aggressiv gemacht hat, während des Zeitfensters, wartet die Order die Verzögerung trotzdem vollständig ab. Gehaltene Orders werden nicht neu bewertet.
•
Orders werden der Reihe nach freigegeben. Holds werden nach dem First-in-first-out-Prinzip aufgelöst – eine spätere Order kann daher keine frühere überholen.
•
Die Verzögerung beträgt „mindestens" das konfigurierte Zeitfenster. Orders, die durch einen Stop- oder Take-Profit-Trigger ausgelöst werden, werden beim nächsten Ereignis freigegeben, das der Matching Engine verarbeitet. Auf einem ruhigen Markt kann die Wartezeit dadurch spürbar länger ausfallen als das konfigurierte Zeitfenster.
•
Messe die Verzögerung nicht selbst. Lies stattdessen makerProtectionMillis, da sich dieser Wert jederzeit ändern kann.

Was kann während eines Holds passieren?

Eine gehaltene Order befindet sich noch nicht im Orderbuch und ist nicht garantiert, dorthin zu gelangen. Während des Zeitfensters kann eine Order durch Ereignisse beeinflusst werden, die nichts mit deinem eigenen Trading zu tun haben:

•
Der Markt ist ausgesetzt: Die Order wird mit marketSuspended abgelehnt.
•
Dein Konto wird de-risked oder liquidiert: Die Order wird mit CANCELLED_WHILE_HELD abgelehnt.
•
Margin oder Preis-Collars bewegen sich gegen dich: Die Order kann bei der Freigabe abgelehnt werden.
•
Du änderst deinen Hebel oder Margin-Modus: Die Änderung wird abgewiesen, solange Anfragen im Hold sind. Versuche es erneut, sobald alle Holds freigegeben wurden.

Erhältst du eine Ablehnung ungefähr ein Zeitfenster nach dem Absenden einer Order, liegt das in der Regel nicht an einem fehlerhaften Order-Format. Prüfe den zurückgegebenen Status.

Zurückgehaltene Order stornieren

Du kannst eine Order stornieren, während sie im Hold ist – Stornierungen werden nie verzögert. Wichtig dabei: Eine Stornierung kann bereits ausgelöste Aggression nicht zurücknehmen. Die Stornierung entzieht der Order das Recht, im Orderbuch zu verbleiben, nicht aber die Pflicht zu handeln.

Eine stornierte, zurückgehaltene Order kann dennoch ausgeführt werden. Bewegt sich der Markt während des Zeitfensters zu deinen Gunsten, schöpft die Order bei Freigabe die verfügbare Liquidität ab. Sende die Order nach einer erfolgreichen Stornierung nicht erneut.

Was passiert, hängt vom Typ der zurückgehaltenen Anfrage ab:

•
Limit-Order: Die Stornierung wird bestätigt, und die Order wird als Immediate-or-Cancel freigegeben. Sie nimmt, was möglich ist; der Rest wird verworfen. Du erhältst zwei Antworten: die der Stornierung und die der Order selbst, etwa ein Zeitfenster später. Kann die Order bei der Freigabe nicht ausgeführt werden, gibt REST v3 iocWouldNotExecute zurück.
•
IOC-, FOK- oder Market-Order: Es gibt nichts zu konvertieren; die Stornierung gibt daher ORDER_NOT_FOUND zurück, und die Order wird bei Freigabe dennoch ausgeführt.
•
Bearbeitung einer Resting-Order: Die ursprüngliche Order bleibt während des Zeitfensters zu ihrem alten Preis aktiv. Eine Stornierung wird absorbiert; bei Freigabe wird die Bearbeitung so umgeschrieben, dass die Order einen neuen Preis erhält und nicht mehr im Orderbuch verbleiben kann.
•
Order-Gruppe: Eine Gruppe mit einer zurückgehaltenen übergeordneten Order kann während des Fensters nicht storniert werden und wird bei Freigabe aktiv. Storniere sie, sobald sie aktiv ist.
•
Totmannschalter (cancelallordersafter): Eine zurückgehaltene Order wird auf dieselbe Weise konvertiert. Der Schalter ruft eine zurückgehaltene Order nicht zurück.

Wenn weder eine Resting-Order verbleiben noch eine neue Order ausgeführt werden soll, warte das Fenster ab (maximal 100 ms) und storniere dann.

Self-Trade-Schutz

Wird eine zurückgehaltene Order freigegeben, storniert sie stets alle deine Resting-Orders, gegen die sie gehandelt würde – unabhängig von der für dein Konto konfigurierten Self-Trade-Strategie. Dies gilt für den gesamten Kontoverbund, einschließlich Master-Konto, Schwesterkonten und Sub-Konten.

•
Deine Resting-Order wird mit dem Grund CANCELLED_BY_SELF_TRADE storniert, und die freigegebene Order wird ausgeführt.
•
FOK-Orders und RFQs sind die Ausnahme. Deine konfigurierte Strategie gilt wie gewohnt.
•
Orders, die nie zurückgehalten wurden, sind ebenfalls nicht betroffen.

Wenn du auf REJECT_TAKER setzt, um deine Resting-Quotes auf einem Maker-Protection-Markt zu schützen, greift dieser Schutz nicht gegenüber deinen eigenen freigegebenen Orders.

Limits bei zurückgehaltenen Orders

Gleichzeitige Holds. Es können maximal 250 Anfragen gleichzeitig zurückgehalten werden. Eine Anfrage, die dieses Limit überschreitet, wird abgelehnt und so gemeldet, als hättest du dein Order-Limit erreicht (tooManyOrders bei REST v3, TOO_MANY_ORDERS bei REST v4, ORDER_LIMIT_EXCEEDED bei Marktdaten und SBE). Das Limit begrenzt die Anzahl gleichzeitig aktiver Holds, nicht die Sendegeschwindigkeit von Orders. Es wird über ein Master-Konto und dessen Sub-Konten geteilt; ein erneuter Versuch ist sicher, sobald frühere Holds freigegeben wurden.

Kontolimits werden beim Öffnen des Holds festgelegt. Um Änderungen an Kontoeinstellungen während des Fensters zu verhindern, werden einige Limits beim Öffnen des Holds und nicht bei der Freigabe festgelegt:

•
Offenes Order-Limit: Hast du dein Limit erreicht, wird die Order zugelassen, aber so konvertiert, dass sie nicht als Resting-Order verbleiben kann.
•
Maximale Position: Das Budget wird bei der Orderaufgabe für die Order reserviert. Eine zu diesem Zeitpunkt abgelehnte Order bleibt abgelehnt, selbst wenn du Budget freigibst. Reserviertes Budget steht späteren Orders nicht zur Verfügung; diese werden mit MAX_POSITION_EXCEEDED abgelehnt.
•
Client-Order-IDs: Ein Hold reserviert die Client-Order-ID für die Dauer des Fensters. Die Wiederverwendung für eine andere Platzierung wird sofort mit clientOrderIdAlreadyExist abgelehnt. Warte das Fenster ab, bevor du eine ID wiederverwendest, oder referenziere laufende Stornierungen über die Order-ID.

Batch-Orders

Ein Batch wird nicht als Einheit zurückgehalten. Das Fenster beginnt mit der ersten Liquidität entnehmenden Anweisung im Batch.

•
Anweisungen vor der ersten aggressiven Anweisung werden sofort gesendet.
•
Die erste aggressive Anweisung und alle nachfolgenden warten das Fenster gemeinsam ab.
•
Stornierungen werden stets sofort gesendet. Eine Stornierung, die im Batch nach der Ziel-Order platziert wird, beansprucht den Hold dieser Order innerhalb desselben Batch. Eine davor platzierte Stornierung kann dies nicht.

Damit eine passive Anweisung das Orderbuch ohne Verzögerung erreicht, platziere sie im Batch vor jeder aggressiven Anweisung.

API und FIX nutzen

REST. Die Verbindung wird für die Dauer der Verzögerung gehalten, und die Antwort enthält das endgültige Ergebnis. Setze den clientseitigen Timeout großzügig oberhalb des Fensters. Da das Fenster nie mehr als 100 ms beträgt, deckt ein einziges Timeout-Budget jeden Markt ab. Wenn du processBefore bei einer aggressiven Order verwendest, muss dieser Wert den Hold berücksichtigen – andernfalls wird die Order jedes Mal mit wouldProcessAfterSpecifiedTime abgelehnt.

WebSocket. Während eine Order zurückgehalten wird, werden keine Ereignisse veröffentlicht. Du empfängst die üblichen open_orders- und fills-Ereignisse, sobald die Order freigegeben wird – etwa ein Fenster später als gewohnt.

FIX. Das Gateway sendet einen informativen ExecutionReport, wenn eine Anfrage zurückgehalten wird: Pending New (39=A) bei einer Platzierung oder Pending Replace (39=E) bei einer Änderung. Der Report ist rein informativ und kein terminaler Zustand. Eine zurückgehaltene Platzierung hat noch keine OrderID – während des Fensters ist ClOrdID daher dein einziger Anhaltspunkt für die Order. Die eigentliche Bestätigung folgt bei der Freigabe.

Bekannte Einschränkung bei Order-Gruppen

Wenn ein Leg einer Order-Gruppe zurückgehalten wird, während ein gegenläufiges Geschwister-Leg ausgeführt wird, bleibt das gehaltene Leg bestehen und beide Legs können aktiv werden. Ein Fix ist in Arbeit.

Prüfe auf Maker-Protection-Märkten deine Ausführungen nach jeder Ausführung eines Geschwister-Legs in einer Order-Gruppe, statt davon auszugehen, dass ein Leg das andere storniert hat.

Integration testen

Maker Protection ist seit dem 27.08.2026 in der UAT-Umgebung auf den Launch-Märkten aktiv – mit demselben 20-ms-Fenster und dem Limit von 250 gleichzeitigen Holds wie in der Produktionsumgebung. Wende dich für UAT-Zugang an deinen Account-Manager. Folgendes solltest du testen:

•
Stornierung während eines Holds und Umgang mit einer Order, die danach dennoch ausgeführt wird
•
Stornierung während einer zurückgehaltenen Änderung
•
Eine deiner Resting-Orders wird durch eine freigegebene Order storniert – auch wenn REJECT_TAKER gesetzt ist
•
Umgang mit tooManyOrders bei einer Order-Platzierung und dem erneuten Versuch
•
Wiederverwendung einer Client-Order-ID innerhalb eines Fensters
•
Reihenfolge der Batch-Anweisungen und clientseitige Timeouts oberhalb des makerProtectionMillis-Werts des Marktes