# 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](etat-implementation.md) for the implemented verdict.