Cet article est un résumé de Maker Protection. Pour les détails techniques complets, y compris le comportement spécifique à chaque protocole pour REST, WebSocket et FIX, consultez le guide développeur Maker Protection.
Maker Protection est un délai court et fixe appliqué aux ordres susceptibles de prendre de la liquidité sur certains marchés Kraken Derivatives. Il accorde aux ordres maker en attente une brève fenêtre pour réagir aux nouvelles informations avant qu'un ordre entrant puisse être exécuté contre eux. Maker Protection est actif depuis le 24 septembre 2026.
Sur un marché doté de Maker Protection, toute action sur un ordre susceptible de prendre de la liquidité est suspendue pendant une courte fenêtre avant d'atteindre le moteur d'appariement. Les placements post-only et toutes les annulations ne sont jamais suspendus.
Délai : 20 ms au lancement, sans jamais dépasser 100 ms. Le délai est publié par marché sous le paramètre makerProtectionMillis.
Marchés : Uniquement certains marchés d'instruments dérivés (contrats à terme). Le spot n'est pas concerné.
Cohérence : Le comportement est identique sur REST, WebSocket et FIX.
Équité : Le délai s'applique de façon identique à tous les clients. Aucune exemption par compte n'est prévue.
Comment l'éviter : Soumettez l'ordre en mode post-only. Un ordre à cours limité sans post-only est suspendu même s'il aurait pu reposer dans le carnet d'ordres, car le délai dépend du type d'ordre, non de son issue.
Un ordre suspendu prend sa place dans la file d'attente au moment de sa libération, et non à celui de sa réception.
La source de référence est le champ makerProtectionMillis sur GET /instruments et GET /trading/instruments. Si un marché n'a pas de Maker Protection, le champ est entièrement absent ; traitez donc un champ manquant et une valeur nulle de la même façon : aucun délai.
59 marchés étaient couverts au lancement le 24 septembre 2026.
Les 10 marchés perpétuels linéaires les plus liquides sont exclus afin de ne pas ralentir le flux taker actif sur les grandes paires.
Tout contrat perpétuel inscrit après le 24 septembre 2026 bénéficie de Maker Protection dès son lancement.
Les ajouts sont annoncés sur status.kraken.com avant chaque fenêtre de maintenance.
Action | Suspendu ? |
|---|---|
Ordre à cours limité, IOC, FOK ou ordre au marché | Oui |
Ordre post-only | Non |
Modification d'un ordre pouvant se reposer dans le carnet ou prendre de la liquidité | Oui |
Modification d'un ordre post-only au repos dans le carnet | Non |
Placement d'un ordre stop, take-profit ou trailing stop | Non |
L'ordre émis par le déclenchement d'un stop ou d'un take-profit | Oui, sauf si l'ordre émis est post-only |
Groupe d'ordres avec un ordre parent non-post-only | Oui |
Groupe d'ordres rattaché à un ordre existant | Non |
Annuler, annuler tout, annuler tout après | Non |
Les transactions en bloc et les autres flux hors carnet sont également exemptés.
Il n'existe pas d'état "en attente" pour les ordres dans l'API publique. Maker Protection se manifeste par une latence supplémentaire sur les ordres agressifs. Les propriétés suivantes méritent d'être prises en compte lors de l'intégration :
La validation s'effectue à la libération. La marge, les limites de prix et le statut du marché sont vérifiés à l'expiration du délai, et non à la soumission. Un ordre valide au moment de la soumission peut donc être rejeté.
La fenêtre est toujours intégralement écoulée. Si la liquidité qui rendait votre ordre agressif disparaît pendant la fenêtre, l'ordre attend néanmoins la fin du délai. Les ordres en attente ne sont pas réévalués.
Les ordres sont libérés dans l'ordre de réception. Les mises en attente sont levées selon le principe Premier entré, premier sorti : un ordre ultérieur ne peut pas dépasser un ordre antérieur.
Le délai est "au moins" égal à la fenêtre configurée. Les ordres déclenchés par un stop ou un take-profit sont libérés au prochain événement traité par le moteur d'appariement ; sur un marché peu actif, l'attente peut donc dépasser sensiblement la fenêtre configurée.
Ne mesurez pas le délai vous-même. Lisez plutôt makerProtectionMillis, car cette valeur peut être modifiée à tout moment.
Un ordre en attente n'est pas encore inscrit au carnet et rien ne garantit qu'il le sera. Pendant la fenêtre, un ordre peut être affecté par des événements sans lien avec votre propre trading :
Le marché est suspendu : l'ordre est rejeté avec marketSuspended.
Votre compte fait l'objet d'une réduction du risque ou d'une liquidation : l'ordre est refusé avec CANCELLED_WHILE_HELD.
La marge ou les limites de prix évoluent en votre défaveur : l'ordre peut être rejeté à la libération.
Vous modifiez votre effet de levier ou votre mode de marge : la modification est refusée tant que vous avez des demandes en attente. Réessayez une fois vos mises en attente levées.
Si vous recevez un rejet environ une fenêtre après l'envoi d'un ordre, la cause n'est généralement pas une anomalie de l'ordre lui-même. Vérifiez le statut retourné.
Vous pouvez annuler un ordre pendant qu'il est en attente ; les annulations ne sont jamais soumises au délai. Cependant, une annulation ne peut pas révoquer une agression déjà engagée. L'annulation retire à l'ordre le droit de reposer au carnet, mais pas son obligation de s'exécuter.
Un ordre en attente annulé peut encore être exécuté. Si le marché évolue en votre faveur pendant la fenêtre, l'ordre capte la liquidité disponible à sa libération. Ne relancez pas la soumission après une annulation réussie.
Le résultat dépend du type de demande en attente :
Ordre à cours limité : l'annulation est prise en compte et l'ordre est libéré en immediate-or-cancel. Il capte ce qu'il peut ; le solde restant est annulé. Vous recevez deux réponses : celle de l'annulation, puis celle de l'ordre lui-même environ une fenêtre plus tard. Si l'ordre ne peut pas s'exécuter à la libération, REST v3 retourne iocWouldNotExecute.
Ordre IOC, FOK ou au marché : il n'y a rien à convertir ; l'annulation retourne donc ORDER_NOT_FOUND et l'ordre est tout de même transmis à la libération.
Modification d'un ordre au repos : l'ordre original reste actif à son ancien prix pendant la fenêtre. L'annulation est absorbée ; à la libération, la modification est réécrite de sorte que l'ordre soit repriced et ne puisse plus reposer au carnet.
Groupe d'ordres : un groupe dont l'ordre parent est retenu ne peut pas être annulé pendant la fenêtre et devient actif à la libération. Annulez-le une fois qu'il est actif.
Veille automatique (cancelallordersafter) : un ordre retenu est converti de la même manière. La veille automatique ne rappelle pas un ordre retenu.
Si vous ne souhaitez aucun ordre au repos ni aucune nouvelle transaction, attendez la fin de la fenêtre (100 ms au maximum), puis annulez.
Lorsqu'un ordre retenu est libéré, il annule systématiquement tout ordre au repos vous appartenant qu'il pourrait croiser, quelle que soit la stratégie anti-auto-exécution configurée sur votre compte. Cela s'applique à l'ensemble de votre arborescence de comptes, y compris votre compte principal, les comptes frères et les sous-comptes.
Votre ordre au repos est annulé avec le motif CANCELLED_BY_SELF_TRADE, et l'ordre libéré s'exécute.
Les ordres FOK et les RFQ font exception à cette règle. Votre stratégie configurée s'applique normalement.
Les ordres qui n'ont jamais été retenus ne sont pas affectés.
Si vous utilisez REJECT_TAKER pour protéger vos cotations au repos sur un marché Maker Protection, cette protection ne s'applique pas à vos propres ordres libérés après rétention.
Rétentions simultanées. Vous pouvez avoir au maximum 250 demandes retenues en même temps. Toute demande au-delà de cette limite est refusée et signalée comme si vous aviez atteint votre limite d'ordres (tooManyOrders sur REST v3, TOO_MANY_ORDERS sur REST v4, ORDER_LIMIT_EXCEEDED sur les données de marché et SBE). Cette limite porte sur le nombre de rétentions actives simultanément, non sur la cadence d'envoi des ordres. Elle est partagée entre un compte principal et ses sous-comptes ; vous pouvez renvoyer la demande une fois les rétentions précédentes libérées.
Limites de compte fixées à l'ouverture de la rétention. Pour éviter toute modification des paramètres de compte en cours de fenêtre, certaines limites sont réglées à l'ouverture de la rétention plutôt qu'à la libération :
Limite d'ordres ouverts : si vous avez atteint votre limite, l'ordre est accepté mais converti de façon à ne pas pouvoir rester au repos.
Position maximale : le budget est réservé pour l'ordre au moment de la soumission. Un ordre refusé à ce stade reste refusé même si vous libérez du budget ; le budget réservé est indisponible pour les ordres suivants, qui sont refusés avec MAX_POSITION_EXCEEDED.
Identifiants d'ordres client : une rétention réserve son identifiant d'ordre client pour la durée de la fenêtre. Toute réutilisation de cet identifiant pour un autre placement est immédiatement refusée avec clientOrderIdAlreadyExist. Attendez la fin de la fenêtre avant de réutiliser un identifiant, ou gérez les annulations en cours par identifiant d'ordre.
Un lot n'est pas retenu comme une seule unité. La fenêtre démarre à la première instruction preneuse de liquidité du lot.
Les instructions précédant la première instruction agressive sont envoyées immédiatement.
La première instruction agressive, ainsi que toutes celles qui la suivent, attendent ensemble la fin de la fenêtre.
Les annulations sont toujours envoyées immédiatement. Une annulation placée après l'ordre qu'elle cible reprend la rétention de cet ordre au sein du même lot. Une annulation placée avant ne le peut pas.
Pour qu'une instruction passive atteigne le carnet d'ordres sans délai, placez-la avant toute instruction agressive dans le lot.
REST. La connexion est maintenue pendant le délai et la réponse contient le résultat final. Définissez le délai d'expiration côté client avec une marge confortable au-dessus de la fenêtre. Comme la fenêtre ne dépasse jamais 100 ms, un seul délai d'expiration couvre l'ensemble des marchés. Si vous envoyez processBefore sur un ordre agressif, la valeur doit intégrer la durée de rétention, faute de quoi l'ordre est rejeté systématiquement avec wouldProcessAfterSpecifiedTime.
WebSocket. Aucun événement n'est publié pendant la rétention d'un ordre. Vous recevez les événements habituels open_orders et fills une fois l'ordre libéré, soit environ une fenêtre plus tard qu'auparavant.
FIX. La passerelle envoie un ExecutionReport informatif lorsqu'une demande est retenue : Pending New (39=A) pour un placement, ou Pending Replace (39=E) pour une modification. Ce rapport est purement informatif et ne constitue pas un état terminal. Un placement retenu ne possède pas encore de OrderID ; le ClOrdID est donc votre seul identifiant pour l'ordre pendant la fenêtre. L'acquittement définitif intervient à la libération.
Si un volet d'un groupe d'ordres est retenu au moment où un volet opposé est exécuté, le volet retenu n'est pas supprimé et les deux volets peuvent devenir actifs simultanément. Un correctif est en cours.
Sur les marchés Maker Protection, vérifiez vos exécutions après toute exécution d'un volet au sein d'un groupe d'ordres, plutôt que de supposer qu'un volet a annulé l'autre.
Maker Protection est activé sur les marchés de lancement dans l'environnement UAT client depuis le 27 août 2026, avec la même fenêtre de 20 ms et le même plafond de 250 retenues qu'en production. Contactez votre chargé de compte pour accéder à l'UAT. Points à tester :
L'annulation pendant une retenue, et la gestion d'un ordre qui est tout de même exécuté par la suite
L'annulation pendant un amendement retenu
Un ordre au repos annulé par un ordre libéré, même avec REJECT_TAKER activé
La gestion de tooManyOrders lors d'un placement, et la nouvelle tentative associée
La réutilisation d'un identifiant d'ordre client dans une même fenêtre
L'ordonnancement des instructions en lot, et les délais d'expiration côté client au-delà du makerProtectionMillis du marché