Ethereum ABI Encoder/Decoder

ABI (Application Binary Interface) encoding is how Ethereum represents function arguments and return values as raw bytes. It's used in calldata, event logs, and function return data. Static types are padded to 32-byte slots. Dynamic types (bytes, string, arrays) use an offset/length scheme where the static section holds a pointer to the dynamic data location.

abi.encode pads all types to 32-byte boundaries — safe and unambiguous. abi.encodePacked concatenates types without padding — smaller output but can be ambiguous (e.g., abi.encodePacked('a','bc') == abi.encodePacked('ab','c')). Never use encodePacked for signatures or hash inputs that combine dynamic types, as it can enable hash collision attacks.

Event logs have up to 4 topics (32 bytes each) and arbitrary data. The first topic is the event selector (keccak256 of the event signature). Indexed parameters go into topics (up to 3). Non-indexed parameters go into data as ABI-encoded values. Dynamic types (string, bytes, arrays) when indexed are keccak256-hashed — you can't reverse this.

Structs are encoded as tuples in ABI. A struct with fields (uint256 a, address b) is encoded as tuple(uint256,address). The encoding follows the same rules as regular ABI — static fields are at their offsets, dynamic fields use pointer indirection. Nested structs are recursively encoded.

Revert with a reason string encodes as: selector for Error(string) = 0x08c379a0, followed by ABI-encoded string offset + length + data. Custom errors use their own selector + ABI-encoded arguments. You can decode a revert reason by removing the 4-byte selector and decoding the remaining data as ABI-encoded (string) or custom error types.