什么是 链上合约与代币分析？

链上合约与代币分析技能为评估去中心化项目提供了一个系统化的框架。它超越了简单的语法检查，执行深度的架构映射、权限审计和经济流向追踪。通过利用 Openclaw Skills，开发者和分析师可以在部署或交互之前，发现 ERC-20 代币、DeFi 金库和复杂协议模块中隐藏的风险。

此技能旨在回答有关系统控制、价值移动和用户安全的关键问题。它弥合了原始代码分析与实际经济评估之间的鸿沟，确保每一个特权操作和潜在攻击面都得到记录和理解。

下载入口:https://github.com/openclaw/skills/tree/main/skills/0xrowan/onchain-contract-tokens

安装与下载

1. ClawHub CLI

从源直接安装技能的最快方式。

2. 手动安装

将技能文件夹复制到以下位置之一

优先级：工作区 > 本地 > 内置

3. 提示词安装

将此提示词复制到 OpenClaw 即可自动安装。

链上合约与代币分析 应用场景

• 审查 ERC-20 代币合约是否存在蜜罐逻辑或隐藏税收。
• 审计 DeFi 协议中的权限系统和基于角色的访问控制。
• 分析启动平台中的费用分配机制和国库路由。
• 验证升级模式和 proxy 实现的安全性。
• 评估新链上项目的市场风险和流动性锁定保证。

1. 确定项目范围，从单个代币合约到完整的协议系统和管理注册表。
2. 映射技术架构，识别主要合约、所有权角色和外部依赖项。
3. 验证控制权限，特别寻找如铸造、扣押或紧急暂停等危险权力。
4. 分析代币机制，如供应模型、转账限制和隐藏余额逻辑。
5. 追踪费用和价值流向，以准确识别用户资金和协议收入的积累位置。
6. 评估升级风险，检查常见的攻击面，如重入、签名重放或不安全的授权。
7. 评估面向市场的风险，区分恶意逻辑与设计缺陷。

链上合约与代币分析 配置指南

此技能是 Openclaw Skills 库的一部分，已准备好在兼容的 AI 代理环境中使用。要集成此分析功能，请确保您的代理可以访问技能定义和必要的区块链数据提供商。

# 该技能通常通过提供合约地址或源代码来调用
/skill onchain-contract-token-analysis --target [contract_address_or_file]

链上合约与代币分析 数据架构与分类体系

该技能生成一份涵盖目标合约几个关键维度的结构化分析报告。

name: onchain-contract-token-analysis
description: Analyze smart contracts, token mechanics, permissions, fee flows, upgradeability, market risks, and likely attack surfaces for onchain projects. Use when reviewing ERC-20s, launchpads, vaults, staking systems, LP fee routing, ownership controls, proxy setups, or suspicious token behavior.
user-invocable: true
metadata: {"openclaw":{"emoji":"??","skillKey":"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