token-integration-analyzer

代币集成分析器

用途

使用 Trail of Bits 的代币集成检查清单，系统分析代码库中的代币相关安全问题：

1. 代币实现：分析代币是否遵循 ERC20/ERC721 标准，或是否存在非标准行为
2. 代币集成：分析协议如何处理任意代币，包括特殊的非标准代币
3. 链上分析：查询已部署合约的稀缺性、分布和配置
4. 安全评估：识别 20 多种已知特殊代币模式所带来的风险

框架：构建安全合约——代币集成检查清单 + 特殊 ERC20 数据库

---

工作原理

第 1 阶段：上下文发现

确定分析上下文：

• 代币实现：你是否正在构建代币合约？
• 代币集成：你的协议是否与外部代币交互？
• 平台：Ethereum、其他 EVM 链，还是其他平台？
• 代币类型：ERC20、ERC721，还是两者都有？

第 2 阶段：Slither 分析（如果使用 Solidity）

对于 Solidity 项目，我会协助运行：

• slither-check-erc - ERC 一致性检查
• slither --print human-summary - 复杂度和升级分析
• slither --print contract-summary - 函数分析
• slither-prop - 生成用于测试的属性

第 3 阶段：代码分析

分析以下内容：

• 合约组成和复杂度
• 所有者权限和中心化风险
• ERC20/ERC721 一致性
• 已知的特殊代币模式
• 集成安全模式

第 4 阶段：链上分析（如果已部署）

如果你提供合约地址，我会查询：

• 代币稀缺性和分布
• 总供应量和持有者集中度
• 交易所上架情况
• 链上配置

第 5 阶段：风险评估

提供：

• 已识别的漏洞
• 非标准行为
• 集成风险
• 按优先级排序的建议

---

评估类别

我会检查 10 个全面类别，涵盖代币安全的各个方面。详细的评估标准、模式和检查清单，请参阅 ASSESSMENT_CATEGORIES.md。

快速参考：

1. 一般注意事项 - 安全审查、团队透明度、安全联系人
2. 合约组成 - 复杂度分析、SafeMath 使用情况、函数数量、入口点
3. 所有者权限 - 可升级性、铸造、暂停功能、黑名单、团队问责
4. ERC20 合规性 - 返回值、元数据、小数位数、竞态条件、Slither 检查
5. ERC20 扩展风险 - 外部调用/钩子、转账费用、重基准/收益型代币
6. 代币稀缺性分析 - 供应量分布、持有者集中度、交易所分布、闪电贷/铸造风险
7. 奇特的 ERC20 模式（包括 24 种模式）：
   • 可重入调用（ERC777 钩子）
   • 缺少返回值（USDT、BNB、OMG）
   • 转账收取费用（STA、PAXG）
   • 在转账之外修改余额（Ampleforth、Compound）
   • 可升级代币（USDC、USDT）
   • 可闪电铸造（DAI）
   • 区块列表（USDC、USDT）
   • 可暂停代币（BNB、ZIL）
   • 授权竞态保护（USDT、KNC）
   • 对向零地址授权/转账进行回退
   • 对零值授权/转账进行回退
   • 多个代币地址
   • 小数位数较少（USDC：6，Gemini：2）
   • 小数位数较多（YAM-V2：24）
   • src == msg.sender 时调用 transferFrom
   • 非字符串元数据（MKR）
   • 失败时不回退（ZRX、EURS）
   • 对大额授权进行回退（UNI、COMP）
   • 通过代币名称注入代码
   • 特殊的 permit 函数（DAI、RAI、GLM）
   • 转账金额少于指定金额（cUSDCv3）
   • ERC-20 原生货币表示形式（Celo、Polygon、zkSync）
   • 以及更多……
8. 代币集成安全性 - 安全转账模式、余额验证、允许列表、包装器、防御性模式
9. ERC721 合规性 - 转账至 0x0、safeTransferFrom、元数据、ownerOf、清除授权、代币 ID 不可变性
10. ERC721 常见风险 - onERC721Received 重入、安全铸造、销毁时清除授权

---

示例输出

分析完成后，你将收到一份结构如下的综合报告：

=== 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 [email protected]
✗ No security mailing list for critical announcements

**Risk:** Users won't be notified of critical issues
**Action:** Set up [email protected] 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!
}

风险： 所有者可以任意增加供应量 修复： 添加最大供应量上限或限制铸造频率

暂停功能

✓ 已实现可暂停模式（OpenZeppelin） ✓ 只有所有者可以暂停 ⚠ 暂停状态会影响所有转账（包括现有持有者）

风险： 所有者可以锁住所有用户资金 缓解措施： 为暂停功能使用多签（已实现 ✓）

黑名单

✗ 没有黑名单功能 评估： 良好——不存在中心化审查风险

团队透明度

✓ 团队成员信息公开（team.md） ✓ 公司在瑞士注册 ✓ 可问责且可联系

状态： 可接受

---

4. ERC20 合规性

Slither-check-erc 结果

命令：slither-check-erc . RewardToken --erc erc20

✓ transfer 返回 bool ✓ transferFrom 返回 bool ✓ 存在 name、decimals、symbol ✓ decimals 返回 uint8（值：18） ✓ 已缓解竞态条件（increaseAllowance/decreaseAllowance）

状态： 完全合规

slither-prop 测试结果

命令：slither-prop . --contract RewardToken

生成了 12 个属性，全部通过： ✓ 转账不会改变总供应量 ✓ 授权额度会正确更新 ✓ 余额更新与转账金额一致 ✓ 无法操纵余额 [… 另外 8 个属性 …]

Echidna 模糊测试： 50,000 次运行，未发现违规 ✓

状态： 优秀

---

5. 奇特代币模式分析

集成安全性检查

你的协议集成了 5 种外部代币：

1. USDT（0xdac17f9...）
2. USDC（0xa0b86991...）
3. DAI（0x6b175474...）
4. WETH（0xc02aaa39...）
5. UNI（0x1f9840a8...）

发现的严重问题

❌ 模式 7.2：缺少返回值 发现于： USDT 集成 文件：contracts/Vault.sol:156

IERC20(usdt).transferFrom(msg.sender, address(this), amount);
// No return value check! USDT doesn't return 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;  // WRONG! Should use actual received amount

风险： 代币收取手续费时，账目不匹配 利用方式： 用户获得的份额多于存入的代币数量 修复： 根据 balanceAfter - balanceBefore 计算份额

---

已知的非标准代币处理情况

✓ USDC： 处理得当（使用 SafeERC20，已考虑 6 位小数） ⚠ DAI： 未使用 permit() 函数（可节省 Gas） ✗ USDT： 未处理缺少返回值的情况（严重） ✓ WETH： 标准封装，处理得当 ⚠ UNI： 未检查大额授权处理（>= 2^96 时会回滚）

---

[... 其余分析类别的其他章节 ...]

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!