When you start exploring blockchain data on platforms like Etherscan, you'll often interact with addresses. These addresses can point to either an Externally Owned Account (EOA) controlled by a private key or a smart contract. To interact effectively with a smart contract, you need to understand its capabilities—this is where the Application Binary Interface (ABI) becomes essential.
What Are Addresses and ABIs?
An address on the blockchain identifies either an account or a contract. If it's a contract address, you need to know what functions it supports to interact with it. For instance, if you want to swap tokens on Uniswap V2, you might call a function named swapExactTokensForTokens.
The ABI defines the structure of a smart contract's functions. It specifies function names, input parameters, and output formats, enabling tools like ethers.js to encode and decode transactions correctly. Here’s an example of an ABI snippet for the swapExactTokensForTokens function:
[
{
"inputs": [
{ "internalType": "uint256", "name": "amountIn", "type": "uint256" },
{ "internalType": "uint256", "name": "amountOutMin", "type": "uint256" },
{ "internalType": "address[]", "name": "path", "type": "address[]" },
{ "internalType": "address", "name": "to", "type": "address" },
{ "internalType": "uint256", "name": "deadline", "type": "uint256" }
],
"name": "swapExactTokensForTokens",
"outputs": [
{ "internalType": "uint256[]", "name": "amounts", "type": "uint256[]" }
],
"stateMutability": "nonpayable",
"type": "function"
}
]Crucially, the ABI is not inherently tied to an address. You can use any ABI to interact with a contract address, but the transaction will only succeed if the contract actually supports the function you're trying to call. For example, Uniswap V2 recognizes swapExactTokensForTokens but might not recognize a deposit function from a different ABI.
This flexibility is particularly important when dealing with upgradeable contracts.
How Upgradeable Contracts Work
Upgradeable contracts address a key limitation of blockchain: immutability. Once deployed, traditional smart contracts cannot be changed. However, projects often need to update features or fix bugs without requiring users to migrate to a new address.
Upgradeable contracts use a proxy pattern consisting of two main components:
- Proxy Contract: This is the entry point for users. It stores the address of the logic contract and delegates all function calls to it.
- Logic Contract (Implementation): This contract contains the actual business logic and functionality.
When a user interacts with the proxy contract, it uses a low-level operation called delegatecall to execute the code from the logic contract in its own context. Think of it as the proxy contract "borrowing" the logic contract's capabilities.
From the user’s perspective, they always interact with the same address (the proxy), but the underlying logic can be updated by changing the logic contract address stored in the proxy.
To interact correctly, users must use the ABI of the logic contract, not the proxy. Calling an unrecognized function on either contract will result in a failed transaction.
👉 Explore advanced contract interaction methods
Interacting with Contracts on Etherscan
Etherscan provides a user-friendly interface for interacting with smart contracts. If a contract has verified its source code, Etherscan can generate its ABI and offer "Read" and "Write" tabs for contract interaction.
For upgradeable contracts that adhere to standards like EIP-1967, Etherscan automatically detects the proxy pattern. It then provides additional tabs: "Read as Proxy" and "Write as Proxy." These tabs display the functions from the logic contract's ABI, allowing users to interact with the intended functionality.
- Standard Read/Write: These tabs show functions belonging to the proxy contract itself, which are typically administrative and not for end-users.
- Read/Write as Proxy: These tabs show functions from the logic contract, which are the ones users actually need.
If a contract hasn't verified its source code or isn't a standard upgradeable proxy, Etherscan cannot display its ABI or provide an interaction interface. In such cases, you need alternative tools and must obtain the correct ABI from the project's official documentation, repository, or website.
Frequently Asked Questions
What is the main difference between a contract address and an ABI?
A contract address is the unique location of a deployed smart contract on the blockchain. The ABI is a JSON file that defines how to interact with that contract by describing its available functions, their inputs, and their outputs.
Why would I use the wrong ABI with a contract address?
You normally wouldn't do this intentionally. However, with upgradeable contracts, you must use the logic contract's ABI to interact with the proxy contract's address. This is the correct and intended way to call functions on an upgradeable contract.
How can I find the ABI for a contract if it's not on Etherscan?
The best source is the official project documentation, their GitHub repository, or their website. Reputable projects will always publish the ABIs for their deployed contracts to ensure users can interact with them.
What happens if I call a function that a contract doesn't recognize?
The transaction will fail and revert. You will still pay gas fees for the computational effort required to attempt the execution, so it's important to use the correct ABI.
Are all upgradeable contracts built the same way?
No, there are different standards and patterns for implementing upgradeability, such as EIP-1967 and EIP-897. While the core concept of a proxy and logic contract is common, the specific implementation details can vary.
Is it safe to interact with upgradeable contracts?
The safety depends on the project's governance and transparency. While the pattern itself is secure, you should always audit the project's reputation and understand who controls the ability to upgrade the logic contract, as this control carries significant power.
Understanding the relationship between addresses and ABIs is fundamental to navigating the world of decentralized applications. By using the correct ABI for your target contract, you can ensure successful interactions, whether dealing with standard contracts or advanced upgradeable proxies.