Maker Protection

Poslední aktualizace: 30. září 2026

Tento článek je shrnutím funkce Maker Protection. Úplné technické podrobnosti včetně chování specifického pro protokoly REST, WebSocket a FIX najdete v příručce Maker Protection pro vývojáře.

Maker Protection je krátké, pevně stanovené zpoždění aplikované na příkazy, které by mohly odebírat likviditu na vybraných trzích Kraken Derivatives. Příkazům tvůrců čekajícím v knize příkazů poskytuje krátké okno pro reakci na nové informace předtím, než s nimi může obchodovat příchozí příkaz. Maker Protection je aktivní od 24. září 2026.

Co je Maker Protection?

Na trhu s Maker Protection je každý příkaz, který by mohl odebírat likviditu, zadržen na krátké okno před dosažením párovacího enginu. Příkazy post-only a veškerá zrušení zadržení nepodléhají.

•
Zpoždění: 20 ms při spuštění, nejvýše však 100 ms. Zpoždění je pro každý trh publikováno jako makerProtectionMillis.
•
Trhy: Pouze vybrané trhy derivátů (futures). Na spot se nevztahuje.
•
Konzistence: Chování je totožné pro REST, WebSocket i FIX.
•
Spravedlnost: Zpoždění se vztahuje stejně na každého klienta. Neexistují žádné výjimky pro jednotlivé účty.
•
Jak se tomu vyhnout: Odešlete příkaz jako post-only. Limitní příkaz bez post-only je zadržen i tehdy, pokud by jinak zůstal v knize příkazů, protože zpoždění závisí na typu příkazu, nikoli na výsledku.

Zadržený příkaz zaujme místo ve frontě při uvolnění, nikoli při přijetí.

Které trhy mají Maker Protection?

Autoritativním zdrojem je pole makerProtectionMillis v GET /instruments a GET /trading/instruments. Pokud trh nemá Maker Protection, pole zcela chybí – chybějící pole a hodnotu nula proto považujte za totéž: žádné zpoždění.

•
Při spuštění 24. září 2026 funkce pokrývala 59 trhů.
•
10 nejlikvidnějších lineárních trhů perpetuálních futures je vyloučeno, aby se nezpomaloval tok příkazů účastníků na hlavních trzích.
•
Každé perpetuální futures kótované po 24. září 2026 má Maker Protection aktivní od spuštění.
•
Nové přírůstky jsou oznamovány na status.kraken.com před každým servisním oknem.

Které příkazy jsou zpožděny?

Akce	Zpožděn?
Limitní, IOC, FOK nebo tržní příkaz	Ano
Příkaz post-only	Ne
Úprava příkazu, který může ležet v knize nebo odebírat likviditu	Ano
Úprava pasivního příkazu post-only	Ne
Zadání příkazu stop, take-profit nebo trailing stop	Ne
Příkaz aktivovaný triggerem stop nebo take-profit	Ano, není-li aktivovaný příkaz post-only
Skupina příkazů s novým nadřazeným příkazem bez post-only	Ano
Skupina příkazů navázaná na existující příkaz	Ne
Zrušení, zrušení všeho, zrušení všeho po době	Ne

Blokové obchody a ostatní mimoburzovní tok jsou rovněž vyjmuty.

Jak zpoždění funguje

Ve veřejném API neexistuje stav „pozdržený" příkaz. Maker Protection se projeví jako zvýšená latence u agresivních příkazů – při navrhování integrace je vhodné počítat s těmito vlastnostmi:

•
Ověření probíhá při uvolnění. Marže, cenová pásma a stav trhu se kontrolují po skončení zpoždění, nikoli při odeslání příkazu. Příkaz, který byl při odeslání platný, může být přesto zamítnut.
•
Celé okno je vždy vyčerpáno. Pokud likvidita, která váš příkaz učinila agresivním, během okna zmizí, příkaz na zpoždění přesto čeká. Pozdržené příkazy se znovu nevyhodnocují.
•
Příkazy jsou uvolňovány v pořadí. Pozastavení se uvolňují první dovnitř, první ven, takže pozdější příkaz nemůže předstihnout dřívější.
•
Zpoždění trvá „nejméně" nastavené okno. Příkazy spuštěné triggerem stop nebo take-profit jsou uvolněny při nejbližší události, kterou párovací engine zpracuje – na klidném trhu tak mohou čekat znatelně déle, než odpovídá nastavenému oknu.
•
Zpoždění neměřte sami. Místo toho čtěte hodnotu makerProtectionMillis, která se může kdykoli změnit.

Co se může stát, dokud je příkaz pozdržen

Pozdržený příkaz ještě není v knize příkazů a není zaručeno, že se tam dostane. Během okna může příkaz ovlivnit událost nesouvisející s vaším obchodováním:

•
Trh je pozastaven: příkaz je zamítnut s kódem marketSuspended.
•
Váš účet je de-riskován nebo likvidován: příkaz je odmítnut s kódem CANCELLED_WHILE_HELD.
•
Marže nebo cenová pásma se obrátí proti vám: příkaz může být při uvolnění zamítnut.
•
Změníte pákový efekt nebo režim marže: změna je odmítnuta, dokud máte jakoukoli žádost pozdrženu. Opakujte pokus, až budou vaše pozastavení uvolněna.

Pokud obdržíte zamítnutí přibližně jedno okno po odeslání příkazu, příkaz nebyl zpravidla zamítnut kvůli chybnému formátu. Zkontrolujte vrácený stav.

Zrušení podrženého příkazu

Pozdržený příkaz lze zrušit a zrušení není nikdy zpožděno. Zrušením však nelze odvolat zahájenou agresi. Zrušení odebere příkazu právo čekat v knize, nikoli však povinnost obchodovat.

Zrušený pozdržený příkaz se může přesto realizovat. Pokud se trh během okna pohne ve váš prospěch, příkaz při uvolnění odebere dostupnou likviditu. Po úspěšném zrušení příkaz znovu neodesílejte.

Co se stane, závisí na typu pozdržené žádosti:

•
Limitní příkaz: zrušení je potvrzeno a příkaz je uvolněn jako immediate-or-cancel. Realizuje, co může, a zbytek je zahozen. Obdržíte dvě odpovědi: potvrzení zrušení a vlastní odpověď příkazu přibližně o jedno okno později. Pokud příkaz při uvolnění nemůže obchodovat, REST v3 vrátí iocWouldNotExecute.
•
IOC, FOK nebo tržní příkaz: není co převádět, takže zrušení vrátí ORDER_NOT_FOUND a příkaz se při uvolnění přesto provede.
•
Úprava čekajícího příkazu: původní příkaz zůstává aktivní za původní cenu po celou dobu okna. Zrušení je absorbováno a při uvolnění je úprava přepsána tak, aby příkaz dostal novou cenu a již nemohl zůstat v knize příkazů.
•
Skupina příkazů: skupinu s podrženým nadřazeným příkazem nelze během okna zrušit – aktivuje se při uvolnění. Zrušte ji, jakmile je aktivní.
•
Bezpečnostní spínač (cancelallordersafter): podržený příkaz se převede stejným způsobem. Bezpečnostní spínač podržený příkaz neodvolá.

Pokud nechcete mít žádný čekající příkaz ani žádný nový obchod, vyčkejte do konce okna (nejvýše 100 ms) a teprve pak zrušte.

Ochrana před vlastním obchodem

Při uvolnění podrženého příkazu se vždy zruší každý váš čekající příkaz, proti kterému by se spároval – bez ohledu na strategii ochrany před vlastním obchodem nastavenou na vašem účtu. Platí to pro celý strom vašich účtů, včetně hlavního účtu, sourozeneckých účtů a podúčtů.

•
Váš čekající příkaz se zruší s důvodem CANCELLED_BY_SELF_TRADE a uvolněný příkaz se provede.
•
Výjimkou jsou příkazy FOK a RFQ. Na ně se vaše nastavená strategie vztahuje standardně.
•
Příkazy, které nikdy podrženy nebyly, tím nejsou dotčeny.

Pokud se spoléháte na REJECT_TAKER k ochraně svých čekajících nabídek na trhu s Maker Protection, tato ochrana se nevztahuje na vaše vlastní uvolněné příkazy.

Limity platné po dobu podržení příkazů

Souběžná podržení. Současně lze podržet nejvýše 250 žádostí. Žádost překračující tento limit je odmítnuta a hlášena jako dosažení limitu příkazů (tooManyOrders v REST v3, TOO_MANY_ORDERS v REST v4, ORDER_LIMIT_EXCEEDED v tržních datech a SBE). Limit určuje, kolik podržení může být aktivních současně – nikoli jak rychle lze odesílat příkazy. Je sdílen napříč hlavním účtem a jeho podúčty; po uvolnění dřívějších podržení je opakování žádosti bezpečné.

Limity účtu se stanovují při zahájení podržení. Aby nebylo možné měnit nastavení účtu během okna, některé limity se určí při zahájení podržení, nikoli až při uvolnění:

•
Limit otevřených příkazů: pokud jste na svém limitu, příkaz je přijat, ale převeden tak, aby nemohl být zapsán do knihy příkazů.
•
Maximální pozice: rozpočet se pro příkaz rezervuje při odeslání. Příkaz odmítnutý v tomto okamžiku zůstane odmítnut i v případě, že rozpočet uvolníte, a rezervovaný rozpočet není dostupný pro pozdější příkazy, které jsou odmítány s chybou MAX_POSITION_EXCEEDED.
•
ID příkazů klienta: podržení si rezervuje své ID příkazu klienta po dobu okna. Opětovné použití téhož ID pro jiné zadání je okamžitě odmítnuto s chybou clientOrderIdAlreadyExist. Před opětovným použitím ID vyčkejte do konce okna, nebo adresujte průběžná zrušení pomocí ID příkazu.

Dávkové příkazy

Dávka se nepodržuje jako celek. Okno se spouští od prvního příkazu odebírajícího likviditu v dávce.

•
Příkazy před prvním agresivním příkazem se odešlou okamžitě.
•
První agresivní příkaz a vše za ním čekají do konce okna společně.
•
Zrušení se vždy odesílají okamžitě. Zrušení zadané za cílovým příkazem v rámci téže dávky na sebe převezme jeho podržení. Zrušení zadané před ním to udělat nemůže.

Chcete-li zajistit, aby pasivní pokyn byl zapsán do knihy příkazů bez prodlevy, zařaďte ho před jakýkoli agresivní pokyn v dávce.

Použití API a FIX

REST. Připojení je po dobu prodlevy podrženo a odpověď obsahuje konečný výsledek. Nastavte timeout na straně klienta s dostatečnou rezervou nad hodnotu okna. Protože okno nikdy nepřekročí 100 ms, jeden timeout postačí pro všechny trhy. Pokud u agresivního příkazu odesíláte processBefore, musí tato hodnota zohledňovat dobu podržení – jinak bude příkaz pokaždé odmítnut s chybou wouldProcessAfterSpecifiedTime.

WebSocket. Po dobu podržení příkazu se nic nepublikuje. Události open_orders a fills obdržíte po uvolnění příkazu, přibližně o jedno okno později než dříve.

FIX. Při podržení žádosti odešle brána informativní zprávu ExecutionReport: Pending New (39=A) pro zadání příkazu, nebo Pending Replace (39=E) pro úpravu. Zpráva je pouze informativní a nepředstavuje koncový stav. Podržené zadání příkazu zatím nemá OrderID, takže ClOrdID je po dobu okna vaším jediným odkazem na příkaz. Skutečné potvrzení přichází při uvolnění.

Známé omezení u skupin příkazů

Pokud je jedna větev skupiny příkazů podržena ve chvíli, kdy se realizuje protilehlá větev, podržená větev se neodstraní a obě větve mohou být aktivovány. Probíhá oprava.

Na trzích s Maker Protection po realizaci jakékoli větve ve skupině příkazů zkontrolujte své realizace – nespoléhejte na to, že jedna větev automaticky zrušila druhou.

Testování integrace

Maker Protection je v prostředí UAT pro klienty aktivní na trzích dostupných od spuštění od 27. srpna 2026 se stejným oknem 20 ms a limitem 250 podržených příkazů jako v produkci. Pro přístup do UAT kontaktujte svého správce účtu. Doporučujeme otestovat:

•
Zrušení příkazu během podržení a zpracování příkazu, který se přesto realizuje
•
Zrušení příkazu během podržené úpravy
•
Zrušení vašeho čekajícího příkazu uvolněným příkazem, a to i při nastaveném REJECT_TAKER
•
Zpracování chyby tooManyOrders při zadání příkazu a opakované odeslání
•
Opakované použití klientského ID příkazu v rámci jednoho okna
•
Pořadí instrukcí v dávce a časové limity na straně klienta přesahující hodnotu makerProtectionMillis daného trhu