How to Read a Smart Contract on Etherscan

Detailed Instructions

First, navigate to the token or project's page on Etherscan (e.g., for USDC, go to etherscan.io/token/0xa0b86991c6218b36c1d19d4a2e9eb0ce3606eb48). The contract address is displayed prominently. Click on the 'Contract' tab to access the smart contract interface. The most critical check here is the Contract Verification status. A verified contract means its human-readable source code matches the deployed bytecode, allowing you to audit its logic. An unverified contract shows only raw, unreadable bytecode.

• Sub-step 1: Confirm the Address: Always double-check the contract address from the project's official website or documentation to avoid phishing sites.
• Sub-step 2: Check Verification: Look for a green checkmark and 'Contract Source Code Verified' label under the 'Contract' tab.
• Sub-step 3: Review Compiler Info: If verified, note the Solidity compiler version (e.g., v0.8.20) and any optimization settings used, as these affect gas costs and potential vulnerabilities.

Tip: For popular contracts like Uniswap V2 Factory (0x5C69bEe701ef814a2B6a3EDD4B1652CB9cc5aA6f), you can also see the number of 'Write Contract' interactions, indicating its activity level.

Detailed Instructions

In the 'Contract' tab, the 'Code' section displays the verified source code. Start by examining the contract's state variables (stored data) and function definitions. Key areas to focus on include the contract's inheritance (e.g., contract MyToken is ERC20, Ownable), which imports functionality from other contracts. Pay close attention to access control modifiers like onlyOwner or public, which dictate who can call certain functions. For example, a mint function with onlyOwner is centrally controlled.

• Sub-step 1: Identify Core Functions: Look for standard functions like transfer, approve, balanceOf for tokens, or swap for a DEX.
• Sub-step 2: Analyze Security Features: Check for reentrancy guards, pause mechanisms, and event emissions (e.g., event Transfer(address indexed from, address indexed to, uint256 value)).
• Sub-step 3: Examine Custom Logic: Review any unique business logic, mathematical calculations for fees, or upgradeability patterns (e.g., proxy contracts).

Tip: Use the 'Search' function within the code viewer to quickly find specific terms like 'fee' or 'owner' to understand critical governance and economic parameters.

Detailed Instructions

The 'Read Contract' tab provides a list of all view and pure functions that return data without costing gas. This is where you query the blockchain's current state. For an ERC-20 token contract, you can check any address's token balance, the total supply, or allowance granted to a spender. Simply enter the required parameters and click 'Query'. For instance, to check the balance of Vitalik Buterin's address (0xd8dA6BF26964aF9D7eEd9e03E53415D37aA96045) for the DAI stablecoin:

codeCopy
Function: balanceOf(address account)
Parameter: 0xd8dA6BF26964aF9D7eEd9e03E53415D37aA96045
Result: 555000000000000000000000 (555,000 DAI)

• Sub-step 1: Query Common Data: Start with name, symbol, decimals, and totalSupply to understand the token basics.
• Sub-step 2: Check Specific Interactions: Use allowance(owner, spender) to see if a DeFi protocol like Uniswap (0x68b3465833fb72A70ecDF485E0e4C7bD8665Fc45) is approved to spend tokens from a user's wallet.
• Sub-step 3: Verify Contract State: For complex contracts, read governance parameters like proposalCount, quorumVotes, or treasuryAddress.

Tip: Results are often returned in wei (the smallest unit). Remember to adjust for decimals; 18 decimals means dividing the result by 1,000,000,000,000,000,000 to get the human-readable amount.

Detailed Instructions

Navigate to the 'Transactions' and 'Events' tabs to see the contract's historical activity. Every interaction (like a token transfer or swap) is recorded as a transaction with a unique hash. Clicking on a transaction reveals details like the from and to addresses, gas used, and the specific function called (e.g., transfer). More importantly, smart contracts emit events, which are logged, indexed data. For example, a successful transfer will emit a Transfer event. The 'Event Logs' section decodes these logs.

• Sub-step 1: Filter Transactions: Use filters to view only 'Internal Txns' or specific transaction types (e.g., only those calling the swap function).
• Sub-step 2: Decode Event Logs: Look at recent Transfer or Approval events to see real-time token movements and permissions granted.
• Sub-step 3: Trace Contract Creation: Find the contract's creation transaction by clicking 'Creator' under the 'Contract' tab. This shows the initial constructor arguments and deployer address, which is crucial for verifying legitimacy.

Tip: For a deep dive, use the 'State Changes' tab on a transaction detail page. It shows exactly which storage slots in the contract were modified and their old/new values, revealing the precise impact of the call.

Detailed Instructions

Begin by navigating to the project's official website or documentation to obtain the verified contract address. Never rely on addresses from unofficial sources. On Etherscan, paste this address into the search bar. The critical first check is the Contract tab. Look for the green checkmark and "Contract Source Code Verified" label. This confirms the code you see matches the deployed bytecode. If it's unverified, you cannot audit it reliably.

• Sub-step 1: Check Verification Status: Ensure the contract is marked as "Verified". An unverified contract is a major red flag.
• Sub-step 2: Review the Contract Name and Compiler: Note the contract name and Solidity compiler version (e.g., v0.8.20). Outdated compilers may have known vulnerabilities.
• Sub-step 3: Confirm Creator Address: Under the "Contract" tab, check the transaction that created the contract (Contract Creation). Verify the deploying address aligns with the project's known deployer wallet.

Tip: For tokens, also check the "Read Contract" tab for standard fields like name, symbol, and totalSupply to ensure they match the project's claims.

Detailed Instructions

Click the "Contract" tab and select the "Code" sub-tab to view the verified source code. Start by identifying the constructor function. This function runs only once during deployment and sets critical initial state variables. Scrutinize any arguments it takes and what permissions are granted. For example, check if ownership (owner) or admin roles are set to a multi-signature wallet or a risky EOA.

• Sub-step 1: Identify Ownership: Search for owner, admin, or DEFAULT_ADMIN_ROLE assignments in the constructor.
• Sub-step 2: Review Immutable Variables: Look for variables declared with immutable or constant. These cannot be changed after deployment, which is good for trust.
• Sub-step 3: Check for Initial Mint or Supply: If it's a token, see if the constructor mints an initial supply and where those tokens are sent.

codeCopy
// Example of a concerning constructor setting ownership to `msg.sender` without a timelock
constructor() {
    owner = msg.sender;
}

Tip: A contract where the deployer retains excessive single-key control is a centralization risk. Prefer contracts where ownership is renounced or managed by a multi-sig.

Detailed Instructions

Navigate through the contract's functions, focusing on those that control value or access. The most important areas are access control mechanisms, pause functions, and upgradeability. Use the "Read Contract" and "Write Contract" tabs to see the current state and function interfaces. Look for functions like transferOwnership, pause, upgradeTo, or setFee.

• Sub-step 1: Map Privileged Functions: List all functions with modifiers like onlyOwner, onlyAdmin, or whenNotPaused.
• Sub-step 2: Check for Reentrancy Guards: Search for nonReentrant modifiers on functions that handle ETH or token transfers.
• Sub-step 3: Verify Fee Structures: Read state variables for fee, tax, or commission and check if there are functions to change them arbitrarily.

codeCopy
// A safe pattern using OpenZeppelin's ReentrancyGuard
function withdraw() external nonReentrant {
    // ... transfer logic
}

Tip: Excessive admin power to mint unlimited tokens, change fees, or pause transfers indefinitely are significant centralization and rug-pull risks.

Detailed Instructions

Smart contracts do not operate in isolation. Examine all external calls (using call, delegatecall, or transfer) and interactions with other contract addresses stored in state variables (e.g., router, stakingContract). These are potential points of failure if the external contract is malicious or buggy. Simultaneously, review the event declarations and where they are emitted. Events like Transfer, OwnershipTransferred, or Paused provide a transparent log for off-chain monitoring.

• Sub-step 1: Identify External Dependencies: List all hardcoded addresses or variables that are set to interact with other contracts (e.g., Uniswap V2 Router: 0x7a250d5630B4cF539739dF2C5dAcb4c659F2488D).
• Sub-step 2: Check for Approvals: Look for approve or setApprovalForAll functions that could grant excessive spending allowances to other addresses.
• Sub-step 3: Audit Event Emission: Ensure critical state changes (ownership transfer, large withdrawals) are accompanied by an event emission for accountability.

Tip: Use the "Events" tab on Etherscan to see a real-time history of emitted logs. A lack of events for major actions is a transparency issue.