Solidity Function Selector

About Solidity Function Selector

The Solidity Function Selector tool helps developers work with Ethereum smart contract function selectors and event signatures. Function selectors are the first 4 bytes of the Keccak256 hash of a function signature and are used to identify which function to call in a smart contract. Event signatures (Topic0) are the full 32-byte Keccak256 hash of the event signature. This tool generates selectors from signatures and looks up common selectors in a built-in database.

What is a function selector?

A function selector is a 4-byte identifier used in Ethereum to specify which function to call in a smart contract. It's calculated as the first 4 bytes of the Keccak256 hash of the function signature. For example, the function signature 'transfer(address,uint256)' generates the selector '0xa9059cbb'.

How are function selectors calculated?

Function selectors are calculated by:
1. Creating the function signature (e.g., 'transfer(address,uint256)')
2. Computing the Keccak256 hash of the signature
3. Taking the first 4 bytes (8 hex characters) of the hash
4. Prepending '0x' to create the selector

What is an event signature (Topic0)?

An event signature, also known as Topic0, is the full 32-byte Keccak256 hash of an event signature. Unlike function selectors which use only 4 bytes, event signatures use the complete hash. This is used to identify events in transaction logs. For example, 'Transfer(address,address,uint256)' generates a unique 32-byte Topic0.

Why lookup function selectors?

When analyzing smart contracts or transactions, you often encounter raw function selectors (like 0xa9059cbb) without knowing what function they represent. Looking up selectors helps you understand what functions are being called. This is especially useful for debugging, auditing, or understanding unfamiliar contracts.

What is the difference between function and event selectors?

Function selectors are 4 bytes (8 hex chars) and identify function calls, while event signatures are 32 bytes (64 hex chars) and identify events in logs. Function selectors are used in transaction input data, while event signatures appear as Topic0 in transaction logs.

What is the difference between a function selector and event Topic0?

Function selector is the first 4 BYTES of Keccak256(funcName(types)) used in transaction calldata. Event Topic0 is the FULL 32 bytes of Keccak256(EventName(types)) used as the first topic in event logs. Functions are tight (4-byte) because calldata costs gas; events use full hash because logs are off-chain searchable indexes.

Why must I use Keccak-256 instead of SHA3-256 for Ethereum?

Ethereum standardized on the pre-NIST submission Keccak-256 BEFORE NIST tweaked it into the final SHA3 standard (which added padding). Many cryptographic libraries call the Ethereum variant keccak256 to distinguish it. SHA3-256 and Keccak-256 produce DIFFERENT hashes for the same input — using SHA3 gives wrong selectors.

Can two different functions accidentally share the same 4-byte selector?

Yes, this is called a selector collision. The chance is roughly 1 in 4.3 billion per function pair (2^32). The infamous Solidity 0x42966c68 collision: burn(uint256) and burn_uint256_(uint256). When deploying, modern compilers warn on collisions within one contract. The risk is mainly with proxy patterns where you control delegatecall routing.

How do I lookup an unknown 4-byte selector found on Etherscan?

Paste it into 4byte.directory or Openchain.xyz signature databases — they host millions of canonicalized signatures crowdsourced from verified contracts. This tool links to both. If the selector is not in the database, the function likely came from an unverified contract or a private DEX strategy; you can sometimes match the calldata pattern.

What are the canonical signature rules, and why does 'uint' give a different selector than 'uint256'?

Solidity hashes a strict canonical form: NO spaces, every type spelled out in full. 'uint' is an alias for 'uint256', 'int' for 'int256', and 'byte' for 'bytes1' — but the selector is the Keccak-256 of the literal string, so 'transfer(address, uint256)' with a space, or 'transfer(address,uint)', hashes to a value that will NEVER match the deployed contract. Tuples (structs) are written as parenthesized type lists, e.g. exactInputSingle((address,address,uint24,...)), and array suffixes like [] or [3] are kept. This tool normalizes your input and shows the exact canonical signature it hashed, so you can verify it before signing a transaction.

How does the 4-byte selector relate to the calldata of a transaction?

Transaction input data = the 4-byte selector followed by ABI-encoded arguments, each padded to a 32-byte (64 hex char) word. Static types (address, uint256, bool) sit inline in their head slot; dynamic types (bytes, string, T[]) put a 32-byte OFFSET in the head slot that points to length+data in the tail. So reading tx input is: strip the first 4 bytes to identify the function, then slice the remainder into 32-byte words per the signature. The Calldata Template in this tool gives you that skeleton (selector + one zeroed word per top-level argument) to paste into eth_call or cast and fill in.

Key Features

• Generate function selectors (4 bytes) from signatures
• Generate event signatures (Topic0, 32 bytes)
• Display full Keccak256 hash
• Lookup common function selectors in built-in database
• Validate signature and selector formats
• Load random examples for testing
• Links to external signature databases (4byte.directory, Openchain)
• Includes 30+ common ERC20, DeFi, and governance selectors
• Client-side computation for privacy