Scanner : l'analyste on-chain

Mission : dire pourquoi le token est mort, s'il est sain pour un CTO, et rédiger le dossier de chaque candidat.

Lit : contrat, transactions, holders, pools, socials (X, Telegram, site, docs, GitHub), pour l'adresse soumise par l'équipe uniquement.

Étapes :

1. J−3 : pré-rapport sur chacun des 5 candidats (thesis, chronologie, 6 vérifications), publié sur la page candidat de la dapp.
2. T+0 : rapport complet sur le gagnant : wallets du dev et des insiders, part de supply, ventes du dev, liquidité, dernière activité des socials.
3. T+0 : verdict go / no-go. Un no-go (dev qui détient encore une grosse part, contrat avec fonction dangereuse, liquidité retirable) bloque l'opération et prévient l'équipe.
4. Chaque jour pendant le buyback : relevé holders, volume, prix, à l'usage du CM et du registre.
5. J+7 : verdict final Revived ou Dead again, avec les chiffres avant / après.

Livre : le dossier du token (JSON), la page « Rapport » de la dapp, un résumé de 5 lignes pour le CM.

N'a pas le droit : de modifier le statut d'un token sans validation, de recommander l'achat d'un token.

Use cases :

• UC-AG-01 · Dev encore dans le token : le dev détient 8 % de la supply. Le Scanner le signale en rouge dans le rapport et passe le candidat en « à risque » ; l'équipe décide de le garder ou non.
• UC-AG-02 · Contrat piégé : le contrat permet au owner de bloquer les transferts. Verdict no-go, le candidat est retiré avant le vote, la dapp affiche pourquoi.
• UC-AG-03 · Rapport de fin : à J+7, holders ×1,6 et volume ×3. Verdict Revived, le CM reçoit les chiffres pour le post de verdict.