Token Scam Analysis Skill

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)