What is ABI (application binary interface)?

The published description of a contract's functions and their argument types, which lets external software encode a call the contract will understand.

Function calls are identified on chain by the first four bytes of a hash of the signature, so without the ABI a transaction's calldata is an opaque blob (source: the Solidity documentation). This is why a verified contract on a block explorer shows readable function names and an unverified one does not, and why a wallet can sometimes tell you what you are signing and sometimes cannot. Treat an unreadable transaction as a reason to stop.

Publishing the source and ABI is voluntary. A verified badge means only that the published source compiles to the deployed bytecode, not that the code is safe. Developers meet the ABI daily; buyers meet it once, at the moment a wallet either explains a transaction in words or shows a wall of hex.

How it works

A contract's compiled bytecode contains no names. The Solidity documentation specifies that a function is dispatched by its selector, the first four bytes of the keccak-256 hash of its canonical signature, which is the function name plus its argument types with no spaces.

The ABI is a JSON document listing every public function, its inputs, its outputs, and every event the contract emits. Software reads it, computes the selectors, and packs arguments into 32-byte slots in the order the ABI declares.

Decoding runs the same process backwards. A wallet or explorer with the ABI turns raw bytes into "approve this address to spend an unlimited amount." Without it, the same bytes stay bytes. That is also how an event log becomes a readable transfer line in your history.

Verification on an explorer is the usual publication route. You upload the source and compiler settings, the explorer recompiles, and if the output matches the deployed bytecode it stores the source and ABI for everyone.

Example

The canonical signature for a standard token transfer is transfer(address,uint256), and its selector is 0xa9059cbb, a value anyone can recompute from the signature. A transfer call is therefore 4 bytes of selector plus one 32-byte slot for the destination and one 32-byte slot for the amount, which is 68 bytes of calldata in total. With the ABI your wallet shows a destination and an amount. Without it, it shows 68 bytes beginning 0xa9059cbb and nothing else.

Why it matters when you buy

If you only buy on an exchange, you never touch an ABI directly, because the venue handles the chain. The moment you withdraw and start approving contracts yourself, a wallet's ability to name what you are signing is your main defense, and that ability depends on a published ABI. Before interacting with any token you found on a chart, check that the contract is verified on the chain's explorer, and see the buyability scores for whether the asset is listed on a regulated venue at all.

Related terms

• calldata — the encoded bytes an ABI describes
• smart contract — the deployed code the ABI documents
• block explorer — where verified source and ABIs are published
• blind signing — what happens when no ABI is available
• transaction simulation — previewing a decoded call before signing
• smart contract audit — a separate review of whether the code is safe

Questions

Do I need the ABI to send a token?

No. Wallets ship with the standard token ABIs built in, so ordinary sends and approvals decode without any extra work. You notice the ABI only with unusual or newly deployed contracts.

Why does my hardware wallet show hex instead of words?

Because it does not have the ABI for that contract on the device. Some wallets stream a decoded summary from the companion app; others require you to enable blind signing, which removes your ability to check what you approve.

Is an unverified contract automatically a scam?

Not automatically, but it removes your ability to check. A project with nothing to hide has no reason to leave the source unpublished, so treat unverified as a reason to slow down.