ABI (Application Binary Interface)

What's in an ABI

A typical ABI is a JSON array, with one entry per function, event, or constructor exposed by a contract. Each entry describes:

• The name (e.g. transfer, approve, Transfer for an event)
• The input parameters and their types (e.g. address, uint256, bytes32)
• The output return types
• Whether the function is view/pure (read-only) or state-changing
• For events, which parameters are indexed (and therefore filterable in logs)

When Solidity code is compiled, the ABI is generated alongside the bytecode. Tools then use the ABI to encode function calls into the binary data that the EVM actually understands.

Why it matters

Without the ABI, you can still send raw transactions to a contract, but you'd need to manually pack the function selector and arguments into hex — error-prone and impractical. With the ABI, every wallet, indexer, block explorer, and dApp can read and write to the contract using high-level function names.

This is why verified contracts on Etherscan are so much more useful than unverified ones: when the source is verified, the ABI becomes available, so anyone can interact with the contract through Etherscan's "Read Contract" / "Write Contract" tabs without needing to build a custom UI.

Standard ABIs

Common token standards have well-known ABIs that all conformant contracts share. The ERC-20 ABI is identical across every fungible-token contract; same for ERC-721 NFTs. This is why your wallet can show balances and let you transfer any ERC-20 without integrating each one individually — it ships with the standard ABI and applies it to every recognized contract.

Fragments

In production code, you rarely need a contract's full ABI — most tools accept ABI "fragments" representing just the functions you plan to call. Libraries like ethers.js and viem can also derive ABI fragments from human-readable signatures like function transfer(address,uint256) returns (bool), which keeps frontend bundles small.