Home/Blockchain/ABI Decoder Mini-game/Decoding Basics

🔍 Decoding Basics: From Bytecode to Function Calls

Understand function selectors, parameter encoding, and data types

Your Progress

0 / 5 completed
1
2
3
4
5

⚙️ How ABI Decoding Works

Every contract call starts with a 4-byte function selector, followed by encoded parameters. Let's break down exactly how to decode this data.

🔑 Step 1: Function Selector

The first 4 bytes (8 hex characters after 0x) identify which function is being called. This is created by:

  1. Taking the function signature (e.g., transfer(address,uint256))
  2. Hashing it with Keccak256
  3. Taking the first 4 bytes of the hash
Example:
keccak256("transfer(address,uint256)")
= 0xa9059cbb2ab09eb219583f4a59a5d0623ade346d...
→ Selector: 0xa9059cbb

🎯 Interactive: Live Decoder

Paste transaction input data to decode it step-by-step:

📚 Common Function Selectors

Learn to recognize these frequently-used function selectors:

ERC20 Transfer
transfer(address,uint256)
0xa9059cbb
ERC20 Approve
approve(address,uint256)
0x095ea7b3
ERC20 TransferFrom
transferFrom(address,address,uint256)
0x23b872dd
ERC20 BalanceOf
balanceOf(address)
0x70a08231

🧮 Parameter Encoding Rules

📏

Fixed-size types (address, uint, bool)

Each parameter takes exactly 32 bytes (64 hex characters), padded with zeros if needed.

📦

Dynamic types (string, bytes, arrays)

Encoded as: offset (32 bytes) → length (32 bytes) → actual data (variable length)

🔢

Multiple parameters

Encoded sequentially, each aligned to 32-byte boundaries for efficient EVM processing.

⚠️ Common Pitfalls

  • •Wrong function signature: Even a tiny mismatch (like uint vs uint256) creates a different selector
  • •Padding errors: All parameters must be padded to 32-byte boundaries
  • •Endianness: Numbers are big-endian (most significant byte first)
  • •No spaces: Function signatures must have no spaces: transfer(address,uint256) not transfer(address, uint256)