Calldata

Calldata is a read-only, non-modifiable data area in an Ethereum transaction that contains the function signature and arguments passed to a smart contract. It is the primary input mechanism for contract execution.

• Location: Exists outside the EVM's memory and storage.
• Purpose: Specifies which function to call and what data to pass.
• Structure: Begins with a 4-byte function selector, followed by ABI-encoded arguments.

Using calldata is cheaper than using memory or storage for data input in many scenarios. The gas cost is based on two rules:

• Non-zero bytes: Cost 16 gas each.
• Zero bytes: Cost 4 gas each (68 gas post-EIP-2028).

This incentivizes efficient encoding, such as using smaller integer types (uint8 vs uint256) and packing multiple arguments into bytes to maximize zero bytes.

A critical optimization is declaring function arguments as calldata instead of memory for reference types (arrays, structs, strings).

• calldata: Arguments are read directly from the transaction data. No copy cost.
• memory: Arguments are copied from calldata into a new memory location, incurring significant allocation gas.

Rule: Use calldata for all external function inputs unless you need to modify them within the function.

The Application Binary Interface (ABI) defines how to encode data into calldata. The first 4 bytes are the function selector, a hash of the function signature (e.g., transfer(address,uint256)).

• Example: transfer(address,uint256) selector is 0xa9059cbb.
• Optimization: Using existing, standardized function signatures (like ERC-20's) avoids the need for custom encoding logic and reduces contract size.

Calldata is ideal for batch operations where the contract processes a list of inputs. Passing an array of structs or addresses as calldata is far more gas-efficient than multiple individual transactions.

Example: An airdrop contract that takes a calldata array of (address, uint256) pairs can process hundreds of transfers in one transaction, saving massively on base transaction fees (21,000 gas per tx).

While optimized for reading, calldata has constraints.

• Immutable: Data cannot be modified by the contract.
• External Only: The calldata location is only valid for parameters of external functions. Public functions can use it if called externally.
• Best Practice: Always use the smallest, most packed data representation possible and audit ABI encoding off-chain to minimize byte size before submission.

Calldata is the cheapest data location for passing arguments to a contract function, as it is non-persistent and read-only. Unlike storage, writing to calldata is impossible, and unlike memory, it is not allocated within the EVM for the contract's execution. This makes it ideal for bulk data that only needs to be read, such as signatures, proofs, or batch operation parameters. Its cost was significantly reduced by EIP-2028, making Layer 2 solutions like Optimistic Rollups more economical.

The first 4 bytes of calldata are the function selector, a hash of the function signature. The remaining bytes contain the ABI-encoded arguments. For example, a call to transfer(address,uint256) encodes the recipient address and token amount into a predictable byte sequence. Off-chain clients and indexers decode this calldata to interpret transaction intent. Understanding this structure is essential for building wallets, explorers, and interacting with contracts programmatically.

Every external call to a smart contract uses calldata. Common examples include:

• Sending tokens via a transfer function.
• Approving a spender with an approve call.
• Swapping assets on a decentralized exchange (DEX).
• Submitting a bid in an auction contract. The calldata contains all the necessary instructions for the contract to execute the specific function with the provided parameters.

Using calldata for function parameters in view and pure functions, or in internal functions that pass on data without modification, saves gas. Since Solidity 0.6.9, you can declare parameters as calldata instead of memory for reference types (like arrays, strings). This prevents an expensive copy operation, as the function reads directly from the immutable transaction data.

Calldata is the cheapest data location for input parameters, costing 4 gas for a zero byte and 16 gas for a non-zero byte. However, functions that process unbounded calldata arrays (e.g., airdrops) can be exploited for gas griefing, causing transactions to fail or become prohibitively expensive. Contracts must implement reasonable limits on input size to prevent denial-of-service attacks.

Malformed or maliciously encoded calldata is a primary attack vector. Key risks include:

• Signature Replay: Using abi.encodePacked for signed messages can create hash collisions.
• Type Confusion: Improper use of abi.decode can lead to misinterpretation of data.
• Selector Clashing: Custom function selectors may conflict, leading to unintended function execution. Always use abi.encode, validate data length/range, and employ checks-effects-interactions.

When using delegatecall, the entire calldata context (including msg.sender and msg.value) is forwarded to the logic contract. If the calldata is not validated before delegation, an attacker can craft calls that exploit the logic contract's state from the proxy's context. This is critical in proxy upgrade patterns and requires strict access control on the delegatecall entry point.

When sending Ether via low-level calls (e.g., addr.call{value: x}("")), any calldata provided is executed by the recipient's fallback function. An attacker's contract can use this calldata to re-enter the calling function before state updates are finalized. The Checks-Effects-Interactions pattern and using transfer or send (which forward limited 2300 gas) mitigate this, but the safest practice is to complete all state changes before any external call.

Calldata is public on-chain data from the moment a transaction is broadcast to the mempool. This exposes:

• Function arguments (e.g., token amounts, wallet addresses).
• Contract logic intent before execution.
• Signature parameters for permit functions. Malicious actors can frontrun transactions by copying and replacing the calldata with a higher gas fee. Solutions include using commit-reveal schemes or private mempools.

Zero-knowledge proofs, like those used in zk-Rollups, often use calldata as a data availability layer. The security of the system depends on the integrity and availability of this posted data. If calldata is withheld or corrupted, proofs cannot be verified, potentially freezing funds. This highlights the role of Ethereum calldata as a secure, immutable bulletin board for layer-2 state transitions.

Transaction data is the raw, encoded information included in a transaction that specifies the contract call and its arguments. It is the on-chain representation of calldata. This data is immutable, publicly visible, and is a primary factor in determining a transaction's gas cost, especially on networks like Ethereum where storage is expensive.

ABI (Application Binary Interface) Encoding is the process of converting function calls and their parameters into the low-level bytecode that makes up calldata. It defines the standard for how data is packed and parsed. Key encoding formats include:

• abi.encode(): For general-purpose, non-standardized arguments.
• abi.encodePacked(): Creates tightly packed data for gas efficiency (e.g., hashing).
• abi.encodeWithSignature(): Encodes data along with a function signature.

Memory is a volatile, expandable byte-array used for temporary data storage during contract execution. It is distinct from calldata, which is immutable input data. When a function is called, parameters marked as memory are copied from calldata into this temporary workspace, incurring gas costs. Understanding the calldata vs. memory distinction is critical for writing gas-efficient functions, especially for array and struct parameters.

EIP-4844 introduces blob-carrying transactions, a new transaction type designed to reduce the cost of calldata for Layer 2 rollups. Instead of posting large data batches directly to calldata, rollups can attach data blobs, which are large, temporary data packets stored separately and cheaper for about 18 days. This significantly lowers the cost of data availability, a major expense for scaling solutions.

The function selector is the first 4 bytes of the calldata and uniquely identifies which function in a smart contract to execute. It is derived by taking the first 4 bytes of the Keccak-256 hash of the function's signature (e.g., transfer(address,uint256)). The EVM uses this selector to jump to the correct function logic, with the remaining calldata containing the encoded arguments for that function.

Using calldata effectively is a primary method for gas optimization. Key strategies include:

• Using calldata for read-only external function parameters instead of memory to avoid copy costs.
• Using abi.encodePacked for creating compact data for hashing operations.
• Minimizing the amount of data sent in transactions, as every non-zero byte costs 16 gas and every zero-byte costs 4 gas on Ethereum.
• Leveraging Layer 2 solutions or EIP-4844 blobs for bulk data.