Comment fonctionne le moteur de vente de Loxley AI : suivi des positions, évaluation du trailing stop-loss, paliers de take-profit, simulation de vente via agrégateur, et la règle de conception qui veut que les ventes ne soient jamais bloquées par le scanner de sécurité.
La plupart des bots de trading investissent leur ingéniosité dans les entrées et traitent la vente comme une réflexion après coup. Loxley AI inverse cette priorité : le moteur de vente est le sous-système le plus protégé de la stack. Ce document explique comment les positions sont suivies et comment les sorties — trailing stop-loss, paliers de take-profit, ventes manuelles — sont exécutées sur Robinhood Chain.
Chaque achat exécuté enregistre une position liée au wallet du membre et au contrat du token. Le tracker stocke le montant d'entrée, la base de prix d'entrée et les paramètres de sortie configurés par le membre. L'état des positions vit côté serveur, pas dans l'interface du chat, de sorte qu'un membre qui ferme Telegram garde des stops fonctionnels.
Un trailing stop suit le prix à la hausse et ne le suit jamais à la baisse. Concrètement, le moteur enregistre la valeur la plus élevée observée depuis l'entrée (le pic) et arme une sortie lorsque la valeur courante tombe d'un pourcentage configuré sous ce pic. Trois détails d'implémentation comptent :
Les membres peuvent définir des échelons de palier — par exemple, vendre 25 % à +50 %, puis 25 % à +100 %. Les échelons s'exécutent indépendamment du trailing stop, et chaque exécution met à jour le reste suivi. Les paliers sont la façon dont les communautés institutionnalisent la discipline : personne n'a besoin d'être courageux à 3 h du matin ; l'échelon a été décidé à l'entrée.
Avant que toute sortie ne soit diffusée, le moteur l'exécute à blanc. Les simulations de vente interrogent le même routage de qualité agrégateur utilisé pour l'exécution et valident que la position est réellement sortable aux conditions cotées. Si une estimation interne et une simulation au niveau de la route divergent, c'est la simulation au niveau de la route qui l'emporte. Cela détecte le schéma classique de rug où un graphique semble vivant mais où le pool ne peut pas absorber une vente — et cela détecte les hooks V4 (crochets) qui se comportent différemment à la sortie qu'à l'entrée.
Le scanner de sécurité existe pour protéger les entrées. Il n'a aucun droit de veto sur les sorties. Un token peut être noté critique, un hook peut être signalé, un pool peut sembler moribond — et la vente manuelle d'un membre s'exécute quand même immédiatement, chaque voie poussant la vente plutôt que de l'entraver. Il en va de même pour les sorties automatiques : les stops et les paliers se déclenchent même quand le scanner interdirait un nouvel achat. La protection à l'entrée ne doit jamais devenir un emprisonnement à la sortie.
Si une route échoue, le moteur réessaie via des routes et des points de terminaison RPC alternatifs plutôt que d'abandonner après une seule tentative. Les échecs persistants remontent au membre avec un statut en langage clair, et les opérateurs voient les signaux agrégés d'échecs de sortie dans leur tableau de bord — jamais en silence.
Suivant : le scanner de sécurité des hooks V4 → Toute la doc
Built for operators, not slippage goblins. Talk to us →