transaction calldata explained
calldata is the input data of a transaction that calls a contract — the bytes that say which function to run and with what arguments. it's the hex blob you see in the "input data" field on a block explorer.
the structure
calldata begins with a 4-byte function selector, followed by the function's arguments encoded according to the ABI specification. so a call to transfer(address,uint256) is 0xa9059cbb and then the recipient and amount, encoded — typically 4 + 32 + 32 = 68 bytes.
how arguments are encoded
arguments are laid out in 32-byte (256-bit) words. static types — addresses, fixed integers, booleans, bytesN — sit inline, each padded to a full word: an address is left-padded to 32 bytes, a uint256 is big-endian, a bool is 0 or 1. dynamic types — strings,bytes, and variable-length arrays — don't fit in one word, so their slot holds an offset pointing further into the data, where the length and contents are stored. decoding therefore means walking these offsets, not just reading word by word.
how to decode it
the bytes alone aren't self-describing — the same word could be an address, a uint256, or part of a string. to decode, you need the function's types, which come from its ABI. a decoder matches the leading selector to a function, then reads each argument according to its declared type, following offsets for the dynamic ones.
try it
paste any transaction's input data into the calldata decoder to decode the call and its typed arguments against an ABI.