What Is an ABI? How Apps Talk to Ethereum Contracts

An ABI, or Application Binary Interface, is a structured description of a smart contract's functions, their input parameters, and their return types, generated automatically when a contract is compiled. It serves as the schema that lets external applications — wallets, frontends, and scripts — correctly encode a function call and decode the resulting data when interacting with a deployed contract.

Why contracts need an interface description at all

Once a /glossary/smart-contract written in a language like /blog/what-is-solidity-programming-language is compiled, all that actually exists on-chain is raw EVM bytecode — machine-level instructions with no inherent labels for function names or parameter types. An application trying to call a specific function on that contract has no way to know, just from the bytecode, what functions exist or what data they expect. The ABI fills this gap: it's a separate, human-and-machine-readable specification, generated during compilation, that maps out each function's name, its expected inputs, and what it returns.

How the encoding process works

When an application wants to call a contract function, it uses the ABI to encode the function call into the specific low-level format the EVM expects — typically a short function identifier (derived from hashing the function's name and parameter types) followed by the encoded arguments. This encoded data becomes the transaction's input data field, the same field visible when reading a transaction on a block explorer, as covered in /blog/how-to-read-etherscan-transactions. When the contract returns data, the ABI is used again in reverse, decoding the raw returned bytes back into readable values like numbers, addresses, or strings.

Where the ABI comes from

The ABI is produced automatically by the Solidity compiler alongside the bytecode itself, as part of the compilation step covered in /blog/how-to-deploy-a-smart-contract. Developers building an application that interacts with a specific deployed contract need a copy of that contract's ABI — either from their own build artifacts if they wrote the contract, or from a public source like a verified contract listing on a block explorer if they're integrating with someone else's protocol.

A simple analogy

Concept	Analogy
Compiled bytecode	A machine's internal wiring — functional, but unreadable without documentation
ABI	The instruction manual describing what buttons exist and what each one expects as input
Function call encoding	Pressing a specific button in the correct sequence described by the manual
Return data decoding	Reading the machine's output display using that same manual

ABIs and libraries like Ethers.js

JavaScript libraries used to interact with Ethereum, compared in /blog/what-is-web3js-vs-ethersjs, rely directly on a contract's ABI to provide a convenient interface for developers — rather than manually constructing encoded call data by hand, a developer can call a function by name in their code, and the library handles the ABI-based encoding and decoding automatically behind the scenes.

Why verifying source code matters for ABI trust

An ABI only accurately reflects what a contract does if it genuinely corresponds to the deployed bytecode. This is one of the practical reasons contract source code verification matters, as discussed in /blog/how-to-read-etherscan-transactions — a verified, publicly matched source-to-bytecode pairing gives confidence that the displayed functions and the ABI describing them genuinely reflect the contract's real behavior, rather than being a misleading or incomplete description supplied by an untrustworthy source.

ABIs and contract interface standards

Some ABIs follow well-known, standardized patterns because the underlying contracts implement a common interface — for instance, most fungible tokens share a large portion of an identical ABI structure because they follow the same standardized token interface. This standardization is genuinely useful: it means an application built to interact with one compliant token can generally interact with any other compliant token using largely the same ABI-based calls, without needing custom integration work for every new token it supports. Custom, non-standard contracts, by contrast, require their own unique ABI, since their function names and structures don't match any common template.

Why this matters for everyday users

Most users never interact with an ABI directly — wallets and application frontends handle this encoding and decoding invisibly. It becomes directly relevant for developers building integrations, for anyone manually verifying what a transaction actually does before signing it (particularly before granting a /blog/how-token-approvals-work-ethereum), and for understanding why block explorers can display readable function names for some contracts but only raw, undecoded data for others whose source hasn't been verified.

What happens when an ABI is wrong or outdated

Using an outdated or mismatched ABI — for instance, after a contract has been upgraded through the pattern described in /blog/what-is-proxy-contract-upgradeable — can cause an application to encode a call incorrectly or misinterpret returned data, typically resulting in a failed transaction or a nonsensical displayed value rather than a silent, invisible error. This is one of several practical reasons applications interacting with upgradeable contracts need a reliable way to fetch the current, correct ABI rather than relying on a version cached from an earlier point in the contract's history.

Bottom line

The ABI is the schema that bridges human-readable contract functions and the raw bytecode Ethereum actually executes, letting applications correctly encode calls and decode results. It's generated automatically at compile time, but its accuracy depends on genuinely corresponding to the deployed contract — which is why verified source code, not just a trusted-looking ABI file, is the stronger signal when evaluating an unfamiliar contract.