# Annexe E · Score de reprise

Le score de reprise est une note sur 100 qui répond à une question : **est-ce que le CTO de Vivra peut faire repartir ce projet ?** Il est calculé à l'analyse de chaque projet soumis par l'équipe, et affiché sur la dapp pour les candidats, pour que les votants comparent les 5 candidats sur la même base.

Il ne sert pas à choisir les candidats : l'équipe choisit librement les 5 projets. Il ne remplace pas non plus les filtres de la cible Vivra (plus haut ≥ 500 k$, market cap actuelle entre 15 et 50 k$, compte X en ligne mais silencieux, docs accessibles : voir [Analyse des projets](analyse-des-projets.md)). Les filtres disent **qui peut entrer**, le score dit **qui a le plus de chances de repartir**.

## Les 5 piliers

| Pilier | Points | La question |
| --- | --- | --- |
| 1. Communauté vivante | 25 | Y a-t-il encore des gens derrière le projet ? |
| 2. Impact du buyback | 25 | Notre buyback va-t-il se voir sur le chart ? |
| 3. Pression vendeuse | 20 | Qui va vendre au premier pump ? |
| 4. Fond du projet | 15 | Y a-t-il un vrai projet à reprendre, au bon moment ? |
| 5. Flywheel | 15 | Le CTO va-t-il rapporter des frais pour racheter du $VIVRA ? |
| **Total** | **100** | |

`clamp(x)` borne `x` entre 0 et 1. Les logarithmes servent à ce qu'un petit projet ne soit pas écrasé par un gros : passer de 300 à 1 000 holders compte autant que passer de 1 500 à 5 000.

## 1. Communauté vivante (25 points)

| Critère | Points | Calcul |
| --- | --- | --- |
| Holders réels | 10 | `10 × clamp( (log10(holders) − log10(300)) / (log10(5 000) − log10(300)) )` ; hors poussière, pools, burn et wallets du dev |
| Holders fidèles | 7 | `7 × clamp( (holders depuis plus de 30 j / holders) / 0,6 )` |
| Nouveaux holders | 4 | `4 × clamp( nouveaux holders sur 7 j / 25 )` : des gens achètent encore un projet mort |
| Activité de la communauté | 4 | `2` si au moins un message de membre sur le Telegram dans les 7 derniers jours ; `2` si au moins 5 tweets d'autres comptes citent le ticker ou le projet sur 7 jours |

Le compte X du projet est silencieux par définition (c'est un filtre de la cible) : on mesure ici la communauté, pas l'équipe.

## 2. Impact du buyback (25 points)

| Critère | Points | Calcul |
| --- | --- | --- |
| Hausse simulée | 25 | `25 × clamp( hausse / 100 % )` |

`hausse` = la hausse de prix obtenue en simulant l'achat de toute l'enveloppe de buyback du cycle, d'un seul coup, sur la liquidité actuelle (pool v4 ou courbe), taxes comprises. L'enveloppe utilisée est celle prévue au moment du calcul (réserve Buyback, dans la limite du plafond par token CTO).

Une hausse simulée de 100 % ou plus donne les 25 points. En vrai, le buyback est étalé en tranches sur 7 jours, donc la hausse réelle sera différente : ce chiffre sert à comparer les candidats entre eux, pas à prédire un prix. Il n'est jamais affiché comme une promesse (voir « Sur la dapp »).

## 3. Pression vendeuse (20 points)

| Critère | Points | Calcul |
| --- | --- | --- |
| Bag du dev et des insiders | 8 | `8 × clamp( 1 − bag / 5 % )` ; dev, wallets liés (financés par le dev ou l'ayant financé), wallets du lancement |
| Concentration | 6 | top 10 hors pools, burn et dev : `6` si ≤ 20 %, `0` si ≥ 50 %, linéaire entre les deux |
| Holders sous l'eau | 6 | `6 × clamp( part de la supply détenue par des wallets à −80 % ou pire / 0,7 )` |

Pourquoi « sous l'eau » est un bon signe : un holder à −90 % ne vend pas au premier +50 %. Plus la supply est entre ses mains, mieux le pump tient. Le prix de revient de chaque wallet est calculé à partir de ses achats (moyenne pondérée des trades du token), en ignorant les jetons reçus par simple transfert.

## 4. Fond du projet (15 points)

| Critère | Points | Calcul |
| --- | --- | --- |
| Documentation | 4 | `4` si des docs ou un whitepaper sont en ligne ; `2` si seul le site est en ligne |
| Code | 3 | `1` si un repo GitHub public existe ; `+2` s'il a au moins 50 commits |
| Audience X | 2 | `2 × clamp( (log10(followers) − log10(1 000)) / (log10(50 000) − log10(1 000)) )` |
| Hauteur du sommet | 3 | `3 × clamp( (log10(market cap au plus haut) − log10(500 000)) / (log10(5 000 000) − log10(500 000)) )` |
| Timing | 3 | jours depuis la mort (premier jour où les conditions Dead sont réunies) : `3` entre 21 et 84 jours, `1,5` entre 14 et 20 jours ou entre 85 et 180 jours, `0` sinon |

Le timing : trop tôt, le token dumpe encore ; trop tard, tout le monde l'a oublié.

## 5. Flywheel (15 points)

| Critère | Points | Calcul |
| --- | --- | --- |
| Creator tax | 10 | `10 × clamp( creator tax en bps / 300 )` |
| Pons v2 | 5 | `5` si le token est un Pons v2 (CTO officiel et frais suivis on-chain) |

## Paliers affichés

| Score | Libellé | Couleur |
| --- | --- | --- |
| 75 à 100 | Forte reprise possible | orange Vivra |
| 50 à 74 | Reprise possible | encre |
| 0 à 49 | Reprise difficile | gris |

## Exemple

Un projet tech Pons v2 : plus haut à 1,2 M$, market cap actuelle 28 k$, 1 184 holders dont 540 depuis plus de 30 jours, 9 nouveaux holders sur 7 jours, Telegram actif mais peu de mentions sur X, hausse simulée du buyback de +62 %, bag du dev 1,2 %, top 10 à 28 %, 55 % de la supply chez des holders à −80 % ou pire, docs GitBook en ligne, repo GitHub de 140 commits, 6 200 followers, mort depuis 52 jours, creator tax de 2 %.

| Pilier | Détail | Points |
| --- | --- | --- |
| Communauté vivante | 4,9 + 5,3 + 1,4 + 2 | 13,6 / 25 |
| Impact du buyback | 25 × 0,62 | 15,5 / 25 |
| Pression vendeuse | 6,1 + 4,4 + 4,7 | 15,2 / 20 |
| Fond du projet | 4 + 3 + 0,9 + 1,1 + 3 | 12,1 / 15 |
| Flywheel | 6,7 + 5 | 11,7 / 15 |
| **Score** | | **68 : Reprise possible** |

## Données nécessaires

| Donnée | D'où elle vient | Fréquence |
| --- | --- | --- |
| Holders, ancienneté, nouveaux holders, concentration | transferts ERC-20 du token, lus à l'analyse | à l'analyse, puis 15 min pendant le vote |
| Prix de revient par wallet | trades du token (courbe et pool) | à l'analyse, puis 15 min pendant le vote |
| Wallets du dev et liés | traçage des financements (annexe A, `dev_wallets`) | à l'analyse |
| Hausse simulée | devis sur la courbe ou le pool v4 (lecture, sans transaction) | à l'analyse, puis 15 min pendant le vote |
| Telegram, mentions X, followers | API X et lien Telegram | à l'analyse, puis 1 fois par jour pendant le vote |
| Docs, site, whitepaper, GitHub | requêtes HTTP et API GitHub | à l'analyse |
| Date de mort | premier jour où les conditions Dead sont réunies, recalculé sur l'historique | à l'analyse |

## Paramètres et stockage

- Toutes les bornes et tous les points sont dans `settings`, sous les clés `recovery.*`. Un changement crée une nouvelle `weights_version` : les scores déjà figés sur des fiches publiées ne bougent pas.
- Chaque calcul est écrit dans `recovery_scores`, avec le détail de chaque critère dans `components` : valeur brute, ratio, points.
- À la publication d'un cycle, le score de chaque candidat est figé. C'est lui qu'affiche la fiche pendant tout le vote ; la valeur en direct est affichée à côté, en plus petit.
- Une donnée introuvable vaut 0 sur son critère et s'affiche « non trouvé ».
- Fonction pure dans `packages/core/recovery-score.ts`, testée avec l'exemple ci-dessus et des cas limites (0 holder, donnée manquante, valeurs au-delà des bornes).

## Sur la dapp

- **Fiche candidat** : un bloc « Score de reprise » en haut, avec la note en grand chiffre, le libellé du palier, et une barre par pilier qu'on peut déplier pour voir chaque critère avec sa valeur brute (« 1 184 holders », « 55 % de la supply sous l'eau »…). Un lien « Comment c'est calculé » renvoie vers cette page.
- **Vote** : la note de chaque candidat à côté de son nom.
- **Back-office** : la note de chaque projet analysé, pour aider l'équipe à composer le bulletin.
- La hausse simulée est affichée comme « impact estimé du buyback sur la liquidité actuelle », jamais comme un objectif de prix.
- Mention sous le bloc : « Le score décrit l'état du projet, ce n'est pas un conseil d'achat. »