Calldata is the read-only input data attached to an Ethereum transaction that tells a smart contract which function to call and what arguments to pass. It is encoded as hexadecimal bytes following a specific ABI encoding scheme. For rollups, calldata is also the mechanism for posting compressed L2 transaction batches to Ethereum L1, making it a critical cost factor for L2 fees.

What Is Calldata?

3 min read

The short version

Calldata is the instruction label on a package sent to a smart contract. It says: "Open function X with parameters Y and Z." The contract reads these instructions and acts accordingly. For L2 rollups, calldata is also used as cheap permanent storage, posting compressed transaction summaries to L1 for anyone to verify later.

How It Works

A transaction's calldata consists of: the first 4 bytes = function selector (keccak256 hash of the function signature, truncated). Remaining bytes = ABI-encoded function arguments (each padded to 32 bytes for fixed types, with offset pointers for dynamic types). Example: calling transfer(0xBob, 100) encodes as: 0xa9059cbb (selector for "transfer(address,uint256)") + 000...Bob (address padded to 32 bytes) + 000...64 (100 in hex, padded to 32 bytes). Calldata is cheaper than storage (16 gas per non-zero byte vs. 20,000 gas for a new storage slot). That is why rollups post batches as calldata, it is the cheapest way to make data permanently available on L1. EIP-4844 (proto-danksharding) introduced "blobs" as an even cheaper alternative to calldata for rollup data, reducing L2 fees further.

Reading calldata on Etherscan

You inspect a Uniswap swap transaction on Etherscan. Under "Input Data" you see: 0x38ed1739000000000000000000000000000000000000000000000000000000003b9aca00... The first 4 bytes (38ed1739) are the function selector, Etherscan decodes this as swapExactTokensForTokens. The following 32-byte chunks encode: amountIn (1000000000 = 1 USDC with 6 decimals), amountOutMin (minimum tokens to accept), path (array of token addresses for the route), recipient address, and deadline timestamp. What the Uniswap Router contract reads to execute your swap.

What People Get Wrong

  • Calldata is stored in the contract

    Calldata is transient per transaction, it exists only during execution and in the transaction receipt (permanently in block history). It is not written to contract storage. It is read-only during execution.

  • Simple ETH transfers have calldata

    A plain ETH transfer has empty calldata (0x). Only transactions calling contract functions have non-empty calldata. However, you CAN include arbitrary data in any transaction's calldata field (this is how inscriptions/ordinals work on some chains).

  • Calldata costs are constant

    Calldata pricing was reduced in EIP-4844 (via blobs). Before EIP-4844, calldata cost 16 gas/non-zero byte and 4 gas/zero byte. After EIP-4844, rollups can use blobs instead (~1-10x cheaper for data availability). Calldata itself still costs the same, but there is now a cheaper alternative for rollup data posting.

Sources & Further Reading

Questions People Also Ask

Why is calldata important for L2 costs?
L2 fees are primarily driven by the cost of posting data to L1. Before blobs, rollups posted compressed batches as L1 calldata, which accounted for 80-95% of L2 transaction fees. EIP-4844 blobs provide a cheaper alternative, dramatically reducing L2 costs.
What is ABI encoding?
ABI (Application Binary Interface) encoding is the standard way Ethereum encodes function calls and their parameters into calldata bytes. It defines how types (uint256, address, bytes, arrays) are serialized into a flat byte sequence that contracts can decode.
Can I send arbitrary data in calldata?
Yes. Any transaction can include arbitrary bytes in the calldata field. If sent to an EOA (not a contract), the data is ignored by the protocol but permanently recorded on-chain. This is how "Ethscriptions" and similar inscription systems work.

More in Smart Contracts & Ethereum

See all →
Was this page helpful?

Page last checked