Analyse des projets (à la demande)
Vivra ne scanne pas toute la blockchain. C'est l'équipe qui trouve les projets morts et envoie leurs adresses. Le Scanner analyse seulement ces tokens-là, et seuls ceux que l'équipe valide apparaissent sur la dapp.
Pas d'indexer qui lit tous les lancements Pons en continu : ça coûte cher en RPC et en stockage, pour des milliers de tokens qu'on ne reprendra jamais.
Le parcours#
- L'équipe soumet une adresse dans le back-office : l'adresse du contrat, plus en option un lien X, Telegram, docs ou GitHub si elle les connaît déjà.
- Le Scanner l'analyse, en quelques minutes, pour ce token seul : données on-chain, cible Vivra, règles de sécurité, socials et docs, score de reprise, et un brouillon de fiche (thèse, chronologie, risques).
- L'équipe relit l'analyse dans le back-office et choisit :
- Valider : le projet passe dans la réserve de candidats, prêt à être mis sur un bulletin ;
- Rejeter : il reste en base avec le motif, invisible sur la dapp, et ne sera pas réanalysé sauf demande ;
- Relancer l'analyse : après avoir ajouté un lien manquant, par exemple.
- Publication : quand l'équipe compose un cycle, elle prend 5 projets validés. Leurs fiches deviennent publiques sur la dapp à la publication du cycle, pas avant.
Une analyse peut être relancée à tout moment. Les chiffres du marché sont rafraîchis juste avant la publication du cycle, puis le score est figé pour le vote.
Ce que le Scanner lit, pour un token#
| Donnée | Source | Coût |
|---|---|---|
| Contrat : mint, vente possible, owner, fonctions owner | lecture du bytecode et appels simulés (RPC) | quelques appels |
| Version Pons, état (courbe ou gradué), pool, creator tax, destinataire des frais | lectures sur la factory Pons v2 et le hook (RPC) | quelques appels |
| Holders, ancienneté, nouveaux holders, concentration, prix de revient | events Transfer et trades de ce token seul, depuis son bloc de lancement (eth_getLogs filtré sur son adresse), ou l'API de l'explorateur de Robinhood Chain si elle le permet | une lecture par analyse |
| Prix, market cap, plus haut, volume | trades du même historique, ou l'API Pons de Bitquery en option | inclus |
| Wallets du dev et liés | transactions du wallet créateur, sur 2 niveaux | quelques appels |
| Hausse simulée du buyback | devis sur la courbe ou le pool v4 (lecture, sans transaction) | 1 appel |
| Compte X : existe, date du dernier tweet, followers | API X, pour ce compte seul | 1 à 2 appels |
| Photo de profil et bannière du projet | API X (image de profil et bannière du compte), copiées dans le stockage objet de Vivra pour ne pas dépendre du lien X | 1 appel |
| Docs, whitepaper, site, GitHub | requêtes HTTP et API GitHub | quelques appels |
| Telegram | nombre de membres via le lien public ; activité seulement si un bot Vivra est dans le groupe | 1 appel |
À vérifier au jalon M1 : qu'un eth_getLogs sur toute la vie d'un token passe chez Alchemy sans dépasser la limite de blocs par requête (sinon, découper par tranches de blocs).
Mise à jour prévue, Vivra Scout : une infra qui surveille toute la chaîne et propose d'elle-même les projets morts qui collent à la cible. En V1, on s'en passe : l'équipe trouve les projets et soumet les adresses.
Statut Dead#
Un token est Dead quand trois conditions sont réunies : volume moyen sous 1 000 $ par jour sur 7 jours, prix en baisse d'au moins 85 % depuis son plus haut, et dev inactif depuis 14 jours (aucune transaction du wallet créateur). Le Scanner le vérifie à l'analyse ; un token soumis qui n'est pas Dead est signalé, l'équipe décide.
La cible de Vivra#
Vivra reprend des projets tech légitimes qui ont vraiment existé, pas des memes jetables : un produit, des docs, un compte X encore en ligne. Le projet a couru, il est retombé, l'équipe ne poste plus, mais tout ce qu'il faut pour le reprendre est encore là.
| Règle | Seuil par défaut | Source |
|---|---|---|
| Market cap au plus haut | 500 000 $ ou plus | historique des trades |
| Market cap actuelle | entre 15 000 $ et 50 000 $ | dernier relevé |
| Compte X du projet | existe toujours (ni supprimé, ni suspendu) | API X |
| Silence sur X | aucun tweet du compte du projet depuis 30 jours ou plus | API X |
| Documentation accessible | au moins une source en ligne : docs (GitBook, Notion, sous-domaine docs), whitepaper, repo GitHub, ou site encore en ligne | vérification HTTP, puis relecture de l'équipe |
| Projet tech | un produit, un protocole ou un outil décrit dans les docs, pas seulement un meme | proposé par le Scanner, confirmé par l'équipe |
Règles de sécurité#
| Règle | Seuil | Bloquante |
|---|---|---|
| Holders avec un solde réel | plus de 300 | oui |
| Fonction de mint | aucune | oui |
| Vente possible | oui | oui |
| Liquidité | pool Uniswap v4 verrouillé (token Pons v2 gradué) ou encore sur la courbe | oui |
| Bag du dev et de ses wallets liés | moins de 5 % | oui |
| Version Pons | v2 de préférence | non, compte dans le score de reprise |
| Creator tax | plus de 0 % | non, compte dans le score de reprise |
Le résultat de chaque règle s'affiche dans le back-office : vert, rouge, ou « non trouvé ». Une règle bloquante en rouge n'empêche pas l'équipe de valider, mais elle doit écrire pourquoi, et la fiche publique affichera la règle non remplie.
Les seuils sont des paramètres en base, modifiables depuis le back-office sans redéploiement.
Suivi après validation#
Seuls les tokens qui comptent sont suivis en continu, ce qui garde l'infra minuscule :
| Tokens suivis | Fréquence | Pourquoi |
|---|---|---|
| Les 5 candidats du vote en cours | toutes les 15 min | marché en direct sur les fiches |
| Le token CTO en opération (72 h, buyback, verdict) | en direct (events de son pool ou de sa courbe) | war room, chart, tranches |
| Les tokens repris, jusqu'à J+30 | toutes les heures | suivi, verdict, passation |
| Les tokens repris dont les frais vont à Vivra | une fois par jour | registre des frais (events Credited de l'escrow) |
| Tout le reste | jamais |
En pratique : moins de 10 tokens suivis à la fois.
Cycle de vie d'un token#
| De | Vers | Déclencheur |
|---|---|---|
| (soumis) | Analysé | le Scanner a fini son analyse |
| Analysé | Validé | l'équipe le valide |
| Analysé | Rejeté | l'équipe le rejette, avec un motif |
| Validé | Candidate | l'équipe le met sur un bulletin |
| Candidate | CTO live | il gagne le vote |
| Candidate | Validé | il perd le vote ; il peut revenir sur un bulletin suivant |
| CTO live | Sending | à la fin des 72 h, si le volume ou les holders dépassent les seuils de départ |
| CTO live ou Sending | Revived | verdict positif à J+7 (questions ouvertes, décision 9) |
| CTO live ou Sending | Dead again | verdict négatif à J+7 |
API#
Entrées, sorties et erreurs de chaque route : Annexe B · API.
GET /candidates/:id: la fiche publique d'un candidat publié.GET /stats: chiffres de la landing (takeovers, revived, $VIVRA brûlé).POST /admin/projects: soumettre une adresse à analyser (équipe).GET /admin/projects,POST /admin/projects/:address/review: relire, valider ou rejeter (équipe).
Connexion et vote :
POST /auth/email: envoie un lien magique ou un code à 6 chiffres ; refuse les emails jetables.POST /auth/verify: valide le code ou le lien, ouvre une session de 30 jours.GET /cycles/current: cycle en cours, candidats, horaires, parts de vote.POST /votes: vote ou change de vote pour le cycle en cours.POST /supports: soutien à un candidat.GET /operations/:idet un canal WebSocket : étapes, journal, tranches d'un CTO.
Critères d'acceptation#
- Une adresse soumise sur testnet donne une analyse complète (cible, sécurité, socials, score, brouillon de fiche) en moins de 10 minutes.
- Les résultats de 10 tokens analysés sont vérifiés à la main contre l'explorateur.
- Un token rejeté n'apparaît nulle part sur la dapp ni dans l'API publique.
- Aucun job ne lit les lancements ou les trades de tokens qui ne sont ni candidats, ni repris.