token-integration-analyzer

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Token Integration Analyzer

Token集成分析工具

Purpose

用途

Systematically analyzes the codebase for token-related security concerns using Trail of Bits' token integration checklist:

Token Implementations: Analyze if your token follows ERC20/ERC721 standards or has non-standard behavior
Token Integrations: Analyze how your protocol handles arbitrary tokens, including weird/non-standard tokens
On-chain Analysis: Query deployed contracts for scarcity, distribution, and configuration
Security Assessment: Identify risks from 20+ known weird token patterns

Framework: Building Secure Contracts - Token Integration Checklist + Weird ERC20 Database

基于Trail of Bits的代币集成清单，系统性分析代码库中与Token相关的安全问题：

Token实现：分析你的Token是否遵循ERC20/ERC721标准，或存在非标准行为
Token集成：分析你的协议如何处理任意Token，包括特殊/非标准Token
链上分析：查询已部署合约的稀缺性、分布情况与配置信息
安全评估：识别20余种已知特殊Token模式带来的风险

框架：Building Secure Contracts - Token Integration Checklist + Weird ERC20 Database

How This Works

工作流程

Phase 1: Context Discovery

第一阶段：场景识别

Determines analysis context:

Token implementation: Are you building a token contract?
Token integration: Does your protocol interact with external tokens?
Platform: Ethereum, other EVM chains, or different platform?
Token types: ERC20, ERC721, or both?

确定分析场景：

Token实现：你是否正在构建一个Token合约？
Token集成：你的协议是否与外部Token交互？
平台：Ethereum、其他EVM链，还是其他平台？
Token类型：ERC20、ERC721，还是两者兼具？

Phase 2: Slither Analysis (if Solidity)

第二阶段：Slither分析（若为Solidity项目）

For Solidity projects, I'll help run:

```
slither-check-erc
```
- ERC conformity checks
```
slither --print human-summary
```
- Complexity and upgrade analysis
```
slither --print contract-summary
```
- Function analysis
```
slither-prop
```
- Property generation for testing

对于Solidity项目，我将协助运行以下命令：

```
slither-check-erc
```
- ERC合规性检查
```
slither --print human-summary
```
- 复杂度与可升级性分析
```
slither --print contract-summary
```
- 函数分析
```
slither-prop
```
- 生成测试用属性

Phase 3: Code Analysis

第三阶段：代码分析

Analyzes:

Contract composition and complexity
Owner privileges and centralization risks
ERC20/ERC721 conformity
Known weird token patterns
Integration safety patterns

分析内容包括：

合约构成与复杂度
所有者权限与中心化风险
ERC20/ERC721合规性
已知特殊Token模式
集成安全模式

Phase 4: On-chain Analysis (if deployed)

第四阶段：链上分析（若已部署）

If you provide a contract address, I'll query:

Token scarcity and distribution
Total supply and holder concentration
Exchange listings
On-chain configuration

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

Token稀缺性与分布情况
总供应量与持有者集中度
交易所上线情况
链上配置信息

Phase 5: Risk Assessment

第五阶段：风险评估

Provides:

Identified vulnerabilities
Non-standard behaviors
Integration risks
Prioritized recommendations

提供以下内容：

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

Assessment Categories

评估类别

I check 10 comprehensive categories covering all aspects of token security. For detailed criteria, patterns, and checklists, see ASSESSMENT_CATEGORIES.md.

我会检查涵盖Token安全所有方面的10个综合类别。如需详细标准、模式与清单，请查看ASSESSMENT_CATEGORIES.md。

Quick Reference:

快速参考：

General Considerations - Security reviews, team transparency, security contacts
Contract Composition - Complexity analysis, SafeMath usage, function count, entry points
Owner Privileges - Upgradeability, minting, pausability, blacklisting, team accountability
ERC20 Conformity - Return values, metadata, decimals, race conditions, Slither checks
ERC20 Extension Risks - External calls/hooks, transfer fees, rebasing/yield-bearing tokens
Token Scarcity Analysis - Supply distribution, holder concentration, exchange distribution, flash loan/mint risks
Weird ERC20 Patterns (24 patterns including):
- Reentrant calls (ERC777 hooks)
- Missing return values (USDT, BNB, OMG)
- Fee on transfer (STA, PAXG)
- Balance modifications outside transfers (Ampleforth, Compound)
- Upgradable tokens (USDC, USDT)
- Flash mintable (DAI)
- Blocklists (USDC, USDT)
- Pausable tokens (BNB, ZIL)
- Approval race protections (USDT, KNC)
- Revert on approval/transfer to zero address
- Revert on zero value approvals/transfers
- Multiple token addresses
- Low decimals (USDC: 6, Gemini: 2)
- High decimals (YAM-V2: 24)
- transferFrom with src == msg.sender
- Non-string metadata (MKR)
- No revert on failure (ZRX, EURS)
- Revert on large approvals (UNI, COMP)
- Code injection via token name
- Unusual permit function (DAI, RAI, GLM)
- Transfer less than amount (cUSDCv3)
- ERC-20 native currency representation (Celo, Polygon, zkSync)
- And more...
Token Integration Safety - Safe transfer patterns, balance verification, allowlists, wrappers, defensive patterns
ERC721 Conformity - Transfer to 0x0, safeTransferFrom, metadata, ownerOf, approval clearing, token ID immutability
ERC721 Common Risks - onERC721Received reentrancy, safe minting, burning approval clearing

通用考量：安全审计、团队透明度、安全联系方式
合约构成：复杂度分析、SafeMath使用、函数数量、入口点
所有者权限：可升级性、铸造权限、暂停功能、黑名单、团队问责制
ERC20合规性：返回值、元数据、小数位数、竞争条件、Slither检查
ERC20扩展风险：外部调用/钩子、转账手续费、重基/生息Token
Token稀缺性分析：供应量分布、持有者集中度、交易所分布、闪电贷/铸造风险
特殊ERC20模式（24种，包括）：
- 可重入调用（ERC777钩子）
- 缺少返回值（USDT, BNB, OMG）
- 转账手续费（STA, PAXG）
- 转账外的余额修改（Ampleforth, Compound）
- 可升级Token（USDC, USDT）
- 可闪电铸造（DAI）
- 黑名单（USDC, USDT）
- 可暂停Token（BNB, ZIL）
- 授权竞争保护（USDT, KNC）
- 向零地址授权/转账时回滚
- 零金额授权/转账时回滚
- 多Token地址
- 低小数位数（USDC: 6, Gemini: 2）
- 高小数位数（YAM-V2: 24）
- transferFrom中src == msg.sender
- 非字符串元数据（MKR）
- 失败时不回滚（ZRX, EURS）
- 大额授权时回滚（UNI, COMP）
- 通过Token名称注入代码
- 异常permit函数（DAI, RAI, GLM）
- 转账金额不足（cUSDCv3）
- ERC-20原生货币表示（Celo, Polygon, zkSync）
- 更多...
Token集成安全性：安全转账模式、余额验证、白名单、包装器、防御模式
ERC721合规性：向0x0转账、safeTransferFrom、元数据、ownerOf、授权清除、Token ID不可变性
ERC721常见风险：onERC721Received重入、安全铸造、燃烧时的授权清除

Example Output

示例输出

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

---

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

=== 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.

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

✓ 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

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)

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

✓ 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

⚠ 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

❌ 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

Pausability

✓ 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 ✓)

✓ 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 ✓)

Blacklisting

✗ No blacklist functionality Assessment: Good - no centralized censorship risk

Team Transparency

✓ Team members public (team.md) ✓ Company registered in Switzerland ✓ Accountable and contactable

Status: ACCEPTABLE

✓ Team members public (team.md) ✓ Company registered in Switzerland ✓ Accountable and contactable

Status: ACCEPTABLE

4. ERC20 CONFORMITY

Slither-check-erc Results

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

slither-prop Test Results

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

Command: slither-prop . --contract RewardToken

Echidna fuzzing: 50,000 runs, no violations ✓

Status: EXCELLENT

5. WEIRD TOKEN PATTERN ANALYSIS

Integration Safety Check

Your Protocol Integrates 5 External Tokens:

USDT (0xdac17f9...)
USDC (0xa0b86991...)
DAI (0x6b175474...)
WETH (0xc02aaa39...)
UNI (0x1f9840a8...)

Your Protocol Integrates 5 External Tokens:

USDT (0xdac17f9...)
USDC (0xa0b86991...)
DAI (0x6b175474...)
WETH (0xc02aaa39...)
UNI (0x1f9840a8...)

Critical Issues Found

❌ Pattern 7.2: Missing Return Values Found in: USDT integration File: contracts/Vault.sol:156

solidity

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

solidity

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

❌ Pattern 7.2: Missing Return Values Found in: USDT integration File: contracts/Vault.sol:156

solidity

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

solidity

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

Known Non-Standard Token Handling

✓ 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).

---

[... 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

常见误区	错误原因	必要措施
"Token看起来符合标准，ERC20检查通过"	除ERC20合规性外，还存在20余种特殊Token模式	检查数据库中的所有特殊Token模式（缺少返回值、零地址回滚、钩子等）
"Slither未发现问题，集成是安全的"	Slither可检测部分模式，但会遗漏集成逻辑	完成所有5项Token集成标准的手动分析
"未检测到转账手续费，跳过该检查"	转账手续费可能由所有者控制或为条件性的	测试所有转账场景，检查是否存在条件性手续费逻辑
"已存在余额检查，处理是安全的"	仅余额检查无法防范所有特殊Token	验证安全转账包装器、回滚处理、授权模式
"Token由知名团队部署，默认符合标准"	声誉无法保证行为符合标准	分析实际代码与链上行为，不要依赖假设
"集成使用了OpenZeppelin，肯定安全"	OpenZeppelin库无法防范外部特殊Token	验证所有外部Token调用的防御模式
"无法运行Slither，跳过自动化分析"	Slither提供关键的ERC合规性检查	手动验证所有slither-check-erc标准，或记录无法运行的原因
"该模式看起来没问题"	直觉会遗漏细微的Token集成漏洞	系统性检查所有20余种特殊Token模式，并提供代码证据

Deliverables

交付物

When analysis is complete, I'll provide:

Compliance Checklist - Checkboxes for all assessment categories
Weird Token Pattern Analysis - Presence/absence of all 24 patterns with risk levels and evidence
On-chain Analysis Report (if applicable) - Holder distribution, exchange listings, configuration
Integration Safety Assessment (if applicable) - Safe transfer usage, defensive patterns, weird token handling
Prioritized Recommendations - CRITICAL/HIGH/MEDIUM/LOW issues with specific fixes

Complete deliverable templates available in REPORT_TEMPLATES.md.

分析完成后，我将提供：

合规检查表：所有评估类别的勾选清单
特殊Token模式分析：所有24种模式的存在/缺失情况，附带风险等级与证据
链上分析报告（如适用）：持有者分布、交易所上线情况、配置信息
集成安全评估（如适用）：安全转账使用情况、防御模式、特殊Token处理
优先级排序的建议：CRITICAL/HIGH/MEDIUM/LOW级别的问题与具体修复方案

完整的交付物模板请查看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!

我需要以下信息：

你的代码库
场景：Token实现还是Token集成？
Token类型：ERC20、ERC721，还是两者兼具？
合约地址（如已部署并需要链上分析）
RPC端点（如需查询链上数据）

让我们分析你的Token实现或集成的安全风险！