Project analysis on demand
Vivra does not scan the entire blockchain. The team finds dead projects and submits their addresses. The Scanner analyzes only those tokens, and only projects approved by the team appear in the dapp.
There is no indexer continuously reading every Pons launch: that would incur RPC and storage costs for thousands of tokens that will never be taken over.
The flow#
- The team submits an address in the back-office: contract address, optionally with known X, Telegram, docs, or GitHub links.
- The Scanner analyzes it within a few minutes, for that token only: on-chain data, Vivra target, safety rules, socials and docs, recovery score, and a draft dossier (thesis, timeline, risks).
- The team reviews the analysis in the back-office and chooses:
- Approve: the project enters the candidate reserve, ready for a ballot;
- Reject: it remains in the database with a reason, invisible in the dapp, and is not reanalyzed unless requested;
- Rerun analysis: for example, after adding a missing link.
- Publication: when assembling a cycle, the team selects 5 approved projects. Their dossiers become public when the cycle is published, not before.
Analysis can be rerun at any time. Market figures refresh immediately before cycle publication, then the score is frozen for voting.
What the Scanner reads for one token#
| Data | Source | Cost |
|---|---|---|
| Contract: minting, ability to sell, owner, owner functions | bytecode reads and simulated calls (RPC) | a few calls |
| Pons version, state (curve or graduated), pool, creator tax, fee recipient | Pons v2 factory and hook reads (RPC) | a few calls |
| Holders, holding age, new holders, concentration, cost basis | Transfer events and trades for this token only, from its launch block (eth_getLogs filtered by address), or Robinhood Chain explorer API if supported | one history read per analysis |
| Price, market cap, high, volume | trades from the same history, optionally Bitquery's Pons API | included |
| Developer and linked wallets | creator wallet transactions, two levels deep | a few calls |
| Simulated buyback price impact | curve or v4 pool quote (read-only, no transaction) | 1 call |
| X account: existence, last tweet, followers | X API for this account only | 1–2 calls |
| Project profile picture and banner | X API images, copied into Vivra object storage to avoid relying on X URLs | 1 call |
| Docs, whitepaper, website, GitHub | HTTP requests and GitHub API | a few calls |
| Telegram | member count through the public link; activity only when a Vivra bot is in the group | 1 call |
Verify at milestone M1 that eth_getLogs over a token's full history stays within Alchemy's block-range limit; otherwise split requests into block ranges.
Planned update, Vivra Scout: infrastructure that monitors the entire chain and automatically proposes dead projects matching the target. V1 does without it: the team finds projects and submits addresses.
Dead status#
A token is Dead when three conditions hold: average volume below $1,000 per day over 7 days, price down at least 85% from its high, and developer inactivity for 14 days (no creator-wallet transaction). The Scanner checks this during analysis; a submitted token that is not Dead is flagged for the team to decide.
Vivra's target#
Vivra takes over legitimate tech projects that actually existed, not disposable memes: a product, documentation, and an X account still online. The project had traction, fell back, and its team stopped posting, but the foundations for a takeover remain.
| Rule | Default threshold | Source |
|---|---|---|
| All-time-high market cap | $500,000 or more | trade history |
| Current market cap | $15,000–$50,000 | latest snapshot |
| Project X account | still exists, neither deleted nor suspended | X API |
| X silence | no project-account tweet for at least 30 days | X API |
| Accessible documentation | at least one online source: docs (GitBook, Notion, docs subdomain), whitepaper, GitHub repository, or live website | HTTP check, then team review |
| Tech project | a product, protocol, or tool described in the docs, not just a meme | proposed by Scanner, confirmed by team |
Safety rules#
| Rule | Threshold | Blocking |
|---|---|---|
| Holders with a real balance | more than 300 | yes |
| Mint function | none | yes |
| Selling possible | yes | yes |
| Liquidity | locked Uniswap v4 pool (graduated Pons v2 token), or still on the curve | yes |
| Developer and linked-wallet holdings | less than 5% | yes |
| Pons version | preferably v2 | no; contributes to recovery score |
| Creator tax | above 0% | no; contributes to recovery score |
Each rule's result appears in the back-office: green, red, or “not found.” A failed blocking rule does not prevent a team override, but the team must explain why, and the public dossier displays the failed rule.
Thresholds are database parameters that can be changed in the back-office without redeployment.
Tracking after approval#
Only relevant tokens are continuously tracked, keeping infrastructure small:
| Tracked tokens | Frequency | Purpose |
|---|---|---|
| The 5 candidates in the current vote | every 15 min | live market data in dossiers |
| CTO token during its operation (72 h, buyback, verdict) | live, from pool or curve events | war room, chart, slices |
| Tokens taken over, through Day 30 | hourly | follow-up, verdict, handover |
| Tokens whose fees go to Vivra | daily | fee ledger from escrow Credited events |
| Everything else | never |
In practice, the specification expects fewer than 10 tokens tracked at once.
Token lifecycle#
| From | To | Trigger |
|---|---|---|
| (submitted) | Analyzed | Scanner finishes analysis |
| Analyzed | Approved | team approves |
| Analyzed | Rejected | team rejects with a reason |
| Approved | Candidate | team adds it to a ballot |
| Candidate | CTO live | wins the vote |
| Candidate | Approved | loses the vote; can return on a later ballot |
| CTO live | Sending | after 72 h, if volume or holders exceed starting thresholds |
| CTO live or Sending | Revived | positive Day 7 verdict (open questions, decision 9) |
| CTO live or Sending | Dead again | negative Day 7 verdict |
API#
Inputs, outputs, and errors for each route: Appendix B · API.
GET /candidates/:id: public dossier of a published candidate.GET /stats: landing figures (takeovers, revived, $VIVRA burned).POST /admin/projects: submit an address for analysis (team).GET /admin/projects,POST /admin/projects/:address/review: review, approve, or reject (team).
Sign-in and voting:
POST /auth/email: send a magic link or six-digit code; reject disposable emails.POST /auth/verify: verify the code or link and open a 30-day session.GET /cycles/current: current cycle, candidates, times, vote shares.POST /votes: vote or change a vote in the current cycle.POST /supports: support a candidate.GET /operations/:idand a WebSocket channel: CTO steps, log, and slices.
Acceptance criteria#
- A testnet address submission produces a full analysis (target, safety, socials, score, draft dossier) in under 10 minutes.
- Results for 10 analyzed tokens are manually checked against the explorer.
- A rejected token appears nowhere in the dapp or public API.
- No job reads launches or trades of tokens that are neither candidates nor taken over.