Maker Protection

Sist oppdatert: 30. september 2026

Denne artikkelen er et sammendrag av Maker Protection. For fullstendig teknisk dokumentasjon, inkludert protokollspesifikk atferd for REST, WebSocket og FIX, se utviklerveiledningen for Maker Protection.

Maker Protection er en kort, fast forsinkelse som gjelder for ordrer som kan ta likviditet i utvalgte Kraken Derivatives-markeder. Den gir hvilende maker-ordrer et kort tidsvindu til å reagere på ny informasjon før en innkommende ordre kan handles mot dem. Maker Protection har vært aktiv siden 24. september 2026.

Hva er Maker Protection?

I et marked med Maker Protection holdes enhver ordrehandling som kan ta likviditet i et kort tidsvindu før den når den matchende motoren. Post-only-plasseringer og alle kanselleringer holdes aldri.

•
Forsinkelse: 20 ms ved lansering, og aldri mer enn 100 ms. Forsinkelsen publiseres per marked som makerProtectionMillis.
•
Markeder: Kun utvalgte derivatmarkeder (futures). Spot påvirkes ikke.
•
Konsistens: Atferden er identisk på REST, WebSocket og FIX.
•
Likebehandling: Forsinkelsen gjelder likt for alle kunder. Det finnes ingen unntak per konto.
•
Slik unngår du det: Send ordren som post-only. En Limit-ordre uten post-only holdes selv om den ville ha hvilt i ordreboken, fordi forsinkelsen avhenger av ordretypen, ikke utfallet.

En holdt ordre får sin plass i køen når den frigis, ikke når den ble mottatt.

Hvilke markeder har Maker Protection?

Den autoritative kilden er feltet makerProtectionMillis på GET /instruments og GET /trading/instruments. Hvis et marked ikke har Maker Protection, utelates feltet helt – behandle derfor et manglende felt og en verdi på null som det samme: ingen forsinkelse.

•
59 markeder var inkludert ved lansering 24. september 2026.
•
De 10 mest likvide lineære evigvarende-markedene er utelukket, slik at aktiv taker-flyt i de største markedene ikke bremses.
•
Alle evigvarende kontrakter notert etter 24. september 2026 har Maker Protection fra lansering.
•
Tillegg kunngjøres på status.kraken.com før hvert vedlikeholdsvindu.

Hvilke ordrer forsinkes?

Handling	Forsinket?
Limit-, IOC-, FOK- eller markedsordre	Ja
Post-only-ordre	Nei
Redigering av en ordre som kan hvile og ta likviditet	Ja
Redigering av en hvilende post-only-ordre	Nei
Plassering av stop-, take-profit- eller trailing-stop-ordre	Nei
Ordren som utløses av en stop- eller take-profit-trigger	Ja, med mindre den utløste ordren er post-only
Ordregruppe med ny ikke-post-only-forelder	Ja
Ordregruppe som kobler seg til en eksisterende ordre	Nei
Kanseller, kanseller alle, kanseller-alle-etter	Nei

Blokkhandler og annen handel utenfor ordreboken er også unntatt.

Slik fungerer forsinkelsen

Det finnes ingen «holdt»-ordrestatus i det offentlige API-et. Maker Protection vises som ekstra forsinkelse (latenstid) på aggressive ordrer, og det er verdt å ta hensyn til disse egenskapene i integrasjonen din:

•
Validering skjer ved frigivelse. Margin, priskrager og markedsstatus kontrolleres når forsinkelsen er over, ikke når du sender ordren. En ordre som var gyldig ved innsending kan likevel avvises.
•
Hele vinduet avventes alltid. Hvis likviditeten som gjorde ordren din aggressiv forsvinner i løpet av vinduet, venter ordren likevel ut forsinkelsen. Ordrer på vent evalueres ikke på nytt.
•
Ordrer frigis i rekkefølge. Ventende forespørsler frigis først inn, først ut, slik at en senere ordre ikke kan gå foran en tidligere.
•
Forsinkelsen er «minst» det konfigurerte vinduet. Ordrer utløst av en stop- eller take-profit-trigger frigis ved neste hendelse den matchende motoren behandler, så på et rolig marked kan de vente merkbart lenger enn det konfigurerte vinduet.
•
Ikke mål forsinkelsen. Les makerProtectionMillis i stedet, siden den kan endres når som helst.

Hva kan skje mens en ordre er holdt

En holdt ordre er ennå ikke i ordreboken og er ikke garantert å komme dit. I løpet av vinduet kan en ordre påvirkes av hendelser som ikke har noe med din egen handel å gjøre:

•
Markedet er suspendert: ordren avvises med marketSuspended.
•
Kontoen din de-riskes eller likvideres: ordren avvises med CANCELLED_WHILE_HELD.
•
Margin eller priskrager beveger seg mot deg: ordren kan avvises ved frigivelse.
•
Du endrer giring eller marginmodus: endringen avvises så lenge du har forespørsler på vent. Prøv igjen når de ventende forespørslene er frigitt.

Hvis du mottar et avslag omtrent ett vindu etter at du sendte en ordre, skyldes det vanligvis ikke at ordren var feilformatert. Kontroller den returnerte statusen.

Kansellering av en holdt ordre

Du kan kansellere en ordre mens den er holdt, og kanselleringer forsinkes aldri. En kansellering kan imidlertid ikke angre allerede igangsatt aggresjon. Kansellering fjerner ordrens rett til å ligge i ordreboken, men ikke dens forpliktelse til å handle.

En kansellert holdt ordre kan fortsatt utføres. Hvis markedet beveger seg i din favør i løpet av vinduet, tar ordren likevel den tilgjengelige likviditeten ved frigivelse. Ikke forsøk å legge inn ordren på nytt etter en vellykket kansellering.

Hva som skjer, avhenger av hvilken type forespørsel som holdes tilbake:

•
Limit-ordre: kanselleringen bekreftes, og ordren frigis som immediate-or-cancel. Den tar det den kan, og eventuell rest forkastes. Du mottar to svar: ett for kanselleringen og ett for selve ordren omtrent ett vindu senere. Hvis ordren ikke kan handles ved frigivelse, returnerer REST v3 iocWouldNotExecute.
•
IOC, FOK eller markedsordre: det er ingenting å konvertere, så kanselleringen returnerer ORDER_NOT_FOUND og ordren utføres likevel ved frigivelse.
•
Redigering av en liggende ordre: den opprinnelige ordren forblir aktiv til sin gamle pris i løpet av vinduet. En kansellering absorberes, og ved frigivelse skrives redigeringen om slik at ordren prises på nytt og ikke lenger kan ligge i ordreboken.
•
Ordregruppe: en gruppe med en holdt overordnet ordre kan ikke kanselleres i holdevinduet og aktiveres ved frigivelse. Kanseller den når den er aktiv.
•
Dødmannsknapp (cancelallordersafter): en holdt ordre konverteres på samme måte. Dødmannsknappen tilbakekaller ikke en holdt ordre.

Hvis du ikke vil ha noe liggende og ingen ny handel, venter du ut vinduet (maks 100 ms) og kansellerer deretter.

Selvhandel-beskyttelse

Når en holdt ordre frigis, kansellerer den alltid eventuelle liggende ordrer fra deg som den ville truffet, uavhengig av hvilken selvhandel-strategi kontoen din bruker. Dette gjelder hele kontohierarkiet ditt, inkludert hovedkontoen, søsterkontoer og underkontoer.

•
Din liggende ordre kanselleres med årsaken CANCELLED_BY_SELF_TRADE, og den frigitte ordren utføres.
•
FOK-ordrer og RFQ-er er unntaket. Den konfigurerte strategien din gjelder som normalt.
•
Ordrer som aldri ble holdt, påvirkes heller ikke.

Hvis du bruker REJECT_TAKER for å beskytte dine liggende tilbud på et Maker Protection-marked, gjelder ikke denne beskyttelsen mot dine egne frigitte ordrer.

Begrensninger som gjelder mens ordrer holdes

Samtidige hold. Du kan ha maks 250 forespørsler holdt samtidig. En forespørsel utover grensen avvises og rapporteres som om du hadde nådd ordrebegrensningen din (tooManyOrders på REST v3, TOO_MANY_ORDERS på REST v4, ORDER_LIMIT_EXCEEDED på markedsdata og SBE). Grensen begrenser antall aktive hold samtidig, ikke hvor raskt du kan sende ordrer. Den deles mellom en hovedkonto og dens underkontoer, og det er trygt å prøve igjen når tidligere hold er frigitt.

Kontobegrensninger fastsettes når holdet åpnes. For å hindre at kontoinnstillinger endres midt i vinduet, fastsettes noen begrensninger når holdet åpnes, ikke ved frigivelse:

•
Grense for åpne ordrer: hvis du er på grensen, blir ordren akseptert, men konvertert slik at den ikke kan ligge.
•
Maksimumsposisjon: budsjettet reserveres for ordren ved innsending. En ordre som avvises på det tidspunktet, forblir avvist selv om du frigjør budsjett, og reservert budsjett er utilgjengelig for senere ordrer, som avvises med MAX_POSITION_EXCEEDED.
•
Kundeordre-ID-er: et hold reserverer sin kundeordre-ID for vinduet. Gjenbruk av ID-en for en ny plassering avvises umiddelbart med clientOrderIdAlreadyExist. Vent ut vinduet før du gjenbruker en ID, eller håndter pågående kanselleringer via ordre-ID.

Batchordrer

En batch holdes ikke som én enhet. Vinduet starter ved den første aggressive instruksjonen i batchen.

•
Instruksjoner før den første aggressive instruksjonen sendes umiddelbart.
•
Den første aggressive instruksjonen, og alt etter den, venter ut vinduet sammen.
•
Kanselleringer sendes alltid umiddelbart. En kansellering plassert etter den ordren den retter seg mot, overtar holdet for den ordren innenfor samme batch. En kansellering plassert før den kan ikke gjøre det.

For å sikre at en passiv instruksjon når ordreboken uten forsinkelse, plasser den foran eventuelle aggressive instruksjoner i batchen.

Bruk av API og FIX

REST. Tilkoblingen holdes i forsinkelsesperioden, og svaret inneholder det endelige resultatet. Sett tidsavbruddet på klientsiden godt over vinduet. Siden vinduet aldri overstiger 100 ms, dekker ett tidsavbrudd alle markeder. Hvis du sender processBefore på en aggressiv ordre, må det ta høyde for holdet – ellers avvises ordren hver gang med wouldProcessAfterSpecifiedTime.

WebSocket. Ingenting publiseres mens en ordre holdes. Du mottar de vanlige open_orders- og fills-hendelsene når ordren frigis, omtrent ett vindu senere enn før.

FIX. Gatewayen sender en rådgivende ExecutionReport når en forespørsel holdes: Pending New (39=A) for en plassering, eller Pending Replace (39=E) for en endring. Rapporten er kun rådgivende og er ikke en endelig tilstand. En holdt plassering har ingen OrderID ennå, så ClOrdID er eneste håndtak på ordren i vinduet. Den reelle bekreftelsen følger ved frigivelse.

Kjent begrensning med ordregrupper

Hvis én del av en ordregruppe holdes tilbake når en motstående søsterordre utføres, fjernes ikke den tilbakeholdte delen, og begge deler kan bli aktive. En løsning er under arbeid.

På Maker Protection-markeder bør du sjekke utførelsene dine etter enhver søsterutføring i en ordregruppe, i stedet for å anta at én del har kansellert den andre.

Test integrasjonen din

Maker Protection har vært aktivert på lansjeringsmarkedene i kunde-UAT-miljøet siden 27. august 2026, med samme 20 ms-vindu og 250-holdsgrense som i produksjon. Kontakt kontosjefen din for UAT-tilgang. Det er verdt å teste:

•
Kansellering under et hold, og håndtering av en ordre som likevel utføres etterpå
•
Kansellering under en tilbakeholdt endring
•
En liggende ordre som kanselleres av en frigjort ordre, selv med REJECT_TAKER satt
•
Håndtering av tooManyOrders ved en plassering, og nytt forsøk
•
Gjenbruk av en kundeordre-ID innenfor et vindu
•
Rekkefølge på batchinstruksjoner, og tidsavbrudd på klientsiden over markedets makerProtectionMillis