token-integration-analyzer by trailofbits/skills
npx skills add https://github.com/trailofbits/skills --skill token-integration-analyzer使用 Trail of Bits 的代币集成检查清单,系统地分析代码库中与代币相关的安全问题:
框架:构建安全合约 - 代币集成检查清单 + 奇怪 ERC20 数据库
确定分析上下文:
对于 Solidity 项目,我将帮助运行:
slither-check-erc - ERC 合规性检查slither --print human-summary - 复杂性和升级分析slither --print contract-summary - 函数分析广告位招租
在这里展示您的产品或服务
触达数万 AI 开发者,精准高效
slither-prop - 用于测试的属性生成分析内容:
如果您提供合约地址,我将查询:
提供:
我检查涵盖代币安全所有方面的 10 个综合类别。有关详细标准、模式和检查清单,请参阅 ASSESSMENT_CATEGORIES.md。
分析完成后,您将收到一份结构如下的综合报告:
=== 代币集成分析报告 ===
项目:MultiToken DEX
分析的代币:自定义奖励代币 + 集成安全性
平台:Solidity 0.8.20
分析日期:2024年3月15日
---
## 执行摘要
代币类型:ERC20 实现 + 集成外部代币的协议
总体风险等级:中等
关键问题:2
高风险问题:3
中等风险问题:4
**主要关注点:**
⚠ 未正确处理转账费用代币
⚠ 缺少返回值验证(USDT 兼容性)
⚠ 所有者可以无限制铸造代币
**建议:** 在主网上线前解决关键/高风险问题。
---
## 1. 一般考虑事项
✓ 合约已由 CertiK 审计(2023年6月)
✓ 团队可通过 security@project.com 联系
✗ 没有用于关键公告的安全邮件列表
**风险:** 用户不会收到关键问题通知
**行动:** 设置 security@project.com 邮件列表
---
## 2. 合约组成
### 复杂性分析
**Slither human-summary 结果:**
- 456 行代码
- 圈复杂度:平均 6,最大 14(transferWithFee())
- 12 个函数,8 个状态变量
- 继承深度:3(中等)
✓ 合约复杂性合理
⚠ transferWithFee() 复杂度高(14)- 考虑拆分
### SafeMath 使用情况
✓ 使用 Solidity 0.8.20(内置溢出保护)
✓ 未发现未检查的块
✓ 所有算术操作都受到保护
### 非代币函数
**ERC20 之外的函数:**
- setFeeCollector() - 管理员函数 ✓
- setTransferFee() - 管理员函数 ✓
- withdrawFees() - 管理员函数 ✓
- pause()/unpause() - 紧急函数 ✓
⚠ 4 个非代币函数(可接受但增加了复杂性)
### 地址入口点
✓ 单一合约地址
✓ 没有具有多个入口点的代理
✓ 没有导致地址混淆的代币迁移
**状态:** 通过
---
## 3. 所有者权限
### 可升级性
⚠ 合约使用 TransparentUpgradeableProxy
**风险:** 所有者可以随时更改合约逻辑
**当前实现:**
- ProxyAdmin: 0x1234...(2/3 多重签名)✓
- 时间锁:无 ✗
**建议:** 为所有升级添加 48 小时时间锁
### 铸造能力
❌ 关键:无限铸造
文件:contracts/RewardToken.sol:89
```solidity
function mint(address to, uint256 amount) external onlyOwner {
_mint(to, amount); // 没有上限!
}
风险: 所有者可以任意增加供应量 修复: 添加最大供应量上限或限速铸造
✓ 已实现可暂停模式(OpenZeppelin) ✓ 只有所有者可以暂停 ⚠ 暂停状态影响所有转账(包括现有持有者)
风险: 所有者可以锁定所有用户资金 缓解措施: 对暂停函数使用多重签名(已实现 ✓)
✗ 无黑名单功能 评估: 良好 - 无中心化审查风险
✓ 团队成员公开(team.md) ✓ 公司在瑞士注册 ✓ 可问责且可联系
状态: 可接受
命令:slither-check-erc . RewardToken --erc erc20
✓ transfer 返回 bool ✓ transferFrom 返回 bool ✓ 存在 name、decimals、symbol ✓ decimals 返回 uint8(值:18) ✓ 竞态条件已缓解(increaseAllowance/decreaseAllowance)
状态: 完全合规
命令:slither-prop . --contract RewardToken
生成了 12 个属性,全部通过: ✓ 转账不会改变总供应量 ✓ 津贴正确更新 ✓ 余额更新与转账金额匹配 ✓ 无法进行余额操作 [... 还有 8 个属性 ...]
Echidna 模糊测试: 50,000 次运行,无违规 ✓
状态: 优秀
您的协议集成了 5 个外部代币:
❌ 模式 7.2:缺少返回值 发现于: USDT 集成 文件:contracts/Vault.sol:156
IERC20(usdt).transferFrom(msg.sender, address(this), amount);
// 没有返回值检查!USDT 不返回 bool
风险: USDT 转账时静默失败 利用: 用户看似已存款,但代币未移动 修复: 使用 OpenZeppelin SafeERC20 包装器
❌ 模式 7.3:转账费用 风险对象: 任何有转账费用的代币 文件:contracts/Vault.sol:170
uint256 balanceBefore = IERC20(token).balanceOf(address(this));
token.transferFrom(msg.sender, address(this), amount);
shares = amount * exchangeRate; // 错误!应使用实际接收金额
风险: 如果代币收取费用,会计不匹配 利用: 用户获得的份额多于存入的代币 修复: 根据 balanceAfter - balanceBefore 计算份额
✓ USDC: 正确处理(SafeERC20,考虑了 6 位小数) ⚠ DAI: 未使用 permit() 函数(节省 gas 的机会) ✗ USDT: 未处理缺少返回值(关键) ✓ WETH: 标准包装器,正确处理 ⚠ UNI: 未检查大额批准处理(>= 2^96 时回退)
[... 其余分析类别的附加部分 ...]
有关完整的报告模板和交付物格式,请参阅 [REPORT_TEMPLATES.md](resources/REPORT_TEMPLATES.md)。
---
## 合理化解释(请勿跳过)
| 合理化解释 | 为何错误 | 所需行动 |
|-----------------|----------------|-----------------|
| "代币看起来标准,ERC20 检查通过" | 除了 ERC20 合规性外,还存在 20 多种奇怪代币模式 | 检查数据库中的所有奇怪代币模式(缺少返回值、零值回退、钩子等) |
| "Slither 显示无问题,集成安全" | Slither 检测到一些模式,但会遗漏集成逻辑 | 对所有 5 个代币集成标准进行完整的手动分析 |
| "未检测到转账费用,跳过该检查" | 转账费用可能由所有者控制或有条件触发 | 测试所有转账场景,检查条件性费用逻辑 |
| "存在余额检查,处理安全" | 仅凭余额检查无法防范所有奇怪代币 | 验证安全转账包装器、回退处理、批准模式 |
| "代币由信誉良好的团队部署,假设为标准" | 信誉不能保证标准行为 | 分析实际代码和链上行为,不要信任假设 |
| "集成使用 OpenZeppelin,一定安全" | OpenZeppelin 库无法防范奇怪的外部代币 | 验证所有外部代币调用周围的防御性模式 |
| "无法运行 Slither,跳过自动化分析" | Slither 提供关键的 ERC 合规性检查 | 手动验证所有 slither-check-erc 标准或记录受阻原因 |
| "这种模式看起来没问题" | 直觉会忽略微妙的代币集成错误 | 用代码证据系统地检查所有 20 多种奇怪代币模式 |
---
## 交付物
分析完成后,我将提供:
1. **合规性检查清单** - 所有评估类别的复选框
2. **奇怪代币模式分析** - 所有 24 种模式的存在/不存在情况,附带风险等级和证据
3. **链上分析报告**(如适用) - 持有者分布、交易所上市情况、配置
4. **集成安全评估**(如适用) - 安全转账使用情况、防御性模式、奇怪代币处理
5. **优先级建议** - 关键/高/中/低风险问题及具体修复方案
完整的交付物模板可在 [REPORT_TEMPLATES.md](resources/REPORT_TEMPLATES.md) 中找到。
---
## 准备开始
**我需要:**
- 您的代码库
- 上下文:代币实现还是集成?
- 代币类型:ERC20、ERC721 还是两者兼有?
- 合约地址(如果已部署并需要链上分析)
- RPC 端点(如果需要查询链上数据)
让我们分析您的代币实现或集成中的安全风险!
每周安装
1.2K
仓库
GitHub 星标
3.9K
首次出现
Jan 19, 2026
安全审计
安装于
claude-code1.1K
codex1.0K
opencode951
gemini-cli936
cursor904
github-copilot874
Systematically analyzes the codebase for token-related security concerns using Trail of Bits' token integration checklist:
Framework : Building Secure Contracts - Token Integration Checklist + Weird ERC20 Database
Determines analysis context:
For Solidity projects, I'll help run:
slither-check-erc - ERC conformity checksslither --print human-summary - Complexity and upgrade analysisslither --print contract-summary - Function analysisslither-prop - Property generation for testingAnalyzes:
If you provide a contract address, I'll query:
Provides:
I check 10 comprehensive categories covering all aspects of token security. For detailed criteria, patterns, and checklists, see ASSESSMENT_CATEGORIES.md.
When analysis is complete, you'll receive a comprehensive report structured as follows:
=== TOKEN INTEGRATION ANALYSIS REPORT ===
Project: MultiToken DEX
Token Analyzed: Custom Reward Token + Integration Safety
Platform: Solidity 0.8.20
Analysis Date: March 15, 2024
---
## EXECUTIVE SUMMARY
Token Type: ERC20 Implementation + Protocol Integrating External Tokens
Overall Risk Level: MEDIUM
Critical Issues: 2
High Issues: 3
Medium Issues: 4
**Top Concerns:**
⚠ Fee-on-transfer tokens not handled correctly
⚠ No validation for missing return values (USDT compatibility)
⚠ Owner can mint unlimited tokens without cap
**Recommendation:** Address critical/high issues before mainnet launch.
---
## 1. GENERAL CONSIDERATIONS
✓ Contract audited by CertiK (June 2023)
✓ Team contactable via security@project.com
✗ No security mailing list for critical announcements
**Risk:** Users won't be notified of critical issues
**Action:** Set up security@project.com mailing list
---
## 2. CONTRACT COMPOSITION
### Complexity Analysis
**Slither human-summary Results:**
- 456 lines of code
- Cyclomatic complexity: Average 6, Max 14 (transferWithFee())
- 12 functions, 8 state variables
- Inheritance depth: 3 (moderate)
✓ Contract complexity is reasonable
⚠ transferWithFee() complexity high (14) - consider splitting
### SafeMath Usage
✓ Using Solidity 0.8.20 (built-in overflow protection)
✓ No unchecked blocks found
✓ All arithmetic operations protected
### Non-Token Functions
**Functions Beyond ERC20:**
- setFeeCollector() - Admin function ✓
- setTransferFee() - Admin function ✓
- withdrawFees() - Admin function ✓
- pause()/unpause() - Emergency functions ✓
⚠ 4 non-token functions (acceptable but adds complexity)
### Address Entry Points
✓ Single contract address
✓ No proxy with multiple entry points
✓ No token migration creating address confusion
**Status:** PASS
---
## 3. OWNER PRIVILEGES
### Upgradeability
⚠ Contract uses TransparentUpgradeableProxy
**Risk:** Owner can change contract logic at any time
**Current Implementation:**
- ProxyAdmin: 0x1234... (2/3 multisig) ✓
- Timelock: None ✗
**Recommendation:** Add 48-hour timelock to all upgrades
### Minting Capabilities
❌ CRITICAL: Unlimited minting
File: contracts/RewardToken.sol:89
```solidity
function mint(address to, uint256 amount) external onlyOwner {
_mint(to, amount); // No cap!
}
Risk: Owner can inflate supply arbitrarily Fix: Add maximum supply cap or rate-limited minting
✓ Pausable pattern implemented (OpenZeppelin) ✓ Only owner can pause ⚠ Paused state affects all transfers (including existing holders)
Risk: Owner can trap all user funds Mitigation: Use multi-sig for pause function (already implemented ✓)
✗ No blacklist functionality Assessment: Good - no centralized censorship risk
✓ Team members public (team.md) ✓ Company registered in Switzerland ✓ Accountable and contactable
Status: ACCEPTABLE
Command: slither-check-erc . RewardToken --erc erc20
✓ transfer returns bool ✓ transferFrom returns bool ✓ name, decimals, symbol present ✓ decimals returns uint8 (value: 18) ✓ Race condition mitigated (increaseAllowance/decreaseAllowance)
Status: FULLY COMPLIANT
Command: slither-prop . --contract RewardToken
Generated 12 properties, all passed: ✓ Transfer doesn't change total supply ✓ Allowance correctly updates ✓ Balance updates match transfer amounts ✓ No balance manipulation possible [... 8 more properties ...]
Echidna fuzzing: 50,000 runs, no violations ✓
Status: EXCELLENT
Your Protocol Integrates 5 External Tokens:
❌ Pattern 7.2: Missing Return Values Found in: USDT integration File: contracts/Vault.sol:156
IERC20(usdt).transferFrom(msg.sender, address(this), amount);
// No return value check! USDT doesn't return bool
Risk: Silent failures on USDT transfers Exploit: User appears to deposit, but no tokens moved Fix: Use OpenZeppelin SafeERC20 wrapper
❌ Pattern 7.3: Fee on Transfer Risk for: Any token with transfer fees File: contracts/Vault.sol:170
uint256 balanceBefore = IERC20(token).balanceOf(address(this));
token.transferFrom(msg.sender, address(this), amount);
shares = amount * exchangeRate; // WRONG! Should use actual received amount
Risk: Accounting mismatch if token takes fees Exploit: User credited more shares than tokens deposited Fix: Calculate shares from balanceAfter - balanceBefore
✓ USDC: Properly handled (SafeERC20, 6 decimals accounted for) ⚠ DAI: permit() function not used (opportunity for gas savings) ✗ USDT: Missing return value not handled (CRITICAL) ✓ WETH: Standard wrapper, properly handled ⚠ UNI: Large approval handling not checked (reverts >= 2^96)
[... Additional sections for remaining analysis categories ...]
For complete report template and deliverables format, see [REPORT_TEMPLATES.md](resources/REPORT_TEMPLATES.md).
---
## Rationalizations (Do Not Skip)
| Rationalization | Why It's Wrong | Required Action |
|-----------------|----------------|-----------------|
| "Token looks standard, ERC20 checks pass" | 20+ weird token patterns exist beyond ERC20 compliance | Check ALL weird token patterns from database (missing return, revert on zero, hooks, etc.) |
| "Slither shows no issues, integration is safe" | Slither detects some patterns, misses integration logic | Complete manual analysis of all 5 token integration criteria |
| "No fee-on-transfer detected, skip that check" | Fee-on-transfer can be owner-controlled or conditional | Test all transfer scenarios, check for conditional fee logic |
| "Balance checks exist, handling is safe" | Balance checks alone don't protect against all weird tokens | Verify safe transfer wrappers, revert handling, approval patterns |
| "Token is deployed by reputable team, assume standard" | Reputation doesn't guarantee standard behavior | Analyze actual code and on-chain behavior, don't trust assumptions |
| "Integration uses OpenZeppelin, must be safe" | OpenZeppelin libraries don't protect against weird external tokens | Verify defensive patterns around all external token calls |
| "Can't run Slither, skipping automated analysis" | Slither provides critical ERC conformance checks | Manually verify all slither-check-erc criteria or document why blocked |
| "This pattern seems fine" | Intuition misses subtle token integration bugs | Systematically check all 20+ weird token patterns with code evidence |
---
## Deliverables
When analysis is complete, I'll provide:
1. **Compliance Checklist** - Checkboxes for all assessment categories
2. **Weird Token Pattern Analysis** - Presence/absence of all 24 patterns with risk levels and evidence
3. **On-chain Analysis Report** (if applicable) - Holder distribution, exchange listings, configuration
4. **Integration Safety Assessment** (if applicable) - Safe transfer usage, defensive patterns, weird token handling
5. **Prioritized Recommendations** - CRITICAL/HIGH/MEDIUM/LOW issues with specific fixes
Complete deliverable templates available in [REPORT_TEMPLATES.md](resources/REPORT_TEMPLATES.md).
---
## Ready to Begin
**What I'll need**:
- Your codebase
- Context: Token implementation or integration?
- Token type: ERC20, ERC721, or both?
- Contract address (if deployed and want on-chain analysis)
- RPC endpoint (if querying on-chain)
Let's analyze your token implementation or integration for security risks!
Weekly Installs
1.2K
Repository
GitHub Stars
3.9K
First Seen
Jan 19, 2026
Security Audits
Gen Agent Trust HubPassSocketPassSnykWarn
Installed on
claude-code1.1K
codex1.0K
opencode951
gemini-cli936
cursor904
github-copilot874
React 组合模式指南:Vercel 组件架构最佳实践,提升代码可维护性
102,200 周安装