Les premiers blocs d'un lancement vous disent à qui le token est vraiment destiné.

Comment Loxley AI détecte les snipers sur les lancements frais de Robinhood Chain : ancrage à la transaction de création, liens entre deployer et financeurs de LP, analyse des achats dans le même bloc, score de concentration, et comment les verdicts alimentent la barrière de sécurité.

Chaque nouveau token sur Robinhood Chain laisse une trace forensique dans ses premiers blocs. Le module de détection des snipes de Loxley AI lit cette trace pour répondre à la question qui décide si un lancement est tradable : l'offre initiale est-elle entre les mains d'une foule équitable, ou entre celles des amis du deployer ?

Ancrage à la transaction de création

L'analyseur ancre chaque token à la transaction qui l'a créé (ou à son premier événement de liquidité, lorsque le flux du launchpad diffère). À partir de cet ancrage, il reconstitue le graphe du lancement : l'adresse du deployer, les wallets qui ont financé le deployer, le fournisseur de liquidité et les financeurs de LP, et chaque achat exécuté dans le même bloc et les blocs immédiatement suivants. L'ancrage à la création est délibéré : les événements ultérieurs peuvent être gonflés avec de faux achats « communautaires », mais la fenêtre de création est le seul enregistrement que l'escroc ne peut pas réécrire rétroactivement.

Ce qui est mesuré

• Achats dans le même bloc et les blocs proches : les wallets qui transactent dans le bloc de création sont de facto des initiés (bots abonnés au deployer, ou le deployer lui-même via des wallets frais).
• Analyse des liens : liens de financement de gas et de financement initial entre les premiers acheteurs, le deployer et le financeur de LP. Dix snipers « différents » financés par un seul wallet sont un seul sniper.
• Concentration : le pourcentage de l'offre en circulation détenu par des wallets liés à des initiés, pondéré par rapport à la liquidité réelle totale.
• Intégrité de la liquidité : si les tokens LP sont verrouillés pour une durée dans un contrat de locker reconnu, brûlés, ou simplement posés sans verrouillage dans le wallet du deployer. Les chiffres d'offre proviennent de lectures on-chain des contrats eux-mêmes — jamais dérivés des journaux d'événements, que les arnaques sophistiquées falsifient spécifiquement pour tromper les indexeurs.

Des mesures au score

Le module produit un score de concentration et un ensemble d'étiquettes (deployer, initié, lié au LP, cluster de bots) qui alimentent le verdict de sécurité en couches décrit dans la documentation du scanner. Un token peut avoir un code de contrat impeccable et rester noté dangereux parce que la distribution de l'offre indique que le trade est déjà terminé avant d'avoir commencé.

Renseignement sur les acteurs connus

Les écosystèmes de lancement ont leurs récidivistes. Les adresses et les clusters de financement associés à des rugs précédents sont suivis, et les nouvelles créations qui leur sont liées sont signalées au moment de la détection — avant que les membres ne dépensent un centime. Pour les opérateurs de communautés, c'est la différence entre un chat rempli de gagnants et un chat rempli de liquidité de sortie : l'avertissement voyage avec l'alerte.

Vitesse contre profondeur

L'analyse profonde des liens est coûteuse, donc le pipeline est ordonné : les vérifications déterministes peu coûteuses (verrouillages, pouvoirs, concentration dans le même bloc) s'exécutent en ligne à la vitesse de la détection ; l'analyse de graphe plus lourde s'exécute en asynchrone et améliore un verdict en quelques secondes. Si la couche profonde est incomplète quand une décision s'impose, le verdict indique exactement quelles couches sont en attente — les états dégradés ne sont jamais masqués ni mis en cache.

Suivant : l'architecture shardée → Toute la doc

Built for operators, not slippage goblins. Talk to us →