Dead Code Detector in Deployed Contracts
Free to download on every platform. Comes pre-installed on BotFone, BotPad and BotFlip — with extra free apps included.
About this app
WHAT IT DOES
This tool analyzes deployed smart contracts to identify functions that have never been called—so-called "dead code." By fetching the contract's bytecode and extracting all possible 4-byte function selectors, then cross-referencing this against historical transaction logs across a user-defined block range, it determines which functions are actively used and which are dormant. The results are presented as a ranked table showing each function's selector, call count, percentage of total calls, and a clear "active" or "dead" status. A visual bar chart highlights the distribution, and a prominent summary shows the total number of dead functions discovered. This is essential for developers looking to remove unused code, auditors assessing contract bloat, and teams optimizing gas costs by eliminating unnecessary functionality.
HOW TO USE
Connect your wallet (read-only, no transaction required) and select the target network. Enter the contract address you want to analyze, specify the block range (start and end blocks), and set a chunk size for log scanning. Click "detect dead code" and the tool will first fetch the contract's bytecode to extract all possible function selectors, then scan the specified range for transaction logs, extracting method IDs from calldata. Results display with dead functions clearly marked, alongside a summary of dead vs. active functions, and a detailed breakdown table. Use this data to identify functions that can be safely removed from future contract versions, reducing deployment costs and attack surface.
TECHNICAL MECHANISM
The analyzer uses ethers.js v5.7.2 to perform three main operations. First, it calls eth_getCode to retrieve the contract's runtime bytecode, then scans the bytecode hex string for all 4-byte sequences that match the pattern of a function selector (0x followed by 8 hex digits), building a comprehensive set of all possible function signatures the contract could handle. Second, it performs eth_getLogs queries across the specified block range, automatically handling RPC rate limits through a chunk-and-halve strategy that reduces chunk size on failure until the scan completes. Third, for each log found, it fetches the associated transaction data and extracts the first 4 bytes of calldata (the method ID actually called). The tool then compares the set of all possible selectors against the set of called selectors, marking any selector that appears in the bytecode but has zero calls as "dead code." Results are sorted with dead functions first for immediate visibility, and percentages are calculated based on total call distribution.
WHAT IT CANNOT SEE
This tool cannot detect functions that are never called but still emit logs through internal mechanisms, as it relies on calldata analysis. It cannot differentiate between intentionally unused functions and dead code that was never deployed. It is limited by the RPC provider's historical block range availability and rate limits. It cannot see internal transactions or delegate calls that do not emit logs, meaning functions invoked via DELEGATECALL may appear dead even if used. Method ID matching may produce false positives if different functions share the same 4-byte signature (though this is extremely rare). It cannot analyze contracts that have not been verified or do not emit logs, as logs are required to detect transactions. The accuracy of results depends on the completeness and reliability of the underlying RPC data and event emissions. It cannot detect dead code in libraries or contracts that are called via DELEGATECALL without logs, as those calls bypass the contract's own log emissions.
PLEASE NOTE
This is a read‑only analytics tool—it never submits transactions or signs anything. It is designed for EVM‑compatible chains. For best results, use an archival RPC node with broad historical access. The tool works best on contracts that emit events on every transaction; contracts without logs will produce no results. The selector extraction from bytecode is heuristic and may miss selectors that are not present in the runtime bytecode in a recognizable 4-byte pattern.