Maker Protection

Senest opdateret: 30. september 2026

Denne artikel er en oversigt over Maker Protection. For den fulde tekniske dokumentation, herunder protokolspecifik adfærd for REST, WebSocket og FIX, se Maker Protection-udviklervejledningen.

Maker Protection er en kort, fast forsinkelse, der anvendes på ordrer, som potentielt kan tage likviditet på udvalgte Kraken Derivatives-markeder. Det giver hvilende maker-ordrer et kort tidsvindue til at reagere på ny information, inden en indkommende ordre kan handle imod dem. Maker Protection har været aktivt siden den 24. september 2026.

På et marked med Maker Protection tilbageholdes enhver ordrehandling, der potentielt kan tage likviditet, i et kort tidsvindue, inden den når matching-maskinen. Post-only-placeringer og alle annulleringer tilbageholdes aldrig.

  • •

    Forsinkelse: 20 ms ved lanceringen og aldrig mere end 100 ms. Forsinkelsen offentliggøres pr. marked som makerProtectionMillis.

  • •

    Markeder: Kun udvalgte Derivatives-markeder (futures). Spot er ikke berørt.

  • •

    Konsistens: Adfærden er identisk på REST, WebSocket og FIX.

  • •

    Fairness: Forsinkelsen gælder ens for alle kunder. Der er ingen kontospecifikke undtagelser.

  • •

    Sådan undgår du det: Indsend ordren som post-only. En limitordre uden post-only tilbageholdes, selv hvis den ville have hvilet i ordrebogen, fordi forsinkelsen afhænger af ordretypen, ikke udfaldet.

En tilbageholdt ordre indtager sin plads i køen, når den frigives, ikke når den blev modtaget.

Den autoritative kilde er feltet makerProtectionMillis på GET /instruments og GET /trading/instruments. Hvis et marked ikke har Maker Protection, udelades feltet helt, så et manglende felt og en værdi på nul behandles ens: ingen forsinkelse.

  • •

    59 markeder var dækket ved lanceringen den 24. september 2026.

  • •

    De 10 mest likvide lineære uamortisable markeder er undtaget, så aktiv taker-strøm i de store markeder ikke bremses.

  • •

    Alle uamortisable kontrakter noteret efter den 24. september 2026 har Maker Protection fra lanceringen.

  • •

    Tilføjelser annonceres på status.kraken.com forud for hvert vedligeholdelsesvindue.

Handling

Forsinket?

Limit-, IOC-, FOK- eller markedsordre

Ja

Post-only-ordre

Nej

Redigering af en ordre, der kan hvile og fjerne likviditet

Ja

Redigering af en hvilende post-only-ordre

Nej

Placering af stop-, take-profit- eller trailing-stop-ordre

Nej

Den ordre, der udløses af et stop- eller take-profit-trigger

Ja, medmindre den udløste ordre er post-only

Ordregruppe med ny ikke-post-only-forælder

Ja

Ordregruppe tilknyttet en eksisterende ordre

Nej

Annuller, annuller alle, annuller alle efter

Nej

Blokhandler og andet off-book flow er også undtaget.

Der findes ingen "tilbageholdt" ordretilstand i den offentlige API. Maker Protection viser sig som ekstra latenstid på aggressive ordrer, og disse egenskaber er værd at designe udenom:

  • •

    Validering sker ved frigivelse. Margin, priskraver og markedsstatus kontrolleres, når forsinkelsen slutter – ikke når du indsender. En ordre, der var gyldig ved indsendelsen, kan stadig afvises.

  • •

    Det fulde vindue gennemføres altid. Hvis den likviditet, der gjorde din ordre aggressiv, forsvinder i løbet af vinduet, venter ordren stadig forsinkelsen ud. Tilbageholdte ordrer revurderes ikke.

  • •

    Ordrer frigives i rækkefølge. Tilbageholdelser frigives først ind, først ud, så en senere ordre ikke kan overhale en tidligere.

  • •

    Forsinkelsen er "mindst" det konfigurerede vindue. Ordrer udløst af et stop- eller take-profit-trigger frigives ved den næste hændelse, matching-maskinen behandler – på et stille marked kan de derfor vente mærkbart længere end det konfigurerede vindue.

  • •

    Mål ikke forsinkelsen. Læs makerProtectionMillis i stedet, da den kan ændres til enhver tid.

En tilbageholdt ordre er endnu ikke på bogen og er ikke garanteret at nå dertil. I løbet af vinduet kan en ordre påvirkes af hændelser, der er uden relation til din egen handel:

  • •

    Markedet er suspenderet: ordren afvises med marketSuspended.

  • •

    Din konto afrisikeres eller likvideres: ordren afvises med CANCELLED_WHILE_HELD.

  • •

    Margin eller priskraver bevæger sig imod dig: ordren kan afvises ved frigivelse.

  • •

    Du ændrer din gearing eller margen-tilstand: ændringen afvises, så længe du har anmodninger under tilbageholdelse. Prøv igen, når dine tilbageholdelser er frigivet.

Hvis du modtager en afvisning ca. ét vindue efter at have sendt en ordre, skyldes det som regel ikke, at ordren var forkert udformet. Kontrollér den returnerede status.

Du kan annullere en ordre, mens den er tilbageholdt, og annulleringer forsinkes aldrig. En annullering kan dog ikke tilbagekalde indgået aggression. Annulleringen fjerner ordrens ret til at hvile på bogen, men ikke dens forpligtelse til at handle.

En annulleret tilbageholdt ordre kan stadig gennemføres. Bevæger markedet sig i din favør i løbet af vinduet, tager ordren stadig den likviditet, den kan, ved frigivelse. Afgiv ikke ordren igen efter en vellykket annullering.

Hvad der sker, afhænger af typen af den anmodning, der tilbageholdes:

  • •

    Limitordre: annulleringen bekræftes, og ordren frigives som immediate-or-cancel. Den tager, hvad den kan, og eventuel rest kasseres. Du modtager to svar: annulleringens og ordrens eget ca. ét vindue senere. Kan ordren ikke handle ved frigivelse, returnerer REST v3 iocWouldNotExecute.

  • •

    IOC-, FOK- eller markedsordre: der er intet at konvertere, så annulleringen returnerer ORDER_NOT_FOUND, og ordren lander stadig ved frigivelse.

  • •

    Redigering af en resting-ordre: den oprindelige ordre forbliver aktiv til sin gamle pris i løbet af vinduet. En annullering absorberes, og ved frigivelse omskrives redigeringen, så ordren får ny pris og ikke længere kan stå som resting-ordre.

  • •

    Ordregruppe: en gruppe med en tilbageholdt overordnet ordre kan ikke annulleres i vinduet og går live ved frigivelse. Annuller den, når den er live.

  • •

    Sikkerhedsstop (cancelallordersafter): en tilbageholdt ordre konverteres på samme måde. Sikkerhedsstoppet tilbagekalder ikke en tilbageholdt ordre.

Hvis du ikke ønsker nogen resting-ordrer og ingen ny handel, så vent vinduet ud (maksimalt 100 ms) og annuller derefter.

Ordregruppe: en gruppe med en tilbageholdt overordnet ordre kan ikke annulleres i vinduet og aktiveres ved frigivelse. Annuller den, når den er aktiv.

  • •

    Din resting-ordre annulleres med årsagen CANCELLED_BY_SELF_TRADE, og den frigivne ordre handles.

  • •

    Din resting-ordre annulleres med årsagen CANCELLED_BY_SELF_TRADE, og den frigivne ordre gennemføres.

  • •

    Ordrer, der aldrig har været tilbageholdt, er heller ikke påvirket.

Hvis du anvender REJECT_TAKER til at beskytte dine resting-pristilbud på et Maker Protection-marked, gælder denne beskyttelse ikke over for dine egne frigivne ordrer.

Samtidige tilbageholdelser. Du kan højst have 250 anmodninger tilbageholdt ad gangen. En anmodning ud over grænsen afvises og rapporteres, som om du havde nået din ordregræns (tooManyOrders på REST v3, TOO_MANY_ORDERS på REST v4, ORDER_LIMIT_EXCEEDED på markedsdata og SBE). Grænsen begrænser, hvor mange tilbageholdelser der er aktive samtidig – ikke hvor hurtigt du kan sende ordrer. Den deles på tværs af en masterkonto og dens underkonti, og det er sikkert at forsøge igen, når dine tidligere tilbageholdelser er frigivet.

Kontogrænser fastsættes, når tilbageholdelsen åbnes. For at forhindre, at kontoindstillinger ændres midt i vinduet, fastsættes visse grænser ved åbningen af tilbageholdelsen – ikke ved frigivelse:

  • •

    Grænse for åbne ordrer: hvis du er ved din grænse, accepteres ordren, men konverteres, så den ikke kan hvile på ordrebogen.

  • •

    Maksimal position: budgettet reserveres til ordren ved afsendelse. En ordre, der afvises på det tidspunkt, forbliver afvist, selv hvis du frigør budget – og reserveret budget er ikke tilgængeligt for efterfølgende ordrer, som afvises med MAX_POSITION_EXCEEDED.

  • •

    Kundeordre-id'er: en tilbageholdelse reserverer sit kundeordre-id i vinduet. Genbrug af det til en anden placering afvises straks med clientOrderIdAlreadyExist. Vent vinduet ud, før du genbruger et id, eller håndter igangværende annulleringer via ordre-id.

En batch tilbageholdes ikke som én samlet enhed. Vinduet starter ved den første likviditetstageende instruktion i batchen.

  • •

    Instruktioner forud for den første aggressive instruktion sendes straks.

  • •

    Den første aggressive instruktion og alt efter den venter vinduet ud samlet.

  • •

    Annulleringer sendes altid straks. En annullering placeret efter den ordre, den er rettet mod, overtager ordrens tilbageholdelse inden for samme batch. En annullering placeret forud for den kan ikke.

For at sikre, at en passiv instruktion når ordrebogen uden forsinkelse, skal den placeres inden eventuelle aggressive instruktioner i batchen.

REST. Forbindelsen holdes i forsinkelsesperioden, og svaret indeholder det endelige resultat. Indstil timeout på klientsiden med god margin over vinduet. Da vinduet aldrig overstiger 100 ms, dækker ét enkelt timeout-budget alle markeder. Hvis du sender processBefore på en aggressiv ordre, skal værdien tage højde for tilbageholdelsen – ellers afvises ordren hver gang med wouldProcessAfterSpecifiedTime.

WebSocket. Der publiceres intet, mens en ordre er tilbageholdt. Du modtager de sædvanlige open_orders- og fills-hændelser, når ordren frigives – ca. ét vindue senere end normalt.

FIX. Gatewayen sender en vejledende ExecutionReport, når en anmodning tilbageholdes: Pending New (39=A) ved en placering eller Pending Replace (39=E) ved en ændring. Rapporten er udelukkende vejledende og udgør ikke en endelig tilstand. En tilbageholdt placering har endnu ikke noget OrderID, så ClOrdID er din eneste reference til ordren i vinduet. Den reelle bekræftelse følger ved frigivelse.

Hvis det ene ben i en ordregruppe er tilbageholdt, når det modsatte ben leveres, fjernes det tilbageholdte ben ikke, og begge ben kan aktiveres. En rettelse er under udarbejdelse.

På Maker Protection-markeder bør du kontrollere dine leveringer efter enhver levering på det modsatte ben i en ordregruppe – frem for at antage, at det ene ben har annulleret det andet.

Maker Protection har været aktiveret på lanceringsmarkederne i klient-UAT-miljøet siden den 27. august 2026 med samme 20 ms-vindue og grænse på 250 samtidige tilbageholdelser som i produktion. Kontakt din account manager for adgang til UAT. Det er værd at teste:

  • •

    Annullering under en tilbageholdelse og håndtering af en ordre, der alligevel leveres bagefter

  • •

    Annullering under en tilbageholdt ændring

  • •

    At en resting-ordre annulleres af en frigivet ordre, selv med REJECT_TAKER aktiveret

  • •

    Håndtering af tooManyOrders ved en ordreplacering og genforsøg

  • •

    Genbrug af et klientordre-ID inden for et vindue

  • •

    Rækkefølge af batch-instruktioner og klientside-timeouts over markedets makerProtectionMillis