openclaw/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