Cycles, candidates, and voting
A new cycle starts every week: 5 published dossiers, a 48-hour vote, then the winner's operation begins within one minute of closing. Everything is managed through a team-only back-office.
At launch, the first 5 dossiers are published alongside $VIVRA and voting opens immediately. Each following week, candidates that were not elected can remain on the next ballot, with the team adding enough to reach 5.
Overlap: a CTO token's buyback (7 days) and follow-up (30 days) continue while the next token's vote and operation run. The orchestrator, Buyback Bot, and dapp must handle multiple active CTO tokens: up to 2 buybacks and 5 follow-ups in parallel.
Cycle back-office#
- Create a cycle: number, dossier publication date, vote opening and closing times.
- Choose 5 candidates from projects submitted, analyzed, and approved by the team (Project analysis).
- The Scanner generates a pre-report for each of the 5 candidates (section 6), reviewed by the team.
- Write each dossier's thesis and plan, then publish all 5 together.
- Voting opens automatically at the scheduled time.
- At closing, results are calculated and published, and the winner's operation is created.
Back-office access uses a signature from an allowlisted team wallet, with an action audit log.
Candidate dossier contents#
| Block | Fields | Source |
|---|---|---|
| Header | project profile picture and banner (from X), ticker, name, category, tagline, Pons version, state (graduated or curve), contract address | project analysis, written tagline |
| Recovery score | score out of 100, tier, 5 pillars and their criteria, frozen at publication (Appendix E) | calculated during analysis |
| Why we chose it | one-sentence thesis, one paragraph, 3 reasons | written by team |
| Scanner report | analysis, 6 checks (mint, selling, liquidity, developer holdings, owner functions, top 10) | agent, reviewed |
| How it died | 4–6 key dates | agent, reviewed |
| Operation plan | identity, website, utility, X, Telegram | written by team |
| Risks | 1–3 risks | written by team |
| Market | market cap, liquidity, 24 h and 7-day volume, high, drawdown, holders, 30-day holders, developer holdings, creator tax | candidate tracking every 15 min |
| Socials | clickable X, Telegram, website, docs, GitHub, and chart buttons, each with metric and status; disabled when unavailable | project analysis |
| After the CTO | creator fees per trade, buyback cap, fee allocation | calculated |
Email voting, without a wallet#
- Sign-in: email with a magic link or six-digit code. No wallet or password.
- One vote per verified email per cycle. Voters can switch candidates until closing.
- Anti-fraud: disposable domains blocked, account limits per IP and device, invisible signup captcha, minimum delay between signup and first vote (24 h, configurable). This delay does not apply to cycle 1: voting opens at launch and everyone is new.
- Exclusions: team accounts cannot vote.
- Tie: the candidate with more supports (below) wins.
- Transparency: per-candidate totals and voter count are public. Email addresses are never published.
Without a wallet, voting is not tied to $VIVRA ownership. A possible later feature would voluntarily link a wallet for extra voting weight.
Community support#
An email-authenticated visitor can click “I support $TICKER” on a candidate dossier. The count appears on the dossier and is used only to break a tie. Support does not prove token ownership.
Acceptance criteria#
- A complete testnet cycle: publication, vote, closing, result, operation creation, with no manual intervention after publication.
- The public tally matches votes stored in the database.
- A vote after closing, from a disposable email, or from a team account is rejected.