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 への準拠 - 戻り値、メタデータ、小数桁数、競合状態、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個のプロパティを生成し、すべて合格： ✓ Transfer によって総供給量が変化しない ✓ Allowance が正しく更新される ✓ 残高の更新が送金額と一致する ✓ 残高を操作できない [... ほか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() 関数が使用されていません（ガスを節約できる可能性があります） ✗ 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!