Dit artikel is een samenvatting van Maker Protection. Voor de volledige technische details, inclusief protocolspecifiek gedrag voor REST, WebSocket en FIX, zie de ontwikkelaarsgids voor Maker Protection.
Maker Protection is een korte, vaste vertraging die wordt toegepast op orders die liquiditeit kunnen onttrekken op geselecteerde Kraken Derivatives-markten. Het geeft rustende maker-orders een kort tijdvenster om te reageren op nieuwe informatie voordat een inkomende order ertegen kan traden. Maker Protection is actief sinds 24 september 2026.
Op een markt met Maker Protection wordt elke orderactie die liquiditeit kan onttrekken korte tijd vastgehouden voordat deze de matching engine bereikt. Post-only-plaatsingen en alle annuleringen worden nooit vastgehouden.
Vertraging: 20 ms bij launch, en nooit meer dan 100 ms. De vertraging wordt per markt gepubliceerd als makerProtectionMillis.
Markten: Alleen geselecteerde Derivatives (futures)-markten. Spot wordt niet beïnvloed.
Consistentie: Het gedrag is identiek op REST, WebSocket en FIX.
Eerlijkheid: De vertraging geldt voor elke gebruiker gelijkelijk. Er zijn geen vrijstellingen per account.
Hoe vermijd je dit: Plaats de order als post-only. Een limietorder zonder post-only wordt vastgehouden, ook als deze op het orderboek zou rusten – de vertraging hangt af van het ordertype, niet van de uitkomst.
Een vastgehouden order neemt zijn plaats in de wachtrij in op het moment van vrijgave, niet op het moment van ontvangst.
De gezaghebbende bron is het veld makerProtectionMillis bij GET /instruments en GET /trading/instruments. Als een markt geen Maker Protection heeft, wordt het veld volledig weggelaten – behandel een ontbrekend veld en een waarde van nul dus als hetzelfde: geen vertraging.
Bij de launch op 24 september 2026 waren 59 markten opgenomen.
De 10 meest liquide lineaire perpetualmarkten zijn uitgesloten, zodat actieve taker-stroom in de majors niet vertraagt.
Elk perpetual dat na 24 september 2026 wordt genoteerd, heeft Maker Protection vanaf de launch.
Toevoegingen worden vooraf aangekondigd op status.kraken.com, vóór elk onderhoudsvenster.
Actie | Vertraagd? |
|---|---|
Limietorder, IOC, FOK of marktorder | Ja |
Post-only-order | Nee |
Wijziging van een order die op het orderboek kan blijven staan en liquiditeit kan ontnemen | Ja |
Wijziging van een rustende post-only-order | Nee |
Plaatsing van stop-, take-profit- of trailing-stop-order | Nee |
De order die door een stop- of take-profit-trigger wordt geactiveerd | Ja, tenzij de geactiveerde order post-only is |
Ordergroep met een nieuwe niet-post-only bovenliggende order | Ja |
Ordergroep die aan een bestaande order wordt gekoppeld | Nee |
Annuleren, alles annuleren, alles annuleren na tijdstip | Nee |
Bloktrades en andere off-book stromen zijn ook vrijgesteld.
Er is geen "aangehouden" orderstatus in de publieke API. Maker Protection is zichtbaar als extra latentie op agressieve orders. Houd bij het ontwerpen van je integratie rekening met de volgende eigenschappen:
Validatie vindt plaats bij vrijgave. Marge, prijscollars en marktstatus worden gecontroleerd wanneer de vertraging eindigt, niet op het moment van indienen. Een order die bij indiening geldig was, kan alsnog worden geweigerd.
Het volledige venster wordt altijd afgewacht. Als de liquiditeit die je order agressief maakte tijdens het venster verdwijnt, wacht de order de vertraging alsnog volledig uit. Aangehouden orders worden niet opnieuw beoordeeld.
Orders worden vrijgegeven in volgorde van binnenkomst. Aangehouden orders worden vrijgegeven volgens first in, first out (FIFO), zodat een latere order een eerdere niet kan inhalen.
De vertraging is "minimaal" het geconfigureerde venster. Orders die door een stop- of take-profit-trigger worden afgevuurd, worden vrijgegeven bij de volgende gebeurtenis die de Matching engine verwerkt. Op een rustige markt kan dat merkbaar langer duren dan het geconfigureerde venster.
Meet de vertraging niet zelf. Lees in plaats daarvan makerProtectionMillis, omdat deze waarde op elk moment kan worden gewijzigd.
Een aangehouden order staat nog niet in het orderboek en er is geen garantie dat deze er komt. Tijdens het venster kan een order worden beïnvloed door gebeurtenissen die niets met je eigen trading te maken hebben:
De markt is gesuspendeerd: de order wordt geweigerd met marketSuspended.
Je account wordt ontrisked of geliquideerd: de order wordt geweigerd met CANCELLED_WHILE_HELD.
Marge of prijscollars bewegen tegen je in: de order kan bij vrijgave worden geweigerd.
Je wijzigt je hefboomwerking of margemodus: de wijziging wordt geweigerd zolang je verzoeken in de wacht staan. Probeer het opnieuw zodra je aangehouden verzoeken zijn vrijgegeven.
Als je ongeveer één venster na het verzenden van een order een weigering ontvangt, is die weigering doorgaans niet het gevolg van een fout in de order zelf. Controleer de geretourneerde status.
Je kunt een order annuleren terwijl deze wordt aangehouden; annuleringen worden nooit vertraagd. Een annulering kan echter geen ingezette agressie terugdraaien. Annuleren verwijdert het recht van de order om in het orderboek te rusten, maar niet de verplichting om te traden.
Een geannuleerde aangehouden order kan nog steeds worden gevuld. Als de markt tijdens het venster in je voordeel beweegt, neemt de order bij vrijgave alsnog de beschikbare liquiditeit op. Dien de plaatsing niet opnieuw in na een geslaagde annulering.
Wat er gebeurt, hangt af van het type verzoek dat wordt aangehouden:
Limietorder: de annulering wordt bevestigd en de order wordt vrijgegeven als immediate-or-cancel. De order neemt wat mogelijk is; het resterende deel wordt verworpen. Je ontvangt twee reacties: die van de annulering en die van de order zelf, ongeveer één venster later. Als de order bij vrijgave niet kan traden, retourneert REST v3 iocWouldNotExecute.
IOC-, FOK- of marktorder: er is niets om te omzetten, dus de annulering retourneert ORDER_NOT_FOUND en de order wordt bij vrijgave alsnog uitgevoerd.
Bewerking van een rustende order: de oorspronkelijke order blijft actief tegen de oude prijs tijdens het venster. Een annulering wordt geabsorbeerd; bij vrijgave wordt de bewerking herschreven zodat de order opnieuw geprijsd wordt en niet meer kan rusten.
Order group: een groep met een vastgehouden bovenliggende order kan niet worden geannuleerd tijdens het venster en wordt actief bij vrijgave. Annuleer de groep zodra deze actief is.
Dead man's switch (cancelallordersafter): een vastgehouden order wordt op dezelfde manier omgezet. De switch annuleert een vastgehouden order niet terug.
Als je wilt dat er niets blijft rusten en er niets nieuws wordt getraded, wacht dan het venster uit (maximaal 100 ms) en annuleer daarna.
Wanneer een vastgehouden order wordt vrijgegeven, annuleert deze altijd elke rustende order van jou waartegen hij zou matchen, ongeacht welke self-trade-strategie je account gebruikt. Dit geldt voor je gehele account-structuur, inclusief je Master-account, nevenaccounts en subaccounts.
Je rustende order wordt geannuleerd met de reden CANCELLED_BY_SELF_TRADE, waarna de vrijgegeven order wordt uitgevoerd.
FOK-orders en RFQ's zijn de uitzondering. Je geconfigureerde strategie geldt gewoon.
Orders die nooit vastgehouden zijn geweest, worden ook niet beïnvloed.
Als je op REJECT_TAKER vertrouwt om je rustende quotes op een Maker Protection-markt te beschermen, geldt die bescherming niet tegen je eigen vrijgegeven orders.
Gelijktijdige holds. Je kunt maximaal 250 verzoeken tegelijk vastgehouden hebben. Een verzoek dat de limiet overschrijdt, wordt geweigerd en gerapporteerd alsof je je orderlimiet hebt bereikt (tooManyOrders op REST v3, TOO_MANY_ORDERS op REST v4, ORDER_LIMIT_EXCEEDED op marktdata en SBE). De limiet beperkt het aantal gelijktijdige holds, niet de snelheid waarmee je orders kunt verzenden. De limiet wordt gedeeld door een Master-account en zijn subaccounts; opnieuw proberen is veilig zodra je eerdere holds zijn vrijgegeven.
Accountlimieten worden bepaald bij het openen van de hold. Om te voorkomen dat accountinstellingen worden gewijzigd tijdens het venster, worden sommige limieten vastgelegd bij het openen van de hold en niet bij vrijgave:
Limiet voor openstaande orders: als je je limiet hebt bereikt, wordt de order toegelaten maar omgezet zodat hij niet kan rusten.
Maximale positie: het budget wordt gereserveerd voor de order bij indiening. Een op dat moment geweigerde order blijft geweigerd, ook als je budget vrijmaakt; gereserveerd budget is niet beschikbaar voor latere orders, die worden geweigerd met MAX_POSITION_EXCEEDED.
Client-order-ID's: een hold reserveert het bijbehorende client-order-ID voor de duur van het venster. Hergebruik voor een andere plaatsing wordt direct geweigerd met clientOrderIdAlreadyExist. Wacht het venster uit voordat je een ID hergebruikt, of verwerk lopende annuleringen via order-ID.
Een batch wordt niet als één geheel vastgehouden. Het venster start bij de eerste liquiditeitsnemende instructie in de batch.
Instructies vóór de eerste agressieve instructie worden direct verzonden.
De eerste agressieve instructie en alles daarna wachten samen het venster uit.
Annuleringen worden altijd direct verzonden. Een annulering die na de beoogde order wordt geplaatst, claimt de hold van die order binnen dezelfde batch. Een annulering die ervóór wordt geplaatst, kan dat niet.
Zorg dat een passieve instructie zonder vertraging het orderboek bereikt door deze vóór elke agressieve instructie in de batch te plaatsen.
REST. De verbinding wordt vastgehouden voor de duur van de vertraging en het antwoord bevat de definitieve uitkomst. Stel je client-side timeout ruim boven het venster in. Omdat het venster nooit meer dan 100 ms bedraagt, dekt één timeout-budget alle markten. Als je processBefore meestuurt bij een agressieve order, moet daarin de hold worden meegenomen; anders wordt de order elke keer geweigerd met wouldProcessAfterSpecifiedTime.
WebSocket. Er wordt niets gepubliceerd terwijl een order vastgehouden is. Je ontvangt de gebruikelijke open_orders- en fills-events zodra de order is vrijgegeven, ongeveer één venster later dan voorheen.
FIX. De gateway stuurt een adviserend ExecutionReport wanneer een verzoek wordt vastgehouden: Pending New (39=A) bij een plaatsing, of Pending Replace (39=E) bij een wijziging. Het rapport is uitsluitend adviserend en geen definitieve status. Een vastgehouden plaatsing heeft nog geen OrderID, dus ClOrdID is je enige referentie naar de order tijdens het venster. De echte bevestiging volgt bij vrijgave.
Als één Leg van een ordergroep in de wacht staat op het moment dat een tegengestelde sibling-Leg wordt uitgevoerd (Fill), wordt de wachtende Leg niet verwijderd en kunnen beide Legs actief worden. Er wordt aan een oplossing gewerkt.
Controleer op Maker Protection-markten je fills na elke sibling-Fill in een ordergroep, in plaats van ervan uit te gaan dat de ene Leg de andere heeft geannuleerd.
Maker Protection is sinds 27 augustus 2026 actief op de lanceringsmarkten in de UAT-omgeving, met hetzelfde venster van 20 ms en een limiet van 250 gelijktijdige holds als in productie. Neem contact op met je accountmanager voor UAT-toegang. Het is de moeite waard het volgende te testen:
Annuleren tijdens een hold, en omgaan met een Order die daarna toch wordt gefilld
Annuleren tijdens een aangehouden wijziging
Een rustende order van jezelf die wordt geannuleerd door een vrijgegeven Order, zelfs met REJECT_TAKER ingesteld
Omgaan met tooManyOrders bij een plaatsing en opnieuw proberen
Een client order-ID hergebruiken binnen een venster
Volgorde van batch-instructies en client-side timeouts boven de makerProtectionMillis van de markt