# Appendix E · Recovery score

The recovery score is a mark out of 100 answering one question: **can a Vivra CTO help this project recover?** It is calculated during analysis of each team-submitted project and displayed for candidates so voters can compare the five projects consistently.

It does not select candidates: the team chooses the five projects. It also does not replace Vivra's target filters (peak market cap ≥ $500k, current market cap $15k–$50k, X account online but silent, accessible docs; see [Project analysis](analyse-des-projets.md)). Filters determine **who can enter**; the score compares **recovery potential**.

## The five pillars

| Pillar | Points | Question |
| --- | --- | --- |
| 1. Living community | 25 | Are people still behind the project? |
| 2. Buyback impact | 25 | Would the buyback materially affect the current market? |
| 3. Selling pressure | 20 | Who might sell into an initial recovery? |
| 4. Project fundamentals | 15 | Is there a real project to take over, at the right time? |
| 5. Flywheel | 15 | Could the CTO generate fees to buy back $VIVRA? |
| **Total** | **100** | |

`clamp(x)` bounds `x` between 0 and 1. Logarithms keep larger projects from overwhelming smaller ones: moving from 300 to 1,000 holders counts as much as moving from 1,500 to 5,000.

## 1. Living community (25 points)

| Criterion | Points | Calculation |
| --- | --- | --- |
| Real holders | 10 | `10 × clamp((log10(holders) − log10(300)) / (log10(5000) − log10(300)))`; excludes dust, pools, burn, and developer wallets |
| Loyal holders | 7 | `7 × clamp((holders for more than 30 days / holders) / 0.6)` |
| New holders | 4 | `4 × clamp(new holders over 7 days / 25)`; people still buying a dead project |
| Community activity | 4 | `2` if at least one member message appeared in Telegram over the last 7 days; `2` if at least 5 tweets from other accounts mention the ticker or project over 7 days |

The project's X account is silent by definition (a target filter): this measures the community, not the team.

## 2. Buyback impact (25 points)

| Criterion | Points | Calculation |
| --- | --- | --- |
| Simulated increase | 25 | `25 × clamp(increase / 100%)` |

`increase` is the price increase obtained by simulating the entire cycle buyback envelope as one purchase against current liquidity (v4 pool or curve), including taxes. The envelope is the planned amount at calculation time (Buyback reserve, within the CTO token's cap).

A simulated increase of 100% or more gives 25 points. Actual buybacks are split over 7 days, so real results differ. This figure compares candidates; it does not predict a price and must never be displayed as a promise (see Dapp display).

## 3. Selling pressure (20 points)

| Criterion | Points | Calculation |
| --- | --- | --- |
| Developer and insider holdings | 8 | `8 × clamp(1 − holdings / 5%)`; developer, linked wallets (funded by or funding the developer), launch wallets |
| Concentration | 6 | top 10 excluding pools, burn, and developer: `6` at ≤ 20%, `0` at ≥ 50%, linear between |
| Underwater holders | 6 | `6 × clamp(supply share held by wallets at −80% or worse / 0.7)` |

The source's rationale is that a holder down 90% may be less inclined to sell after an initial 50% rebound. This is a scoring assumption, not a guarantee of behavior. Each wallet's cost basis is calculated from its purchases (weighted average of token trades), excluding tokens received through transfers alone.

## 4. Project fundamentals (15 points)

| Criterion | Points | Calculation |
| --- | --- | --- |
| Documentation | 4 | `4` for online docs or a whitepaper; `2` if only the website is online |
| Code | 3 | `1` for a public GitHub repository; `+2` for at least 50 commits |
| X audience | 2 | `2 × clamp((log10(followers) − log10(1000)) / (log10(50000) − log10(1000)))` |
| Peak market cap | 3 | `3 × clamp((log10(peak market cap) − log10(500000)) / (log10(5000000) − log10(500000)))` |
| Timing | 3 | days since death (first day all Dead conditions held): `3` at 21–84 days, `1.5` at 14–20 or 85–180 days, `0` otherwise |

Timing rationale: too early, selling may still be ongoing; too late, the community may have moved on.

## 5. Flywheel (15 points)

| Criterion | Points | Calculation |
| --- | --- | --- |
| Creator tax | 10 | `10 × clamp(creator tax in bps / 300)` |
| Pons v2 | 5 | `5` for a Pons v2 token (official CTO and on-chain fee tracking) |

## Display tiers

| Score | Label | Color |
| --- | --- | --- |
| 75–100 | Strong recovery potential | Vivra orange |
| 50–74 | Recovery possible | ink |
| 0–49 | Difficult recovery | gray |

## Example

An illustrative Pons v2 tech project: $1.2M peak, $28k current market cap, 1,184 holders including 540 holding longer than 30 days, 9 new holders over 7 days, active Telegram but few X mentions, simulated buyback increase +62%, developer holdings 1.2%, top 10 at 28%, 55% of supply held at −80% or worse, online GitBook docs, GitHub repository with 140 commits, 6,200 followers, dead for 52 days, creator tax 2%.

| Pillar | Breakdown | Points |
| --- | --- | --- |
| Living community | 4.9 + 5.3 + 1.4 + 2 | 13.6 / 25 |
| Buyback impact | 25 × 0.62 | 15.5 / 25 |
| Selling pressure | 6.1 + 4.4 + 4.7 | 15.2 / 20 |
| Project fundamentals | 4 + 3 + 0.9 + 1.1 + 3 | 12.1 / 15 |
| Flywheel | 6.7 + 5 | 11.7 / 15 |
| **Score** | | **68: Recovery possible** |

## Required data

| Data | Source | Frequency |
| --- | --- | --- |
| Holders, holding age, new holders, concentration | token ERC-20 transfers, read during analysis | at analysis, then every 15 min during voting |
| Cost basis per wallet | token trades (curve and pool) | at analysis, then every 15 min during voting |
| Developer and linked wallets | funding trace (Appendix A, `dev_wallets`) | at analysis |
| Simulated increase | curve or v4 pool quote (read-only, no transaction) | at analysis, then every 15 min during voting |
| Telegram, X mentions, followers | X API and Telegram link | at analysis, then daily during voting |
| Docs, website, whitepaper, GitHub | HTTP requests and GitHub API | at analysis |
| Date of death | first day Dead conditions held, recomputed from history | at analysis |

## Parameters and storage

- All bounds and point values are in `settings` under `recovery.*`. A change creates a new `weights_version`; scores already frozen on published dossiers remain unchanged.
- Each calculation is written to `recovery_scores`, with raw value, ratio, and points for every criterion in `components`.
- Each candidate's score is frozen at cycle publication and displayed throughout voting; the live score appears beside it in a smaller format.
- Missing data earns 0 for its criterion and is labeled “not found.”
- The source names a pure function in `packages/core/recovery-score.ts`, tested with this example and edge cases (0 holders, missing data, out-of-range values). The inspected implementation is `packages/core/src/recoveryScore.ts`.

## Dapp display

- **Candidate dossier**: Recovery score block near the top, with a large score, tier label, and one expandable bar per pillar showing each criterion and raw value (“1,184 holders,” “55% of supply underwater,” etc.). A “How it is calculated” link points here.
- **Vote**: each candidate's score beside its name.
- **Back-office**: each analyzed project's score helps the team assemble the ballot.
- Label the simulated increase “estimated buyback impact on current liquidity,” never a price target.
- Notice below the block: “The score describes the project's state; it is not investment advice.”