How to Read Verified and Unverified Smart Contracts

How to Read Verified and Unverified Smart Contracts

How to read smart contracts on Etherscan is a daily hunter skill: most of your time is spent reading strangers' code (or the absence of it), not writing your own vault. This Andrax tutorial — by Syed Zada Abrar — covers ~40% theory, ~60% practical.

Prerequisites: Solidity Essentials for Bug Hunters; Wallet, RPC & Block Explorer Setup; How to Start Web3 Bug Hunting in 2026. Hub: Web3 Bug Hunting Learning Path 2026.

Ethics fence (read this first): everything below that touches a live chain is read-only — viewing verified source, decoding ABIs, and querying public storage slots. Any exploit experiment belongs on Remix VM, Foundry/Anvil, or a public CTF. Never send confirmation transactions that abuse live user funds. Immunefi permanently bans testing on mainnet or public testnets of in-scope code (Immunefi rules).

Primary references: Sourcify, Sourcify exact match vs match, Solidity storage layout, cast storage, Etherscan contract verification docs.

What “verified” actually means

On explorers, verified means someone uploaded source (and compiler settings) that recompile to the deployed bytecode — not that an auditor blessed the contract, and not that it is safe to use.

Sourcify's docs explain Exact Match vs Match clearly: Exact Match means the metadata hash fingerprint matches; a Match still means the logic compiles to the same runtime code aside from that fingerprint (docs). Verification ≠ safety. Sourcify itself says verifiers do not audit contents.

Hunter takeaway: verified source is a gift. Treat unverified bytecode as incomplete evidence — never invent Critical severity from a guessed decompiler comment alone.

The Contract tab workflow (verified)

Open a verified contract on Etherscan (or a Sourcify-backed explorer). Skim in the same order as the Solidity essentials guide, but now with explorer UI affordances:

1. Contract / Code — pragma, license, file list (multi-file vs flattened)
2. Read Contract — view/pure getters; confirm what the UI labels vs what the source says
3. Write Contract — map every state-changing entry point (do not click Write against live protocols for “testing”)
4. Events — reconstruct history from Logs
5. Proxy (if shown) — Implementation / Admin slots; remember you must read implementation source and proxy storage layout

Multi-file vs flattened

Flattened single-file verifies are easier to Ctrl-F. Multi-file preserves imports and is closer to how the team ships. Prefer multi-file when available; use forge flatten later only in your local clone when you need a single audit notebook.

ABI as a map, not truth

The ABI lists function signatures and types. It does not prove:

• That onlyOwner is correctly implemented
• That a token is standard ERC-20
• That initialize cannot be called twice

Hunters decode calldata with the ABI, then prove behavior against source (or against a local fork). Tools: explorer's Decode Input Data, Foundry cast 4byte-calldata / cast decode-calldata, and openchain.xyz-backed selector lookups via Cast.

Lab A — Verified vs bytecode-only view

Pick one well-known verified contract and one unverified (or “not verified”) contract on Ethereum mainnet. Famous tokens such as WETH9 at 0xC02aaA39b223FE8D0A0e5C4F27eAD9083C756Cc2 are useful because explorers show verified source and you can practice read-only inspection without inventing a random DeFi target (Etherscan token page).

Part 1 — Verified walkthrough (notes template)

For the verified contract, write five bullets:

1. Compiler version + optimization runs (from verification metadata)
2. Inheritance / interfaces that matter
3. Top five external/public functions that move value or rights
4. Every modifier that looks like auth (onlyOwner, roles, custom)
5. Every low-level call / delegatecall / token transfer you spot

Cross-check the same address on Sourcify Lookup if available. Note Exact Match vs Match.

Part 2 — Bytecode-only view

For an unverified contract (any small unverified deployment you find on a public explorer — do not attack it):

1. Open the Code tab — you should see runtime bytecode, not Solidity.
2. Note bytecode size (cast codesize <addr> --rpc-url $RPC once Foundry is installed).
3. Extract function selectors from recent successful txs (first 4 bytes of input) and resolve with cast 4byte <selector> or the explorer's decoder when known.
4. List what you cannot know yet: modifier bodies, private helper names, intentional vs accidental complexity.

Write one paragraph: “What would I need (source, ABI, or both) before filing any report?”

Storage slots without myths

Solidity packs state into 32-byte slots. Layout rules live in the official docs (Layout of State Variables in Storage):

• Scalars fill slots in declaration order (with packing for smaller types)
• Mappings and dynamic arrays use keccak256-based slot formulas — you do not “see” all keys by reading slot 0
• private does not hide data from chain observers (the Solidity essentials guide reminder)

Hunters use storage to:

• Confirm proxy implementation/admin slots (EIP-1967 patterns)
• Check whether an initialized flag flipped
• Validate a hypothesis from source (“owner should be slot 0”) against live state — read-only

You never need a private key to read storage.

Lab B — cast storage on a public example (read-only)

Install Foundry if you have not (installation / foundryup). Set a public Ethereum RPC (ETH_RPC_URL or --rpc-url). No private keys.

Example — WETH9 (verified, public):

# Runtime bytecode size (read-only)
cast codesize 0xC02aaA39b223FE8D0A0e5C4F27eAD9083C756Cc2 --rpc-url $ETH_RPC_URL

# Raw storage at slot 0 (whatever the contract stores there — document, don't invent meaning)
cast storage 0xC02aaA39b223FE8D0A0e5C4F27eAD9083C756Cc2 0 --rpc-url $ETH_RPC_URL

# Optional: compare against a view call if ABI is known
cast call 0xC02aaA39b223FE8D0A0e5C4F27eAD9083C756Cc2 "name()(string)" --rpc-url $ETH_RPC_URL

cast storage returns the raw 32-byte word at a slot (reference). For mappings you will later use cast index to compute the slot from key + base slot — still read-only.

Lab write-up (required):

Rules for this lab:

• Public RPC only; no secrets in your notes
• No cast send against mainnet protocols
• If meaning is unclear, write “unknown — need source” instead of forcing a Critical narrative

When you have a local Foundry project (next spoke), prefer forge inspect Contract storage-layout on your compiled artifacts — that teaches packing without guessing live DeFi slots.

ABI decoding for hunters

Common tasks:

# Resolve a selector
cast 4byte 0xa9059cbb

# Decode calldata (selector + args)
cast decode-calldata "transfer(address,uint256)" 0xa9059cbb000000000000000000000000...

# Pretty-print unknown calldata (online selector DB)
cast pretty-calldata 0xa9059cbb000000000000000000000000...

On Etherscan, open a transaction → Input Data → Decode Input Data when the contract is verified. For unverified callees, you may only get the selector until you find an ABI elsewhere (Sourcify, another chain's verify, a GitHub commit — always verify it matches bytecode).

Smell checklist while decoding:

• Unexpected delegatecall targets in proxy admin txs
• initialize / upgradeTo called by a non-timelock EOA
• Approvals to unknown spenders right before a drain (study historical public txs only)

Unverified contracts: honest tactics (still ethical)

When source is missing:

1. Selectors + events — reconstruct the public interface from usage
2. Bytecode tools — length, immutable args, metadata CBOR trailing bytes (compiler fingerprint)
3. Diff against known templates — many unverified contracts are slight forks of verified ones
4. Ask for source — in bounty programs, unverified in-scope code is often still fair game if scope allows, but your PoC must still be local-fork runnable
5. Do not interact adversarially with live unverified contracts “to see what happens”

Decompilers (e.g. community tools) produce hypotheses, not evidence. Pair every decompiler claim with a Foundry test on a fork after you are inside authorized scope — never as a mainnet spray.

Proxy reading in one page

If the explorer shows “Proxy,” you are usually looking at:

• Proxy address users send txs to
• Implementation address holding logic
• Admin / upgrade authority (sometimes a separate ProxyAdmin)

Read both sources. Storage that matters often lives in the proxy; logic lives in the implementation. EIP-1967 implementation slot is a common pattern — later the proxy guide goes deep. For now: whenever you see delegatecall, re-ask the Solidity essentials guide's question — “whose storage, whose auth?”

# Read-only helper many hunters use (implementation slot helpers exist in Cast)
cast implementation 0xYourProxy --rpc-url $ETH_RPC_URL

(Only against addresses you are studying for learning or in-scope review — still no exploit txs.)

Common beginner traps

Workbook template (copy into your notes)

Address:
Chain:
Verified? Etherscan / Sourcify Exact / Sourcify Match / None
Compiler / optimizer:
Value-moving entry points:
Auth modifiers:
External calls / hooks:
Proxy? Impl address:
Storage notes (slot → meaning → confidence):
Open questions before any report:
Ethics check: read-only on live chain? PoC plan is local/CTF/scope?

Diffing two verifications of the “same” address

Sometimes Etherscan shows verified source while Sourcify shows a Match (not Exact), or another explorer disagrees. Record:

• Compiler version + settings on each verifier
• Whether the metadata hash / IPFS CBOR trailer matches
• Whether the ABI JSON differs in event or error definitions

If two verifications disagree functionally, stop and treat the on-chain bytecode as ground truth: recompile locally with each candidate source set until one matches. Filing against the wrong source file is an expensive embarrassment.

Reading constructor args and immutables

Verified pages often decode constructor arguments. Immutables are baked into runtime bytecode. When hunting proxies or cloned contracts (minimal proxies / clones), confirm which addresses were immutably set — routers, oracles, owners — before assuming an admin can still change them via storage.

# Creation bytecode / explorer “Contract Creation” tx is the usual place to study constructor args
# Cast helpers exist for some workflows; always pair with verified source
cast creation-code --help >/dev/null 2>&1 || true

Use the Foundry book when you need the exact cast subcommand for your installed version — CLI surfaces evolve (Cast reference hub).

Next steps

• Prev: Solidity Essentials for Bug Hunters · Wallet / RPC / Etherscan setup
• Hub: Web3 Bug Hunting Learning Path 2026
• Next: Foundry + Slither Setup for Smart Contract Security (2026) · Solidity Reentrancy Explained (Classic, Cross-Function, Read-Only)
• Keep practicing Ethernaut while you read real verified contracts — apply the Contract-tab order every time

Educational content by Syed Zada Abrar for Andrax (andraxpentester.in). Authorized research only.