All
Filtruj według:
Jak mogę wpłacić gotówkę na konto?
Potrzebuję pomocy w weryfikacji konta
Dlaczego nie mogę uzyskać dostępu do konta?
Czy są jakieś opłaty za wypłatę kryptowalut?
Potrzebuję pomocy w zalogowaniu się na konto
Ten artykuł zawiera ogólne omówienie funkcji Maker Protection. Pełną dokumentację techniczną, w tym zachowanie specyficzne dla protokołów REST, WebSocket i FIX, znajdziesz w przewodniku dla deweloperów dotyczącym Maker Protection.
Maker Protection to krótkie, stałe opóźnienie stosowane wobec zleceń, które mogą pobierać płynność na wybranych rynkach Kraken Derivatives. Daje oczekującym zleceniom maker krótkie okno czasowe na reakcję na nowe informacje, zanim napływające zlecenie będzie mogło zawrzeć z nimi transakcję. Maker Protection działa od 24 września 2026 r.
Na rynku z Maker Protection każda operacja na zleceniu, która mogłaby pobrać płynność, jest wstrzymywana na krótkie okno czasowe przed dotarciem do silnika dopasowywania zleceń. Zlecenia post-only oraz wszelkie anulowania nigdy nie są wstrzymywane.
Opóźnienie: 20 ms przy uruchomieniu, nigdy więcej niż 100 ms. Wartość opóźnienia jest publikowana dla każdego rynku jako makerProtectionMillis.
Rynki: Wyłącznie wybrane rynki instrumentów pochodnych (kontraktów futures). Rynek spot nie jest objęty.
Spójność: Zachowanie jest identyczne dla REST, WebSocket i FIX.
Równe traktowanie: Opóźnienie obowiązuje wszystkich klientów w jednakowym stopniu. Nie ma wyjątków dla poszczególnych kont.
Jak tego uniknąć: Złóż zlecenie jako post-only. Zlecenie z limitem ceny bez opcji post-only jest wstrzymywane nawet wtedy, gdy oczekiwałoby w arkuszu zleceń – opóźnienie zależy bowiem od typu zlecenia, a nie od jego ostatecznego wyniku.
Wstrzymane zlecenie zajmuje miejsce w kolejce w chwili zwolnienia, a nie w chwili wpłynięcia.
Miarodajnym źródłem jest pole makerProtectionMillis w odpowiedziach GET /instruments oraz GET /trading/instruments. Jeśli dany rynek nie ma Maker Protection, pole jest całkowicie pomijane – brak pola i wartość zero oznaczają to samo: brak opóźnienia.
W dniu uruchomienia, 24 września 2026 r., funkcją objęto 59 rynków.
10 najbardziej płynnych liniowych rynków instrumentów wieczystych jest wyłączonych, aby nie spowalniać aktywnego przepływu zleceń taker na głównych parach walutowych.
Każdy instrument wieczysty notowany po 24 września 2026 r. ma Maker Protection od momentu uruchomienia.
Informacje o nowych rynkach są ogłaszane na status.kraken.com przed każdym oknem serwisowym.
Działanie | Opóźnione? |
|---|---|
Zlecenie z limitem ceny, IOC, FOK lub zlecenie rynkowe | Tak |
Zlecenie post-only | Nie |
Modyfikacja zlecenia, które może oczekiwać w księdze i pobierać płynność | Tak |
Modyfikacja oczekującego zlecenia post-only | Nie |
Złożenie zlecenia stop, take-profit lub trailing stop | Nie |
Zlecenie aktywowane przez stop lub take-profit | Tak, chyba że aktywowane zlecenie jest post-only |
Grupa zleceń z nowym zleceniem nadrzędnym niebędącym post-only | Tak |
Grupa zleceń dołączana do istniejącego zlecenia | Nie |
Anulowanie, anulowanie wszystkich, anulowanie wszystkich po czasie | Nie |
Transakcje blokowe i inne zlecenia realizowane poza arkuszem zleceń są również zwolnione z opóźnienia.
W publicznym API nie istnieje stan zlecenia „wstrzymanego". Maker Protection objawia się jako dodatkowa latencja przy zleceniach agresywnych – warto uwzględnić poniższe właściwości podczas projektowania integracji:
Walidacja następuje po zwolnieniu. Margin, widełki cenowe i status rynku są sprawdzane w momencie zakończenia opóźnienia, nie w chwili złożenia zlecenia. Zlecenie prawidłowe w chwili złożenia może nadal zostać odrzucone.
Pełne okno jest zawsze odczekiwane. Jeśli płynność, która uczyniła zlecenie agresywnym, zniknie w trakcie okna, zlecenie i tak czeka do końca opóźnienia. Wstrzymane zlecenia nie są ponownie weryfikowane.
Zlecenia są zwalniane w kolejności ich przyjęcia. Wstrzymania są zwalniane metodą FIFO, więc późniejsze zlecenie nie może wyprzedzić wcześniejszego.
Opóźnienie wynosi „co najmniej" skonfigurowane okno. Zlecenia wyzwalane przez stop lub take-profit są zwalniane przy kolejnym zdarzeniu przetwarzanym przez silnik dopasowywania zleceń – na spokojnym rynku mogą więc oczekiwać zauważalnie dłużej niż skonfigurowane okno.
Nie mierz opóźnienia samodzielnie. Zamiast tego odczytaj wartość makerProtectionMillis – może być zmieniana w dowolnym momencie.
Wstrzymane zlecenie nie jest jeszcze w arkuszu zleceń i nie ma gwarancji, że się tam znajdzie. W trakcie okna zlecenie może być dotknięte zdarzeniami niezwiązanymi z Twoim handlem:
Rynek jest zawieszony: zlecenie jest odrzucane z kodem marketSuspended.
Twoje konto zostaje poddane redukcji ryzyka lub likwidacji: zlecenie jest odrzucane z kodem CANCELLED_WHILE_HELD.
Margin lub widełki cenowe zmieniają się na Twoją niekorzyść: zlecenie może zostać odrzucone w momencie zwolnienia.
Zmieniasz dźwignię lub tryb margin: zmiana jest odrzucana, gdy masz jakiekolwiek wstrzymane żądanie. Ponów próbę po zwolnieniu wstrzymań.
Jeśli otrzymasz odrzucenie mniej więcej jedno okno po wysłaniu zlecenia, zazwyczaj nie wynika ono z błędnego formatu samego zlecenia. Sprawdź zwrócony status.
Możesz anulować zlecenie, gdy jest wstrzymane – anulowania nigdy nie są opóźniane. Jednak anulowanie nie może cofnąć podjętej agresji. Anulowanie odbiera zleceniu prawo do oczekiwania w arkuszu, lecz nie zwalnia go z obowiązku zawarcia transakcji.
Anulowane wstrzymane zlecenie może nadal zostać zrealizowane. Jeśli w trakcie okna rynek poruszy się na Twoją korzyść, zlecenie i tak pobiera tyle płynności, ile może, w momencie zwolnienia. Nie ponawiaj zlecenia po pomyślnym anulowaniu.
Dalszy przebieg zależy od typu wstrzymanego żądania:
Zlecenie z limitem ceny: anulowanie jest potwierdzane, a zlecenie jest zwalniane jako immediate-or-cancel. Pobiera tyle płynności, ile może, a pozostała część jest odrzucana. Otrzymujesz dwie odpowiedzi: potwierdzenie anulowania oraz odpowiedź dotyczącą samego zlecenia – mniej więcej jedno okno później. Jeśli zlecenie nie może być zrealizowane w momencie zwolnienia, REST v3 zwraca iocWouldNotExecute.
Zlecenie IOC, FOK lub rynkowe: nie ma nic do konwersji, więc anulowanie zwraca ORDER_NOT_FOUND, a zlecenie i tak trafia do realizacji w momencie zwolnienia.
Edycja zlecenia oczekującego: oryginalne zlecenie pozostaje aktywne po starej cenie przez cały czas trwania okna. Anulowanie jest absorbowane, a po zwolnieniu edycja jest przekształcana tak, że zlecenie zmienia cenę i nie może już oczekiwać w arkuszu.
Grupa zleceń: grupy ze wstrzymanym zleceniem nadrzędnym nie można anulować w trakcie okna czasowego – staje się ona aktywna po jego upływie. Anuluj ją, gdy jest już aktywna.
Wyłącznik bezpieczeństwa (Dead Man's Switch) (cancelallordersafter): wstrzymane zlecenie jest konwertowane w ten sam sposób. Wyłącznik nie odwołuje wstrzymanego zlecenia.
Jeśli chcesz mieć pewność, że żadne zlecenie nie pozostanie oczekujące i żadne nowe nie zostanie zrealizowane, poczekaj na upłynięcie okna (maksymalnie 100 ms), a następnie anuluj.
Po zwolnieniu wstrzymanego zlecenia zawsze anuluje ono pasujące zlecenia oczekujące na Twoim koncie, niezależnie od skonfigurowanej strategii ochrony przed samozawarciem. Dotyczy to całego drzewa kont, w tym konta głównego, kont siostrzanych i subkont.
Twoje zlecenie oczekujące zostaje anulowane z przyczyną CANCELLED_BY_SELF_TRADE, a zwolnione zlecenie zostaje zrealizowane.
Wyjątkiem są zlecenia FOK i RFQ – dla nich obowiązuje skonfigurowana przez Ciebie strategia.
Zlecenia, które nigdy nie były wstrzymane, pozostają niezmienione.
Jeśli używasz REJECT_TAKER do ochrony swoich kwotowań oczekujących na rynku z Maker Protection, ochrona ta nie działa wobec Twoich własnych zwolnionych zleceń.
Równoczesne wstrzymania. Możesz mieć jednocześnie wstrzymanych co najwyżej 250 żądań. Żądanie przekraczające ten limit jest odrzucane i zgłaszane tak, jakbyś osiągnął limit zleceń (tooManyOrders w REST v3, TOO_MANY_ORDERS w REST v4, ORDER_LIMIT_EXCEEDED w danych rynkowych i SBE). Limit dotyczy liczby aktywnych wstrzymań w danym momencie, a nie prędkości wysyłania zleceń. Jest współdzielony przez konto główne i jego subkonta – ponowna próba jest bezpieczna po zwolnieniu wcześniejszych wstrzymań.
Limity konta ustalane w momencie otwarcia wstrzymania. Aby uniemożliwić zmianę ustawień konta w trakcie okna, niektóre limity są ustalane w chwili otwarcia wstrzymania, a nie przy jego zwolnieniu:
Limit otwartych zleceń: jeśli osiągnąłeś limit, zlecenie zostaje przyjęte, lecz skonwertowane tak, by nie mogło pozostać oczekujące.
Maksymalna pozycja: budżet jest rezerwowany dla zlecenia w momencie jego złożenia. Zlecenie odrzucone w tym momencie pozostaje odrzucone nawet po zwolnieniu budżetu, a zarezerwowany budżet jest niedostępny dla kolejnych zleceń, które są odrzucane z kodem MAX_POSITION_EXCEEDED.
Identyfikatory zleceń klienta: wstrzymanie rezerwuje swój identyfikator zlecenia klienta na czas okna. Ponowne użycie go dla innego zlecenia jest natychmiast odrzucane z kodem clientOrderIdAlreadyExist. Poczekaj na upłynięcie okna przed ponownym użyciem identyfikatora albo wskazuj anulowania oczekujących zleceń po identyfikatorze zlecenia.
Batch nie jest wstrzymywany jako całość. Okno czasowe rozpoczyna się od pierwszej instrukcji pobierającej płynność w batchu.
Instrukcje poprzedzające pierwszą agresywną instrukcję są wysyłane natychmiast.
Pierwsza agresywna instrukcja i wszystkie po niej czekają razem na upłynięcie okna.
Anulowania są zawsze wysyłane natychmiast. Anulowanie złożone po zleceniu, którego dotyczy, przejmuje wstrzymanie tego zlecenia w ramach tego samego batchu. Anulowanie złożone przed nim nie może tego przejąć.
Aby mieć pewność, że pasywna instrukcja trafi do arkusza bez opóźnienia, umieść ją przed wszelkimi agresywnymi instrukcjami w batchu.
REST. Połączenie jest utrzymywane przez czas opóźnienia, a odpowiedź zawiera ostateczny wynik. Ustaw timeout po stronie klienta ze znacznym zapasem powyżej okna. Ponieważ okno nigdy nie przekracza 100 ms, jeden limit timeout pokrywa wszystkie rynki. Jeśli wysyłasz processBefore dla agresywnego zlecenia, musi ono uwzględniać czas wstrzymania – w przeciwnym razie zlecenie będzie każdorazowo odrzucane z kodem wouldProcessAfterSpecifiedTime.
WebSocket. Gdy zlecenie jest wstrzymane, żadne dane nie są publikowane. Standardowe zdarzenia open_orders i fills otrzymasz po zwolnieniu zlecenia – z opóźnieniem mniej więcej o jedno okno czasowe.
FIX. Brama wysyła informacyjny komunikat ExecutionReport w momencie wstrzymania żądania: Pending New (39=A) dla złożenia zlecenia lub Pending Replace (39=E) dla zmiany. Raport ma charakter wyłącznie informacyjny i nie jest stanem końcowym. Wstrzymane zlecenie nie ma jeszcze OrderID, dlatego ClOrdID to jedyny uchwyt na zlecenie dostępny w trakcie okna. Właściwe potwierdzenie następuje po zwolnieniu.
Jeśli jedna noga transakcji grupy zleceń jest wstrzymana, gdy przeciwna noga zostaje zrealizowana, wstrzymana noga nie jest usuwana i obie nogi mogą stać się aktywne. Trwają prace nad rozwiązaniem tego problemu.
Na rynkach z Maker Protection sprawdzaj realizacje po każdej realizacji siostrzanej nogi w grupie zleceń – nie zakładaj, że jedna noga anulowała drugą.
Maker Protection jest włączony na rynkach startowych w środowisku UAT dla klientów od 27 sierpnia 2026 r., z tym samym oknem 20 ms i limitem 250 wstrzymań co w środowisku produkcyjnym. Skontaktuj się z opiekunem konta, aby uzyskać dostęp do UAT. Warto przetestować:
Anulowanie podczas wstrzymania i obsługa zlecenia, które mimo to zostało zrealizowane
Anulowanie podczas wstrzymanej modyfikacji zlecenia
Anulowanie twojego zlecenia oczekującego przez zwolnione zlecenie, nawet przy ustawionym REJECT_TAKER
Obsługa błędu tooManyOrders przy składaniu zlecenia i ponowna próba
Ponowne użycie identyfikatora zlecenia klienta w obrębie okna wstrzymania
Kolejność instrukcji w żądaniu wsadowym oraz limity czasu po stronie klienta powyżej wartości makerProtectionMillis danego rynku