Enhancement: Add Automatic Token Standard Detection Printer

[dguido]

Summary

Add a printer that automatically identifies and classifies token contracts (ERC-20, ERC-721, ERC-1155) based on their implemented interfaces, helping developers and auditors quickly understand the token landscape in a codebase.

Motivation

Token contracts are fundamental to the blockchain ecosystem, but identifying them in large codebases can be challenging:

1. Manual identification is error-prone - Tokens may not follow naming conventions
2. Partial implementations are common - Contracts may implement subsets of standards
3. Multiple token types - A codebase may contain various token standards
4. Integration requirements - External tools need to know which contracts are tokens
5. Security implications - Token contracts require specific security considerations

An automatic token detector would:

• Quickly identify all token contracts in a project
• Classify tokens by their standard (ERC-20, ERC-721, etc.)
• Detect partial or non-compliant implementations
• Aid in security reviews and integration planning

Token Detection Methodology

The printer identifies tokens by checking for standard function signatures and events:

ERC-20 Detection

• totalSupply(), balanceOf(address), transfer(address,uint256)
• allowance(address,address), approve(address,uint256), transferFrom(address,address,uint256)
• Transfer and Approval events

ERC-721 Detection

• balanceOf(address), ownerOf(uint256), safeTransferFrom variants
• transferFrom(address,address,uint256), approve(address,uint256)
• setApprovalForAll(address,bool), isApprovedForAll(address,address)
• Transfer, Approval, and ApprovalForAll events

ERC-1155 Detection

• safeTransferFrom(address,address,uint256,uint256,bytes)
• safeBatchTransferFrom(address,address,uint256[],uint256[],bytes)
• balanceOf(address,uint256), balanceOfBatch(address[],uint256[])
• setApprovalForAll(address,bool), isApprovedForAll(address,address)

Expected Output

Token Contract Analysis
=======================

ERC-20 Tokens (3 found):
-------------------------
1. MyToken (contracts/MyToken.sol:10)
   Confidence: HIGH (100% interface compliance)
   ✓ All required functions implemented
   ✓ All required events implemented
   
2. PartialToken (contracts/PartialToken.sol:25)
   Confidence: MEDIUM (83% interface compliance)
   ✓ 5/6 required functions implemented
   ✗ Missing: approve(address,uint256)
   ✓ All required events implemented

ERC-721 Tokens (2 found):
--------------------------
1. MyNFT (contracts/MyNFT.sol:15)
   Confidence: HIGH (100% interface compliance)
   ✓ All required functions implemented
   ✓ Includes metadata extension
   
2. BasicNFT (contracts/BasicNFT.sol:30)  
   Confidence: HIGH (89% interface compliance)
   ✓ Core functions implemented
   ✗ Missing: safeTransferFrom variants

ERC-1155 Tokens (1 found):
---------------------------
1. MultiToken (contracts/MultiToken.sol:20)
   Confidence: HIGH (100% interface compliance)
   ✓ All required functions implemented

Partial/Unknown Implementations (2 found):
-------------------------------------------
1. CustomToken (contracts/CustomToken.sol:40)
   Appears to be: Modified ERC-20
   Implements: 4/6 ERC-20 functions
   Note: May be intentionally non-standard
   
2. HybridToken (contracts/HybridToken.sol:50)
   Appears to be: ERC-20/721 Hybrid
   Warning: Implements conflicting interfaces

Summary Statistics:
-------------------
Total contracts analyzed: 45
Token contracts found: 8
- ERC-20: 3 (2 fully compliant, 1 partial)
- ERC-721: 2 (2 fully compliant)
- ERC-1155: 1 (1 fully compliant)
- Non-standard: 2

Advanced Features

Extension Detection

• Identify common extensions (Mintable, Burnable, Pausable for ERC-20)
• Detect metadata and enumerable extensions for ERC-721
• Flag non-standard modifications

Compliance Checking

• Verify function signatures match standards
• Check return types and modifiers
• Validate event parameters

Security Warnings

• Flag missing overflow protection in ERC-20
• Detect external calls in transfer functions
• Identify reentrancy risks

Command-Line Interface

# Basic usage
slither . --print token-detector

# With options
slither . --print token-detector \
  --token-threshold 0.8 \       # Min implementation % to classify
  --include-interfaces \         # Include interface contracts
  --check-extensions \           # Detect token extensions
  --export-json tokens.json     # Export results to JSON

Benefits

1. Quick project overview - Instantly understand token landscape
2. Integration planning - Know which contracts to integrate with
3. Security focus - Prioritize token contracts for review
4. Compliance verification - Ensure standard compliance
5. Documentation aid - Auto-generate token documentation

Priority

Medium - This printer provides immediate value for projects dealing with tokens, which represents a large percentage of smart contract development. It aids in documentation, security reviews, and integration efforts. The implementation is straightforward with high accuracy and clear benefits.

[dguido]

This is a great enhancement proposal that would complement the existing slither-check-erc tool nicely.

Current State vs Proposed Enhancement

The existing slither-check-erc tool already provides comprehensive ERC compliance checking, but it requires:

1. Manual specification of which contract to check (--contract ContractName)
2. Explicit ERC selection (--erc ERC20/ERC721/etc.)
3. One contract at a time analysis

Your proposed token detector printer would solve the discovery problem by:

• Automatically scanning all contracts in a codebase
• Auto-detecting which token standards each contract implements
• Providing a project-wide overview of the token landscape

Implementation Suggestion

Since slither-check-erc already has the logic for checking ERC compliance (in slither/utils/erc.py and slither/tools/erc_conformance/), the new printer could potentially:

1. Reuse existing ERC definitions from slither.utils.erc.ERCS which already includes:

   • ERC20, ERC223, ERC165, ERC721, ERC1820, ERC777, ERC1155, ERC2612, ERC1363, ERC4524, ERC4626

2. Leverage the signature checking logic from generic_erc_checks() to determine compliance percentages

3. Run in "discovery mode" - iterate through all contracts and test each against the known ERC signatures to determine which standards they likely implement

Workflow Integration

This would create a powerful two-step workflow:

1. Discovery: Run slither . --print token-detector to find all token contracts and their likely standards
2. Verification: Run slither-check-erc on specific contracts identified in step 1 for detailed compliance analysis

The proposed printer essentially provides the "what tokens do I have?" answer, while slither-check-erc provides the "is this token correctly implemented?" answer.

Additional Considerations

• The confidence scoring based on interface compliance percentage is excellent
• Consider adding a flag to export results in a format that can be piped directly to slither-check-erc for batch verification
• The existing slither-check-erc supports more token standards than just ERC20/721/1155, so the detector could potentially identify these as well