onchain-contract-token-analysis

# Onchain Contract / Token Analysis

Use this skill when the task is to assess a token, protocol, launch module, vault, staking system, router, or related onchain project from a security, permissions, tokenomics, or behavior perspective.

## Core objective

Produce a practical analysis that answers:

- What the system does
- Who controls it
- How value and fees move
- What privileged actions exist
- What users can lose money from
- Whether there are obvious red flags or design risks

## Workflow

### 1. Identify the scope

First determine which of these the request actually targets:

- token contract
- factory / launcher
- vault / staking / locker
- router / hook / proxy / module
- admin / governance / registry
- full protocol system

If the scope is unclear, infer it from the files, addresses, ABI names, deployment scripts, or docs.

### 2. Map the architecture

Before judging risk, build a compact model of the system:

- main contracts
- ownership / admin roles
- external dependencies
- upgradeability pattern
- event flow
- token creation flow
- fee routing flow

Prefer a short system map over long prose.

### 3. Check control and permissions

Always verify:

- `owner`, `admin`, `governor`, `operator`, `manager`, `signer`
- role-based access control
- pausable / blacklist / whitelist powers
- mint / burn / seize / rescue / withdraw permissions
- parameter setters
- upgrade authority
- emergency functions

Call out who can do what, and whether those powers are bounded or dangerous.

### 4. Check token mechanics

For ERC-20 and tokenized systems, verify:

- total supply model
- mintability
- burnability
- transfer restrictions
- fee on transfer / tax
- max wallet / max tx rules
- trading enable switch
- blacklist / antibot logic
- rebasing / reflection / hidden balance logic
- allowance edge cases

If the token claims to be standard, confirm whether behavior actually matches that claim.

### 5. Check fee and value flow

Trace where user funds or protocol fees go:

- LP fee recipients
- treasury recipients
- locker / vault recipients
- protocol fee splits
- conversion / swap path
- withdrawal path
- claim path

Do not just name recipients. Explain whether they are:

- immutable
- admin-changeable
- delayed
- claim-based
- dependent on offchain identity or signatures

### 6. Check upgradeability and mutability

If proxies or modules exist, verify:

- proxy type
- implementation admin
- initialization safety
- reinitialization protection
- storage layout assumptions
- upgrade trust model

If not upgradeable, still check whether behavior can change through configurable modules.

### 7. Check attack surface

Look for:

- arbitrary external calls
- reentrancy opportunities
- unchecked token callbacks
- unsafe approvals
- signature replay
- missing nonce / deadline checks
- address(0) edge cases
- misconfigured recipient logic
- accounting mismatch
- stale state after recipient updates
- rounding leakage
- griefing / denial-of-service vectors

When risk depends on business assumptions, state that explicitly.

### 8. Check market-facing risk

When the target is a token or launch flow, explicitly assess:

- honeypot-like behavior
- sell restrictions
- hidden tax changes
- admin ability to freeze exits
- liquidity custody
- locker guarantees
- whether front-end labels could misclassify the asset

Do not overclaim. Distinguish:

- confirmed malicious logic
- dangerous centralization
- poor design
- heuristic / market-behavior false positives

## Output format

Default to this structure:

### Summary

One short paragraph stating what the system is and the top conclusion.

### Findings

List issues in severity order:

- severity
- title
- affected contract / function
- why it matters
- exploit or failure mode
- whether it is confirmed or conditional

### Trust model

State:

- who controls upgrades
- who controls fees
- who controls pauses or restrictions
- what users must trust offchain

### Token / fee flow

Explain:

- how tokens are created
- where fees accrue
- who can claim them
- what can change later

### Open questions

List anything blocked by missing source, missing ABI, missing deployment info, or offchain dependencies.

## Special guidance

### When reviewing a suspicious token

Be precise:

- "can blacklist holders" is stronger than "looks risky"
- "owner can change tax" is stronger than "may be a scam"
- "no onchain sell restriction found" is stronger than "not a honeypot"

### When reviewing a launch module

Always distinguish:

- launcher logic
- underlying token implementation
- LP locker behavior
- fee locker behavior
- who receives economic rights

### When chain data is required

If the task depends on live state, verify with current chain or explorer data instead of assuming from source alone.

## Do not

- Do not call something malicious without code-based support
- Do not confuse admin centralization with exploitability
- Do not ignore offchain identity dependencies when they control payouts
- Do not stop at contract syntax; trace actual economic outcomes