Cómo funciona el motor de ventas de Loxley AI: seguimiento de posiciones, evaluación del trailing stop-loss, escaleras de take-profit, simulación de ventas con agregador y la regla de diseño de que las ventas nunca se bloquean por el escáner de seguridad.
La mayoría de los bots de trading invierte su ingenio en las entradas y trata la venta como una ocurrencia tardía. Loxley AI invierte esa prioridad: el motor de ventas es el subsistema más protegido de la pila. Este documento explica cómo se rastrean las posiciones y cómo se ejecutan las salidas — trailing stop-loss (stop dinámico de protección), escaleras de take-profit, ventas manuales — en Robinhood Chain.
Cada compra ejecutada registra una posición vinculada a la billetera del miembro y al contrato del token. El rastreador almacena el importe de entrada, la base del precio de entrada y los parámetros de salida configurados por el miembro. El estado de la posición vive en el servidor, no en la interfaz del chat, así que un miembro que cierra Telegram sigue teniendo stops funcionando.
Un trailing stop sigue el precio hacia arriba y nunca lo sigue hacia abajo. En concreto, el motor registra el valor más alto observado desde la entrada (el pico) y arma una salida cuando el valor actual cae un porcentaje configurado por debajo de ese pico. Tres detalles de implementación importan:
Los miembros pueden fijar peldaños de escalera — por ejemplo, vender el 25% al +50%, otro 25% al +100%. Los peldaños se ejecutan con independencia del trailing stop, y cada ejecución actualiza el resto rastreado. Las escaleras son cómo las comunidades institucionalizan la disciplina: nadie tiene que ser valiente a las 3 de la madrugada; el peldaño se decidió en la entrada.
Antes de difundir cualquier salida, el motor la ejecuta en seco. Las simulaciones de venta consultan el mismo enrutamiento de nivel de agregador usado para la ejecución y validan que la posición realmente se puede vender en los términos cotizados. Si una estimación interna y una simulación a nivel de ruta discrepan, gana la simulación a nivel de ruta. Esto detecta el clásico patrón de rug en el que el gráfico parece vivo pero el pool no puede absorber una venta — y detecta hooks de V4 (contratos que interceptan la lógica del pool) que se comportan de forma distinta en la salida que en la entrada.
El escáner de seguridad existe para proteger las entradas. No tiene veto sobre las salidas. Un token puede estar calificado como crítico, un hook puede estar marcado, un pool puede parecer terminal — y la venta manual de un miembro se ejecuta igualmente de inmediato, con todos los carriles empujando la venta en lugar de obstruirla. Lo mismo vale para las salidas automáticas: los stops y las escaleras se disparan incluso cuando el escáner prohibiría una compra nueva. La protección en la entrada nunca debe convertirse en encarcelamiento en la salida.
Si una ruta falla, el motor reintenta a través de rutas alternativas y endpoints RPC en lugar de rendirse tras un intento. Los fallos persistentes se comunican al miembro con un estado en lenguaje claro, y los operadores ven señales agregadas de fallos de salida en su panel — nunca en silencio.
Siguiente: escáner de seguridad de hooks de V4 → Toda la documentación
Built for operators, not slippage goblins. Talk to us →