Token Integration Analyzer

Assessment Categories Reference

This document contains detailed assessment criteria for token analysis. Each category includes what to check, analysis methods, and verification checklists.

1. GENERAL CONSIDERATIONS

What I'll check:

• Security review history

• Team contacts and transparency

• Security mailing list existence

I'll ask you:

• Has this token been audited?

• Is the team contactable?

• Is there a security mailing list?

Best practices:

• Interact only with reviewed tokens

• Maintain contact with token teams

• Subscribe to security announcements

2. CONTRACT COMPOSITION

What I'll analyze:

Complexity:

• Overall contract complexity

• Lines of code

• Inheritance depth

• Function count

• Use Slither's human-summary printer

SafeMath Usage (pre-0.8 Solidity):

• Arithmetic operations protection

• Unchecked blocks justification

Non-token Functions:

• Functions beyond standard ERC interface

• Unnecessary complexity

• Use Slither's contract-summary printer

Single Address Entry Point:

• Multiple addresses pointing to same token

• Proxy patterns that create multiple entry points

Checks:

• [ ] Contract avoids unnecessary complexity

• [ ] Contract uses SafeMath or Solidity 0.8+ (for Solidity)

• [ ] Contract has only a few non-token-related functions

• [ ] Token has only one address entry point

3. OWNER PRIVILEGES

What I'll check:

Upgradeability:

• Proxy patterns (UUPS, Transparent, Beacon)

• Implementation change mechanisms

• Use Slither's human-summary printer

Minting Capabilities:

• Unlimited vs limited minting

• Minting access controls

• Total supply caps

Pausability:

• Pause mechanisms

• Who can pause

• Impact on existing holders

Blacklisting:

• Blocklist functionality

• Admin controls

• USDC/USDT-style blocklists

Team Transparency:

• Known team members

• Legal jurisdiction

• Accountability

Checks:

• [ ] Token is not upgradeable (or upgrade risks understood)

• [ ] Owner has limited minting capabilities

• [ ] Token is not pausable (or pause risks understood)

• [ ] Owner cannot blacklist addresses (or risks understood)

• [ ] Team is known and accountable

4. ERC20 CONFORMITY CHECKS

What I'll analyze:

Return Values:

• transfer returns bool

• transferFrom returns bool

• Missing returns (USDT, BNB, OMG pattern)

• False returns (Tether Gold pattern)

Function Presence:

• name, decimals, symbol existence

• Optional functions handling

Decimals Type:

• Returns uint8

• Value below 255

• Low decimals (USDC: 6, Gemini USD: 2)

• High decimals (YAM-V2: 24)

Race Condition Mitigation:

• ERC20 approve race condition

• Increase/decrease allowance pattern

• USDT/KNC approval protection

Slither Tools:

• Run slither-check-erc for automated checks

• Run slither-prop to generate properties

Checks:

• [ ] transfer and transferFrom return boolean

• [ ] name, decimals, symbol present if used

• [ ] decimals returns uint8 with value < 255

• [ ] Token mitigates ERC20 race condition

• [ ] Contract passes slither-check-erc tests

• [ ] Contract passes slither-prop generated tests

5. ERC20 EXTENSION RISKS

What I'll check:

External Calls in Transfers:

• ERC777 hooks

• Reentrancy risks

• tokensReceived callbacks

• Check for: Amp (AMP), imBTC patterns

Transfer Fees:

• Deflationary tokens

• Fee-on-transfer (STA, PAXG)

• Future fee risks (USDT, USDC can add fees)

• Balance checks after transfer

Interest/Yield Bearing:

• Rebasing tokens (Ampleforth)

• Airdropped governance tokens

• Compound-style interest

• Cached balance issues

Checks:

• [ ] Token is not ERC777 or has no external calls in transfer

• [ ] transfer/transferFrom do not take fees

• [ ] Interest earned from token is accounted for

6. TOKEN SCARCITY ANALYSIS

What I'll do:

For deployed tokens, I'll query on-chain data using web3/ethers:

Supply Distribution:

// Query holder distribution
// Check top 10 holders percentage
// Identify concentration risk

Total Supply:

// Query totalSupply
// Check if sufficient for manipulation resistance
// Identify low supply risk

Exchange Distribution:

// Query balance on major DEXs/CEXs
// Check if tokens concentrated in one exchange
// Identify single point of failure

Flash Loan Risk:

• Large fund attack potential

• Flash loan availability for this token

Flash Minting:

• Flash mint functions (DAI-style)

• Maximum mintable amount

• Overflow risks

Checks:

• [ ] Supply owned by more than a few users

• [ ] Total supply is sufficient

• [ ] Tokens located in more than a few exchanges

• [ ] Flash loan/large fund risks understood

• [ ] Token does not allow flash minting (or risks understood)

Note: I'll only perform on-chain analysis if you provide a contract address. Won't hallucinate if not applicable.

7. WEIRD ERC20 PATTERNS

I'll check for all 20+ known weird token patterns:

7.1 Reentrant Calls

• ERC777 tokens with hooks

• Transfer callbacks

• Historical exploits: imBTC Uniswap, lendf.me

Tokens: Amp (AMP), imBTC

7.2 Missing Return Values

• No bool return on transfer/transferFrom

• Some methods return, others don't

• False returns on success (Tether Gold)

Tokens: USDT, BNB, OMG, Tether Gold

7.3 Fee on Transfer

• Transfer fees (STA, PAXG)

• Future fee capability (USDT, USDC)

• Deflationary mechanics

Exploit: Balancer STA hack ($500k)

7.4 Balance Modifications Outside Transfers

• Rebasing tokens (Ampleforth)

• Governance airdrops (Compound)

• Mintable/burnable by admin

• Cached balance risks

7.5 Upgradable Tokens

• USDC, USDT upgradeability

• Logic change risks

• Freeze integration on upgrade

7.6 Flash Mintable

• DAI flash mint module

• type(uint256).max supply risk

• One-transaction minting

7.7 Blocklists

• USDC, USDT blocklists

• Admin-controlled blocking

• Contract trap risk

• Regulatory/extortion risk

7.8 Pausable Tokens

• BNB, ZIL pause functionality

• Admin pause risk

• User fund trap

7.9 Approval Race Protections

• USDT, KNC approval restrictions

• Cannot approve M > 0 when N > 0 approved

• Integration issues

7.10 Revert on Approval to Zero Address

• OpenZeppelin pattern

• approve(address(0), amt) reverts

• Special case handling needed

7.11 Revert on Zero Value Approvals

• BNB pattern

• approve(address, 0) reverts

• Approval reset issues

7.12 Revert on Zero Value Transfers

• LEND pattern

• Zero amount transfers fail

• Edge case handling

7.13 Multiple Token Addresses

• Proxied tokens with multiple addresses

• Address-based tracking broken

• Rescue function exploits

7.14 Low Decimals

• USDC: 6 decimals

• Gemini USD: 2 decimals

• Precision loss amplified

7.15 High Decimals

• YAM-V2: 24 decimals

• Overflow risks

• Liveness issues

7.16 transferFrom with src == msg.sender

• DSToken: no allowance decrease

• OpenZeppelin: always decrease

• Different semantics

7.17 Non-string Metadata

• MKR: bytes32 name/symbol

• Metadata consumption issues

• Type casting needed

7.18 Revert on Transfer to Zero Address

• OpenZeppelin pattern

• Burn mechanism broken

• Zero address handling

7.19 No Revert on Failure

• ZRX, EURS pattern

• Returns false instead of reverting

• Forgotten require wrapping

7.20 Revert on Large Approvals

• UNI, COMP: max uint96

• uint256(-1) special case

• Allowance mapping mismatch

7.21 Code Injection via Token Name

• Malicious JavaScript in name

• Frontend exploits

• Etherdelta hack pattern

7.22 Unusual Permit Function

• DAI, RAI, GLM non-EIP2612 permit

• No revert on unsupported permit

• Phantom function execution

7.23 Transfer Less Than Amount

• cUSDCv3 type(uint256).max handling

• Only balance transferred

• Vault accounting broken

7.24 ERC-20 Native Currency Representation

• Celo: CELO token

• Polygon: POL token

• zkSync Era: ETH token

• Double spending risks

Exploit: Uniswap V4 critical vulnerability

For each pattern I'll:

• Search for implementation

• Assess risk level

• Check integration safety

• Provide mitigation strategies

8. TOKEN INTEGRATION SAFETY

If analyzing a protocol that integrates tokens:

What I'll check:

Safe Transfer Pattern:

// Check for proper transfer handling
// Verify return value checking
// Look for SafeERC20 usage

Balance Verification:

// Check balance before and after
// Don't assume transfer amount = actual amount
// Fee-on-transfer protection

Allowlist Pattern:

// Contract-level allowlist
// Known good tokens
// UI-level filtering

Wrapper Contracts:

// Edge wrappers for external tokens
// Consistent internal semantics
// Isolation of weird behavior

Defensive Patterns:

• Reentrancy guards on token interactions

• Balance caching strategies

• Upgrade detection mechanisms

• Zero value handling

• Return value verification

9. ERC721 CONFORMITY CHECKS

What I'll analyze:

Transfer to 0x0:

• Should revert per standard

• Burning mechanism

• Token loss prevention

safeTransferFrom Implementation:

• Correct signature

• onERC721Received callback

• NFT loss to contracts

Metadata Functions:

• name, symbol presence

• Can return empty string

• decimals returns uint8(0) if present

ownerOf Behavior:

• Reverts for invalid tokenId

• Reverts for burned tokens

• Never returns 0x0

Transfer Clears Approvals:

• Per standard requirement

• Approval state management

Token ID Immutability:

• ID cannot change during lifetime

• Per standard requirement

Checks:

• [ ] Transfers to 0x0 revert

• [ ] safeTransferFrom implemented correctly

• [ ] name, symbol present if used

• [ ] decimals returns uint8(0) if present

• [ ] ownerOf reverts for invalid/burned tokens

• [ ] Transfers clear approvals

• [ ] Token IDs immutable during lifetime

10. ERC721 COMMON RISKS

What I'll check:

onERC721Received Callback:

• Reentrancy via callback

• safeMint risks

• External call ordering

Safe Minting to Contracts:

• Minting functions behave like safeTransferFrom

• Prevent NFT loss to contracts

• Handle contract recipients

Burning Clears Approvals:

• Burn function existence

• Approval clearing

• Approval state after burn

Checks:

• [ ] onERC721Received callback reentrancy protected

• [ ] NFTs safely minted to smart contracts

• [ ] Burning tokens clears approvals

Slither Integration

Commands I'll Help Run

ERC Conformity Check:

# For ERC20
slither-check-erc [address-or-path] TokenName --erc erc20

# For ERC721
slither-check-erc [address-or-path] TokenName --erc erc721

Contract Analysis:

# Human-readable summary (complexity, upgrades, etc.)
slither [target] --print human-summary

# Function and modifier summary
slither [target] --print contract-summary

Property Generation:

# Generate test properties for Echidna/Manticore
slither-prop . --contract TokenName

Note: I'll adapt based on whether tools are available. I can work without Slither but recommend using it for Solidity projects.

On-chain Analysis Integration

Querying Deployed Contracts

If you provide a contract address, I can query on-chain data:

Setup:

// I'll use web3.js or ethers.js
const Web3 = require('web3');
const web3 = new Web3('RPC_URL');

Token Information:

// Query basic info
const name = await token.methods.name().call();
const symbol = await token.methods.symbol().call();
const decimals = await token.methods.decimals().call();
const totalSupply = await token.methods.totalSupply().call();

Holder Analysis:

// Query top holders
// Calculate concentration
// Identify whale risk

Exchange Analysis:

// Query balances on Uniswap, Curve, etc.
// Check centralization in single exchange

Configuration:

// Query owner/admin
// Check pause status
// Verify upgrade configuration

Note: I'll only perform on-chain queries if you provide an address and RPC endpoint. Won't hallucinate if not applicable.

Known Non-Standard Tokens Database

I have comprehensive knowledge of known non-standard tokens:

Missing Revert

• Basic Attention Token (BAT)

• Huobi Token (HT)

• Compound USD Coin (cUSDC)

• 0x Protocol Token (ZRX)

Transfer Hooks (Reentrant)

• Amp (AMP)

• The Tokenized Bitcoin (imBTC)

Missing Return Data

• Binance Coin (BNB) - only on transfer

• OMGToken (OMG)

• Tether USD (USDT)

Permit No-op

• Wrapped Ether (WETH)

Additional Non-Standard

• USDC: upgradeable, 6 decimals

• DAI: non-standard permit, flash mintable

• UNI, COMP: revert on large approvals (>= 2^96)

I'll check if your codebase interacts with any of these and verify proper handling.