[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6DSS1VBTA17GJSGH5BSD4J1":3,"skill-same:01M6DSS1VBTA17GJSGH5BSD4J1":106},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":15,"categories":16,"keywords":17,"publishedAt":34,"linkOnly":35,"markdownContent":36,"markdownBody":37,"frontMatter":38,"refName":39,"commitSha":40,"skillDirectory":41,"forksCount":42,"repositoryHtmlUrl":43,"repositoryHomepageUrl":6,"ownerHtmlUrl":44,"ownerBlogUrl":6,"ownerDescription":6,"updatedAt":45,"install":46,"resources":59},"01M6DSS1VBTA17GJSGH5BSD4J1","token-integration-analyzer",null,"Token integration and implementation analyzer based on Trail of Bits' token integration checklist. Analyzes token implementations for ERC20\u002FERC721 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.","AntifragileTech\u002Fantifragile-claude-code","AntifragileTech","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F174357194?v=4","01M6DQCYMK4CDSQQAN0ZC72NTV","01M6DQCYS9YPW1WKMQ5TJMPQ43",9,"MIT","https:\u002F\u002Fgithub.com\u002FAntifragileTech\u002Fantifragile-claude-code\u002Fblob\u002Fmaster\u002Fassets\u002Fskills\u002Fsecurity\u002Ftoken-integration-analyzer\u002FSKILL.md",[],[18,19,20,21,22,23,24,25,26,27,28,29,30,31,32,33],"integration","token","token integration analyzer","protocols","analysis","Composition","how","integrations","context","implementation","checklist","patterns","erc20","tokens","contract","chain","2026-11-10 10:12:30",false,"---\nname: token-integration-analyzer\ndescription: Token integration and implementation analyzer based on Trail of Bits' token integration checklist. Analyzes token implementations for ERC20\u002FERC721 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.\n---\n\n# Token Integration Analyzer\n\n## Purpose\n\nSystematically analyzes the codebase for token-related security concerns using Trail of Bits' token integration checklist:\n\n1. **Token Implementations**: Analyze if your token follows ERC20\u002FERC721 standards or has non-standard behavior\n2. **Token Integrations**: Analyze how your protocol handles arbitrary tokens, including weird\u002Fnon-standard tokens\n3. **On-chain Analysis**: Query deployed contracts for scarcity, distribution, and configuration\n4. **Security Assessment**: Identify risks from 20+ known weird token patterns\n\n**Framework**: Building Secure Contracts - Token Integration Checklist + Weird ERC20 Database\n\n---\n\n## How This Works\n\n### Phase 1: Context Discovery\nDetermines analysis context:\n- **Token implementation**: Are you building a token contract?\n- **Token integration**: Does your protocol interact with external tokens?\n- **Platform**: Ethereum, other EVM chains, or different platform?\n- **Token types**: ERC20, ERC721, or both?\n\n### Phase 2: Slither Analysis (if Solidity)\nFor Solidity projects, I'll help run:\n- `slither-check-erc` - ERC conformity checks\n- `slither --print human-summary` - Complexity and upgrade analysis\n- `slither --print contract-summary` - Function analysis\n- `slither-prop` - Property generation for testing\n\n### Phase 3: Code Analysis\nAnalyzes:\n- Contract composition and complexity\n- Owner privileges and centralization risks\n- ERC20\u002FERC721 conformity\n- Known weird token patterns\n- Integration safety patterns\n\n### Phase 4: On-chain Analysis (if deployed)\nIf you provide a contract address, I'll query:\n- Token scarcity and distribution\n- Total supply and holder concentration\n- Exchange listings\n- On-chain configuration\n\n### Phase 5: Risk Assessment\nProvides:\n- Identified vulnerabilities\n- Non-standard behaviors\n- Integration risks\n- Prioritized recommendations\n\n---\n\n## Assessment Categories\n\nI check 10 comprehensive categories covering all aspects of token security. For detailed criteria, patterns, and checklists, see [ASSESSMENT_CATEGORIES.md](resources\u002FASSESSMENT_CATEGORIES.md).\n\n### Quick Reference:\n\n1. **General Considerations** - Security reviews, team transparency, security contacts\n2. **Contract Composition** - Complexity analysis, SafeMath usage, function count, entry points\n3. **Owner Privileges** - Upgradeability, minting, pausability, blacklisting, team accountability\n4. **ERC20 Conformity** - Return values, metadata, decimals, race conditions, Slither checks\n5. **ERC20 Extension Risks** - External calls\u002Fhooks, transfer fees, rebasing\u002Fyield-bearing tokens\n6. **Token Scarcity Analysis** - Supply distribution, holder concentration, exchange distribution, flash loan\u002Fmint risks\n7. **Weird ERC20 Patterns** (24 patterns including):\n   - Reentrant calls (ERC777 hooks)\n   - Missing return values (USDT, BNB, OMG)\n   - Fee on transfer (STA, PAXG)\n   - Balance modifications outside transfers (Ampleforth, Compound)\n   - Upgradable tokens (USDC, USDT)\n   - Flash mintable (DAI)\n   - Blocklists (USDC, USDT)\n   - Pausable tokens (BNB, ZIL)\n   - Approval race protections (USDT, KNC)\n   - Revert on approval\u002Ftransfer to zero address\n   - Revert on zero value approvals\u002Ftransfers\n   - Multiple token addresses\n   - Low decimals (USDC: 6, Gemini: 2)\n   - High decimals (YAM-V2: 24)\n   - transferFrom with src == msg.sender\n   - Non-string metadata (MKR)\n   - No revert on failure (ZRX, EURS)\n   - Revert on large approvals (UNI, COMP)\n   - Code injection via token name\n   - Unusual permit function (DAI, RAI, GLM)\n   - Transfer less than amount (cUSDCv3)\n   - ERC-20 native currency representation (Celo, Polygon, zkSync)\n   - [And more...](resources\u002FASSESSMENT_CATEGORIES.md#7-weird-erc20-patterns)\n8. **Token Integration Safety** - Safe transfer patterns, balance verification, allowlists, wrappers, defensive patterns\n9. **ERC721 Conformity** - Transfer to 0x0, safeTransferFrom, metadata, ownerOf, approval clearing, token ID immutability\n10. **ERC721 Common Risks** - onERC721Received reentrancy, safe minting, burning approval clearing\n\n---\n\n## Example Output\n\nWhen analysis is complete, you'll receive a comprehensive report structured as follows:\n\n```\n=== TOKEN INTEGRATION ANALYSIS REPORT ===\n\nProject: MultiToken DEX\nToken Analyzed: Custom Reward Token + Integration Safety\nPlatform: Solidity 0.8.20\nAnalysis Date: March 15, 2024\n\n---\n\n## EXECUTIVE SUMMARY\n\nToken Type: ERC20 Implementation + Protocol Integrating External Tokens\nOverall Risk Level: MEDIUM\nCritical Issues: 2\nHigh Issues: 3\nMedium Issues: 4\n\n**Top Concerns:**\n⚠ Fee-on-transfer tokens not handled correctly\n⚠ No validation for missing return values (USDT compatibility)\n⚠ Owner can mint unlimited tokens without cap\n\n**Recommendation:** Address critical\u002Fhigh issues before mainnet launch.\n\n---\n\n## 1. GENERAL CONSIDERATIONS\n\n✓ Contract audited by CertiK (June 2023)\n✓ Team contactable via security@project.com\n✗ No security mailing list for critical announcements\n\n**Risk:** Users won't be notified of critical issues\n**Action:** Set up security@project.com mailing list\n\n---\n\n## 2. CONTRACT COMPOSITION\n\n### Complexity Analysis\n\n**Slither human-summary Results:**\n- 456 lines of code\n- Cyclomatic complexity: Average 6, Max 14 (transferWithFee())\n- 12 functions, 8 state variables\n- Inheritance depth: 3 (moderate)\n\n✓ Contract complexity is reasonable\n⚠ transferWithFee() complexity high (14) - consider splitting\n\n### SafeMath Usage\n\n✓ Using Solidity 0.8.20 (built-in overflow protection)\n✓ No unchecked blocks found\n✓ All arithmetic operations protected\n\n### Non-Token Functions\n\n**Functions Beyond ERC20:**\n- setFeeCollector() - Admin function ✓\n- setTransferFee() - Admin function ✓\n- withdrawFees() - Admin function ✓\n- pause()\u002Funpause() - Emergency functions ✓\n\n⚠ 4 non-token functions (acceptable but adds complexity)\n\n### Address Entry Points\n\n✓ Single contract address\n✓ No proxy with multiple entry points\n✓ No token migration creating address confusion\n\n**Status:** PASS\n\n---\n\n## 3. OWNER PRIVILEGES\n\n### Upgradeability\n\n⚠ Contract uses TransparentUpgradeableProxy\n**Risk:** Owner can change contract logic at any time\n\n**Current Implementation:**\n- ProxyAdmin: 0x1234... (2\u002F3 multisig) ✓\n- Timelock: None ✗\n\n**Recommendation:** Add 48-hour timelock to all upgrades\n\n### Minting Capabilities\n\n❌ CRITICAL: Unlimited minting\nFile: contracts\u002FRewardToken.sol:89\n```solidity\nfunction mint(address to, uint256 amount) external onlyOwner {\n    _mint(to, amount);  \u002F\u002F No cap!\n}\n```\n\n**Risk:** Owner can inflate supply arbitrarily\n**Fix:** Add maximum supply cap or rate-limited minting\n\n### Pausability\n\n✓ Pausable pattern implemented (OpenZeppelin)\n✓ Only owner can pause\n⚠ Paused state affects all transfers (including existing holders)\n\n**Risk:** Owner can trap all user funds\n**Mitigation:** Use multi-sig for pause function (already implemented ✓)\n\n### Blacklisting\n\n✗ No blacklist functionality\n**Assessment:** Good - no centralized censorship risk\n\n### Team Transparency\n\n✓ Team members public (team.md)\n✓ Company registered in Switzerland\n✓ Accountable and contactable\n\n**Status:** ACCEPTABLE\n\n---\n\n## 4. ERC20 CONFORMITY\n\n### Slither-check-erc Results\n\nCommand: slither-check-erc . RewardToken --erc erc20\n\n✓ transfer returns bool\n✓ transferFrom returns bool\n✓ name, decimals, symbol present\n✓ decimals returns uint8 (value: 18)\n✓ Race condition mitigated (increaseAllowance\u002FdecreaseAllowance)\n\n**Status:** FULLY COMPLIANT\n\n### slither-prop Test Results\n\nCommand: slither-prop . --contract RewardToken\n\n**Generated 12 properties, all passed:**\n✓ Transfer doesn't change total supply\n✓ Allowance correctly updates\n✓ Balance updates match transfer amounts\n✓ No balance manipulation possible\n[... 8 more properties ...]\n\n**Echidna fuzzing:** 50,000 runs, no violations ✓\n\n**Status:** EXCELLENT\n\n---\n\n## 5. WEIRD TOKEN PATTERN ANALYSIS\n\n### Integration Safety Check\n\n**Your Protocol Integrates 5 External Tokens:**\n1. USDT (0xdac17f9...)\n2. USDC (0xa0b86991...)\n3. DAI (0x6b175474...)\n4. WETH (0xc02aaa39...)\n5. UNI (0x1f9840a8...)\n\n### Critical Issues Found\n\n❌ **Pattern 7.2: Missing Return Values**\n**Found in:** USDT integration\nFile: contracts\u002FVault.sol:156\n```solidity\nIERC20(usdt).transferFrom(msg.sender, address(this), amount);\n\u002F\u002F No return value check! USDT doesn't return bool\n```\n\n**Risk:** Silent failures on USDT transfers\n**Exploit:** User appears to deposit, but no tokens moved\n**Fix:** Use OpenZeppelin SafeERC20 wrapper\n\n---\n\n❌ **Pattern 7.3: Fee on Transfer**\n**Risk for:** Any token with transfer fees\nFile: contracts\u002FVault.sol:170\n```solidity\nuint256 balanceBefore = IERC20(token).balanceOf(address(this));\ntoken.transferFrom(msg.sender, address(this), amount);\nshares = amount * exchangeRate;  \u002F\u002F WRONG! Should use actual received amount\n```\n\n**Risk:** Accounting mismatch if token takes fees\n**Exploit:** User credited more shares than tokens deposited\n**Fix:** Calculate shares from `balanceAfter - balanceBefore`\n\n---\n\n### Known Non-Standard Token Handling\n\n✓ **USDC:** Properly handled (SafeERC20, 6 decimals accounted for)\n⚠ **DAI:** permit() function not used (opportunity for gas savings)\n✗ **USDT:** Missing return value not handled (CRITICAL)\n✓ **WETH:** Standard wrapper, properly handled\n⚠ **UNI:** Large approval handling not checked (reverts >= 2^96)\n\n---\n\n[... Additional sections for remaining analysis categories ...]\n```\n\nFor complete report template and deliverables format, see [REPORT_TEMPLATES.md](resources\u002FREPORT_TEMPLATES.md).\n\n---\n\n## Rationalizations (Do Not Skip)\n\n| Rationalization | Why It's Wrong | Required Action |\n|-----------------|----------------|-----------------|\n| \"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.) |\n| \"Slither shows no issues, integration is safe\" | Slither detects some patterns, misses integration logic | Complete manual analysis of all 5 token integration criteria |\n| \"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 |\n| \"Balance checks exist, handling is safe\" | Balance checks alone don't protect against all weird tokens | Verify safe transfer wrappers, revert handling, approval patterns |\n| \"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 |\n| \"Integration uses OpenZeppelin, must be safe\" | OpenZeppelin libraries don't protect against weird external tokens | Verify defensive patterns around all external token calls |\n| \"Can't run Slither, skipping automated analysis\" | Slither provides critical ERC conformance checks | Manually verify all slither-check-erc criteria or document why blocked |\n| \"This pattern seems fine\" | Intuition misses subtle token integration bugs | Systematically check all 20+ weird token patterns with code evidence |\n\n---\n\n## Deliverables\n\nWhen analysis is complete, I'll provide:\n\n1. **Compliance Checklist** - Checkboxes for all assessment categories\n2. **Weird Token Pattern Analysis** - Presence\u002Fabsence of all 24 patterns with risk levels and evidence\n3. **On-chain Analysis Report** (if applicable) - Holder distribution, exchange listings, configuration\n4. **Integration Safety Assessment** (if applicable) - Safe transfer usage, defensive patterns, weird token handling\n5. **Prioritized Recommendations** - CRITICAL\u002FHIGH\u002FMEDIUM\u002FLOW issues with specific fixes\n\nComplete deliverable templates available in [REPORT_TEMPLATES.md](resources\u002FREPORT_TEMPLATES.md).\n\n---\n\n## Ready to Begin\n\n**What I'll need**:\n- Your codebase\n- Context: Token implementation or integration?\n- Token type: ERC20, ERC721, or both?\n- Contract address (if deployed and want on-chain analysis)\n- RPC endpoint (if querying on-chain)\n\nLet's analyze your token implementation or integration for security risks!\n","# Token Integration Analyzer\n\n## Purpose\n\nSystematically analyzes the codebase for token-related security concerns using Trail of Bits' token integration checklist:\n\n1. **Token Implementations**: Analyze if your token follows ERC20\u002FERC721 standards or has non-standard behavior\n2. **Token Integrations**: Analyze how your protocol handles arbitrary tokens, including weird\u002Fnon-standard tokens\n3. **On-chain Analysis**: Query deployed contracts for scarcity, distribution, and configuration\n4. **Security Assessment**: Identify risks from 20+ known weird token patterns\n\n**Framework**: Building Secure Contracts - Token Integration Checklist + Weird ERC20 Database\n\n---\n\n## How This Works\n\n### Phase 1: Context Discovery\nDetermines analysis context:\n- **Token implementation**: Are you building a token contract?\n- **Token integration**: Does your protocol interact with external tokens?\n- **Platform**: Ethereum, other EVM chains, or different platform?\n- **Token types**: ERC20, ERC721, or both?\n\n### Phase 2: Slither Analysis (if Solidity)\nFor Solidity projects, I'll help run:\n- `slither-check-erc` - ERC conformity checks\n- `slither --print human-summary` - Complexity and upgrade analysis\n- `slither --print contract-summary` - Function analysis\n- `slither-prop` - Property generation for testing\n\n### Phase 3: Code Analysis\nAnalyzes:\n- Contract composition and complexity\n- Owner privileges and centralization risks\n- ERC20\u002FERC721 conformity\n- Known weird token patterns\n- Integration safety patterns\n\n### Phase 4: On-chain Analysis (if deployed)\nIf you provide a contract address, I'll query:\n- Token scarcity and distribution\n- Total supply and holder concentration\n- Exchange listings\n- On-chain configuration\n\n### Phase 5: Risk Assessment\nProvides:\n- Identified vulnerabilities\n- Non-standard behaviors\n- Integration risks\n- Prioritized recommendations\n\n---\n\n## Assessment Categories\n\nI check 10 comprehensive categories covering all aspects of token security. For detailed criteria, patterns, and checklists, see [ASSESSMENT_CATEGORIES.md](resources\u002FASSESSMENT_CATEGORIES.md).\n\n### Quick Reference:\n\n1. **General Considerations** - Security reviews, team transparency, security contacts\n2. **Contract Composition** - Complexity analysis, SafeMath usage, function count, entry points\n3. **Owner Privileges** - Upgradeability, minting, pausability, blacklisting, team accountability\n4. **ERC20 Conformity** - Return values, metadata, decimals, race conditions, Slither checks\n5. **ERC20 Extension Risks** - External calls\u002Fhooks, transfer fees, rebasing\u002Fyield-bearing tokens\n6. **Token Scarcity Analysis** - Supply distribution, holder concentration, exchange distribution, flash loan\u002Fmint risks\n7. **Weird ERC20 Patterns** (24 patterns including):\n   - Reentrant calls (ERC777 hooks)\n   - Missing return values (USDT, BNB, OMG)\n   - Fee on transfer (STA, PAXG)\n   - Balance modifications outside transfers (Ampleforth, Compound)\n   - Upgradable tokens (USDC, USDT)\n   - Flash mintable (DAI)\n   - Blocklists (USDC, USDT)\n   - Pausable tokens (BNB, ZIL)\n   - Approval race protections (USDT, KNC)\n   - Revert on approval\u002Ftransfer to zero address\n   - Revert on zero value approvals\u002Ftransfers\n   - Multiple token addresses\n   - Low decimals (USDC: 6, Gemini: 2)\n   - High decimals (YAM-V2: 24)\n   - transferFrom with src == msg.sender\n   - Non-string metadata (MKR)\n   - No revert on failure (ZRX, EURS)\n   - Revert on large approvals (UNI, COMP)\n   - Code injection via token name\n   - Unusual permit function (DAI, RAI, GLM)\n   - Transfer less than amount (cUSDCv3)\n   - ERC-20 native currency representation (Celo, Polygon, zkSync)\n   - [And more...](resources\u002FASSESSMENT_CATEGORIES.md#7-weird-erc20-patterns)\n8. **Token Integration Safety** - Safe transfer patterns, balance verification, allowlists, wrappers, defensive patterns\n9. **ERC721 Conformity** - Transfer to 0x0, safeTransferFrom, metadata, ownerOf, approval clearing, token ID immutability\n10. **ERC721 Common Risks** - onERC721Received reentrancy, safe minting, burning approval clearing\n\n---\n\n## Example Output\n\nWhen analysis is complete, you'll receive a comprehensive report structured as follows:\n\n```\n=== TOKEN INTEGRATION ANALYSIS REPORT ===\n\nProject: MultiToken DEX\nToken Analyzed: Custom Reward Token + Integration Safety\nPlatform: Solidity 0.8.20\nAnalysis Date: March 15, 2024\n\n---\n\n## EXECUTIVE SUMMARY\n\nToken Type: ERC20 Implementation + Protocol Integrating External Tokens\nOverall Risk Level: MEDIUM\nCritical Issues: 2\nHigh Issues: 3\nMedium Issues: 4\n\n**Top Concerns:**\n⚠ Fee-on-transfer tokens not handled correctly\n⚠ No validation for missing return values (USDT compatibility)\n⚠ Owner can mint unlimited tokens without cap\n\n**Recommendation:** Address critical\u002Fhigh issues before mainnet launch.\n\n---\n\n## 1. GENERAL CONSIDERATIONS\n\n✓ Contract audited by CertiK (June 2023)\n✓ Team contactable via security@project.com\n✗ No security mailing list for critical announcements\n\n**Risk:** Users won't be notified of critical issues\n**Action:** Set up security@project.com mailing list\n\n---\n\n## 2. CONTRACT COMPOSITION\n\n### Complexity Analysis\n\n**Slither human-summary Results:**\n- 456 lines of code\n- Cyclomatic complexity: Average 6, Max 14 (transferWithFee())\n- 12 functions, 8 state variables\n- Inheritance depth: 3 (moderate)\n\n✓ Contract complexity is reasonable\n⚠ transferWithFee() complexity high (14) - consider splitting\n\n### SafeMath Usage\n\n✓ Using Solidity 0.8.20 (built-in overflow protection)\n✓ No unchecked blocks found\n✓ All arithmetic operations protected\n\n### Non-Token Functions\n\n**Functions Beyond ERC20:**\n- setFeeCollector() - Admin function ✓\n- setTransferFee() - Admin function ✓\n- withdrawFees() - Admin function ✓\n- pause()\u002Funpause() - Emergency functions ✓\n\n⚠ 4 non-token functions (acceptable but adds complexity)\n\n### Address Entry Points\n\n✓ Single contract address\n✓ No proxy with multiple entry points\n✓ No token migration creating address confusion\n\n**Status:** PASS\n\n---\n\n## 3. OWNER PRIVILEGES\n\n### Upgradeability\n\n⚠ Contract uses TransparentUpgradeableProxy\n**Risk:** Owner can change contract logic at any time\n\n**Current Implementation:**\n- ProxyAdmin: 0x1234... (2\u002F3 multisig) ✓\n- Timelock: None ✗\n\n**Recommendation:** Add 48-hour timelock to all upgrades\n\n### Minting Capabilities\n\n❌ CRITICAL: Unlimited minting\nFile: contracts\u002FRewardToken.sol:89\n```solidity\nfunction mint(address to, uint256 amount) external onlyOwner {\n    _mint(to, amount);  \u002F\u002F No cap!\n}\n```\n\n**Risk:** Owner can inflate supply arbitrarily\n**Fix:** Add maximum supply cap or rate-limited minting\n\n### Pausability\n\n✓ Pausable pattern implemented (OpenZeppelin)\n✓ Only owner can pause\n⚠ Paused state affects all transfers (including existing holders)\n\n**Risk:** Owner can trap all user funds\n**Mitigation:** Use multi-sig for pause function (already implemented ✓)\n\n### Blacklisting\n\n✗ No blacklist functionality\n**Assessment:** Good - no centralized censorship risk\n\n### Team Transparency\n\n✓ Team members public (team.md)\n✓ Company registered in Switzerland\n✓ Accountable and contactable\n\n**Status:** ACCEPTABLE\n\n---\n\n## 4. ERC20 CONFORMITY\n\n### Slither-check-erc Results\n\nCommand: slither-check-erc . RewardToken --erc erc20\n\n✓ transfer returns bool\n✓ transferFrom returns bool\n✓ name, decimals, symbol present\n✓ decimals returns uint8 (value: 18)\n✓ Race condition mitigated (increaseAllowance\u002FdecreaseAllowance)\n\n**Status:** FULLY COMPLIANT\n\n### slither-prop Test Results\n\nCommand: slither-prop . --contract RewardToken\n\n**Generated 12 properties, all passed:**\n✓ Transfer doesn't change total supply\n✓ Allowance correctly updates\n✓ Balance updates match transfer amounts\n✓ No balance manipulation possible\n[... 8 more properties ...]\n\n**Echidna fuzzing:** 50,000 runs, no violations ✓\n\n**Status:** EXCELLENT\n\n---\n\n## 5. WEIRD TOKEN PATTERN ANALYSIS\n\n### Integration Safety Check\n\n**Your Protocol Integrates 5 External Tokens:**\n1. USDT (0xdac17f9...)\n2. USDC (0xa0b86991...)\n3. DAI (0x6b175474...)\n4. WETH (0xc02aaa39...)\n5. UNI (0x1f9840a8...)\n\n### Critical Issues Found\n\n❌ **Pattern 7.2: Missing Return Values**\n**Found in:** USDT integration\nFile: contracts\u002FVault.sol:156\n```solidity\nIERC20(usdt).transferFrom(msg.sender, address(this), amount);\n\u002F\u002F No return value check! USDT doesn't return bool\n```\n\n**Risk:** Silent failures on USDT transfers\n**Exploit:** User appears to deposit, but no tokens moved\n**Fix:** Use OpenZeppelin SafeERC20 wrapper\n\n---\n\n❌ **Pattern 7.3: Fee on Transfer**\n**Risk for:** Any token with transfer fees\nFile: contracts\u002FVault.sol:170\n```solidity\nuint256 balanceBefore = IERC20(token).balanceOf(address(this));\ntoken.transferFrom(msg.sender, address(this), amount);\nshares = amount * exchangeRate;  \u002F\u002F WRONG! Should use actual received amount\n```\n\n**Risk:** Accounting mismatch if token takes fees\n**Exploit:** User credited more shares than tokens deposited\n**Fix:** Calculate shares from `balanceAfter - balanceBefore`\n\n---\n\n### Known Non-Standard Token Handling\n\n✓ **USDC:** Properly handled (SafeERC20, 6 decimals accounted for)\n⚠ **DAI:** permit() function not used (opportunity for gas savings)\n✗ **USDT:** Missing return value not handled (CRITICAL)\n✓ **WETH:** Standard wrapper, properly handled\n⚠ **UNI:** Large approval handling not checked (reverts >= 2^96)\n\n---\n\n[... Additional sections for remaining analysis categories ...]\n```\n\nFor complete report template and deliverables format, see [REPORT_TEMPLATES.md](resources\u002FREPORT_TEMPLATES.md).\n\n---\n\n## Rationalizations (Do Not Skip)\n\n| Rationalization | Why It's Wrong | Required Action |\n|-----------------|----------------|-----------------|\n| \"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.) |\n| \"Slither shows no issues, integration is safe\" | Slither detects some patterns, misses integration logic | Complete manual analysis of all 5 token integration criteria |\n| \"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 |\n| \"Balance checks exist, handling is safe\" | Balance checks alone don't protect against all weird tokens | Verify safe transfer wrappers, revert handling, approval patterns |\n| \"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 |\n| \"Integration uses OpenZeppelin, must be safe\" | OpenZeppelin libraries don't protect against weird external tokens | Verify defensive patterns around all external token calls |\n| \"Can't run Slither, skipping automated analysis\" | Slither provides critical ERC conformance checks | Manually verify all slither-check-erc criteria or document why blocked |\n| \"This pattern seems fine\" | Intuition misses subtle token integration bugs | Systematically check all 20+ weird token patterns with code evidence |\n\n---\n\n## Deliverables\n\nWhen analysis is complete, I'll provide:\n\n1. **Compliance Checklist** - Checkboxes for all assessment categories\n2. **Weird Token Pattern Analysis** - Presence\u002Fabsence of all 24 patterns with risk levels and evidence\n3. **On-chain Analysis Report** (if applicable) - Holder distribution, exchange listings, configuration\n4. **Integration Safety Assessment** (if applicable) - Safe transfer usage, defensive patterns, weird token handling\n5. **Prioritized Recommendations** - CRITICAL\u002FHIGH\u002FMEDIUM\u002FLOW issues with specific fixes\n\nComplete deliverable templates available in [REPORT_TEMPLATES.md](resources\u002FREPORT_TEMPLATES.md).\n\n---\n\n## Ready to Begin\n\n**What I'll need**:\n- Your codebase\n- Context: Token implementation or integration?\n- Token type: ERC20, ERC721, or both?\n- Contract address (if deployed and want on-chain analysis)\n- RPC endpoint (if querying on-chain)\n\nLet's analyze your token implementation or integration for security risks!\n",{"name":5,"description":7},"master","c73386b305dec167db7654e0e6feacb462d4f9dc","assets\u002Fskills\u002Fsecurity\u002Ftoken-integration-analyzer",1,"https:\u002F\u002Fgithub.com\u002FAntifragileTech\u002Fantifragile-claude-code","https:\u002F\u002Fgithub.com\u002FAntifragileTech","2026-10-02 14:22:14",{"source":8,"skillName":5,"commands":47,"prompt":57,"zipAvailable":58},[48,51,54],{"tool":49,"command":50},"npx","npx skills add AntifragileTech\u002Fantifragile-claude-code --skill token-integration-analyzer",{"tool":52,"command":53},"bunx","bunx skills add AntifragileTech\u002Fantifragile-claude-code --skill token-integration-analyzer",{"tool":55,"command":56},"pnpm","pnpm dlx skills add AntifragileTech\u002Fantifragile-claude-code --skill token-integration-analyzer","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002FAntifragileTech\u002Fantifragile-claude-code\u002Fblob\u002Fmaster\u002Fassets\u002Fskills\u002Fsecurity\u002Ftoken-integration-analyzer\u002FSKILL.md",true,[60,66,70,76,80,84,90,94,98,102],{"path":61,"resourceType":62,"resourceTypeDesc":63,"sizeBytes":64,"sourceHtmlUrl":65},"assets\u002FREADME.md","ASSET","资产文件",4862,"https:\u002F\u002Fgithub.com\u002FHuuBar\u002Fskill-routing-experiment\u002Fblob\u002Fmain\u002Funified_skills\u002Fvishal\u002Finstall-skill-tracker\u002Fassets\u002FREADME.md",{"path":67,"resourceType":62,"resourceTypeDesc":63,"sizeBytes":68,"sourceHtmlUrl":69},"assets\u002Fsettings.json",871,"https:\u002F\u002Fgithub.com\u002FHuuBar\u002Fskill-routing-experiment\u002Fblob\u002Fmain\u002Funified_skills\u002Fvishal\u002Finstall-skill-tracker\u002Fassets\u002Fsettings.json",{"path":71,"resourceType":72,"resourceTypeDesc":73,"sizeBytes":74,"sourceHtmlUrl":75},"README.md","REFERENCE","参考文档",19440,"https:\u002F\u002Fgithub.com\u002FHuuBar\u002Fskill-routing-experiment\u002Fblob\u002Fmain\u002Funified_skills\u002Fvishal\u002Finstall-skill-tracker\u002FREADME.md",{"path":77,"resourceType":72,"resourceTypeDesc":73,"sizeBytes":78,"sourceHtmlUrl":79},"resources\u002FASSESSMENT_CATEGORIES.md",12990,"https:\u002F\u002Fgithub.com\u002FAntifragileTech\u002Fantifragile-claude-code\u002Fblob\u002Fmaster\u002Fassets\u002Fskills\u002Fsecurity\u002Ftoken-integration-analyzer\u002Fresources\u002FASSESSMENT_CATEGORIES.md",{"path":81,"resourceType":72,"resourceTypeDesc":73,"sizeBytes":82,"sourceHtmlUrl":83},"resources\u002FREPORT_TEMPLATES.md",3289,"https:\u002F\u002Fgithub.com\u002FAntifragileTech\u002Fantifragile-claude-code\u002Fblob\u002Fmaster\u002Fassets\u002Fskills\u002Fsecurity\u002Ftoken-integration-analyzer\u002Fresources\u002FREPORT_TEMPLATES.md",{"path":85,"resourceType":86,"resourceTypeDesc":87,"sizeBytes":88,"sourceHtmlUrl":89},"scripts\u002Fanalyze-skills.py","SCRIPT","脚本",6283,"https:\u002F\u002Fgithub.com\u002FHuuBar\u002Fskill-routing-experiment\u002Fblob\u002Fmain\u002Funified_skills\u002Fvishal\u002Finstall-skill-tracker\u002Fscripts\u002Fanalyze-skills.py",{"path":91,"resourceType":86,"resourceTypeDesc":87,"sizeBytes":92,"sourceHtmlUrl":93},"scripts\u002Fshow-skill-tokens.sh",1349,"https:\u002F\u002Fgithub.com\u002FHuuBar\u002Fskill-routing-experiment\u002Fblob\u002Fmain\u002Funified_skills\u002Fvishal\u002Finstall-skill-tracker\u002Fscripts\u002Fshow-skill-tokens.sh",{"path":95,"resourceType":86,"resourceTypeDesc":87,"sizeBytes":96,"sourceHtmlUrl":97},"scripts\u002Ftrack-prompts.sh",690,"https:\u002F\u002Fgithub.com\u002FHuuBar\u002Fskill-routing-experiment\u002Fblob\u002Fmain\u002Funified_skills\u002Fvishal\u002Finstall-skill-tracker\u002Fscripts\u002Ftrack-prompts.sh",{"path":99,"resourceType":86,"resourceTypeDesc":87,"sizeBytes":100,"sourceHtmlUrl":101},"scripts\u002Ftrack-skill-end.sh",2956,"https:\u002F\u002Fgithub.com\u002FHuuBar\u002Fskill-routing-experiment\u002Fblob\u002Fmain\u002Funified_skills\u002Fvishal\u002Finstall-skill-tracker\u002Fscripts\u002Ftrack-skill-end.sh",{"path":103,"resourceType":86,"resourceTypeDesc":87,"sizeBytes":104,"sourceHtmlUrl":105},"scripts\u002Ftrack-skill-start.sh",948,"https:\u002F\u002Fgithub.com\u002FHuuBar\u002Fskill-routing-experiment\u002Fblob\u002Fmain\u002Funified_skills\u002Fvishal\u002Finstall-skill-tracker\u002Fscripts\u002Ftrack-skill-start.sh",[107,133,148,163,175,188],{"skillNo":108,"name":109,"nameZh":6,"description":110,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":111,"categories":112,"keywords":126,"publishedAt":34},"01M6DT9Q6VYA615SCXR757TZZ7","writing-skills","Use when creating new skills, editing existing skills, or verifying skills work before deployment","https:\u002F\u002Fgithub.com\u002FAntifragileTech\u002Fantifragile-claude-code\u002Fblob\u002Fmaster\u002Fassets\u002Fskills\u002Fthinking\u002Fwriting-skills\u002FSKILL.md",[113,118,121],{"categoryNo":114,"categoryName":115,"taxonomyType":116,"taxonomyTypeDesc":117},"01JBSEEDCAT000000000000008","测试与质量","SCENARIO","使用场景",{"categoryNo":119,"categoryName":120,"taxonomyType":116,"taxonomyTypeDesc":117},"01JBSEEDCAT000000000000018","写作与文案",{"categoryNo":122,"categoryName":123,"taxonomyType":124,"taxonomyTypeDesc":125},"01JBSEEDCAT000000000000036","内容创作者","PROFESSION","适用职业",[127,128,129,130,131,132],"writing skills","writing","use","editing","work","deployment",{"skillNo":134,"name":135,"nameZh":6,"description":136,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":137,"categories":138,"keywords":141,"publishedAt":34},"01M6DT9GFHDNY90P41WGAE1TV0","writing-plans","Use when you have a spec or requirements for a multi-step task, before touching code","https:\u002F\u002Fgithub.com\u002FAntifragileTech\u002Fantifragile-claude-code\u002Fblob\u002Fmaster\u002Fassets\u002Fskills\u002Fthinking\u002Fwriting-plans\u002FSKILL.md",[139,140],{"categoryNo":119,"categoryName":120,"taxonomyType":116,"taxonomyTypeDesc":117},{"categoryNo":122,"categoryName":123,"taxonomyType":124,"taxonomyTypeDesc":125},[142,143,128,144,145,129,146,147],"plans","writing plans","requirements","task","code","spec",{"skillNo":149,"name":150,"nameZh":6,"description":151,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":152,"categories":153,"keywords":156,"publishedAt":34},"01M6DT9C6PFGD86WS3HY7YE3XG","docs:write-concisely","Apply writing rules to any documentation that humans will read. Makes your writing clearer, stronger, and more professional.","https:\u002F\u002Fgithub.com\u002FAntifragileTech\u002Fantifragile-claude-code\u002Fblob\u002Fmaster\u002Fassets\u002Fskills\u002Fthinking\u002Fwrite-concisely\u002FSKILL.md",[154,155],{"categoryNo":119,"categoryName":120,"taxonomyType":116,"taxonomyTypeDesc":117},{"categoryNo":122,"categoryName":123,"taxonomyType":124,"taxonomyTypeDesc":125},[157,158,159,160,161,162,128],"docs:write concisely","write","docs","read","Rules","documentation",{"skillNo":164,"name":165,"nameZh":6,"description":166,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":167,"categories":168,"keywords":169,"publishedAt":34},"01M6DT98AWQ27P0N1CG97WAG66","kaizen:why","Iterative Five Whys root cause analysis drilling from symptoms to fundamentals","https:\u002F\u002Fgithub.com\u002FAntifragileTech\u002Fantifragile-claude-code\u002Fblob\u002Fmaster\u002Fassets\u002Fskills\u002Fthinking\u002Fwhy\u002FSKILL.md",[],[165,170,171,172,173,22,174],"why","kaizen","issue","five whys","root cause analysis",{"skillNo":176,"name":177,"nameZh":6,"description":178,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":179,"categories":180,"keywords":181,"publishedAt":34},"01M6DT93EH25NAX19R3WGE1P53","verification-loop","A comprehensive verification system for Claude Code sessions.","https:\u002F\u002Fgithub.com\u002FAntifragileTech\u002Fantifragile-claude-code\u002Fblob\u002Fmaster\u002Fassets\u002Fskills\u002Fthinking\u002Fverification-loop\u002FSKILL.md",[],[182,183,184,185,146,186,187],"verification loop","verification","loop","sessions","claude code sessions","system",{"skillNo":189,"name":190,"nameZh":6,"description":191,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":192,"categories":193,"keywords":194,"publishedAt":34},"01M6DT90GW7Z7VCN98P9DVYSNC","verification-before-completion","Use when about to claim work is complete, fixed, or passing, before committing or creating PRs - requires running verification commands and confirming output before making any success claims; evidence before assertions always","https:\u002F\u002Fgithub.com\u002FAntifragileTech\u002Fantifragile-claude-code\u002Fblob\u002Fmaster\u002Fassets\u002Fskills\u002Fthinking\u002Fverification-before-completion\u002FSKILL.md",[],[195,183,196,131,129,197,198,199],"verification before completion","commands","evidence","claim","complete"]