Calldata

Calldata is the immutable, read-only input data passed to a smart contract during a transaction or message call on the Ethereum Virtual Machine (EVM) and compatible blockchains. It is a byte array located in a transaction's data field that specifies which function to execute and includes the encoded arguments for that function. Unlike contract storage, calldata is non-persistent and exists only for the duration of the external call, making it a gas-efficient location for passing function parameters, especially when those parameters are only needed for computation and not for storage.

The structure of calldata is defined by the Ethereum ABI (Application Binary Interface) specification. The first four bytes are a function selector, a hash of the function's signature that uniquely identifies the intended function within the contract. The remaining bytes contain the arguments, each padded to 32 bytes and concatenated in order. When a contract is called, the EVM loads this data, allowing the contract's logic to decode and use the provided inputs. This mechanism is fundamental to all contract-to-contract and external-actor-to-contract interactions.

Using calldata has significant implications for gas optimization. For external functions, parameters stored in calldata are cheaper than parameters stored in memory. Therefore, developers declare function parameters as calldata instead of memory when the function does not need to modify the input data. This is a critical optimization for reducing transaction costs, particularly for functions that handle large arrays or complex data structures passed from an external caller.

Calldata is distinct from other data locations in Solidity: storage (persistent on-chain), memory (temporary, mutable), and stack (EVM opcode handling). It is also different from a transaction's other core fields, such as to (recipient address), value (attached ether), and gasLimit. In the context of Layer 2 solutions and rollups, calldata is especially important, as posting compressed calldata to Layer 1 is a primary method for ensuring data availability and security in optimistic rollups like Arbitrum and Optimism.

Calldata is the immutable, read-only data payload sent with a transaction to specify which smart contract function to call and with what arguments. It is the primary input mechanism for interacting with smart contracts on Ethereum and other EVM-compatible blockchains. When you initiate a transaction—such as swapping tokens or minting an NFT—the details of that action are encoded into a byte sequence and placed in the transaction's data field, which the network refers to as calldata.

The structure of calldata is defined by the Ethereum ABI (Application Binary Interface) specification. It begins with a 4-byte function selector, a hash of the function's signature that tells the EVM which function to execute. This is followed by the encoded arguments for that function, padded to 32-byte words. For example, a call to a transfer(address to, uint256 amount) function would have its selector followed by the 32-byte representation of the recipient's address and the token amount.

A key characteristic of calldata is its immutability and low-cost storage. Unlike data stored in contract memory (memory) or storage (storage), calldata resides directly within the transaction and cannot be modified by the contract. Historically, it was also a significantly cheaper location to read from, especially before Ethereum's EIP-4844 introduced blob transactions, which provided an even more cost-effective data availability layer for rollups.

Within a Solidity smart contract, calldata is accessed via the calldata data location. Function parameters marked as calldata (e.g., function process(bytes calldata input)) provide gas efficiency, as the data is read directly from the transaction without needing to be copied to memory first. Understanding this distinction is crucial for optimizing gas costs, particularly when handling large arrays or bytes data.

The role of calldata extends beyond simple contract calls. It is foundational for delegate calls, where one contract executes code from another while preserving the original contract's context; the calldata is passed directly to the delegated logic. Furthermore, Layer 2 rollups like Optimism and Arbitrum originally used calldata as their primary data availability layer, posting batched transaction data to Ethereum Mainnet—a practice that evolved with the adoption of blob transactions for greater scalability.

Calldata is a read-only, non-persistent data location in the Ethereum Virtual Machine (EVM) that contains the arguments passed to a function during an external call. It is the cheapest data location to use for function inputs, as it exists only for the duration of the call and its gas cost scales linearly with non-zero bytes, making zero bytes exceptionally cheap. This makes calldata the optimal choice for passing large arrays or raw data that the function only needs to read, such as digital signatures or Merkle proofs, without incurring high storage or memory costs.

In contrast, memory is a temporary, mutable data location that is erased between external calls. While reading from memory is inexpensive, writing to it has a moderate gas cost. Memory is typically used for variables declared within a function, for manipulating data loaded from calldata, or for constructing arguments for internal function calls. Unlike calldata, memory can be written to, but its contents are not persistent. The key distinction is that function parameters of reference type (like arrays or structs) must be explicitly marked as calldata to be stored there; otherwise, they default to memory and trigger a copy from the incoming calldata, wasting gas.

Storage is the persistent, on-chain data location that maps to state variables in a smart contract. It is the most expensive location to read from and write to, with operations costing thousands of gas. Data in storage persists across transactions and is permanently recorded on the blockchain. It is used for the core state of a contract, such as token balances or governance settings. Choosing between calldata, memory, and storage is a fundamental gas optimization: use calldata for immutable inputs, memory for intermediate computation, and storage only for data that must survive the transaction.

In the context of optimistic rollups, calldata refers to the practice of posting transaction data from the rollup's sequencer onto the Ethereum mainnet as part of a regular transaction's input data field. This mechanism provides the data availability guarantee required for the rollup's security model, allowing any party to reconstruct the rollup's state and challenge invalid state transitions during the dispute window. By using calldata, rollups leverage Ethereum's existing security and decentralization while minimizing costs compared to storing data directly in contract storage.

The technical implementation involves the rollup's sequencer batching hundreds of L2 transactions, compressing the data, and publishing it as the data payload of an Ethereum transaction. This data is permanently recorded on-chain and is immutable and publicly verifiable. For an optimistic rollup like Optimism or Arbitrum, this published calldata is the cryptographic commitment to the rollup's state transitions. Without this data being available, verifiers would be unable to compute the correct state or submit fraud proofs, breaking the rollup's security.

A key advantage of using calldata is its historical cost efficiency. Ethereum's gas pricing historically made calldata (especially non-zero bytes) significantly cheaper than contract storage operations. This economic incentive drove its adoption as the primary DA solution for early optimistic rollups. However, its cost is variable and subject to mainnet congestion. This volatility led to the exploration and development of alternative data availability solutions like blobs introduced by EIP-4844 and dedicated DA layers.

The shift from pure calldata is exemplified by Ethereum's Proto-Danksharding upgrade (EIP-4844), which introduced blob-carrying transactions. Blobs provide a dedicated, large, and temporary data space that is much cheaper than calldata for rollup data. While calldata remains a functional and fully secure DA layer, modern rollup architectures are increasingly migrating to blobs to achieve lower transaction fees while maintaining the same level of data availability security on Ethereum.

From a security perspective, the use of calldata ensures trust minimization. The Data Availability Committee (DAC) model, used by some early scaling solutions, is not required because the data is unconditionally available on-chain. This aligns with Ethereum's credible neutrality and allows for permissionless verification. The guarantee that data cannot be withheld is fundamental to the fraud proof mechanism in optimistic rollups and the validity proof system in zk-rollups that may also use calldata for input data.