Um assinante pode receber um sinal correto e ainda assim acabar com uma posicao incorreta. A razao geralmente nao esta na logica do lider, mas entre o envio da ordem e seu estado final: tempo esgotado, execucao parcial, cancelamento, nova solicitacao ou operacao manual na conta.
Para evitar que tais divergencias se acumulem, o sistema de copytrading precisa de uma reconciliacao separada. Ela compara a posicao alvo, as ordens ativas conhecidas e o estado real da conta na exchange. Nenhuma dessas fontes pode ser considerada um quadro completo por si so.
Tres estados de uma unica negociacao
Apos o sinal, existem pelo menos tres estados diferentes.
Intencao do sistema. Qual posicao o assinante deve ter apos aplicar o fator de copia, limites de risco, lote minimo e arredondamento.
Ordens enviadas, mas nao concluidas. Elas ja podem alterar a posicao, embora o volume atual na conta ainda nao tenha sido modificado.
Fato da exchange. Ordens, execucoes e posicao que a exchange retorna via fluxo privado e requisicoes REST de controle.
Se compararmos o alvo apenas com a posicao atual, o sistema pode nao perceber uma ordem em transito e enviar volume extra. Se confiar apenas no registro local, nao vera uma operacao manual ou alteracao ocorrida apos perda de conexao. A reconciliacao deve considerar ambas as fontes.
Por que a resposta a criacao de ordem nao encerra a operacao
APIs das exchanges funcionam de forma assincrona. A resposta bem-sucedida geralmente indica que a plataforma aceitou a requisicao para processamento. Depois disso, o status da ordem pode mudar.
Na documentacao da Bybit, para obter ordens abertas e fechadas, sao indicados separadamente estados de ordens nao preenchidas, parcialmente preenchidas e recentemente concluidas. Para atualizacoes rapidas, a exchange recomenda um fluxo WebSocket privado de ordens. A Binance transmite mudancas de status e volume executado acumulado em evento de atualizacao de ordem. Na documentacao da OKX tambem e descrita a assinatura do canal de ordens e transicoes entre estados live, filled e cancelamento.
Assim, surge a regra pratica: resposta HTTP, evento da ordem e posicao na conta sao evidencias diferentes. Para conclusao final, devem ser vinculadas por um identificador persistente.
Timeout e repeticao perigosa
Timeout significa apenas que o cliente nao recebeu resposta a tempo. Nao indica se a requisicao chegou ao sistema de negociacao.
Ha dois cenarios possiveis:
- a exchange nao recebeu a ordem;
- a exchange recebeu e ate executou a ordem, mas a resposta foi perdida no caminho.
Se repetir a requisicao imediatamente sem verificacao, no segundo cenario sera criada uma segunda ordem. Por isso, a integracao comercial geralmente usa um ID de cliente unico e processamento idempotente do seu lado. Apos resultado incerto, o sistema primeiro busca a ordem pelo ID ou a recupera por historico e fluxo de eventos. Uma nova ordem so e criada depois de classificar a tentativa anterior.
Este e um principio geral de integracao confiavel, nao uma afirmacao sobre implementacao interna especifica do CopyTrader.
Execucao parcial altera o calculo do delta
Suponha que a posicao alvo do assinante seja 1,0 BTC, a posicao atual real seja 0,6 BTC, e a ordem aberta de compra de 0,4 BTC ja tenha sido executada pela metade.
Se a exchange ja incluiu os 0,2 BTC executados na posicao atual, resta uma quantidade aberta de 0,2 BTC. O estado considerado e:
posicao real saldo nao executado das ordens ativas.
No exemplo, isso e 0,8 0,2 = 1,0 BTC. Uma ordem adicional nao e necessaria.
Se o sistema olhar apenas para a posicao 0,8 BTC, pode enviar mais 0,2 BTC e apos a conclusao da primeira ordem tera 1,2 BTC. Se contar todo o volume original da ordem sobre a posicao ja atualizada, o erro sera outro: a parte executada sera considerada duas vezes.
A formula exata depende do modelo de posicoes, direcao, modo hedge/one-way e contrato da exchange. Mas o principio e um so: volume executado e saldo aberto nao podem ser misturados.
Ciclo de reconciliacao de ordens e posicao
Um ciclo pratico de reconciliacao consiste em varios passos.
- Obter o alvo. Registrar a posicao alvo apos regras de copia e restricoes do assinante.
- Capturar o fato da exchange. Obter posicao atual, ordens ativas e status finais recentes.
- Vincular IDs. Associar decisao interna, ID do cliente e order ID da exchange.
- Normalizar estado. Considerar direcao, volume executado, saldo aberto, passo de quantidade e modo da posicao.
- Calcular divergencia. Comparar o alvo com a posicao real e o volume ainda passivel de execucao.
- Classificar motivo. Timeout, rejeicao, preenchimento parcial, cancelamento, operacao manual, perda de evento ou alteracao de configuracao.
- Escolher acao. Observar, cancelar saldo, enviar ordem corretiva, bloquear correcao automatica ou passar o caso para operador.
- Verificar estado final. Depois da acao, consultar novamente o fato da exchange.
Correcao automatica nem sempre e adequada. Se a causa for desconhecida ou houver atividade externa na conta, e mais seguro parar e mostrar a divergencia do que tentar "alcancar" o alvo indefinidamente com novas ordens de mercado.
Cenarios tipicos
| Observacao |
Possivel causa |
O que verificar antes de nova ordem |
| Sem resposta apos envio |
timeout ou perda de conexao |
ID da ordem do cliente, historico de ordens e fluxo privado |
Status permanece partially filled |
liquidez insuficiente ou preco limite |
volume executado, saldo, validade e objetivo atual |
| Ordem cancelada |
cancelamento manual, IOC/FOK, regra da exchange |
status final e motivo do cancelamento |
| Posicao difere e nao ha ordens abertas |
operacao manual, evento perdido, modo diferente de posicao |
historico de execucoes e configuracoes da conta |
| Apos retry, volume maior que o objetivo |
primeira tentativa foi aceita |
ambos order IDs e regra de reenvio |
A tabela ajuda a iniciar a investigacao, mas nao substitui o contrato especifico da exchange. Nomes de status e ordem de eventos variam.
O que o usuario deve ver
O status "negociacao copiada" nao e suficiente. Ele combina varios estados diferentes e cria uma falsa seguranca.
E mais util mostrar separadamente:
- sinal recebido;
- ordem preparada;
- ordem aceita pela exchange;
- executada parcial ou totalmente;
- rejeitada ou cancelada;
- posicao reconciliada;
- divergencia detectada e acao necessaria.
Para casos controversos, e necessario um registro minimo sem segredos: tempo, instrumento, direcao, volume solicitado e executado, preco medio, status final e link para identificador interno. Chaves de API e outras credenciais nao devem estar neste registro.
Como este material se relaciona com outras verificacoes
Sincronizacao de configuracoes responde se e seguro enviar copia de uma negociacao com os parametros atuais da conta. Estudo de slippage mostra por que o mesmo sinal nao garante o mesmo preco medio. A reconciliacao apos execucao resolve o terceiro problema: o estado real coincide com o que o sistema pretendia criar.
Essas verificacoes nao eliminam o risco de mercado. Elas identificam causas de divergencia e dao ao operador provas para agir corretamente.
O material tem carater educativo e descreve principios gerais de integracoes comerciais. Nao e garantia de execucao especifica, caracteristica de todas as exchanges conectadas ou recomendacao de investimento.