Maker Protection

Ultima actualizare: 30 septembrie 2026

Acest articol este un rezumat al funcției Maker Protection. Pentru detalii tehnice complete, inclusiv comportamentul specific fiecărui protocol pentru REST, WebSocket și FIX, consultați ghidul pentru dezvoltatori Maker Protection.

Maker Protection este o întârziere scurtă și fixă aplicată ordinelor care ar putea prelua lichiditate pe piețele Kraken Derivatives selectate. Aceasta oferă ordinelor maker resting un scurt interval pentru a reacționa la informații noi înainte ca un ordin nou să poată tranzacționa împotriva lor. Maker Protection este activă din 24 septembrie 2026.

Ce este Maker Protection?

Pe o piață cu Maker Protection, orice acțiune asupra unui ordin care ar putea prelua lichiditate este reținută pentru un scurt interval înainte de a ajunge la Motorul de asociere. Plasările post-only și toate anulările nu sunt niciodată reținute.

•
Întârziere: 20 ms la lansare și niciodată mai mult de 100 ms. Întârzierea este publicată per piață ca makerProtectionMillis.
•
Piețe: Exclusiv piețe de Instrumente derivate (contracte futures) selectate. Spot nu este afectat.
•
Uniformitate: Comportamentul este identic pe REST, WebSocket și FIX.
•
Echitate: Întârzierea se aplică în mod egal tuturor clienților. Nu există scutiri per cont.
•
Cum să o eviți: Trimite ordinul ca post-only. Un ordin limită fără post-only este reținut chiar dacă ar fi rămas în registru, deoarece întârzierea depinde de tipul ordinului, nu de rezultat.

Un ordin reținut își ocupă locul în coadă la momentul eliberării, nu la momentul primirii.

Pe ce piețe este disponibil Maker Protection?

Sursa de referință este câmpul makerProtectionMillis din GET /instruments și GET /trading/instruments. Dacă o piață nu are Maker Protection, câmpul lipsește complet – tratează un câmp absent și o valoare zero identic: nicio întârziere.

•
La lansare, pe 24 septembrie 2026, au fost acoperite 59 de piețe.
•
Cele mai lichide 10 piețe de contracte perpetue liniare sunt excluse, pentru a nu încetini fluxul activ al taker-ilor pe piețele principale.
•
Orice contract perpetuu listat după 24 septembrie 2026 beneficiază de Maker Protection de la lansare.
•
Adăugările sunt anunțate pe status.kraken.com înaintea fiecărei ferestre de mentenanță.

Ce ordine sunt întârziate?

Acțiune	Întârziat?
Ordin limită, IOC, FOK sau la piață	Da
Ordin post-only	Nu
Modificare a unui ordin care poate rămâne în registru și prelua lichiditate	Da
Modificare a unui ordin post-only aflat în registru	Nu
Plasare stop, take-profit sau trailing-stop	Nu
Ordinul declanșat de un stop sau take-profit	Da, cu excepția cazului în care ordinul declanșat este post-only
Grup de ordine cu un ordin-părinte care nu este post-only	Da
Grup de ordine atașat la un ordin existent	Nu
Anulare, anulare-totală, anulare-totală-după	Nu

Tranzacțiile bloc și alte fluxuri în afara registrului de ordine sunt, de asemenea, exceptate.

Cum funcționează întârzierea

Nu există o stare de ordin „reținut" în API-ul public. Maker Protection se manifestă ca latență suplimentară pe ordinele agresive, iar aceste caracteristici merită avute în vedere la proiectare:

•
Validarea are loc la eliberare. Marja, benzile de preț și starea pieței sunt verificate la încheierea întârzierii, nu la momentul trimiterii. Un ordin valid la trimitere poate fi în continuare respins.
•
Fereastra completă este întotdeauna respectată. Dacă lichiditatea care a făcut ordinul tău agresiv dispare în timpul ferestrei, ordinul continuă să aștepte până la expirarea întârzierii. Ordinele reținute nu sunt reevaluate.
•
Ordinele sunt eliberate în ordine. Reținerile sunt eliberate primul intrat, primul ieșit, astfel că un ordin ulterior nu poate depăși unul anterior.
•
Întârzierea este „cel puțin" egală cu fereastra configurată. Ordinele declanșate de un stop sau de un trigger take-profit sunt eliberate la următorul eveniment procesat de Motorul de asociere; pe o piață liniștită, așteptarea poate fi vizibil mai lungă decât fereastra configurată.
•
Nu măsura întârzierea. Citește în schimb makerProtectionMillis, deoarece aceasta poate fi modificată oricând.

Ce se poate întâmpla cât timp un ordin este reținut

Un ordin reținut nu se află încă în registrul de ordine și nu este garantat că va ajunge acolo. Pe durata ferestrei, un ordin poate fi afectat de evenimente fără legătură cu propriile tale tranzacții:

•
Piața este suspendată: ordinul este respins cu marketSuspended.
•
Contul tău este de-riscat sau lichidat: ordinul este refuzat cu CANCELLED_WHILE_HELD.
•
Marja sau benzile de preț se mișcă împotriva ta: ordinul poate fi respins la eliberare.
•
Modifici levierul sau modul de marjă: modificarea este refuzată cât timp ai orice solicitare reținută. Încearcă din nou după ce reținerile au fost eliberate.

Dacă primești o respingere la aproximativ o fereastră după trimiterea unui ordin, aceasta nu se datorează de obicei faptului că ordinul în sine era malformat. Verifică statusul returnat.

Anularea unui ordin reținut

Poți anula un ordin cât timp este reținut, iar anulările nu sunt niciodată întârziate. Totuși, o anulare nu poate retrage agresiunea deja angajată. Anularea elimină dreptul ordinului de a rămâne în registru, dar nu și obligația sa de a tranzacționa.

Un ordin reținut anulat poate fi în continuare onorat. Dacă piața evoluează în favoarea ta pe durata ferestrei, ordinul preia în continuare lichiditatea disponibilă la eliberare. Nu retrimite ordinul după o anulare reușită.

Ce se întâmplă depinde de tipul solicitării reținute:

•
Ordin limită: anularea este confirmată, iar ordinul este eliberat ca immediate-or-cancel. Preia ce poate, iar restul este eliminat. Primești două răspunsuri: cel al anulării și cel al ordinului propriu-zis, după aproximativ o fereastră. Dacă ordinul nu poate tranzacționa la eliberare, REST v3 returnează iocWouldNotExecute.
•
Ordin IOC, FOK sau la piață: nu există nimic de convertit, astfel că anularea returnează ORDER_NOT_FOUND, iar ordinul se execută în continuare la eliberare.
•
Modificare a unui ordin în repaus: ordinul original rămâne activ la prețul vechi pe durata ferestrei. O anulare este absorbită, iar la eliberare modificarea este rescrisă astfel încât ordinul își schimbă prețul și nu mai poate rămâne în repaus.
•
Grup de ordine: un grup cu un ordin-părinte reținut nu poate fi anulat în timpul ferestrei și devine activ la eliberare. Anulează-l după ce devine activ.
•
Dead Man's Switch (cancelallordersafter): un ordin reținut este convertit în același mod. Switch-ul nu retrage un ordin reținut.

Dacă nu vrei să rămână ordine în repaus și nici ordine noi să se execute, așteaptă expirarea ferestrei (maximum 100 ms), apoi anulează.

Prevenirea auto-tranzacționării

Când un ordin reținut este eliberat, anulează automat orice ordin în repaus al tău cu care s-ar putea potrivi, indiferent de strategia de auto-tranzacționare configurată în contul tău. Acest lucru se aplică întregii ierarhii de conturi, inclusiv contul principal, conturile asociate și sub-conturile.

•
Ordinul tău în repaus este anulat cu motivul CANCELLED_BY_SELF_TRADE, iar ordinul eliberat se execută.
•
Ordinele FOK și RFQ-urile sunt excepție. Strategia configurată se aplică în mod obișnuit.
•
Ordinele care nu au fost niciodată reținute nu sunt afectate.

Dacă te bazezi pe REJECT_TAKER pentru a-ți proteja cotațiile în repaus pe o piață cu Maker Protection, această protecție nu se aplică pentru propriile ordine eliberate.

Limite aplicabile cât timp ordinele sunt reținute

Rețineri simultane. Poți avea cel mult 250 de solicitări reținute simultan. O solicitare care depășește limita este refuzată și raportată ca și cum ai fi atins limita de ordine (tooManyOrders pe REST v3, TOO_MANY_ORDERS pe REST v4, ORDER_LIMIT_EXCEEDED pe market data și SBE). Limita restricționează numărul de rețineri active în același timp, nu viteza cu care poți trimite ordine. Este partajată între contul principal și sub-conturile sale; poți retrimite în siguranță după ce reținările anterioare au fost eliberate.

Limitele contului se stabilesc la deschiderea reținerii. Pentru a preveni modificarea setărilor contului în cursul ferestrei, unele limite sunt stabilite la deschiderea reținerii, nu la eliberare:

•
Limita de ordine deschise: dacă ai atins limita, ordinul este acceptat, dar convertit astfel încât să nu poată rămâne în repaus.
•
Poziție maximă: bugetul este rezervat pentru ordin la momentul transmiterii. Un ordin refuzat în acel moment rămâne refuzat chiar dacă eliberezi buget ulterior, iar bugetul rezervat nu este disponibil pentru ordine ulterioare, care sunt refuzate cu MAX_POSITION_EXCEEDED.
•
ID-uri de ordine client: o reținere rezervă ID-ul ordinului client pentru durata ferestrei. Reutilizarea acestuia pentru o altă plasare este refuzată imediat cu clientOrderIdAlreadyExist. Așteaptă expirarea ferestrei înainte de a reutiliza un ID sau gestionează anulările în curs prin ID-ul ordinului.

Ordine în lot

Un lot nu este reținut ca unitate unică. Fereastra începe la prima instrucțiune din lot care preia lichiditate.

•
Instrucțiunile de dinaintea primei instrucțiuni agresive sunt trimise imediat.
•
Prima instrucțiune agresivă și tot ce urmează după ea așteaptă împreună expirarea ferestrei.
•
Anulările sunt întotdeauna trimise imediat. O anulare plasată după ordinul vizat preia reținerea acelui ordin în cadrul aceluiași lot. O anulare plasată înainte nu poate face acest lucru.

Pentru a te asigura că o instrucțiune pasivă ajunge în registrul de ordine fără întârziere, plasează-o înaintea oricărei instrucțiuni agresive din lot.

Utilizarea API și FIX

REST. Conexiunea este menținută pe durata întârzierii, iar răspunsul conține rezultatul final. Setează timeout-ul pe partea de client cu o marjă confortabilă peste durata ferestrei. Deoarece fereastra nu depășește niciodată 100 ms, un singur timeout acoperă toate piețele. Dacă trimiți processBefore pe un ordin agresiv, acesta trebuie să includă durata reținerii; în caz contrar, ordinul este refuzat de fiecare dată cu wouldProcessAfterSpecifiedTime.

WebSocket. Nu se publică nimic cât timp un ordin este reținut. Vei primi evenimentele obișnuite open_orders și fills după eliberarea ordinului, cu circa o fereastră de întârziere față de înainte.

FIX. Gateway-ul trimite un ExecutionReport cu titlu informativ când o solicitare este reținută: Pending New (39=A) pentru o plasare sau Pending Replace (39=E) pentru o modificare. Raportul are caracter exclusiv informativ și nu reprezintă o stare finală. O plasare reținută nu are încă OrderID, astfel că ClOrdID este singurul tău identificator pentru ordin pe durata ferestrei. Confirmarea reală urmează la eliberare.

Limitare cunoscută pentru grupurile de ordine

Dacă o ramură a unui grup de ordine este reținută în momentul în care o ramură opusă este onorată, ramura reținută nu este eliminată și ambele ramuri pot deveni active. O remediere este în curs.

Pe piețele cu Maker Protection, verifică onorările după orice onorare a unui ordin dintr-un grup, în loc să presupui că o ramură a anulat-o pe cealaltă.

Testarea integrării

Maker Protection a fost activat pe piețele de lansare în mediul UAT al clientului începând cu 27 august 2026, cu aceeași fereastră de 20 ms și limita de 250 de rețineri ca în producție. Contactează managerul de cont pentru acces UAT. Merită să testezi:

•
Anularea în timpul unei rețineri și gestionarea unui ordin care este totuși onorat ulterior
•
Anularea în timpul unei modificări reținute
•
Un ordin în repaus al tău poate fi anulat de un ordin eliberat, chiar și cu REJECT_TAKER setat
•
Gestionarea tooManyOrders la plasarea unui ordin și reîncercarea acestuia
•
Reutilizarea unui ID de ordin al clientului în cadrul unei ferestre
•
Ordinea instrucțiunilor dintr-un lot și timeout-urile pe partea clientului peste makerProtectionMillis al pieței