EVMTools

Calldata Decoder

Decode raw Ethereum calldata hex into human-readable function calls and parameters.

Common Examples

How to Use This Calldata Decoder

This tool decodes raw Ethereum transaction calldata into human-readable function calls and parameters. It is essential for debugging transactions and understanding what a contract call actually does.

  1. Paste the calldata — copy the hex-encoded calldata from a transaction on Etherscan or from your development tools. It should start with "0x".
  2. Optionally provide the function signature — if you know the function (e.g., "transfer(address,uint256)"), enter it to get fully labeled parameter decoding.
  3. View decoded parameters — the tool displays the function selector, each parameter with its type and decoded value.
  4. Copy the decoded output for documentation, debugging, or sharing with your team.

All decoding runs locally in your browser. No transaction data is sent to any server.

Common Use Cases

  • Transaction debugging — Decode failed transaction calldata to understand what function was called and with what parameters.
  • Security analysis — Inspect calldata from suspicious transactions to verify what actions are being performed on a contract.
  • Multi-sig review — Decode pending multi-sig transaction calldata to verify the proposed action before signing.
  • Governance proposal inspection — Decode the calldata in DAO proposals to verify the exact on-chain actions before voting.
  • MEV research — Analyze transaction calldata in mempool data to understand arbitrage and liquidation bot behavior.

Related Tools

Frequently Asked Questions

What is Ethereum calldata?

Calldata is the hex-encoded data sent along with an Ethereum transaction to invoke a function on a smart contract. It contains the 4-byte function selector (derived from keccak256 of the function signature) followed by ABI-encoded parameters. For example, an ERC-20 transfer encodes the recipient address and amount in the calldata.

How is a function selector calculated?

A function selector is the first 4 bytes of the keccak256 hash of the function's canonical signature. For example, keccak256('transfer(address,uint256)') produces a hash whose first 4 bytes (0xa9059cbb) identify the transfer function. The selector is always the first 4 bytes (8 hex characters) of the calldata.

How do I decode calldata without the ABI?

If you know the function signature (e.g., 'transfer(address,uint256)'), you can provide it to decode the parameters. Without any ABI or signature, you can still identify the function selector (first 4 bytes) and look it up in databases like 4byte.directory. The remaining bytes can be split into 32-byte chunks to inspect raw parameter values.

What is ABI encoding?

ABI (Application Binary Interface) encoding is the standard way Ethereum encodes function calls and their parameters into bytes. Each parameter is padded to 32 bytes. Static types (uint256, address, bool) are encoded inline, while dynamic types (string, bytes, arrays) use an offset pointer to their data location.

Can I decode multi-call or batch transaction calldata?

Yes, if you know the outer function signature (such as multicall(bytes[]) or aggregate((address,bytes)[])), the tool can decode the top-level parameters. The inner calls are encoded as bytes arrays that can each be decoded separately by pasting them back into the tool.