Calldata, from bytes to meaning
Learn Ethereum calldata
Practical explanations of the bytes sent to Ethereum contracts: how a call identifies a function, how its arguments are laid out, and how much you can recover when the ABI is missing.
Guides
How Ethereum calldata works
Build real calls and see how selectors, 32-byte words, offsets, arrays, tuples, and nested calldata fit together.
Read guide →Core conceptEthereum function selectors
Learn how a canonical function signature becomes a 4-byte selector—and why the selector is not a unique function ID.
Read guide →Practical decodingDecode calldata without an ABI
See what can be recovered from raw transaction input, how signature lookup works, and where a contract-specific ABI is still required.
Read guide →A useful mental model
For a standard ABI-encoded external function call, calldata is a 4-byte selector followed by an encoded argument block. The selector proposes a function signature; a matching function ABI gives every following byte a type and structure.
That distinction explains most decoding surprises. The bytes are deterministic, but they are not self-describing: the same word can represent an integer, address, offset, or part of another value depending on the schema used to read it.
ERC calldata references
Look up a standard function’s signature and selector, understand its parameters, and generate an editable calldata example.
- ERC-20 calldata referenceFungible token balances, transfers, and allowances.
- ERC-721 calldata referenceNFT ownership, transfers, approvals, and metadata.
- ERC-1155 calldata referenceMulti-token balances, approvals, and batch transfers.
- ERC-4626 calldata referenceTokenized vault deposits, withdrawals, shares, and previews.