Addresses, ABIs, and Upgradeable Contracts: A Comprehensive Guide

Understanding Addresses and ABIs in Smart Contract Interactions

This guide explores the relationship between contract addresses and ABIs, focusing on how to interact with upgradeable contracts. Designed for beginners or those unfamiliar with smart contract interactions, we'll break down these concepts in an accessible way.

The Fundamentals: Addresses vs. ABIs

When browsing blockchain data through Etherscan, you typically encounter three main elements:

• Blocks
• Transactions
• Addresses

Addresses can represent either:

1. Externally Owned Accounts (EOAs): Controlled by private keys
2. Smart Contracts: Contain executable code

For contract addresses, you need to understand their functionality to interact with them effectively. For instance, when trading on Uniswap V2, you'd call functions like swapExactTokensForTokens to exchange Token A for Token B.

What is an ABI?

The Application Binary Interface (ABI) defines a contract's structure - essentially its "blueprint." It specifies:

• Available functions
• Function names
• Input parameters
• Output parameters
• Function visibility and mutability

Example ABI for Uniswap V2's 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"
  }
]

Key Insight: ABIs aren't bound to specific addresses. You can use different ABIs with the same contract address, though the transaction may fail if the contract doesn't recognize the called function.

Upgradeable Contracts Explained

Why Upgradeable Contracts?

Teams implement upgradeable contracts when they:

• Anticipate frequent feature updates
• Want to avoid deploying new contracts repeatedly
• Need to maintain a single interaction point for users

The Two-Component System

Upgradeable contracts consist of:

1. Proxy Contract: The entry point that users interact with
2. Logic Contract: Contains the actual business logic

The proxy contract handles two primary tasks:

1. Stores the logic contract's address
2. Delegates function calls to the logic contract

How Delegation Works: The delegatecall Opcode

Instead of simply forwarding requests, the proxy contract uses delegatecall to execute the logic contract's functions within its own context. This means:

• The proxy contract "borrows" the logic contract's functionality
• All storage changes occur in the proxy contract's storage
• Users interact with a single, unchanging address

👉 Learn more about proxy patterns in Ethereum

Practical Interactions with Upgradeable Contracts

Using Etherscan Effectively

Etherscan provides user-friendly interfaces for contract interactions when:

• The contract has verified source code
• The ABI is available (automatically derived from source code)

For upgradeable contracts (like Arbitrum's USDT), you'll see additional buttons:

• Read as Proxy: View logic contract functions
• Write as Proxy: Execute logic contract functions

Standard EIP implementations (like EIP-1967) help Etherscan:

1. Identify proxy contracts automatically
2. Fetch the logic contract's ABI
3. Display relevant functions to users

When Contracts Aren't Verified

If a contract hasn't uploaded source code or doesn't follow standard EIPs, you'll need:

1. The correct contract ABI (not the proxy ABI)
2. Alternative tools like MyCrypto, MyEtherWallet, or Remix

Best Practices for Safe Interactions

1. Always verify you're using the correct:

   • Contract address
   • ABI (logic contract ABI for proxies)
2. Check for EIP compliance when dealing with upgradeable contracts
3. Use standard tools that properly handle proxy patterns

👉 Explore advanced Ethereum development tools

FAQ: Addressing Common Questions

Q: Can I use any ABI with any contract address?
A: Technically yes, but the transaction will fail if the contract doesn't implement the called function.

Q: How does Etherscan detect upgradeable contracts?
A: By checking for standard EIP implementations (like EIP-1967) that define specific storage slots or function patterns.

Q: What happens if I call proxy contract functions directly?
A: You'll interact with the proxy's admin functions rather than the logic contract's business functions.

Q: Where can I find a contract's ABI if it's not on Etherscan?
A: Check project repositories, documentation, or official websites - reputable projects typically publish these.

Q: Are there risks with upgradeable contracts?
A: Yes - ensure you trust the contract owners, as they can potentially change functionality. Always verify the current implementation address.

Q: What tools work best with upgradeable contracts?
A: Etherscan (for EIP-compliant contracts), MyCrypto, and dedicated developer tools like Hardhat with proper plugin configurations.