Calldata

What calldata does in contract execution

Calldata is the transaction-supplied input stream that a contract reads during execution. In Ethereum-style virtual machines, it is where the function selector and ABI-encoded arguments arrive, so it defines what code path the contract can invoke and with what parameters.

Because calldata is read-only to the callee, it is useful to think of it as an immutable execution request rather than mutable state. That distinction matters when reasoning about replayability, deterministic execution, and how contracts validate the caller’s intent before using the supplied bytes.

How calldata is structured and decoded

Most calldata begins with the four-byte function selector, followed by encoded arguments laid out according to the contract interface. Dynamic values such as strings, arrays, or nested structures are referenced by offsets, which means decoding depends on both type information and correct length handling.

Incorrect decoding is not just a developer inconvenience. If a contract, proxy, or off-chain parser misinterprets the payload, the result can be wrong function dispatch, malformed parameter handling, or a security check applied to the wrong field. The calldata format therefore sits at the boundary between protocol syntax and application logic.

Why calldata matters for security and contract design

Calldata is often the first thing a smart contract trustfully consumes, so it becomes a major control point for input validation and access decisions. A contract may reject malformed or unexpected payloads, but once a call is accepted, the encoded bytes directly shape execution and can influence value transfers, permissions, and state transitions.

Designers must also account for the fact that calldata is externally supplied and fully attacker-controlled. That makes it part of the attack surface for selector collisions, parameter confusion, crafted edge cases, and any logic that assumes the payload is well formed without checking it carefully.

Operational implications for developers and reviewers

For practitioners, calldata is a debugging and assurance surface as much as a protocol primitive. Reviewers should understand which functions are reachable from raw calldata, how selectors map to contract methods, and whether decoding logic, fallback handling, or proxy routing changes the intended control flow.

It is also important to distinguish calldata from memory and storage when assessing gas use and security behaviour. Calldata cannot be modified during execution, but it can still be copied, transformed, or used to drive decisions that persist in storage, so the security impact depends on how the contract consumes it.

Risk and Threat Considerations

Calldata becomes risky when contracts, proxies, or tooling trust the encoded payload too much. Attackers can craft inputs to exploit weak decoding, confuse function dispatch, or trigger unintended code paths, especially where interfaces are loosely validated or where external tools reconstruct calls from partial data.

Failure mechanism: A malformed or malicious payload is interpreted as a valid call, causing the contract to process the wrong selector, wrong argument values, or an unexpected execution branch.

Impact: The result can include unauthorized state changes, failed access checks, incorrect value movement, denial of service through revert-heavy inputs, or off-chain monitoring errors that miss the true intent of the transaction.

Practitioner Guidance

What to watch for: Treat calldata-sensitive code as a parsing boundary. Contracts, relays, and indexers should validate selector handling, argument lengths, and fallback behaviour with the same care they would apply to any untrusted input channel.

Governance implication: Reviewers should document which calldata formats a contract accepts, which functions are intentionally reachable through raw calls, and how proxy or ABI changes affect downstream consumers. That makes interface drift easier to detect before it becomes a security issue.