Ir para conteúdo principal
Todas as coleçõesCrypto.com ExchangeNegociação
Prevenção de Self-Trade na Crypto.com Exchange
Prevenção de Self-Trade na Crypto.com Exchange
Atualizado há mais de 3 meses

O que é a funcionalidade de Prevenção de Self-Trade (STP) da Crypto.com Exchange?

A Pevenção de Self-Trade (STP) é uma funcionalidade opcional que permite aos utilizadores da Crypto.com Exchange impedir a correspondência de ordens para contas com propriedade comum na Exchange.

A definição de self-trade depende dos seguintes fatores por utilizador e/ou por bolsa:

  • Scope STP: Se as ordens são enviadas da mesma conta principal e/ou subconta(s) pertencente(s) ao mesmo utilizador (stp_scope)

  • ID STP: Se as ordens têm a mesma ID STP (stp_id)

Como funciona o STP?

A verificação STP ocorre quando uma ordem agressora (uma ordem do comprador) é submetida. Se a ordem não for rejeitada e se tornar uma ordem do criador, considera-se que passou na verificação STP. A verificação STP ocorrerá novamente com a próxima ordem do agressor.

Dependendo do conjunto de instruções Prevenção Self-Trade, uma das seguintes ações será tomada quando o STP for detetado para os clientes que optarem por utilizá-lo:

  1. As ordens do comprador serão anuladas

  2. As ordens de vendedor serão anuladas

  3. Tanto a ordem do comprador como a do vendedor serão canceladas

Como posso configurar a funcionalidade STP?

Existem três níveis de instruções STP. Os efeitos serão produzidos pela seguinte ordem de precedência:

  • STP de nível de troca - controlo por defeito

  • Nível de ordem STP - especificado pelo utilizador

  • STP a nível da conta - especificado pelo utilizador

STP de nível de Exchange

Atualmente, não existe um STP de nível de Exchange implementado por defeito na Crypto.com Exchange (Global). Os utilizadores podem definir instruções STP ao nível da ordem e da conta.

*A Crypto.com Exchange (HK) implementou o STP por defeito para todos os utilizadores. Os utilizadores de Hong Kong devem consultar as FAQs da Exchange específicas da região.

Nível da ordem STP

Os utilizadores podem especificar as suas definições STP para cada ordem individual através da API de ordens (REST, WS, FIX). As definições de STP ao nível da ordem podem ser definidas através dos seguintes pedidos de API:

Os campos seguintes definem o STP:

  • Âmbito do STP (stp_scope):

    • M - Conta principal ou subconta(s)

    • S - Apenas subcontas

  • ID STP (stp_id): 0 a 32767

  • Instrução STP (stp_inst):

    • M - Cancelar Criador

    • T - Cancelar comprador

    • B - Cancelar tanto o criador como o comprador

Para que o STP seja efetivo, tanto as ordens do Comprador como do Criador devem ter a definição STP nos seus respetivos pedidos API.

Consulte a secção "Como é que a definição do âmbito STP afeta a correspondência de ordens entre diferentes tipos de conta para a definição STP de nível de ordem?" secção para os cenários STP de nível de ordem.

Nível de conta STP

O STP também pode ser especificado ao nível da conta. As definições STP de nível de conta têm a precedência mais baixa.

Se as ordens individuais não tiverem quaisquer definições STP, serão utilizadas as definições STP predefinidas da conta.

As definições de STP ao nível da conta podem ser definidas através do seguinte pedido de API:

Os campos seguintes definem o STP:

  • Âmbito do STP (stp_scope):

  • M - Conta principal ou subconta(s)

  • S - Apenas subcontas

  • ID STP (stp_id): 0 a 32767

  • Instrução STP (stp_inst):

  • M - Cancelar Criador

  • T - Cancelar comprador

  • B - Cancelar tanto o criador como o comprador

Para que o STP seja efetivo, ambas as contas que criam ordens de Comprador e Criador devem ter a definição STP em vigor. Para evitar a correspondência entre uma conta principal e uma subconta, os utilizadores têm de definir o STP em ambas as contas separadamente.

As definições de STP ao nível da conta podem ser recuperadas no seguinte pedido de API:

Consulte a secção "Como é que a definição do âmbito STP afeta a correspondência de ordens entre diferentes tipos de conta para a definição STP ao nível da conta?" para exemplos de cenários de STP ao nível da conta.

Que instrumentos são compatíveis com o STP?

O STP é suportado para todos os instrumentos na Bolsa Crypto.com.

Que tipos de ordens são compatíveis com o STP?

O STP é compatível tanto com ordens de limite como com ordens de mercado.

Como é que posso verificar se uma ordem foi cancelada devido a STP?

Se uma ordem tiver sido cancelada devido a STP, haverá um "reason": 43012 na resposta da API de cancelamento de ordens em private/get-order-detail e private/get-order-history.

Para mais informações, consulte a secção Response and Reason Codes da documentação da API do Exchange.

Se a funcionalidade STP for utilizada, irá aumentar a latência relativamente às ordens que não utilizam STP?

Não. Todas as ordens submetidas à Crypto.com Exchange, independentemente de conterem uma ID STP, estão sujeitas à mesma verificação de ID STP no motor de negociação. Por conseguinte, o facto de um participante utilizar ou não a funcionalidade não tem qualquer impacto na latência.

Existe alguma taxa para utilizar o STP?

De momento, a Crypto.com Exchange não cobra uma taxa pela utilização do STP.

Os utilizadores do Crypto.com Exchange necessitam de utilizar o STP?

A utilização da funcionalidade STP para o Crypto.com Exchange (Global) é atualmente opcional. Se uma futura STP de nível de livro de ordens for implementada pela Exchange, esta terá precedência sobre a STP de nível de ordens especificadas pelo utilizador. Por enquanto, os utilizadores podem adaptar a sua utilização de STP da forma que lhes for mais adequada, desde que cumpram todos os requisitos de STP e as regras de câmbio relevantes.

*A Crypto.com Exchange (HK) implementou o STP do livro de ordens por defeito para todos os utilizadores. Os utilizadores de Hong Kong devem consultar https://help.crypto.com/en/collections/9971368-crypto-com-exchange-hk

Como é que a definição do âmbito STP afecta a correspondência de ordens entre diferentes tipos de conta para a definição STP de nível de ordem?

Critério: Para que o STP seja efetivo, tanto as ordens do Comprador como do Criador devem ter a definição STP nos respetivos pedidos API.

Dado:

  1. Um utilizador tem uma conta principal e duas subcontas - subconta1 e subconta2

  2. É utilizado o STP ao nível da ordem

  3. Todas as ordens têm a mesma ID STP

Seguem-se os comportamentos de STP para diferentes combinações:

  1. Ordem de conta principal e Ordem de conta principal

    1. stp_scope: M - STP aplicado (as ordens não coincidem)

    2. stp_scope: S - STP aplicado (as ordens não coincidem)

  2. Ordem da conta principal e ordem da subconta1 ou subconta2

    1. stp_scope: M - STP aplicado (as ordens não coincidem)

    2. stp_scope: S - STP não aplicado (as ordens podem corresponder)

  3. Ordem da subconta1 e Ordem da subconta1

    1. stp_scope: M - STP aplicado (as ordens não coincidem)

    2. stp_scope: S - STP aplicado (as ordens não coincidem)

  4. Ordem da subconta1 e ordem da subconta2

    1. stp_scope: M - STP aplicado (as ordens não coincidem)

    2. stp_scope: S - STP não aplicado (as ordens podem corresponder)

Como é que a definição do âmbito STP afeta a correspondência de ordens entre diferentes tipos de conta para a definição STP de nível de conta?

Critério: Para que o STP seja efetivo, ambas as contas que criam ordens Taker e Maker devem ter a definição STP implementada.

Dado:

  • O utilizador tem uma conta principal e 3 subcontas: subconta1, subconta2, subconta3

  • É utilizado o STP ao nível da conta

  • stp_id é o mesmo para todas as contas

Cenários:

  1. Impedir a correspondência de ordens de todas as contas sob a mesma conta principal

    1. Definição: Definir stp_scope como "M" para a conta principal e todas as subcontas

    2. Resultado:

      1. As ordens da conta principal e de todas as subcontas com stp_scope = M não coincidem umas com as outras

      2. Se uma subconta (por exemplo, subconta3) definir stp_scope = S, só impedirá a auto-negociação dentro dessa subconta. Pode ainda corresponder a ordens da conta principal e de outras subcontas

  2. Impedir a correspondência de ordens provenientes apenas da mesma conta

    1. Definição: Definir stp_scope como "S" para a conta principal e subconta(s) desejada(s)

    2. Resultado:

      1. Cada conta com stp_scope = S só impedirá a auto-negociação dentro dessa conta específica

      2. As contas sem quaisquer definições STP podem corresponder a todas as outras contas do mesmo utilizador

      3. Caso especial: O UUID resolvido da conta principal é sempre o seu próprio, mesmo quando stp_scope = S. Se uma subconta definir stp_scope = M, evitará negociar com a conta principal e com ela própria.

  3. Impedir que as ordens de uma subconta específica (por exemplo, subconta1) coincidam com as suas próprias ordens

    1. Definição: Definir stp_scope como "S" para a subconta1

    2. Resultado:

      1. As ordens da subconta1 não coincidem com outras ordens da subconta1

      2. Definir a conta principal como "M" não tem qualquer efeito especial, a menos que as definições STP correspondentes sejam aplicadas às subcontas

  4. Impedir que as ordens de uma subconta específica (por exemplo, subconta2) coincidam com as ordens de todas as outras contas da mesma conta principal

    1. Definição: Definir stp_scope como "M" para a subconta2 e todas as outras subcontas

    2. Resultado:

      1. As ordens da subconta2 não coincidem com as ordens da conta principal e de outras subcontas que também têm stp_scope = M

      2. Se a conta principal for definida como "S", não terá qualquer efeito especial nas subcontas, a menos que estas tenham as suas próprias definições de STP

Isto respondeu à sua pergunta?