What is CallData?
Transaction calldata contains:- Function Selector (4 bytes) - Identifies which function to call
- Encoded Parameters (variable length) - ABI-encoded function arguments
Example: ERC20 Transfer
Callingtransfer(address to, uint256 amount):
Function Selectors
The function selector is the first 4 bytes of the keccak256 hash of the function signature:Canonical Function Signatures
Function signatures must follow strict formatting:- No spaces:
transfer(address,uint256)✅ nottransfer(address, uint256)❌ - Full type names:
uint256✅ notuint❌ - No parameter names:
(address,uint256)✅ not(address to, uint256 amount)❌
How the EVM Processes CallData
The EVM does not automatically decode calldata. Contract bytecode manually reads calldata using specialized opcodes.1. Transaction Arrives
2. EVM Loads Contract Bytecode
3. Bytecode Dispatcher Runs
Solidity compilers generate a “dispatcher” that reads the selector and jumps to the appropriate function:4. Function Code Reads Parameters
When execution jumps to thetransfer function:
EVM Opcodes for CallData
The EVM provides three opcodes for accessing calldata:CALLDATALOAD
offset:
CALLDATASIZE
CALLDATACOPY
CallData vs Bytecode
| CallData | Bytecode |
|---|---|
| Transaction data field | Contract code deployed at address |
| Contains function calls | Contains instructions to execute |
| Read via CALLDATALOAD | Executed instruction-by-instruction |
| Temporary (per transaction) | Permanent (stored on-chain) |
| User-provided | Compiler-generated |
Gas Costs
CallData has specific gas costs (post-EIP-2028):- Zero bytes: 4 gas per byte
- Non-zero bytes: 16 gas per byte
Special Cases
Empty CallData
Sending ETH to an EOA or calling fallback/receive functions:Constructor CallData
Contract deployment transactions contain bytecode + constructor parameters:See Also
- Encoding - Deep dive into ABI encoding
- Decoded Form - CallDataDecoded structure
- Usage Patterns - Common patterns
- EVM Opcodes - Complete opcode reference

