Loading
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, asse
The skill file stays in the publisher's repository.
Paste the copied command in a terminal. It installs this SKILL.md into that agent.
npx skills add trailofbits/skills --skill token-integration-analyzer -a cursor -y
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. Use when integrating or accepting arbitrary ERC20/ERC721 tokens, auditing a token implementation for standards conformity, or assessing risk from weird tokens such as fee-on-transfer, rebasing, missing return values, or blocklists.
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. Use when integrating or accepting arbitrary ERC20/ERC721 tokens, auditing a token implementation for standards conformity, or assessing risk from weird tokens such as fee-on-transfer, rebasing, missing return values, or blocklists.
Systematically 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 [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!
}
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!