Why Learn Hard Solidity Things [ ABI Encoding Series: Part 0 ]

Solidity is EASY.

It's a simple and beautiful language.

With the rise of excellent educational resources, courses, dev-tools, and LLMs, learning and writing Solidity has never been easier.

But here's the hard truth — if it's easy for everyone to get started, it's equally hard to stand out.

Gone are the days when deploying a basic ERC20 contract earned you the title “Smart Contract Engineer.”

Today, mastery means understanding Solidity beyond the surface.

GPT4 and Claude are becoming exceptionally proficient at writing basic to mid-level Solidity, Foundry test cases, and even understanding popular codebases like Uniswap v2, Safe, etc.

So, what do you do as a Smart Contract dev?

YOU DO HARD THINGS by gaining deeper expertise in Solidity and EVM.

Writing basic solidity smart contracts - easy.

Writing gas-optimized, highly secure smart contracts with a deeper understanding of underlying EVM workings - now that's HARD.

I want you to aim for the hard things.

And remember that:

Doing Hard Things is no longer an Option,
It's a Necessity.

One of my main goals with Decipher Club is to create resources to help web3 builders level up and stand out.

I wrote a long-form article series on EVM deep-dives and created Decipher EVM Puzzles with the same intention.

Now, I am starting a new series around ABI Encoding and Decoding - one of the most crucial but difficult topics to master in Solidity-EVM.

The aim of this series is to give you the complete picture of how encoding actually works. Most importantly, I want you to have a fundamental mental model:

• to create the raw calldata hex for any given type, byte by byte, on your own,
• to decipher any given calldata easily and understand its parts and layout.

I explained in one of my it's why it's important to master ABI Encoding and Decoding.

However, this is an extensive version of it to encourage you to dive deep into it and read the next parts of this article series.

Let's start.

Why Learn ABI Encoding-Decoding?

When learning Solidity, most developers interact at the surface: writing functions, deploying contracts, calling them through tools like Remix, Hardhat, or Foundry, and letting libraries handle the rest.

Underneath that surface, however, lives a powerful and precise communication protocol — the ABI, or Application Binary Interface — that defines exactly how contracts talk to each other and to the outside world.

If you’ve ever called a function on-chain, written a script with ethers.js, or used abi.encode() inside your smart contract, you’ve already used ABI encoding.

But,

• ever wondered what gets sent to the EVM?
• ever looked at the raw calldata hex and thought wtf is this gibberish?

Let me explain why you should.

ABI Encoding is Everywhere

Solidity may be the language you write in,
but ABI-Encoded language is what the EVM speaks.

Every Function Call Is ABI-Encoded

ABI encoding is the process of converting high-level Solidity values — like numbers, strings, arrays, structs, and function arguments — into a standardized binary format that the Ethereum Virtual Machine (EVM) can understand, transmit, and execute.

In Solidity, this encoding follows the ABI specification, which ensures:

• Function calls can be understood across contracts and tooling
• Data structures are laid out in a predictable, type-aware format
• Contracts can communicate with each other and with off-chain clients, etc.

For instance, when you call:

myContract.foo(42, "hello");

What your wallet or script sends is a hex blob (calldata)— something like:

0xa9059cbb000000000000000000000000000000000000000000000000000000000000002a0000000000000000000000000000000000000000000000000000000000000068656c6c6f

This blob contains:

• A 4-byte function selector
• The encoded arguments, padded, offset, and aligned precisely

If the contract misinterprets even one byte, the call fails or misbehaves.

But if most of this encoding-decoding is taken care of by libraries and EVM itself, why should you bother learning how ABI encoding works?

There are some quite obvious answers for this.

Why Learn ABI Encoding?

Deeply understanding ABI encoding unlocks much more than decoding calldata — it elevates your Solidity development to the level of low-level, systems-aware engineering.

a. You get a complete learning package

Learning the ABI encoding specification teaches you way more about EVM than just the encoding technique.

For instance, while understanding the encoding mechanism, you end up learning crucial concepts like:

• little and big endianness
• intricacies of calldata
• data offsets
• Storage of static vs dynamic types
• function selectors & argument encoding
• optimization of calldata for gas

All of these concepts are equally imperative for you to grasp the intricacies and beauty of the Ethereum Virtual Machine.

Here are a bunch of questions:

a. what exactly is endianness? which type does solidity use ?
b. how does padding work for addresses vs bytes?
c. how does offsets work ? do we have offset for both static type and dynamic type argument encoding?
d. how does calldata play a role in gas optimization?
e. why does type of argument ( static vs dynamic ) matter in encoding?

If you don't have answers for these questions, you lack adequate knowledge of ABI encoding mechanics in solidity-evm.

And you will benefit the most from this Article Series.

b. Your debugging skills skyrocket

When contracts fail silently or revert with opaque messages, being able to read raw calldata is the difference between guessing and knowing.

If you understand how to read raw calldata easily, debugging complex reverts or reverse engineering isn't going to be a nightmare for you.

And that's what differentiates you from the rest.

With adequate knowledge of how ABI encoding works, you will be able to:

• Match selectors to functions
• Trace malformed calldata
• Identify misaligned offsets or bad padding
• Pinpoint the argument that caused the revert

In security audits, exploit analysis, or forensics, you often receive only the calldata of a transaction.

A solid understanding of ABI encoding/decoding is what allows you to deconstruct raw calldata into function args, identify tampered payloads or decode maliciously crafted offsets.

For instance, reporting bugs like requires deep knowledge of how encoding works:

c. You write highly optimized code

Calldata is not free — every single byte in calldata costs gas.

Since EIP-2028:

• every non-zero byte in a calldata costs - 16 gas
• and, every zero bytes in calldata costs - 4 gas

Recall what I said earlier : being a better smart contract dev means the ability to understand and write highly gas optimized smart contracts

Knowing the ABI encoding in-depth lets you:

• Collapse unused or redundant bytes
• Optimize dynamic type layout (e.g. compact array heads/tails)
• Choose between abi.encode vs abi.encodePacked vs manual encoding
• Write memory-efficient calldata builders in inline assembly

d. You develop a deep understanding of abi.encode vs encodePacked vs encodeWithSelector

These three methods aren’t interchangeable.

Each has precise rules for Padding, Alignment, Collision resistance, Tail encoding, etc.

Understanding ABI rules gives you clarity on when to use:

• abi.encode → full ABI-compliant 32-byte alignment
• abi.encodePacked → raw byte packing (e.g., hashing)
• abi.encodeWithSelector → calldata construction

And it helps you avoid silent bugs when mixing them, especially in custom hashing or proxy contexts.

e. For Fuzzing and Boundary Testing

For fuzzers like Echidna, Foundry, or custom tools, you would often want to:

• Construct edge-case ABI payloads
• Test behavior with invalid or truncated encoding
• Manually flip bytes or mutate offsets

This is only possible when you deeply understand the ABI layout of structs, arrays, dynamic values, and nested types.

f. ABI Encoding goes beyond just function arguments

The Solidity ABI specification isn’t just a quirky convention to build transaction calldata.

It is the foundational communication protocol of the EVM, and its influence spans across functions, events, errors, memory models, tooling, and off-chain integrations.

Understanding how encoding works doesn't just give you a grasp of function arguments and calldata encoding, it covers much more than that.

Here are the extended areas of Solidity that rely on ABI encoding under the hood:

a. Events

• Events are encoded using topics (for indexed parameters) and data blobs (for unindexed ones).
• Indexed dynamic types (like string or bytes) are hashed using keccak256 — meaning if you want to query logs or write event parsers, you must understand ABI’s event encoding rules.

b. Custom Errors

• Solidity supports custom error types, which follow the exact same ABI encoding rules as functions.
• This means error data like InsufficientBalance(uint256 available, uint256 required) is encoded just like calling that function, with a 4-byte selector and arguments.

c. Return Values

• ABI encoding defines not only how function arguments are passed, but also how return values are structured.
• A function returning multiple values (returns (uint, string)) is encoded as a tuple, subject to the same head–tail logic as input arguments. ( head-tail logic is what I will explain in detail in next parts )

d. Memory and Calldata Layout

• When writing inline assembly or low-level memory manipulation code, ABI encoding defines the offset model for dynamic values in memory.
• The .offset and .length members of calldata arrays or strings work because of their ABI-defined layout.

e. Tooling and JSON ABI

• Every interface definition in your contract (function, event, error) is serialized into a JSON ABI — which reflects the canonical ABI type definitions, including tuples and indexed parameters.
• Tools like Hardhat, Foundry, Ethers.js, Wagmi, and MetaMask rely on this ABI schema.

Wrapping it UP

There you go.

I tried to provide a bunch of reasons why:

• solidity smart contract devs should choose to learn Hard Things,
• and why the ABI Encoding Specification is a good topic to start diving deep into EVM and Solidity.

My aim with the next parts of this series is to prepare you with solid mental models of how ABI encoding works. I will try to cover as many examples as possible to cover encoding mechanics for a wide range of types.

And I might release a Decipher ABI Games as well ( similar to Decipher EVM puzzles ) . Stay tuned.

See you in the next part.

Cheers Decipherers.