Den här artikeln är en sammanfattning av Maker Protection. För fullständig teknisk information, inklusive protokollspecifikt beteende för REST, WebSocket och FIX, se utvecklarguiden för Maker Protection.
Maker Protection är en kort, fast fördröjning som tillämpas på ordrar som kan ta likviditet på utvalda Kraken Derivatives-marknader. Den ger vilande maker-ordrar ett kort tidsfönster att reagera på ny information innan en inkommande order kan handla mot dem. Maker Protection har varit aktivt sedan den 24 september 2026.
På en marknad med Maker Protection hålls alla orderåtgärder som kan ta likviditet kvar i ett kort fönster innan de når Matchningsmotorn. Post-only-placeringar och annulleringar hålls aldrig kvar.
Fördröjning: 20 ms vid lansering, aldrig mer än 100 ms. Fördröjningen publiceras per marknad som makerProtectionMillis.
Marknader: Endast utvalda derivatmarknader (terminer). Spot påverkas inte.
Konsistens: Beteendet är identiskt på REST, WebSocket och FIX.
Rättvisa: Fördröjningen gäller lika för alla kunder. Det finns inga undantag per konto.
Så undviker du det: Skicka ordern som post-only. En limitorder utan post-only hålls kvar även om den hade vilat i orderboken, eftersom fördröjningen beror på ordertyp, inte utfall.
En kvarhållen order tar sin plats i kön när den frigörs, inte när den togs emot.
Den auktoritativa källan är fältet makerProtectionMillis på GET /instruments och GET /trading/instruments. Om en marknad saknar Maker Protection utelämnas fältet helt – behandla ett saknat fält och värdet noll som likvärdigt: ingen fördröjning.
59 marknader omfattades vid lanseringen den 24 september 2026.
De 10 mest likvida linjära eviga marknaderna är undantagna för att inte bromsa aktivt taker-flöde i de stora paren.
Alla eviga terminer som listas efter den 24 september 2026 har Maker Protection från start.
Tillägg aviseras på status.kraken.com inför varje underhållsfönster.
Åtgärd | Fördröjd? |
|---|---|
Limitorder, IOC, FOK eller marknadsorder | Ja |
Post-only-order | Nej |
Redigering av en order som kan vila och ta likviditet | Ja |
Redigering av en vilande post-only-order | Nej |
Placering av stop-, take-profit- eller trailing-stop-order | Nej |
Den order som utlöses av en stop- eller take-profit-trigger | Ja, om inte den aktiverade ordern är post-only |
Ordergrupp med en ny förälder som inte är post-only | Ja |
Ordergrupp som kopplas till en befintlig order | Nej |
Annullera, annullera alla, annullera alla efter | Nej |
Blocktrades och annat flöde utanför orderboken är också undantagna.
Det finns inget "hållet" ordertillstånd i det publika API:et. Maker Protection visar sig som extra latens på aggressiva ordrar, och dessa egenskaper är värda att ta hänsyn till vid implementationen:
Validering sker vid frisläppning. Marginal, prisgränser och marknadsstatus kontrolleras när fördröjningen upphör, inte när du skickar in ordern. En order som var giltig vid inlämning kan ändå avvisas.
Hela fönstret används alltid. Om den likviditet som gjorde din order aggressiv försvinner under fönstret väntar ordern ändå ut fördröjningen. Kvarhållna ordrar omvärderas inte.
Ordrar frisläpps i ankomstordning. Kvarhållningar frisläpps först in, först ut – en senare order kan alltså inte gå om en tidigare.
Fördröjningen är "minst" det konfigurerade fönstret. Ordrar som utlöses av en stop- eller take-profit-trigger frisläpps vid nästa händelse som matchningsmotorn behandlar, vilket innebär att de på en stillsam marknad kan vänta märkbart längre än det konfigurerade fönstret.
Mät inte fördröjningen. Läs makerProtectionMillis i stället, eftersom värdet kan ändras när som helst.
En kvarhållen order finns ännu inte i orderboken och är inte garanterad att hamna där. Under fönstret kan en order påverkas av händelser som inte har med din egen handel att göra:
Marknaden är suspenderad: ordern avvisas med marketSuspended.
Ditt konto riskreduceras eller likvideras: ordern nekas med CANCELLED_WHILE_HELD.
Marginal eller prisgränser rör sig mot dig: ordern kan avvisas vid frisläppning.
Du ändrar din hävstång eller ditt marginalläge: ändringen nekas så länge du har en kvarhållen förfrågan. Försök igen när dina kvarhållningar har frisläppts.
Om du får ett avvisningssvar ungefär ett fönster efter att du skickat en order beror det vanligtvis inte på att ordern i sig var felformaterad. Kontrollera den returnerade statusen.
Du kan annullera en order medan den är kvarhållen, och annulleringar fördröjs aldrig. Däremot kan en annullering inte återkalla en redan ingången aggressiv order. Att annullera tar bort orderns rätt att vila i orderboken, men inte dess skyldighet att handla.
En avbruten order kan ändå fyllas. Om marknaden rör sig till din fördel under fönstret tar ordern ändå den likviditet den kan vid frisläppning. Försök inte lägga ordern igen efter ett godkänt avbryt.
Vad som händer beror på typen av förfrågan som hålls:
Limitorder: avbrytandet bekräftas och ordern frisläpps som immediate-or-cancel. Den tar vad den kan och eventuell rest kasseras. Du får två svar: ett för avbrytandet och ett för ordern, ungefär ett fönster senare. Om ordern inte kan handla vid frisläppning returnerar REST v3 iocWouldNotExecute.
IOC-, FOK- eller marknadsorder: det finns inget att konvertera, så avbrytandet returnerar ORDER_NOT_FOUND och ordern når ändå fram vid frisläppning.
Redigering av en vilande order: den ursprungliga ordern ligger kvar aktiv på sitt gamla pris under fönstret. Ett avbrytande absorberas, och vid frisläppning skrivs redigeringen om så att ordern prissätts om och inte längre kan ligga vilande.
Ordergrupp: en grupp med en väntande föräldraorder kan inte annulleras under fönstret och aktiveras vid frisläppning. Annullera den när den är aktiv.
Dödmansgrepp (cancelallordersafter): en väntande order konverteras på samma sätt. Dödmansgreppet återkallar inte en väntande order.
Om du inte vill ha några vilande order eller nya affärer, vänta ut fönstret (högst 100 ms) och annullera sedan.
När en väntande order frisläpps annulleras alltid dina vilande order som den skulle matcha, oavsett vilken självhandelsstrategi ditt konto använder. Det gäller hela din kontohierarki, inklusive ditt huvudkonto, sidokonton och underkonton.
Din vilande order annulleras med orsaken CANCELLED_BY_SELF_TRADE, och den frisläppta ordern utförs.
FOK-order och RFQ:er är undantaget. Din konfigurerade strategi gäller som vanligt.
Order som aldrig hölls kvar påverkas inte.
Om du förlitar dig på REJECT_TAKER för att skydda dina vilande quotes på en Maker Protection-marknad gäller det skyddet inte mot dina egna frisläppta order.
Parallella väntande förfrågningar. Du kan ha högst 250 förfrågningar väntande samtidigt. En förfrågan som överskrider gränsen avvisas och rapporteras som om du hade nått din ordergräns (tooManyOrders på REST v3, TOO_MANY_ORDERS på REST v4, ORDER_LIMIT_EXCEEDED på marknadsdata och SBE). Gränsen styr hur många väntande förfrågningar som kan vara aktiva samtidigt, inte hur snabbt du kan skicka order. Den delas mellan ett huvudkonto och dess underkonton, och du kan försöka igen när tidigare väntande förfrågningar har frisläppts.
Kontogränser fastställs när väntan inleds. För att förhindra att kontoinställningar ändras mitt under fönstret fastställs vissa gränser när väntan inleds, inte vid frisläppning:
Gräns för öppna order: om du har nått din gräns godtas ordern men konverteras så att den inte kan vila på orderboken.
Maximal position: budgeten reserveras för ordern vid registrering. En order som avvisas vid den tidpunkten förblir avvisad även om du frigör budget, och reserverad budget är inte tillgänglig för senare order, som avvisas med MAX_POSITION_EXCEEDED.
Kundorder-ID:n: en väntande förfrågan reserverar sitt kundorder-ID under fönstret. Att återanvända det för en ny orderplacering avvisas omedelbart med clientOrderIdAlreadyExist. Vänta ut fönstret innan du återanvänder ett ID, eller hantera pågående annulleringar med order-ID.
En batch hålls inte kvar som en enhet. Fönstret startar vid den första likviditetstagande instruktionen i batchen.
Instruktioner före den första aggressiva instruktionen skickas omedelbart.
Den första aggressiva instruktionen, och allt efter den, väntar ut fönstret tillsammans.
Annulleringar skickas alltid omedelbart. En annullering som placeras efter den order den riktar sig mot tar över den orderns väntan inom samma batch. En annullering som placeras före den kan inte göra det.
För att en passiv instruktion ska nå orderboken utan fördröjning ska den placeras före eventuella aggressiva instruktioner i batchen.
REST. Anslutningen hålls öppen under fördröjningen och svaret innehåller det slutliga utfallet. Ställ in klientens timeout med god marginal över fönstret. Eftersom fönstret aldrig överstiger 100 ms räcker ett enda timeout-värde för alla marknader. Om du skickar processBefore på en aggressiv order måste värdet ta hänsyn till väntetiden, annars avvisas ordern varje gång med wouldProcessAfterSpecifiedTime.
WebSocket. Inget publiceras medan en order väntar. Du tar emot de vanliga open_orders- och fills-händelserna när ordern frisläpps, ungefär ett fönster senare än tidigare.
FIX. Gatewayen skickar ett rådgivande ExecutionReport när en förfrågan väntar: Pending New (39=A) för en placering, eller Pending Replace (39=E) för en ändring. Rapporten är enbart rådgivande och utgör inte ett avslutat tillstånd. En väntande placering har inget OrderID ännu, så ClOrdID är ditt enda sätt att identifiera ordern under fönstret. Det verkliga bekräftelsemeddelandet följer vid frisläppning.
Om ett ben i en ordergrupp är kvarhållet när ett motstående syskonben fylls, tas det kvarhållna benet inte bort och båda benen kan aktiveras. En fix pågår.
På marknader med Maker Protection, kontrollera dina fyllningar efter varje syskonfyllning i en ordergrupp – anta inte att ett ben har annullerat det andra.
Maker Protection har varit aktiverat på lanseringsmarknaderna i UAT-miljön sedan den 27 augusti 2026, med samma 20 ms-fönster och tak på 250 kvarhållningar som i produktion. Kontakta din kontoansvarig för UAT-åtkomst. Det är värt att testa:
Annullering under en kvarhållning och hantering av en order som ändå fylls efteråt
Annullering under en kvarhållen ändring
En vilande order som annulleras av en frigjord order, även med REJECT_TAKER inställt
Hantering av tooManyOrders vid orderläggning och att försöka på nytt
Återanvändning av ett klientorder-ID inom ett fönster
Ordning på batchinstruktioner och tidsgränser på klientsidan som överstiger marknadens makerProtectionMillis