{"id":3934,"date":"2026-10-12T12:02:54","date_gmt":"2026-10-12T12:02:54","guid":{"rendered":"https:\/\/nownodes.io\/blog\/?p=3934"},"modified":"2026-10-12T12:02:55","modified_gmt":"2026-10-12T12:02:55","slug":"transaction-calldata-explained-how-to-decode-input-data","status":"publish","type":"post","link":"https:\/\/nownodes.io\/blog\/transaction-calldata-explained-how-to-decode-input-data\/","title":{"rendered":"Transaction Calldata Explained: How to Decode Input Data"},"content":{"rendered":"\n

Every Ethereum transaction that touches a smart contract carries a block of hexadecimal data. That block is the calldata, and it tells the contract which function to run and what arguments to pass. On its own it looks like a wall of random hex \u2014 something like 0xa9059cbb000...<\/code>. Decode it, and the wall turns into a plain instruction: send 1 token to this address.<\/p>\n\n\n\n

A plain ETH transfer between two wallets has no calldata at all; the data field is empty. The moment a transaction calls a contract \u2014 a token transfer, a swap, an approval \u2014 calldata appears and carries the full intent of the call.<\/p>\n\n\n\n

This guide covers what transaction calldata is, how it’s structured, and how to decode it with and without the contract’s ABI. It also looks at what calldata costs in gas and how it differs from Solidity’s calldata<\/code> keyword, memory<\/code>, and storage<\/code> \u2014 two things people often mix up.<\/p>\n\n\n

What Is Transaction Input Data?<\/h2>\n\n\n
\"\"<\/figure>\n\n\n\n

Calldata is the input data attached to a transaction and sent to a smart contract when the transaction runs. In a transaction object it lives in the data<\/code> field. When you fetch a transaction back from an Ethereum endpoint, the same bytes appear under the input<\/code> field.<\/p>\n\n\n\n

The contract reads those bytes to decide what to do. Calldata is read-only and exists only for the duration of the call, which makes it the cheapest place a contract can read inputs from.<\/p>\n\n\n\n

If the data field is empty (0x<\/code>), the transaction simply moves ETH. If it contains bytes, the transaction is calling a function \u2014 and those bytes encode both the function and its arguments.<\/p>\n\n\n

How Is Input Data Structured?<\/h2>\n\n\n

Calldata follows a fixed layout defined by the Ethereum Contract ABI<\/a> (Application Binary Interface). The first 4 bytes identify the function. Everything after that is the function’s arguments, encoded in 32-byte chunks.<\/p>\n\n\n

What Is a Function Selector?<\/h3>\n\n\n

The function selector is the first 4 bytes of the calldata, and it’s how a contract knows which function you want. It’s calculated as the first 4 bytes of the Keccak-256 hash of the function’s signature \u2014 the name plus its parameter types, with no spaces.<\/p>\n\n\n\n

For the ERC-20 transfer<\/code> function, the signature is transfer(address,uint256)<\/code>. Hash it, take the first 4 bytes, and you get 0xa9059cbb<\/code>. Any transfer on any ERC-20 token starts with those same 4 bytes.<\/p>\n\n\n

How Arguments Are Encoded<\/h3>\n\n\n

After the selector, each argument is padded to 32 bytes and laid out in order. Fixed-size types like address<\/code> and uint256<\/code> sit inline. Dynamic types like bytes<\/code> or arrays store an offset that points to their real data further along the calldata.<\/p>\n\n\n\n

Here’s the full calldata for a transfer<\/code> of 1 token (18 decimals) to a sample address, split into its parts:<\/p>\n\n\n\n

0xa9059cbb\n0000000000000000000000005b38da6a701c568545dcfcb03fcb875f56beddc4\n0000000000000000000000000000000000000000000000000de0b6b3a7640000<\/code><\/pre>\n\n\n\n
Part<\/th>Bytes<\/th>Value (trimmed)<\/th>Meaning<\/th><\/tr><\/thead>
Selector<\/td>4<\/td>a9059cbb<\/code><\/td>transfer(address,uint256)<\/code><\/td><\/tr>
Argument 1<\/td>32<\/td>\u202656beddC4<\/code><\/td>recipient address, left-padded<\/td><\/tr>
Argument 2<\/td>32<\/td>\u2026a7640000<\/code><\/td>amount: 1000000000000000000<\/code> base units<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
Read top to bottom: call transfer<\/code>, send to 0x5B38\u2026ddC4<\/code>, move one token’s worth of base units. Nothing is hidden in there. Calldata is complete and deterministic.<\/p>\n\n\n
Why Does Decoding Input Data Matter?<\/h2>\n\n\n
Raw calldata hides intent behind hex. Decoding it is the only reliable way to see what a transaction actually does, before or after it runs.<\/p>\n\n\n\n
The clearest case is security. Wallet-drainer scams work by getting a user to sign a transaction whose calldata grants a token approval \u2014 often an unlimited one \u2014 to an attacker’s address. The wallet screen might show a harmless label, but the calldata is the ground truth. Decoding it reveals the real function and the real spender.<\/p>\n\n\n\n
Decoding also drives everyday development: working out why a transaction reverted, confirming a contract call was built correctly, and labeling on-chain activity in analytics and explorers. If you’ve ever seen a wallet preview that reads “Approve USDC for Uniswap,” that line came from decoding calldata.<\/p>\n\n\n
Who Needs to Read Transaction Input?<\/h2>\n\n\n
Anyone who needs to know what a transaction does, not just that it happened. In practice that includes:<\/p>\n\n\n\n