How to Read Input Data on a Transaction to See What It Actually Does

01 October 2026

The input data field on a explorers/transaction-lifecycle-block-explorer/">blockchain transaction contains the instructions that tell a smart contract what to do. Reading it lets you see exactly which function was called and with what parameters, even when the explorer's decoded view is missing or misleading. You decode the raw hex using the contract's ABI (Application Binary Interface), which maps hex signatures to human-readable function names and arguments.

Why raw input data exists

Every transaction that interacts with a smart contract sends a payload in the "input data" field. Simple value transfers (sending ETH from one wallet to another) leave this field empty. But any call to a contract - swapping tokens, depositing into a lending protocol, minting an NFT - packs the function name and its arguments into a hex string.

The first 4 bytes of that hex string are the function selector, a keccak-256 hash of the function signature (e.g., transfer(address,uint256)). The rest is the encoded arguments. If you have the contract's ABI, you can decode everything.

Step-by-Step: decoding input data manually

You don't need to do this by hand every time - explorers and tools automate it - but understanding the structure helps you spot problems.

1. Find the transaction on a block explorer. Open the transaction details page. Look for a field labeled "Input Data," "Data," or "Hex Data." Copy the entire hex string, including the 0x prefix.

2. Identify the function selector. The first 4 bytes after 0x are the selector. For example, 0xa9059cbb is the selector for transfer(address,uint256) on any ERC-20 contract. You can look up common selectors at sites like 4byte.directory or by searching the hex.

3. Separate the arguments. Everything after the first 4 bytes is the encoded arguments, split into 32-byte (64-character) chunks. Each chunk represents a parameter, padded to 32 bytes. Addresses appear as 20 bytes left-padded with zeros; numbers are big-endian integers.

4. Decode using the contract's ABI. If you have the contract's verified source code (most major contracts are verified on Etherscan or similar explorers), you can find the ABI under the "Contract" tab. Paste the full input data into a decoder tool like the one on the explorer's "Decode Input Data" page, or use a standalone tool like cast from Foundry or an online ABI decoder.

5. Check for nested calls. Some transactions call a proxy contract or a multicall contract that bundles multiple actions. In those cases, the input data may contain another layer of encoded calls. You need to decode each inner call separately using the target contract's ABI.

What explorers show you (and what they miss)

Most block explorers attempt to decode input data automatically if the contract is verified. You'll see a "Method" field with the function name and a table of decoded arguments. This is usually correct for standard token transfers and common DeFi actions.

But explorers can fail or mislead in several ways:

• Unverified contracts. If the contract's source code is not published, the explorer cannot decode the input data. You'll see only raw hex. You can still decode it yourself if you obtain the ABI from another source (e.g., the project's GitHub, or by decompiling the bytecode).

• Proxy contracts. Many contracts use a proxy pattern where the logic is in a separate implementation contract. The explorer may show the proxy's fallback function instead of the actual function being called. You need to find the implementation contract address (often stored in a specific storage slot) and decode against that contract's ABI.

• Custom or obscure function signatures. If a project uses a non-standard function signature (e.g., one that doesn't match the 4-byte hash in any public database), the explorer will show "Unknown" or just the raw selector. You can still decode it if you know the signature from the project's documentation.

Practical example: spotting a suspicious approve

Suppose you see a transaction that calls approve on a token contract, but the spender address is a contract you don't recognize, and the amount is a very large number. The decoded input data will show:

• Function: approve(address spender, uint256 amount)
• spender: 0x... (the address being approved)
• amount: 115792089237316195423570985008687907853269984665640564039457584007913129639935 (which is 2^256 - 1, effectively infinite approval)

This is a red flag. The transaction is giving unlimited permission to an unknown contract to spend your tokens. Reading the input data lets you see this before you confirm, or after the fact to understand what happened.

Tools that make it easier

• Etherscan's "Decode Input Data" button. On the transaction page, click this to see a decoded view. Works for verified contracts.
• Tenderly. Simulates the transaction and shows you the full call trace, including internal calls and state changes, with decoded input data for each step.
• Phalcon (by BlockSec). Provides a visual transaction explorer that decodes input data and shows the flow of calls between contracts.
• cast (Foundry). A command-line tool. cast 4byte <selector> looks up the function signature. cast abi-decode --input <abi> <data> decodes the full input.
• 4byte.directory. A searchable database of function selectors. Useful when you have a raw 4-byte hash and need to find what function it corresponds to.

When reading input data saves you

• Before signing a transaction. If you use a hardware wallet or a wallet that shows raw data, you can decode it offline to verify you're approving or calling exactly what you intend.
• After a failed transaction. The input data may reveal that you called a function with the wrong parameter, like an expired deadline or a slippage tolerance that was too low.
• When investigating a scam. If someone sends you a transaction that drains your tokens, the input data shows which function was called and on which contract. That information helps you trace the attacker's next moves.

Back to block explorers