Scanner: the on-chain analyst

Mission: explain why the token died, determine whether it is safe for a CTO, and write each candidate's dossier.

Reads: contract, transactions, holders, pools, socials (X, Telegram, website, docs, GitHub), for the address submitted by the team only.

Steps:

1. Day −3: pre-report on each of the 5 candidates (thesis, timeline, 6 checks), published on the dapp's candidate page.
2. T+0: full report on the winner: developer and insider wallets, supply share, developer sales, liquidity, latest social activity.
3. T+0: go / no-go verdict. A no-go (large developer holdings, dangerous contract function, withdrawable liquidity) blocks the operation and alerts the team.
4. Daily during the buyback: record holders, volume, and price for the CM and ledger.
5. Day 7: final Revived or Dead again verdict, with before / after figures.

Delivers: token dossier (JSON), dapp Report page, and a five-line summary for the CM.

Must not: change a token's status without approval or recommend buying a token.

Use cases:

• UC-AG-01 · Developer still holds tokens: the developer holds 8% of supply. The Scanner highlights this in red and flags the candidate as at risk; the team decides whether to keep it.
• UC-AG-02 · Malicious contract: the owner can block transfers. No-go verdict; the candidate is removed before voting, and the dapp explains why.
• UC-AG-03 · Closing report: on Day 7, holders ×1.6 and volume ×3. The original example labels this Revived and sends figures to the CM for the verdict post. Source inconsistency: this example does not meet the default ×5 volume threshold; use the rules in Implementation status for the implemented verdict.