Maker Protection

Última actualización: 30 de septiembre de 2026

Este artículo es un resumen de Maker Protection. Para obtener todos los detalles técnicos, incluido el comportamiento específico por protocolo para REST, WebSocket y FIX, consulta la guía para desarrolladores de Maker Protection.

Maker Protection es un retraso breve y fijo que se aplica a las órdenes que podrían consumir liquidez en determinados mercados de Kraken Derivatives. Ofrece a las órdenes de maker en reposo una pequeña ventana para reaccionar ante nueva información antes de que una orden entrante pueda operar contra ellas. Maker Protection está activo desde el 24 de septiembre de 2026.

¿Qué es Maker Protection?

En un mercado con Maker Protection, cualquier acción sobre una orden que pueda consumir liquidez queda retenida durante una breve ventana antes de llegar al motor de case de órdenes. Los envíos post-only y todas las cancelaciones nunca se retienen.

•
Retraso: 20 ms en el lanzamiento, nunca más de 100 ms. El retraso se publica por mercado como makerProtectionMillis.
•
Mercados: Solo mercados de Derivados (Futures) seleccionados. El mercado spot no se ve afectado.
•
Uniformidad: El comportamiento es idéntico en REST, WebSocket y FIX.
•
Equidad: El retraso se aplica por igual a todos los clientes. No hay exenciones por cuenta.
•
Cómo evitarlo: Envía la orden como post-only. Una orden límite sin post-only queda retenida aunque hubiera reposado en el libro, ya que el retraso depende del tipo de orden, no del resultado.

Una orden retenida ocupa su lugar en la cola cuando se libera, no cuando se recibió.

¿Qué mercados tienen Maker Protection?

La fuente de referencia es el campo makerProtectionMillis en GET /instruments y GET /trading/instruments. Si un mercado no tiene Maker Protection, el campo se omite por completo; trata un campo ausente y un valor de cero como equivalentes: sin retraso.

•
Al lanzamiento, el 24 de septiembre de 2026, se cubrieron 59 mercados.
•
Los 10 mercados de perpetuos lineales más líquidos están excluidos para no ralentizar el flujo activo de taker en los principales pares.
•
Todos los perpetuos listados después del 24 de septiembre de 2026 tienen Maker Protection desde el lanzamiento.
•
Las incorporaciones se anuncian en status.kraken.com antes de cada ventana de mantenimiento.

¿Qué órdenes se retrasan?

Acción	¿Retrasada?
Orden límite, IOC, FOK o de mercado	Sí
Orden post-only	No
Modificación de una orden que puede reposar y consumir liquidez	Sí
Modificación de una orden post-only en reposo	No
Colocación de stop, take-profit o trailing-stop	No
La orden lanzada por un trigger de stop o de take-profit	Sí, salvo que la orden disparada sea post-only
Grupo de órdenes con un nuevo padre no post-only	Sí
Grupo de órdenes vinculado a una orden existente	No
Cancelar, cancelar todo, cancelar todo después de	No

Las operaciones en bloque y otros flujos fuera del libro también están exentos.

Cómo funciona el retraso

En la API pública no existe ningún estado de orden "retenida". Maker Protection se traduce en latencia adicional en las órdenes agresivas. Ten en cuenta las siguientes propiedades al diseñar tu integración:

•
La validación se produce al liberarse. El margen, los límites de precio y el estado del mercado se comprueban cuando finaliza el retraso, no cuando envías la orden. Una orden válida en el momento del envío puede ser rechazada igualmente.
•
La ventana completa siempre se agota. Si la liquidez que hacía agresiva tu orden desaparece durante la ventana, la orden sigue esperando hasta que finalice el retraso. Las órdenes retenidas no se reevalúan.
•
Las órdenes se liberan en orden. Las retenciones se liberan según el método de primeras entradas, primeras salidas, por lo que una orden posterior no puede adelantar a una anterior.
•
El retraso es "como mínimo" la ventana configurada. Las órdenes activadas por un stop o un trigger de take-profit se liberan con el siguiente evento que procesa el motor de case de órdenes, por lo que en un mercado tranquilo pueden esperar notablemente más que la ventana configurada.
•
No midas el retraso. Consulta makerProtectionMillis en su lugar, ya que puede modificarse en cualquier momento.

Qué puede ocurrir mientras una orden está retenida

Una orden retenida aún no está en el libro y no hay garantía de que llegue a estarlo. Durante la ventana, una orden puede verse afectada por eventos ajenos a tu propio trading:

•
El mercado está suspendido: la orden se rechaza con marketSuspended.
•
Tu cuenta sufre una reducción de riesgo o una liquidación: la orden se rechaza con CANCELLED_WHILE_HELD.
•
El margen o los límites de precio se mueven en tu contra: la orden puede ser rechazada al liberarse.
•
Cambias el apalancamiento o el modo de margen: el cambio se rechaza mientras tengas alguna solicitud retenida. Vuelve a intentarlo una vez liberadas tus retenciones.

Si recibes un rechazo aproximadamente una ventana después de enviar una orden, lo habitual es que no se haya rechazado por estar mal formada. Comprueba el estado devuelto.

Cancelación de una orden retenida

Puedes cancelar una orden mientras está retenida, y las cancelaciones nunca se retrasan. Sin embargo, una cancelación no puede retirar una agresión ya comprometida. Cancelar elimina el derecho de la orden a quedar pasiva en el libro, pero no su obligación de operar.

Una orden retenida y cancelada puede ejecutarse igualmente. Si el mercado se mueve a tu favor durante la ventana, la orden toma la liquidez que pueda al liberarse. No reintentes el envío tras una cancelación exitosa.

Lo que ocurre depende del tipo de solicitud retenida:

•
Orden límite: se confirma la cancelación y la orden se libera como immediate-or-cancel. Toma lo que puede y el resto se descarta. Recibes dos respuestas: la de la cancelación y la de la propia orden aproximadamente una ventana después. Si la orden no puede operar al liberarse, REST v3 devuelve iocWouldNotExecute.
•
Orden IOC, FOK o de mercado: no hay nada que convertir, por lo que la cancelación devuelve ORDER_NOT_FOUND y la orden llega igualmente al motor de casación al liberarse.
•
Edición de una orden pasiva: la orden original permanece activa a su precio anterior durante la ventana. La cancelación queda absorbida y, al liberarse, la edición se reescribe para que la orden cambie de precio y ya no pueda permanecer en el libro.
•
Grupo de órdenes: un grupo con un padre retenido no puede cancelarse durante la ventana y queda activo al liberarse. Cancélalo una vez que esté activo.
•
Dead Man's Switch (interruptor de seguridad) (cancelallordersafter): una orden retenida se convierte del mismo modo. El interruptor no retira una orden retenida.

Si necesitas que no quede ninguna orden pasiva ni se ejecute ninguna nueva, espera a que transcurra la ventana (100 ms como máximo) y cancela.

Prevención de autooperación

Cuando se libera una orden retenida, cancela automáticamente cualquier orden pasiva tuya con la que coincidiría, independientemente de la estrategia de autooperación configurada en tu cuenta. Esto se aplica a todo el árbol de cuentas, incluida tu cuenta principal, las cuentas hermanas y las subcuentas.

•
Tu orden pasiva se cancela con el motivo CANCELLED_BY_SELF_TRADE, y la orden liberada se ejecuta.
•
Las órdenes FOK y las RFQ son la excepción. Tu estrategia configurada se aplica con normalidad.
•
Las órdenes que nunca estuvieron retenidas tampoco se ven afectadas.

Si utilizas REJECT_TAKER para proteger tus cotizaciones pasivas en un mercado con Maker Protection, esa protección no se aplica frente a tus propias órdenes liberadas.

Límites aplicables con órdenes retenidas

Retenciones simultáneas. Puedes tener como máximo 250 solicitudes retenidas a la vez. Una solicitud que supere el límite se rechaza y se notifica como si hubieras alcanzado tu límite de órdenes (tooManyOrders en REST v3, TOO_MANY_ORDERS en REST v4, ORDER_LIMIT_EXCEEDED en datos de mercado y SBE). El límite restringe cuántas retenciones pueden estar activas simultáneamente, no la velocidad a la que puedes enviar órdenes. Se comparte entre la cuenta principal y sus subcuentas, y es seguro reintentar una vez que las retenciones anteriores se hayan liberado.

Límites de cuenta fijados al abrirse la retención. Para evitar que la configuración de la cuenta cambie a mitad de la ventana, algunos límites se establecen cuando se abre la retención y no al liberarse:

•
Límite de órdenes abiertas: si has alcanzado tu límite, la orden se admite pero se convierte para que no pueda quedar pasiva.
•
Posición máxima: el margen se reserva para la orden en el momento del envío. Una orden rechazada en ese punto sigue rechazada aunque liberes margen, y el margen reservado no está disponible para órdenes posteriores, que se rechazan con MAX_POSITION_EXCEEDED.
•
IDs de orden de cliente: una retención reserva su ID de orden de cliente durante la ventana. Reutilizarlo para otro envío se rechaza de inmediato con clientOrderIdAlreadyExist. Espera a que transcurra la ventana antes de reutilizar un ID, o gestiona las cancelaciones en curso por ID de orden.

Órdenes en lote

Un lote no se retiene como una unidad única. La ventana comienza en la primera instrucción que consume liquidez del lote.

•
Las instrucciones anteriores a la primera instrucción agresiva se envían de inmediato.
•
La primera instrucción agresiva, y todo lo que le sigue, esperan juntas a que transcurra la ventana.
•
Las cancelaciones siempre se envían de inmediato. Una cancelación colocada después de la orden a la que apunta asume la retención de esa orden dentro del mismo lote. Una cancelación colocada antes no puede hacerlo.

Para garantizar que una instrucción pasiva llegue al libro sin demora, colócala antes de cualquier instrucción agresiva en el lote.

Uso de la API y FIX

REST. La conexión se mantiene durante el retraso y la respuesta contiene el resultado final. Configura el timeout del lado del cliente con margen suficiente por encima de la ventana. Como la ventana nunca supera los 100 ms, un único valor de timeout cubre todos los mercados. Si envías processBefore en una orden agresiva, debe contemplar la retención; de lo contrario, la orden se rechaza siempre con wouldProcessAfterSpecifiedTime.

WebSocket. No se publica nada mientras una orden está retenida. Recibes los eventos habituales de open_orders y fills una vez que la orden se libera, aproximadamente una ventana más tarde que antes.

FIX. La pasarela envía un ExecutionReport informativo cuando se retiene una solicitud: Pending New (39=A) para un envío, o Pending Replace (39=E) para una modificación. El informe es solo informativo y no constituye un estado terminal. Un envío retenido aún no tiene OrderID, por lo que ClOrdID es tu único identificador de la orden durante la ventana. El acuse de recibo definitivo llega al liberarse.

Limitación conocida en grupos de órdenes

Si una de las patas de un grupo de órdenes está retenida cuando se ejecuta la pata contraria, la pata retenida no se elimina y ambas pueden quedar activas. Hay una corrección en curso.

En mercados con Maker Protection, comprueba tus ejecuciones tras cualquier ejecución de una pata del grupo, en lugar de asumir que la otra pata ha sido cancelada.

Prueba tu integración

Maker Protection lleva activo en los mercados de lanzamiento del entorno UAT para clientes desde el 27 de agosto de 2026, con la misma ventana de 20 ms y el mismo límite de 250 retenciones que en producción. Contacta con tu gestor de cuenta para acceder a UAT. Recomendamos probar lo siguiente:

•
Cancelar durante una retención y gestionar una orden que aun así se ejecuta después
•
Cancelar durante una modificación retenida
•
Una orden pasiva tuya cancelada por una orden liberada, incluso con REJECT_TAKER activado
•
Gestionar tooManyOrders al enviar una orden y volver a intentarlo
•
Reutilizar un ID de orden de cliente dentro de una ventana
•
Ordenación de instrucciones en lotes y timeouts en el lado del cliente por encima del makerProtectionMillis del mercado