Addresses, ABI, and Upgradeable Contracts

·

When interacting with blockchain applications, understanding the relationship between contract addresses, Application Binary Interfaces (ABI), and upgradeable contracts is essential—especially for developers, analysts, or DeFi users who want to directly engage with smart contracts. This article breaks down these core concepts in a clear, practical way, helping you confidently interact with both standard and upgradeable contracts using tools like Etherscan and MyCrypto.

Whether you're calling a token swap function on Uniswap or checking your USDT balance on Arbitrum, the underlying mechanics rely on addresses and ABIs. Let’s dive into how they work together—and what changes when contracts become upgradeable.

Understanding Contract Addresses and ABI

When exploring the blockchain via platforms like Etherscan, you typically focus on blocks, transactions, or addresses. An address can represent either an Externally Owned Account (EOA)—controlled by a private key—or a smart contract.

If the address holds a contract, you’ll need to know what functions it supports to interact with it. For example, to trade tokens on Uniswap V2, you’d call a function named swapExactTokensForTokens. But how does your tool know what parameters this function accepts?

That’s where ABI comes in.

What Is an ABI?

The Application Binary Interface (ABI) is a JSON-formatted definition of a smart contract’s functions, events, inputs, and outputs. It acts like a blueprint that tells development tools (like ethers.js) how to encode function calls correctly for the Ethereum Virtual Machine (EVM).

Here’s a simplified snippet of the swapExactTokensForTokens function ABI:

[
  {
    "inputs": [
      { "name": "amountIn", "type": "uint256" },
      { "name": "amountOutMin", "type": "uint256" },
      { "name": "path", "type": "address[]" },
      { "name": "to", "type": "address" },
      { "name": "deadline", "type": "uint256" }
    ],
    "name": "swapExactTokensForTokens",
    "outputs": [ { "name": "amounts", "type": "uint256[]" } ],
    "stateMutability": "nonpayable",
    "type": "function"
  }
]

This ABI defines:

👉 Discover how to decode contract interactions using ABI data.

Important: ABI Is Not Bound to an Address

A crucial point: an ABI is not inherently tied to a specific contract address. You can use any ABI to interact with any contract address. Tools like ethers.js will encode the call based on the ABI and send it to the specified address.

However, the transaction only succeeds if the target contract actually implements the requested function. For instance:

So while you can send arbitrary function calls, execution depends on whether the contract understands them.

This flexibility becomes especially relevant when dealing with upgradeable contracts, where logic and storage are separated.

The Need for Upgradeable Contracts

Once deployed, Ethereum smart contracts are immutable by default—meaning their code cannot be changed. While this ensures trustlessness, it poses challenges:

To solve this, teams use upgradeable contracts, which allow logic updates while preserving the same entry-point address.

How Do Upgradeable Contracts Work?

Upgradeable contracts follow a proxy pattern consisting of two main components:

  1. Proxy Contract – The public-facing address users interact with.
  2. Logic (Implementation) Contract – Contains the actual business logic.

Users send transactions to the proxy, which forwards execution to the current logic contract using a special EVM opcode called delegatecall.

🔍 Think of delegatecall as letting the logic contract “possess” the proxy—running its code but operating on the proxy’s storage.

Thus, even though the logic changes over time, users keep using the same address.

Interacting with Upgradeable Contracts: Real-World Example

Let’s take USDT on Arbitrum (0xfd086bc7cd5c481dcc9c85ebe478a1c0b69fcbb9) as an example.

On Arbiscan, you’ll notice two unique tabs:

These indicate that the contract is upgradeable. When you use these tabs:

In contrast, regular Read Contract and Write Contract tabs show only the proxy’s internal management functions—typically used by administrators for upgrades.

For instance:

How Does Etherscan Detect Upgradeability?

Etherscan identifies upgradeable contracts by checking compliance with standards like:

If a contract follows EIP-1967, Etherscan reads the implementation address from a well-known storage slot (0x360894a13ba1a3210667c828492db98dca3e2076cc3735a920a3ca505d382bbc) and fetches the logic contract’s ABI automatically.

👉 Learn how blockchain explorers interpret complex contract patterns.

What If the Contract Isn’t Verified or Doesn’t Follow Standards?

Not all contracts publish source code or follow upgradeability standards. In such cases:

But all hope isn’t lost—you just need two things:

  1. The correct contract address
  2. The accurate ABI (preferably of the logic contract)

You don’t need full source code. Most projects publish ABIs in:

Once you have both pieces of data, you can use external tools like MyCrypto, Remix, or ethers.js scripts to interact with the contract.

Example Workflow Using MyCrypto

  1. Open MyCrypto
  2. Navigate to “Interact with Contracts”
  3. Enter the proxy contract address
  4. Paste the logic contract’s ABI
  5. Select a function (e.g., balanceOf)
  6. Input required parameters (e.g., wallet address)
  7. Sign and broadcast the transaction

As long as the proxy correctly delegates the call, your interaction will succeed—even without native Etherscan support.

Core Keywords for Clarity and SEO

To ensure this guide aligns with search intent and remains discoverable, here are the primary keywords naturally integrated throughout:

These terms reflect common queries from developers and DeFi users seeking practical guidance on direct contract interaction.

Frequently Asked Questions (FAQ)

What is the difference between a regular contract and an upgradeable one?

A regular contract has fixed logic after deployment. An upgradeable contract separates logic and storage using a proxy pattern, allowing functionality updates without changing the user-facing address.

Can I interact with an unverified contract?

Yes, as long as you have its ABI and address. Tools like MyCrypto or Remix let you manually input this data to read or write to the contract.

Why does Etherscan show “Read as Proxy” for some contracts?

This indicates the contract uses a proxy pattern (like EIP-1967). “Read as Proxy” shows functions from the logic contract, while “Read Contract” shows only proxy-level functions.

Is it safe to interact with upgradeable contracts?

Generally yes—but there's centralization risk. Since admins can upgrade logic, trust is placed in governance mechanisms. Always review upgradeability controls before interacting.

How do I find a contract’s ABI if it's not on Etherscan?

Check project documentation, GitHub repos, or developer APIs. Some tools also let you extract ABI from verified multi-part contracts or known interfaces (e.g., ERC-20).

Does every proxy use delegatecall?

Most modern proxies do. The delegatecall opcode preserves context (storage, sender) in the proxy while executing logic from the implementation, making it ideal for upgradeability.

Final Thoughts

Understanding how addresses, ABIs, and upgradeable architectures work together empowers you to interact with smart contracts beyond simple wallet approvals. Whether you're debugging, building integrations, or exploring DeFi protocols, knowing when and how to use the right ABI—with awareness of proxy patterns—is invaluable.

As blockchain ecosystems evolve, so do contract design patterns. Staying informed ensures you’re not just using Web3 apps—but truly understanding them.

👉 Start exploring verified contracts and test interactions safely today.