Maker Protection

Última atualização: 30 de setembro de 2026

Este artigo é um resumo do Maker Protection. Para os detalhes técnicos completos, incluindo o comportamento específico por protocolo para REST, WebSocket e FIX, consulte o guia do desenvolvedor do Maker Protection.

Maker Protection é um atraso curto e fixo aplicado a ordens que possam consumir liquidez em mercados selecionados de derivativos da Kraken. Ele dá às ordens maker em repouso uma breve janela para reagir a novas informações antes que uma ordem recebida possa ser executada contra elas. O Maker Protection está ativo desde 24 de setembro de 2026.

O que é Maker Protection?

Em um mercado com Maker Protection, qualquer ação de ordem que possa consumir liquidez fica retida por uma breve janela antes de chegar ao Matching Engine. Envios post-only e todos os cancelamentos nunca são retidos.

•
Atraso: 20 ms no lançamento, nunca superior a 100 ms. O atraso é publicado por mercado como makerProtectionMillis.
•
Mercados: Apenas mercados selecionados de Derivativos (Futuros). Spot não é afetado.
•
Consistência: O comportamento é idêntico em REST, WebSocket e FIX.
•
Equidade: O atraso se aplica igualmente a todos os clientes. Não há isenções por conta.
•
Como evitar: Envie a ordem como post-only. Uma ordem limitada sem post-only é retida mesmo que ficasse em repouso no book, pois o atraso depende do tipo de ordem, não do resultado.

Uma ordem retida ocupa sua posição na fila no momento em que é liberada, não quando foi recebida.

Quais mercados têm Maker Protection?

A fonte oficial é o campo makerProtectionMillis em GET /instruments e GET /trading/instruments. Se um mercado não tiver Maker Protection, o campo é omitido, portanto trate um campo ausente e um valor zero como equivalentes: sem atraso.

•
59 mercados foram incluídos no lançamento em 24 de setembro de 2026.
•
Os 10 mercados perpétuos lineares mais líquidos são excluídos para não reduzir o fluxo taker ativo nos principais pares.
•
Todo perpétuo listado após 24 de setembro de 2026 tem Maker Protection desde o lançamento.
•
As inclusões são anunciadas em status.kraken.com antes de cada janela de manutenção.

Quais ordens são retidas?

Ação	Com atraso?
Ordem limitada, IOC, FOK ou a mercado	Sim
Ordem post-only	Não
Edição de ordem que pode repousar no livro e consumir liquidez	Sim
Edição de ordem post-only em repouso no livro	Não
Envio de stop, take-profit ou trailing stop	Não
A ordem disparada por um gatilho de stop ou take-profit	Sim, exceto se a ordem disparada for post-only
Grupo de ordens com um novo pai não post-only	Sim
Grupo de ordens vinculado a uma ordem existente	Não
Cancelar, cancelar todas, cancelar todas após	Não

Negociações em bloco e outros fluxos fora do livro de ofertas também estão isentos.

Como o atraso funciona

Não existe um estado de ordem «retida» na API pública. A Maker Protection se manifesta como latência adicional em ordens agressivas. Vale considerar estas propriedades ao desenvolver sua integração:

•
A validação ocorre na liberação. Margem, limites de preço e status do mercado são verificados ao fim do atraso, não no momento do envio. Uma ordem válida no envio ainda pode ser rejeitada.
•
A janela completa é sempre cumprida. Se a liquidez que tornava sua ordem agressiva desaparecer durante a janela, a ordem ainda aguarda o fim do atraso. Ordens retidas não são reavaliadas.
•
As ordens são liberadas na ordem de chegada. As retenções seguem o sistema FIFO (primeiro a entrar, primeiro a sair), de modo que uma ordem posterior não pode ultrapassar uma anterior.
•
O atraso é «no mínimo» a janela configurada. Ordens disparadas por um gatilho de stop ou take-profit são liberadas pelo próximo evento processado pelo Matching Engine; em um mercado pouco ativo, elas podem aguardar consideravelmente mais do que a janela configurada.
•
Não meça o atraso manualmente. Consulte makerProtectionMillis, pois o valor pode ser alterado a qualquer momento.

O que pode acontecer enquanto uma ordem está retida

Uma ordem retida ainda não está no livro de ofertas e não há garantia de que chegará lá. Durante a janela, uma ordem pode ser afetada por eventos alheios à sua negociação:

•
O mercado é suspenso: a ordem é rejeitada com marketSuspended.
•
Sua conta sofre redução de risco ou liquidação: a ordem é recusada com CANCELLED_WHILE_HELD.
•
Margem ou limites de preço se movem contra você: a ordem pode ser rejeitada na liberação.
•
Você altera sua alavancagem ou modo de margem: a alteração é recusada enquanto houver qualquer solicitação retida. Tente novamente após a liberação das retenções.

Se você receber uma rejeição aproximadamente uma janela após o envio de uma ordem, geralmente o motivo não é que a ordem estava malformada. Verifique o status retornado.

Cancelamento de uma ordem retida

Você pode cancelar uma ordem enquanto ela está retida, e cancelamentos nunca sofrem atraso. No entanto, um cancelamento não pode desfazer uma agressão já confirmada. O cancelamento remove o direito da ordem de repousar no livro de ofertas, mas não sua obrigação de negociar.

Uma ordem retida e cancelada ainda pode ser executada. Se o mercado se mover a seu favor durante a janela, a ordem ainda tomará a liquidez disponível na liberação. Não reenvie a ordem após um cancelamento bem-sucedido.

O que acontece depende do tipo de solicitação retida:

•
Ordem limitada: o cancelamento é confirmado e a ordem é liberada como immediate-or-cancel. Ela executa o que puder e o restante é descartado. Você recebe duas respostas: a do cancelamento e a da própria ordem, cerca de uma janela depois. Se a ordem não puder ser executada na liberação, o REST v3 retorna iocWouldNotExecute.
•
Ordem IOC, FOK ou a mercado: não há nada a converter, portanto o cancelamento retorna ORDER_NOT_FOUND e a ordem ainda é processada na liberação.
•
Edição de uma resting order: a ordem original permanece ativa no preço antigo durante a janela. O cancelamento é absorvido e, na liberação, a edição é reescrita de modo que a ordem seja reprecificada e não possa mais ficar como resting order.
•
Grupo de ordens: um grupo com um parent retido não pode ser cancelado durante a janela e entra em vigor na liberação. Cancele-o assim que estiver ativo.
•
Dead Man's Switch (cancelallordersafter): uma ordem retida é convertida da mesma forma. O switch não revoga uma ordem retida.

Se você precisar que nenhuma ordem fique em resting e nenhuma nova negociação seja executada, aguarde o término da janela (no máximo 100 ms) e então cancele.

Prevenção de self-trade

Quando uma ordem retida é liberada, ela sempre cancela qualquer resting order sua que ela corresponderia, independentemente da estratégia de self-trade configurada na sua conta. Isso se aplica a toda a sua árvore de contas, incluindo a Conta master, contas irmãs e subcontas.

•
Sua resting order é cancelada com o motivo CANCELLED_BY_SELF_TRADE, e a ordem liberada é negociada.
•
Ordens FOK e RFQs são a exceção. A estratégia configurada se aplica normalmente.
•
Ordens que nunca foram retidas também não são afetadas.

Se você usa REJECT_TAKER para proteger suas resting orders em um mercado com Maker Protection, essa proteção não se aplica às suas próprias ordens liberadas.

Limites aplicáveis durante a retenção de ordens

Retenções simultâneas. Você pode ter no máximo 250 solicitações retidas ao mesmo tempo. Uma solicitação além desse limite é recusada e reportada como se você tivesse atingido o limite de ordens (tooManyOrders no REST v3, TOO_MANY_ORDERS no REST v4, ORDER_LIMIT_EXCEEDED em dados de mercado e SBE). O limite controla quantas retenções estão ativas simultaneamente, não a velocidade de envio de ordens. É compartilhado entre a Conta master e suas subcontas, e é seguro tentar novamente após a liberação das retenções anteriores.

Limites de conta definidos na abertura da retenção. Para evitar alterações nas configurações da conta durante a janela, alguns limites são definidos na abertura da retenção, e não na liberação:

•
Limite de ordens abertas: se você está no limite, a ordem é admitida, mas convertida para que não possa ficar resting.
•
Posição máxima: o capital é reservado para a ordem no momento do envio. Uma ordem recusada nesse ponto permanece recusada mesmo que você libere capital, e o capital reservado fica indisponível para ordens posteriores, que são recusadas com MAX_POSITION_EXCEEDED.
•
IDs de ordem do cliente: uma retenção reserva seu ID de ordem do cliente durante a janela. Reutilizá-lo para outro envio é recusado imediatamente com clientOrderIdAlreadyExist. Aguarde o término da janela antes de reutilizar um ID, ou trate cancelamentos em andamento pelo ID da ordem.

Ordens em lote

Um lote não é retido como uma unidade única. A janela começa na primeira instrução que consome liquidez no lote.

•
As instruções anteriores à primeira instrução agressiva são enviadas imediatamente.
•
A primeira instrução agressiva e tudo que vem depois aguardam o término da janela juntos.
•
Cancelamentos são sempre enviados imediatamente. Um cancelamento posicionado após a ordem que ele visa assume a retenção dessa ordem dentro do mesmo lote. Um cancelamento posicionado antes dela não pode fazer isso.

Para garantir que uma instrução passiva chegue ao book sem atraso, coloque-a antes de qualquer instrução agressiva no lote.

Usando a API e o FIX

REST. A conexão é mantida durante o atraso, e a resposta traz o resultado final. Configure o timeout do lado do cliente com folga acima da janela. Como a janela nunca ultrapassa 100 ms, um único timeout cobre todos os mercados. Se você enviar processBefore em uma ordem agressiva, o valor precisa considerar a retenção; caso contrário, a ordem será rejeitada toda vez com wouldProcessAfterSpecifiedTime.

WebSocket. Nada é publicado enquanto uma ordem está retida. Os eventos open_orders e fills chegam normalmente assim que a ordem é liberada, aproximadamente uma janela mais tarde que o habitual.

FIX. O gateway envia um ExecutionReport informativo quando uma solicitação é retida: Pending New (39=A) para um envio de ordem, ou Pending Replace (39=E) para uma alteração. O relatório é apenas informativo e não representa um estado terminal. Um envio retido ainda não possui OrderID, então ClOrdID é o único identificador da ordem durante a janela. A confirmação definitiva chega na liberação.

Limitação conhecida em grupos de ordens

Se uma posição de um grupo de ordens estiver retida quando uma posição oposta for executada, a posição retida não é removida e ambas podem ser ativadas. Uma correção está em andamento.

Em mercados com Maker Protection, verifique suas execuções após qualquer execução de uma posição irmã em um grupo de ordens, em vez de presumir que uma posição cancelou a outra.

Teste da integração

O Maker Protection está ativo nos mercados de lançamento no ambiente UAT desde 27 de agosto de 2026, com a mesma janela de 20 ms e limite de 250 retenções da produção. Entre em contato com seu gerente de conta para acessar o UAT. Vale a pena testar:

•
Cancelar durante uma retenção e lidar com uma ordem que ainda é executada depois
•
Cancelar durante uma alteração retida
•
Cancelamento de um resting order seu por uma ordem liberada, mesmo com REJECT_TAKER ativo
•
Tratar tooManyOrders em um envio de ordem e reenviá-la
•
Reutilizar um ID de ordem do cliente dentro de uma janela
•
Ordenação de instruções em lote e timeouts do lado do cliente acima do makerProtectionMillis do mercado