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