Calldata

What Is Calldata?

Calldata is the immutable byte array included in every Ethereum transaction. When a user or contract sends a transaction, the calldata field carries the instructions telling the receiving smart contract which function to execute and what parameters to use. Unlike contract storage, calldata cannot be modified during execution: it is strictly read-only.

For a simple ETH transfer, the calldata field is empty. For a smart contract interaction, calldata contains an ABI-encoded payload: the first 4 bytes are the function selector (derived from hashing the function signature), and the remaining bytes encode the arguments in 32-byte slots. This data is stored permanently on-chain as part of the transaction record, but it does not occupy the EVM's state trie, making it significantly cheaper than contract storage.

Calldata gained outsized importance in the rollup era. Because it provides a permanent, verifiable record on Ethereum L1, rollups used calldata as their primary mechanism for publishing compressed transaction batches. This ensured that anyone could reconstruct the L2 state independently, providing the data availability guarantees that rollup security depends on.

How It Works

At the EVM level, three opcodes interact with calldata:

• CALLDATASIZE (0x36): returns the total byte length of the calldata payload
• CALLDATALOAD (0x35): reads 32 bytes from a specified offset in calldata
• CALLDATACOPY (0x37): copies a specified number of bytes from calldata into memory

There is no opcode to write to calldata. This immutability is by design: it prevents contracts from tampering with their own input during execution.

Encoding Format

When calling a smart contract function, the calldata is ABI-encoded according to the Solidity ABI specification:

// Function: transfer(address to, uint256 amount)
// Selector: first 4 bytes of keccak256("transfer(address,uint256)")

0xa9059cbb                                                       // function selector
000000000000000000000000ab5801a7d398351b8be11c439e05c5b3259aec9b   // address (32 bytes)
0000000000000000000000000000000000000000000000000de0b6b3a7640000   // amount (32 bytes)

Static types like uint256 and address are encoded directly into 32-byte slots. Dynamic types like bytes and string use offset pointers to locate their data within the payload.

Gas Cost Structure

Calldata gas pricing has evolved through several Ethereum upgrades:

EIP-2028, activated in the Istanbul hardfork (December 2019), reduced non-zero byte costs from 68 to 16 gas. This 4.25x reduction was specifically motivated by enabling Layer 2 scaling: cheaper calldata meant cheaper rollup data posting.

EIP-7623, activated in the Pectra upgrade (May 2025), introduced a two-tier pricing system. Standard transactions still pay 16/4 gas per byte. However, transactions that are primarily calldata with minimal EVM computation (like rollup batch postings) pay a higher floor rate of 40/10 gas per byte. This change reduced Ethereum's worst-case block size from approximately 7.15 MB to 0.72 MB, while incentivizing remaining rollups to migrate from calldata to blob transactions.

Calldata in Layer 2 Rollups

Before the Dencun upgrade, calldata was the sole mechanism for rollup data availability on Ethereum. Both optimistic rollups and ZK rollups relied on it to publish their compressed transaction data to L1.

The process follows a consistent pattern across rollup types:

1. L2 sequencers collect and execute user transactions off-chain
2. Transactions are compressed into batches using various encoding schemes
3. The compressed batch is posted to Ethereum L1 as calldata in a transaction to the rollup's L1 contract
4. For optimistic rollups: challengers can reconstruct the L2 state from this data and submit fraud proofs during a challenge window
5. For ZK rollups: a validity proof accompanies the data, proving state transition correctness

Data availability costs constituted roughly 90% of rollup gas fees on L1. Because rollups competed for the same 30 million gas block limit as regular L1 transactions, congestion on Ethereum directly inflated L2 costs. A busy NFT mint or DeFi event on L1 would spike fees for rollup users who had nothing to do with the L1 activity.

EIP-4844 and the Shift to Blobs

Proto-danksharding (EIP-4844), activated in the Dencun upgrade on March 13, 2024, introduced blob transactions as a purpose-built alternative to calldata for rollup data availability. This was the most significant change to Ethereum's data economics since EIP-2028.

How Blobs Differ from Calldata

The separate fee market is the critical innovation. L1 congestion no longer affects rollup data costs, and vice versa. Blob pricing follows an EIP-1559-style mechanism: if a block contains more blobs than the target, the blob base fee increases. If fewer, it decreases.

The 18-day retention period is sufficient for rollup security because fraud proof windows (typically 7 days for optimistic rollups) and validity proof verification periods are shorter than the pruning window. Any party needing the data for longer-term purposes can archive it independently.

Cost Impact

The shift from calldata to blobs produced dramatic fee reductions across major L2 networks:

By early 2026, average fees across the largest rollups had declined over 99% compared to pre-Dencun levels, reaching fractions of a cent per transaction. For a deeper analysis of how Ethereum's Layer 2 landscape has evolved, see the Ethereum L2 lessons for Bitcoin scaling research article.

Use Cases

Smart Contract Function Calls

The original and most common use of calldata: encoding function invocations. Every DeFi swap, NFT mint, token transfer, and governance vote passes its parameters through calldata. The function selector in the first 4 bytes tells the contract what to execute; the remaining bytes carry the arguments.

Rollup Data Availability

Rollups that have not yet migrated to blobs still use calldata for posting compressed transaction batches. Some rollups also maintain calldata as a fallback mechanism when blob space is congested, since calldata availability is guaranteed as long as the transaction is included in a block.

On-Chain Data Storage

Because calldata is permanently stored on-chain but cheaper than contract storage (SSTORE costs up to 22,100 gas for 32 bytes vs. at most 512 gas for 32 bytes of calldata), protocols sometimes use calldata for write-once data that needs to be verifiable but not frequently accessed. Event logs serve a similar purpose but are not accessible to the EVM during execution.

Ethereum Inscriptions

Following the popularity of Bitcoin inscriptions, Ethereum saw a wave of "ethscriptions" in 2023 and 2024 that embedded arbitrary data (images, text) in transaction calldata. This pattern exploited the relative cheapness of calldata compared to contract storage, though EIP-7623's floor pricing made data-heavy calldata transactions more expensive starting in 2025.

Why It Matters

Calldata economics have shaped the entire Layer 2 landscape. The cost of posting data to Ethereum L1 directly determines what rollup users pay per transaction. Every reduction in calldata cost (EIP-2028) or introduction of cheaper alternatives (EIP-4844 blobs) has cascaded into lower L2 fees, driving adoption across the ecosystem.

Understanding calldata is essential for anyone evaluating different blockchain scaling approaches. Bitcoin Layer 2 solutions like Spark take fundamentally different approaches to data availability and off-chain scaling. While Ethereum rollups rely on posting compressed data to L1 (whether as calldata or blobs), Spark uses a statechain-based model where off-chain state transfers avoid the need for L1 data posting entirely, eliminating this cost category.

Risks and Considerations

Permanent State Bloat

Unlike blob data, calldata is stored permanently by every full node on the Ethereum network. Heavy calldata usage contributes to state growth and increases the storage requirements for running a node. This was one of the motivations behind EIP-7623: discouraging large calldata payloads that inflate worst-case block sizes.

Cost Volatility

Because calldata shares Ethereum's regular gas market, its cost fluctuates with L1 congestion. During peak demand, calldata costs can spike dramatically. For rollups still using calldata, this translates directly into unpredictable L2 fees for end users.

Migration Complexity

The transition from calldata to blobs requires rollups to update their batch submission infrastructure. While major rollups completed this migration shortly after Dencun, smaller or newer rollups may still rely on calldata. The EIP-7623 floor pricing creates economic pressure to complete the migration, but the transition requires careful testing to ensure data availability guarantees are maintained.

Calldata Limitations for Rollups

Even before blobs, calldata had inherent limitations for rollup data availability. It competes with regular transactions for block space, creating a throughput ceiling. The 30 million gas block limit constrains how much data all rollups combined can post per block. Blob space, while currently limited to 9 blobs per block (post-Pectra), operates on a separate budget that scales independently through future upgrades.

This glossary entry is for informational purposes only and does not constitute financial or investment advice. Always do your own research before using any protocol or technology.