Token Integration Analyzer

目的

Trail of Bits のトークン統合チェックリストを使用して、コードベースのトークン関連のセキュリティ懸念を体系的に分析します：

1. トークン実装: トークンが ERC20/ERC721 標準に従っているか、または非標準の動作を持つかを分析
2. トークン統合: プロトコルが奇妙な/非標準トークンを含む任意のトークンをどのように処理するかを分析
3. オンチェーン分析: デプロイされたコントラクトをクエリして、希少性、分布、および設定を確認
4. セキュリティ評価: 20 以上の既知の奇妙なトークンパターンからのリスクを特定

フレームワーク: Building Secure Contracts - Token Integration Checklist + Weird ERC20 Database

---

仕組み

フェーズ 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 適合性 - リターン値、メタデータ、decimals、レース条件、Slither チェック
5. ERC20 拡張リスク - 外部呼び出し/フック、転送手数料、リベーシング/イールドベアリングトークン
6. トークン希少性分析 - 供給分布、保有者集中度、取引所分布、フラッシュローン/ミントリスク
7. 奇妙な ERC20 パターン（24 パターン含む）：
   • リエントラント呼び出し（ERC777 フック）
   • リターン値の欠落（USDT、BNB、OMG）
   • 転送時の手数料（STA、PAXG）
   • 転送外のバランス変更（Ampleforth、Compound）
   • アップグレード可能なトークン（USDC、USDT）
   • フラッシュミント可能（DAI）
   • ブロックリスト（USDC、USDT）
   • 一時停止可能なトークン（BNB、ZIL）
   • 承認レース保護（USDT、KNC）
   • ゼロアドレスへの承認/転送でリバート
   • ゼロ値の承認/転送でリバート
   • 複数のトークンアドレス
   • 低い decimals（USDC: 6、Gemini: 2）
   • 高い decimals（YAM-V2: 24）
   • transferFrom（src == msg.sender）
   • 非文字列メタデータ（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 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

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

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

---

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

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

---

5. WEIRD TOKEN PATTERN ANALYSIS

Integration Safety Check

Your Protocol Integrates 5 External Tokens:

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

Critical Issues Found

❌ 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

---

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

完全なレポートテンプレートと成果物形式については、[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. **優先順位付けされた推奨事項** - CRITICAL/HIGH/MEDIUM/LOW の問題、具体的な修正方法

完全な成果物テンプレートは [REPORT_TEMPLATES.md](resources/REPORT_TEMPLATES.md) で利用可能です。

---

## 開始する準備はできていますか

**必要な情報**:
- コードベース
- コンテキスト: トークン実装か統合か？
- トークンタイプ: ERC20、ERC721、または両方？
- コントラクトアドレス（デプロイ済みでオンチェーン分析が必要な場合）
- RPC エンドポイント（オンチェーンクエリが必要な場合）

トークン実装または統合のセキュリティリスクを分析しましょう！