Calldata

Calldata is a read-only, non-persistent data area in the Ethereum Virtual Machine (EVM) that contains the arguments passed to a smart contract function during an external call or transaction. It is a crucial component of the EVM execution context, acting as the primary input channel for function parameters and the function selector itself. Unlike contract storage, data in calldata is immutable for the duration of the call and is not stored on-chain after execution, making it a gas-efficient location for passing large amounts of data.

The structure of calldata is a tightly packed byte array. The first four bytes are the function selector, a hash of the function's signature used to identify which contract function to execute. The remaining bytes contain the ABI-encoded arguments for that function. This encoding follows the Ethereum Application Binary Interface (ABI) specification, which defines how to serialize and deserialize data for machine consumption. Developers interact with calldata using Solidity's calldata keyword for function parameters, which ensures the data is read from this specific memory region.

Using calldata for function parameters is a key gas optimization strategy. Reading from calldata is cheaper than reading from memory or copying data into memory. Therefore, for external functions where arguments are provided by the caller, parameters should be declared as calldata when they are only read and not modified. For example, a function signature like function processData(bytes calldata _data) external is more gas-efficient than using bytes memory _data if the data is not altered within the function.

Calldata is distinct from other data locations in Solidity: storage (persistent on-chain), memory (mutable, temporary), and stack (for small local variables). It is the origin point for transaction input data, visible in explorers as the input field of a transaction. While primarily for external calls, internal function calls can also use calldata parameters for consistency and efficiency. Understanding its role is essential for writing secure, efficient smart contracts and analyzing transaction data on-chain.

Calldata is the immutable, read-only input data passed to a smart contract during a transaction or message call, encoded according to the Ethereum Application Binary Interface (ABI). It is a key-value store containing the function signature and its arguments, which the Ethereum Virtual Machine (EVM) uses to execute the correct contract logic. Unlike contract storage, calldata is not persistent on-chain after execution but is permanently recorded as part of the transaction, making it a critical component for verifying transaction intent and enabling trustless interactions.

The structure of calldata is defined by a strict encoding scheme. The first four bytes are a function selector, a hash of the function's name and parameter types that uniquely identifies which function to execute. The remaining bytes contain the ABI-encoded arguments for that function. This binary format is highly efficient for the EVM to parse. When a contract is called, the EVM loads this data into memory, allowing the executing code to reference specific arguments using offsets like calldataload and calldatasize opcodes.

From a gas economics perspective, calldata is unique. On Ethereum, using calldata for non-zero bytes is expensive, but zero bytes are significantly cheaper, incentivizing efficient data packing. For Layer 2 solutions like Optimistic Rollups and zk-Rollups, calldata is often published to Ethereum Mainnet as the primary data availability layer, making its cost a major scaling consideration. This has led to compression techniques and alternative data availability solutions to reduce fees while maintaining security guarantees.

A common practical example is a token transfer. A call to a standard ERC-20 transfer(address to, uint256 amount) function generates calldata starting with the selector for transfer (e.g., 0xa9059cbb), followed by the 32-byte padded to address and the 32-byte padded amount. This exact byte sequence is what validators execute and what appears in transaction receipts, providing a verifiable record of the action initiated by the user.

In an Ethereum Virtual Machine (EVM) transaction, calldata is the immutable, non-persistent input data passed to a smart contract function. It is a byte array located at a specific memory offset, accessible via the msg.data global variable. For example, a function call to transfer tokens, transfer(address recipient, uint256 amount), encodes the function selector and arguments into a raw hexadecimal string that constitutes the transaction's calldata. This data is read by the contract's bytecode to execute the intended logic.

The structure of calldata is critical for function dispatch. The first four bytes are the function selector, a hash of the function signature (e.g., keccak256("transfer(address,uint256)")). Subsequent bytes are the ABI-encoded arguments. In Solidity, you can declare function parameters with the calldata data location, which is gas-efficient for external functions as it prevents unnecessary copying to memory. For instance: function processData(bytes calldata _input) external { ... }. This tells the compiler the _input argument is read directly from the transaction's calldata.

Using calldata is a key optimization. Reading from calldata is cheaper than reading from memory or storage. It is also non-modifiable, enforcing data integrity for the call's duration. A common pattern is to use calldata for arrays and structs in external functions to minimize gas costs. However, calldata cannot be used for internal function calls or for variables that need to be modified; for those, you must copy the data into memory. Understanding this distinction is essential for writing gas-efficient smart contracts.

To inspect calldata in practice, consider a transaction on Etherscan. The 'Input Data' field shows the raw calldata. Decoding it reveals the function called and its arguments. Developers use tools like the Solidity ABI encoder/decoder or libraries such as ethers.js to programmatically encode function calls into the proper calldata format before submitting a transaction. This encoding ensures the contract interpreter can correctly parse and execute the request, making calldata the fundamental carrier of intent in EVM-based blockchain interactions.