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 programador do Maker Protection.
O Maker Protection é um atraso breve e fixo aplicado a ordens que possam retirar liquidez em mercados de Derivados Kraken selecionados. Concede às ordens criadoras de liquidez em repouso uma janela curta para reagir a nova informação antes de uma ordem entrante poder negociar contra elas. O Maker Protection está ativo desde 24 de setembro de 2026.
Num mercado com Maker Protection, qualquer ação sobre uma ordem que possa retirar liquidez fica retida por uma janela breve antes de chegar ao Motor de correspondência. As colocações 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 de Derivados (Futures) selecionados. Os mercados à vista não são afetados.
Consistência: O comportamento é idêntico em REST, WebSocket e FIX.
Equidade: O atraso aplica-se igualmente a todos os clientes. Não existem isenções por conta.
Como evitar: Submeta a ordem como post-only. Uma ordem com limite sem post-only fica retida mesmo que ficasse em repouso no livro de ordens, uma vez que o atraso depende do tipo de ordem, não do resultado.
Uma ordem retida ocupa o seu lugar na fila quando é libertada, não quando foi recebida.
A fonte de referência é o campo makerProtectionMillis em GET /instruments e GET /trading/instruments. Se um mercado não tiver Maker Protection, o campo é simplesmente omitido; trate um campo ausente e um valor zero da mesma forma: sem atraso.
No lançamento, a 24 de setembro de 2026, 59 mercados estavam abrangidos.
Os 10 mercados de perpétuos lineares mais líquidos estão excluídos, para não travar o fluxo ativo de tomadores nas principais.
Todos os perpétuos listados após 24 de setembro de 2026 têm Maker Protection desde o lançamento.
As adições são anunciadas em status.kraken.com antes de cada janela de manutenção.
Ação | Atraso? |
|---|---|
Ordem com limite, IOC, FOK ou a mercado | Sim |
Ordem post-only | Não |
Edição de uma ordem que pode repousar no livro e consumir liquidez | Sim |
Edição de uma ordem post-only em repouso | Não |
Colocação 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 novo elemento principal não post-only | Sim |
Grupo de ordens associado a uma ordem existente | Não |
Cancelar, cancelar tudo, cancelar tudo após | Não |
Os block trades e outros fluxos fora do livro de ordens também estão isentos.
Não existe nenhum estado de ordem «retida» na API pública. A Maker Protection manifesta-se como latência adicional nas ordens agressivas. Vale a pena ter em conta as seguintes propriedades ao conceber a integração:
A validação ocorre na libertação. A margem, os price collars e o estado do mercado são verificados quando o atraso termina, não no momento do envio. Uma ordem válida no envio pode ainda assim ser rejeitada.
A janela completa é sempre cumprida. Se a liquidez que tornou a sua ordem agressiva desaparecer durante a janela, a ordem aguarda na mesma o fim do atraso. As ordens retidas não são reavaliadas.
As ordens são libertadas por ordem de chegada. As retenções são libertadas segundo o princípio Primeiro a entrar, primeiro a sair, pelo que uma ordem posterior não pode ultrapassar uma anterior.
O atraso é «no mínimo» a janela configurada. As ordens despoletadas por um stop ou por um gatilho de take-profit são libertadas pelo próximo evento processado pelo Motor de correspondência; num mercado tranquilo, podem aguardar visivelmente mais do que a janela configurada.
Não meça o atraso. Leia antes o campo makerProtectionMillis, pois este pode ser alterado a qualquer momento.
Uma ordem retida ainda não consta do livro de ordens e não há garantia de que chegue a constar. Durante a janela, uma ordem pode ser afetada por eventos alheios à sua negociação:
O mercado está suspenso: a ordem é rejeitada com marketSuspended.
A sua conta sofre redução de risco ou é liquidada: a ordem é recusada com CANCELLED_WHILE_HELD.
A margem ou os price collars movem-se contra si: a ordem pode ser rejeitada na libertação.
Altera a alavancagem ou o modo de margem: a alteração é recusada enquanto tiver pedidos retidos. Tente novamente após a libertação das retenções.
Se receber uma rejeição aproximadamente uma janela após o envio de uma ordem, a causa habitual não é a ordem estar malformada. Verifique o estado devolvido.
Pode cancelar uma ordem enquanto está retida — os cancelamentos nunca ficam sujeitos a atraso. No entanto, um cancelamento não revoga uma agressão já comprometida. O cancelamento remove o direito da ordem de ficar no livro de ordens, mas não a sua obrigação de negociar.
Uma ordem retida cancelada pode ainda assim ser executada. Se o mercado se mover a seu favor durante a janela, a ordem continua a capturar a liquidez disponível na libertação. Não volte a colocar a ordem após um cancelamento bem-sucedido.
O que acontece depende do tipo de pedido retido:
Ordem com limite: o cancelamento é confirmado e a ordem é libertada como immediate-or-cancel. Captura o que for possível e o remanescente é descartado. Recebe duas respostas: a do cancelamento e a da própria ordem, cerca de uma janela depois. Se a ordem não puder negociar na libertação, o REST v3 devolve iocWouldNotExecute.
Ordem IOC, FOK ou de mercado: não há nada a converter, pelo que o cancelamento devolve ORDER_NOT_FOUND e a ordem é ainda assim executada na libertação.
Edição de uma ordem em espera: a ordem original permanece ativa ao seu preço anterior durante a janela. Um cancelamento é absorvido e, na libertação, a edição é reformulada de forma a que a ordem receba um novo preço e já não possa ficar em espera.
Grupo de ordens: um grupo com um pai em espera não pode ser cancelado durante a janela e fica ativo no momento da libertação. Cancele-o após a libertação.
Interruptor de homem morto (cancelallordersafter): uma ordem em espera é convertida da mesma forma. O interruptor não revoga uma ordem em espera.
Se não pretender que nenhuma ordem fique em espera nem que seja executada qualquer nova negociação, aguarde o fim da janela (no máximo 100 ms) e cancele.
Quando uma ordem em espera é libertada, cancela sempre qualquer ordem em espera sua com a qual correspondesse, independentemente da estratégia de auto-negociação configurada na conta. Aplica-se a toda a árvore de contas, incluindo a conta principal, contas irmãs e subcontas.
A sua ordem em espera é cancelada com o motivo CANCELLED_BY_SELF_TRADE, e a ordem libertada é executada.
As ordens FOK e os RFQs são a exceção. A estratégia configurada aplica-se normalmente.
As ordens que nunca ficaram em espera também não são afetadas.
Se utilizar REJECT_TAKER para proteger as suas cotações em espera num mercado com Maker Protection, essa proteção não se aplica às suas próprias ordens libertadas.
Esperas simultâneas. Pode ter no máximo 250 pedidos em espera ao mesmo tempo. Um pedido além deste limite é recusado e reportado como se tivesse atingido o limite de ordens (tooManyOrders no REST v3, TOO_MANY_ORDERS no REST v4, ORDER_LIMIT_EXCEEDED nos dados de mercado e SBE). O limite restringe o número de esperas ativas em simultâneo, não a velocidade de envio de ordens. É partilhado entre a conta principal e as suas subcontas; pode tentar novamente em segurança após a libertação das esperas anteriores.
Limites de conta definidos na abertura da espera. Para evitar alterações às definições da conta a meio da janela, alguns limites são fixados na abertura da espera e não no momento da libertação:
Limite de ordens abertas: se tiver atingido o seu limite, a ordem é admitida mas convertida de forma a não poder ficar em espera.
Posição máxima: o orçamento é reservado para a ordem no momento da submissão. Uma ordem recusada nesse momento permanece recusada mesmo que liberte orçamento, e o orçamento reservado fica indisponível para ordens posteriores, que são recusadas com MAX_POSITION_EXCEEDED.
IDs de ordem do cliente: uma espera reserva o respetivo ID de ordem do cliente durante a janela. Reutilizá-lo para outra colocação é recusado imediatamente com clientOrderIdAlreadyExist. Aguarde o fim da janela antes de reutilizar um ID, ou referencie cancelamentos em curso pelo ID de ordem.
Um lote não fica em espera como uma unidade única. A janela inicia na primeira instrução que consome liquidez do lote.
As instruções anteriores à primeira instrução agressiva são enviadas imediatamente.
A primeira instrução agressiva e tudo o que se segue aguardam o fim da janela em conjunto.
Os cancelamentos são sempre enviados imediatamente. Um cancelamento colocado após a ordem visada assume a espera dessa ordem dentro do mesmo lote. Um cancelamento colocado antes não o pode fazer.
Para garantir que uma instrução passiva chega ao livro de ordens sem atraso, coloque-a antes de qualquer instrução agressiva no lote.
REST. A ligação fica em espera durante o atraso e a resposta contém o resultado final. Defina o timeout do lado do cliente com uma margem confortável acima da janela. Como a janela nunca excede 100 ms, uma única margem de timeout cobre todos os mercados. Se enviar processBefore numa ordem agressiva, o valor deve contemplar a espera; caso contrário, a ordem é rejeitada sempre com wouldProcessAfterSpecifiedTime.
WebSocket. Nada é publicado enquanto uma ordem está em espera. Receberá os habituais eventos open_orders e fills após a libertação da ordem, com um atraso de aproximadamente uma janela em relação ao habitual.
FIX. O gateway envia um ExecutionReport informativo quando um pedido fica em espera: Pending New (39=A) para uma colocação, ou Pending Replace (39=E) para uma alteração. O relatório é meramente informativo e não representa um estado terminal. Uma colocação em espera ainda não tem OrderID, pelo que o ClOrdID é o único identificador da ordem durante a janela. O reconhecimento definitivo é enviado no momento da libertação.
Se um componente de um grupo de ordens estiver retido quando um componente oposto do mesmo grupo for executado, o componente retido não é removido e ambos podem ficar ativos. Está em curso uma correção.
Nos mercados com Maker Protection, verifique as suas execuções após qualquer execução de um componente do mesmo grupo, em vez de assumir que um componente cancelou o outro.
O Maker Protection está ativo nos mercados de lançamento no ambiente UAT do cliente desde 27 de agosto de 2026, com a mesma janela de 20 ms e o mesmo limite de 250 retenções que em produção. Contacte o seu gestor de conta para obter acesso ao UAT. Recomendamos testar:
Cancelar durante uma retenção e gerir uma ordem que ainda assim é executada depois
Cancelar durante uma alteração retida
Uma ordem em espera sua a ser cancelada por uma ordem libertada, mesmo com REJECT_TAKER definido
Gerir tooManyOrders numa colocação e repetir a tentativa
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