Function Selectors Explained in Detail
A function selector is the first 4 bytes of calldata for a Solidity function call. It is computed from the Keccak-256 hash of the canonical function signature, such as transfer(address,uint256).
The selector tells the contract dispatcher which function should handle the call.
Smart contract example
For an ERC-20 transfer, the signature is:
transfer(address,uint256)
The selector is:
0xa9059cbb
Calldata starts with that selector, followed by ABI-encoded arguments.
Function Selectors in Auditing
Selector handling can fail in subtle ways. A proxy, router, or module system may use selectors to decide which implementation receives a call.
If that mapping is wrong, incomplete, or collides with another function, a call may reach unintended code. Selectors are also relevant when reviewing delegatecall, external calls, fallback logic, and authorization that checks msg.sig.
Red flags in code
-
Authorization based only on
msg.sig. -
Manual calldata parsing in assembly.
-
Fallback functions that route arbitrary selectors.
-
Selector allowlists that are not tied to target addresses.
-
Upgradeable proxies with unclear admin selector handling.
-
Low-level calls built with hardcoded hex selectors.
-
Assumptions that selector uniqueness is guaranteed.
How to test or review it
-
Recompute important selectors with a trusted tool or the function selector calculator.
-
Check every place that reads
msg.sig, slices calldata, or storesbytes4values. -
Confirm each selector maps to the intended function and target contract.
-
For proxies and routers, test unknown selectors, admin-only selectors, overloaded functions, and selector collisions.
-
Review fallback behavior separately from normal Solidity function dispatch, especially in an upgradeable proxy.