Ethereum token research begins with chain ID and contract address, then follows implementation, roles, upgradeability, supply, holders, DEX pools, centralized venues, transfers, protocol activity, and layer-2 representations. A familiar ERC-20 interface does not eliminate custom logic or external dependencies, so every layer remains visible.
Keep each data family traceable so one attractive metric cannot silently override missing identity, liquidity, supply, or control information.
Resolve chain, exact contract, decimals, deployment, migrations, wrapped forms, bridge forms, and provider mappings.
Review verified source, ERC-20 behavior, extensions, custom transfer logic, proxy implementation, and decoder coverage.
Map owners, role administrators, multisignatures, timelocks, guardians, proxy admins, and every privileged action.
Reconcile supply, mint and burn paths, vesting, treasuries, bridges, staking, raw balances, and adjusted concentration.
Inspect active DEX liquidity, fee tiers, routes, price impact, centralized markets, transfer networks, and concentration.
Separate transfers, swaps, bridges, protocol actions, and chain-specific representations across Ethereum and layer 2.
A useful scan is a documented sequence with clear failure states, not a mysterious score that always produces a candidate.
Confirm the exact contract and chain and classify native, bridged, wrapped, proxy, or migrated representations.
Resolve implementation, nonstandard transfer behavior, privileged roles, upgrade paths, and external contract dependencies.
Reconcile supply and holders, then evaluate pools, venues, activity, liquidity, and benchmark-relative chart behavior.
Save contract and decoder versions, label confidence, missing fields, and the reason for reject, monitor, or investigate.
Scanner results become more trustworthy when their blind spots are displayed beside the output.
Source verification does not certify security, economic design, or future behavior under privileged upgrades.
Holder addresses may be contracts, custodians, pools, or multiple wallets controlled by one entity.
The same symbol can have different contracts, bridges, liquidity, controls, and execution conditions on each network.
Move from the page-level framework into a detailed, source-linked research workflow.
Screen Ethereum tokens by contract address, ERC-20 behavior, roles, upgradeability, supply, holders, pools, transfer activity, layer-2 deployment, and market quality.
Read the guide →
Screen DeFi tokens with protocol category, liquidity, usage, revenue, incentives, token value capture, governance, contract controls, oracle exposure, and cross-chain risk.
Read the guide →
A structured checklist for verifying a new token’s identity, contract controls, supply, holders, liquidity, deployer history, market data, and project claims.
Read the guide →It is a system that reads contract, supply, holder, market, and activity data for a specific token address and applies documented research rules.
A proxy delegates logic to an implementation contract that may be upgradeable. The current implementation and upgrade authority are material.
Not directly. Custodians can represent many users, one entity can use many wallets, and contracts can dominate balances.
Use an aggregate ecosystem view only alongside chain-specific contracts, bridge mechanisms, liquidity, controls, and execution data.
Start with a defined universe, combine independent signals, and record why each candidate survives or fails the scan.