Contract Interface Extraction from Bytecode Only

WHAT IT DOES

Contract Interface Extraction from Bytecode Only takes a contract address and reads its runtime bytecode directly from the EVM chain using eth_getCode. It then scans the bytecode for all PUSH4 (0x63) opcodes followed by 4 bytes, extracting every function selector embedded in the contract's dispatch table. This gives you the complete set of callable functions that the contract exposes, without requiring any ABI, source code, or external database. The tool displays each selector as a 0x-prefixed 8-character hex string, along with the bytecode size and the number of PUSH4 instructions found. It also shows the offset positions where each selector appears in the bytecode, helping you understand where the compiler placed the dispatch table entries. This is invaluable when you have a contract without verified source code, when you suspect an ABI is incomplete or incorrect, when you're reverse-engineering a contract, or when you want to verify which functions are actually present in a deployed contract versus what an ABI claims. The tool works on any EVM contract, including tokens, DeFi protocols, NFT contracts, and governance systems.

HOW TO USE

Connect your wallet to select the target EVM network. Enter the contract address you want to analyze. Click "Extract Interface". The tool fetches the full runtime bytecode from the chain using your connected provider. It scans every byte of the code, looking for the PUSH4 instruction (byte value 0x63). Whenever it finds a PUSH4, it reads the next 4 bytes and treats them as a potential function selector. The tool deduplicates selectors and presents them sorted alphabetically. Results include a statistics dashboard showing total selectors found, bytecode size in bytes, and the number of PUSH4 instructions detected. The selector list is displayed as clickable/tappable chips that you can copy to your clipboard as a JSON array. For deeper inspection, the tool displays the first 50 PUSH4 offsets so you can see exactly where each selector lives in the bytecode. You can use these selectors to build a minimal ABI, to check for unannounced functions, or to verify that a contract matches what its documented interface claims to expose.

THE REAL MECHANISM

The Solidity compiler emits a PUSH4 instruction followed by the 4-byte function selector for every public and external function in the contract. These appear in the dispatcher—the part of the bytecode that routes incoming calldata to the correct function implementation. The tool performs a raw binary scan of the runtime bytecode, not the creation bytecode. It looks for the byte sequence 0x63 followed by any 4 bytes. While a few other opcodes could produce similar patterns, the PUSH4 + selector pattern is highly reliable for identifying the dispatch table because the compiler places these at predictable locations near the beginning of the contract's code section. The tool uses a simple sliding window that walks the bytecode two characters at a time, checking for 0x63 and then extracting the next 8 hex characters. This approach captures all selectors regardless of compiler version (Solidity 0.4.x through 0.8.x) and works with both legacy and modern compilation outputs. The tool does not attempt to decode or interpret the selectors—it simply presents the raw data, allowing you to then look up those selectors in signature databases like Etherscan's or use them with an interface like the ABI Decoding Playground Tool.

WHAT IT CANNOT SEE

This tool cannot recover function names, parameter names, parameter types, return types, or any comments from the bytecode. It cannot distinguish between public and external functions—both produce selectors. It cannot detect events, error types (including custom errors), or modifiers. It cannot see the actual function implementation code or determine what the function does. The tool cannot decode constructor arguments or the initialization code that ran when the contract was deployed. It cannot identify proxy implementation contracts because the proxy's bytecode is minimal and the implementation logic resides elsewhere—you would need to analyze the proxy's implementation address separately. The tool cannot detect functions that are only reachable via delegatecall or functions that are part of the fallback or receive functions. It also cannot tell you if a selector corresponds to a function that has been removed or recompiled in a newer version but the old selector remains in the bytecode. The tool does not verify that the extracted selectors are actually reachable or that they correspond to valid function signatures—it just reports what it finds in the binary.

PLEASE NOTE

Contract Interface Extraction from Bytecode Only works exclusively with Ethereum Virtual Machine (EVM) compatible chains including Ethereum, Goerli, Sepolia, Polygon, BSC, Arbitrum, Optimism, Avalanche, and others. The tool requires the contract address to be valid on the selected network and for the node to support eth_getCode. It reads bytecode only and does not send any transactions or modifications to the blockchain. All processing occurs client-side in your browser; no data is sent to any external server. The tool is free to use and does not require authentication. For contracts compiled with optimizations that inline function selectors differently, the tool may occasionally miss selectors or include false positives, though this is rare with modern compilers.