Como funciona o motor de vendas da Loxley AI: rastreamento de posições, avaliação do trailing stop-loss, escadas de take-profit, simulação de venda com agregador e a regra de design de que vendas nunca são bloqueadas pelo scanner de segurança.
A maioria dos bots de trading investe toda a sua engenhosidade nas entradas e trata a venda como um pensamento tardio. A Loxley AI inverte essa prioridade: o motor de vendas é o subsistema mais protegido da pilha. Este documento explica como as posições são rastreadas e como as saídas — trailing stop-loss (stop móvel de proteção), escadas de take-profit, vendas manuais — são executadas na Robinhood Chain.
Cada compra executada registra uma posição vinculada à carteira do membro e ao contrato do token. O rastreador armazena o valor de entrada, a base do preço de entrada e os parâmetros de saída configurados pelo membro. O estado da posição vive no servidor, não na interface do chat, então um membro que fecha o Telegram continua com os stops funcionando.
Um trailing stop segue o preço na subida e nunca o segue na descida. Concretamente, o motor registra o maior valor observado desde a entrada (o pico) e arma uma saída quando o valor atual cai uma porcentagem configurada abaixo desse pico. Três detalhes de implementação importam:
Os membros podem definir degraus de escada — por exemplo, vender 25% a +50%, outros 25% a +100%. Os degraus executam independentemente do trailing stop, e cada execução atualiza o restante rastreado. As escadas são como as comunidades institucionalizam a disciplina: ninguém precisa ser corajoso às 3 da manhã; o degrau foi decidido na entrada.
Antes de qualquer saída ser transmitida, o motor a executa a seco. As simulações de venda consultam o mesmo roteamento de nível de agregador usado na execução e validam que a posição pode de fato ser liquidada nos termos cotados. Se uma estimativa interna e uma simulação no nível da rota divergirem, a simulação no nível da rota vence. Isso captura o clássico padrão de rug em que o gráfico parece vivo, mas o pool não consegue absorver uma venda — e captura hooks de V4 (contratos que interceptam a lógica do pool) que se comportam de um jeito na saída e de outro na entrada.
O scanner de segurança existe para proteger entradas. Ele não tem veto sobre saídas. Um token pode estar classificado como crítico, um hook pode estar sinalizado, um pool pode parecer terminal — e a venda manual de um membro ainda executa imediatamente, com todas as vias empurrando a venda em vez de obstruí-la. O mesmo vale para saídas automáticas: stops e escadas disparam mesmo quando o scanner proibiria uma compra nova. Proteção na entrada nunca pode virar aprisionamento na saída.
Se uma rota falha, o motor tenta novamente por rotas alternativas e endpoints RPC em vez de desistir após uma tentativa. Falhas persistentes são comunicadas ao membro com um status em linguagem clara, e os operadores veem sinais agregados de falhas de saída no seu painel — nunca em silêncio.
A seguir: scanner de segurança de hooks de V4 → Toda a documentação
Built for operators, not slippage goblins. Talk to us →