Token integration and implementation analyzer based on Trail of Bits' token integration checklist. Analyzes token implementations for ERC20/ERC721 conformity, checks for 20+ weird token patterns, assesses contract composition and owner privileges, performs on-chain scarcity analysis, and evaluates how protocols handle non-standard tokens. Context-aware for both token implementations and token integrations.
Analyzes token implementations and integrations for security vulnerabilities using Trail of Bits' checklist and weird token patterns.
/plugin marketplace add trailofbits/skills/plugin install building-secure-contracts@trailofbitsThis skill inherits all available tools. When active, it can use any tool Claude has access to.
resources/ASSESSMENT_CATEGORIES.mdresources/REPORT_TEMPLATES.mdSystematically 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!
Activates when the user asks about AI prompts, needs prompt templates, wants to search for prompts, or mentions prompts.chat. Use for discovering, retrieving, and improving prompts.
Activates when the user asks about Agent Skills, wants to find reusable AI capabilities, needs to install skills, or mentions skills for Claude. Use for discovering, retrieving, and installing skills.
This skill should be used when the user asks to "create an agent", "add an agent", "write a subagent", "agent frontmatter", "when to use description", "agent examples", "agent tools", "agent colors", "autonomous agent", or needs guidance on agent structure, system prompts, triggering conditions, or agent development best practices for Claude Code plugins.