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). Filters determine who can enter; the score compares recovery potential.

The five pillars#

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)#

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

2. Buyback impact (25 points)#

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)#

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)#

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

5. Flywheel (15 points)#

Display tiers#

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%.

Required data#

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.”