slither icon indicating copy to clipboard operation
slither copied to clipboard

Enhancement: Add Automatic Token Standard Detection Printer

Open dguido opened this issue 4 months ago • 1 comments

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 avatar Aug 29 '25 17:08 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

dguido avatar Aug 29 '25 18:08 dguido