token-scam-analysis

What this skill does

# Token Scam Analysis Skill

You are performing a forensic on-chain analysis to determine whether a token (or set of tokens) is a scam, rug-pull, or soft-rug. The output is a written report saved to the user's file storage plus a verdict in chat.

## When to use this skill
- User gives one or more token contract addresses and asks for a risk assessment.
- User mentions a "migration" / "redeploy" / "new contract" narrative.
- User names a Twitter/X handle of the project and wants to cross-reference claims vs on-chain reality.
- Comparing old vs new contracts from the same team.

## Core principle
Narrative is noise. On-chain state is signal. Every claim the team makes should be checked against what the contract and the deployer's wallet actually did. If the two conflict, the chain wins.

**BUT: on-chain cleanliness ≠ not a scam.** A team can deploy a perfectly clean LayerZero OFT or ERC-20, hand it to a multisig, and still run a textbook insider pump-and-dump via CEX coordination and concentrated supply. You MUST always run the off-chain intel pass (Step Final-1) before issuing a verdict, or you will under-call real manipulation cases.

---

## Step 0 — Read the platform's deploy docs BEFORE judging tokenomics claims
Before making any claim about what a team "could not" or "should have" configured, read the deployment docs for the launch platform. Otherwise you will miss capabilities and bait on the team's narrative. Identify the platform by looking at the `allData()` `context` field (e.g., `"interface":"clanker.world"`), the deploy factory address, or the token ABI (`admin/originalAdmin/allData/isVerified` is Clanker-style).

Priority reads by platform:

- **Clanker v4** (`allData()` context = `clanker.world`, factory `0xe85a59c628f7d27878aceb4bf3b35733630083a9`):
  - https://clanker.gitbook.io/clanker-documentation/general/token-deployments  — overview: 100B ERC-20, extensions up to 90% of supply.
  - https://clanker.gitbook.io/clanker-documentation/authenticated/deploy-token-v4.0.0  — full deploy payload (vault, airdrop, fees, up to 7 reward recipients, pool config).
  - https://clanker.gitbook.io/clanker-documentation/references/core-contracts/v4  — ClankerVault / Airdrop extension internals.
  - What you MUST know before judging:
    - Tokenomics (allocations, lockups, vesting, multiple reward splits, custom paired token, initial market cap, static/dynamic fees) are set in the **deploy payload**. A team cannot say "we had to redeploy because we couldn't configure tokenomics" — Clanker v4 supports all of that in one transaction.
    - Min vault lockup 7 days, min airdrop lockup 1 day.
    - Max 90% of supply across all extensions (rest goes to LP).
    - Token bytecode being identical across deploys is **expected** (it's a factory template) — do not use bytecode-sameness as a red flag by itself. Configuration differences live in the deploy payload, not in the token runtime code.
- **Bankr / Doppler / Scheduled Multicurve**: deployer beneficiary shares, no migration, locked pool, 95/5 fee split.
- **Zora / Virtuals / Pump.fun**: platform-specific, look for official docs via `search_tool`.
- **LayerZero OFT multichain tokens** (source has `import "@layerzerolabs/oft-evm/contracts/OFT.sol"` and `peers(uint32)`, `setPeer`, `send`, `setEnforcedOptions`): standard multichain pattern. `setPeer` by owner is the main live admin power — if signers collude they can add a malicious peer chain and mint via `_credit`. Existing peers matching across chain explorers = legit bridge config. LZ V2 endpoint on Base: `0x1a44076050125825900e736c501f859c50fE728c`.

**Save this step to your report.** The "Claim vs reality" section needs to quote a specific docs capability the team *could* have used and chose not to.

---

## Tool map (roughly in order of use)

1. **`token_search`** (identifier_type=address, chain=...) — baseline market data: price, mcap, volume, 24h change, holder count, security scan flag. Set include_chart=false, include_market_data_image=false to keep context lean.
2. **`get_token_launch_info`** — if the token was deployed via Bankr/Doppler, you get the deployer wallet + twitter handle + tweet URL for free. Always try this first even if you think it's Clanker; the tool returns cleanly on non-match.
3. **`get_contract_abi`** (chain=...) — confirm the address is a real contract and enumerate read/write functions. Flag dangerous functions: `mint`, `crosschainMint`, `setOwner`, `updateAdmin`, `blacklist`, `setFee`, `pause`, `updateImage`, `updateMetadata`. For OFTs, note `setPeer` / `setEnforcedOptions` — these are owner-gated but not exit-scam primitives by themselves.
4. **`read_contract`** for on-chain state. For Clanker v4 tokens:
   - `totalSupply() view returns (uint256)` — expect 100_000_000_000 * 10^18.
   - `allData() view returns (address originalAdmin, address admin, string image, string metadata, string context)` — the single richest read. Tells you deployer admin, current admin (if different = admin handoff happened), whether metadata/socials/audits are populated, and which interface launched it (`clanker.world`, Farcaster, etc.).
   - `isVerified() view returns (bool)` — Clanker's own verification flag.
   - `balanceOf(address) view returns (uint256)` — for any wallet you want to check (admin, top holders, pool manager).
   For OFTs: `owner()`, `peers(uint32)` for each known eid (Ethereum=30101, BSC=30102, Arbitrum=30110, Base=30184, Polygon=30109, Optimism=30111), `endpoint()`, `msgInspector()`, `preCrime()`.
5. **`get_clanker_reward_ownership`** (tokenAddress, chain) — returns every reward recipient/admin slot for the token. **This is the single best signal for "did the team actually allocate ecosystem/marketing/CEX rewards like they claim"** — if it shows only one `{admin, recipient}` both equal to the deployer, the team did NOT configure multi-recipient tokenomics.
6. **Direct viem reads via `execute_cli`** when you need to batch-check balances, detect contract vs EOA (top holders with 48-byte bytecode are AA smart-wallet sniper proxies, not whales), or compute concentration. Install `[email protected]` and run a small `analyze.mjs`.

   **RPC configuration (custom env var is OPTIONAL):**
   - First, call `get_env_vars` to check if the user has set a custom RPC var for the chain you're analyzing (`BASE_RPC_URL`, `MAINNET_RPC_URL`, `ARBITRUM_RPC_URL`, etc.). If present, use it — it's almost always higher-rate-limit.
   - If no custom var is set, **fall back to viem's built-in public RPC** by creating the client with just the chain (no custom `transport` URL). Example:
     ```js
     import { createPublicClient, http } from 'viem';
     import { base } from 'viem/chains';
     const rpcUrl = process.env.BASE_RPC_URL; // may be undefined
     const client = createPublicClient({
       chain: base,
       transport: rpcUrl ? http(rpcUrl) : http(), // http() with no arg uses chain.rpcUrls.default
     });
     ```
     This works for `base`, `mainnet`, `arbitrum`, `optimism`, `polygon`, `bnb`, `unichain`, etc. out of the box.
   - The public RPCs are rate-limited and can be flaky under load. If you see `429` / timeouts when batching many reads, either (a) add small delays between calls, (b) chunk the reads, or (c) tell the user at the end of the report that a custom RPC env var would make re-runs faster and more reliable — don't block the analysis on it.

   Always use this viem step to:
   - Cross-check `totalSupply`, `admin`, `originalAdmin`, `isVerified`, `allData` from the RPC directly (don't trust only indexer outputs).
   - `getBalance` + `getTransactionCount` for each deployer and the claimed Twitter wallet.
   - `getBytecode` on each top non-pool holder — 48 bytes = EIP-7702 / minimal-proxy smart wallet (sniper pattern); >100 bytes = real contract (could be Clanker vault/airdrop extension, or a Gnosis Safe); no code = regular EOA.
   - For Safe multisigs: Safe contracts have a known bytecode prefix and a `VERSION()` / `getOwners()` fun