Wallet, RPC & Block Explorer Setup for Smart Contract Hunters

Wallet, RPC & Block Explorer Setup for Smart Contract Hunters

Before you fuzz a vault or file an Immunefi report, you need a safe read surface: a throwaway wallet, a public JSON-RPC endpoint, and fluency with block explorers. This Andrax tutorial — by Syed Zada Abrar — covers ~30% theory and ~70% practical.

Prerequisites: How to Start Web3 Bug Hunting in 2026 (Ethical Path Only). Series hub: Web3 Bug Hunting Learning Path 2026.

Hard lab rule: create a burner wallet, use public RPCs, and study historical public transactions. Never paste seed phrases or private keys into notes, screenshots, CMS drafts, Discord, or git. Never send exploit transactions to mainnet or public testnets “to confirm” — Immunefi bans that.

Why hunters need wallets, RPCs, and explorers (theory)

Smart-contract hunting is mostly reading: verified source, storage, logs, and prior transactions that show how a protocol actually behaves. Three pieces of infrastructure support that:

Etherscan for smart contract auditors (and hunters) is a daily driver: Contract tab, Read/Write contract (read-only for study), Events, and transaction traces. Pair it with Sourcify (docs) when you want decentralized verification metadata and reproducible source matching.

Hunters also use wallets badly. Common failure modes: one MetaMask profile for personal funds and experimental dapps; screenshots that include seed phrases; “temporary” private keys committed to a repo; connecting the hunting wallet to random claim sites. Fix those before you install Foundry.

Lab overview (what you will build today)

1. Create a burner browser-wallet account (or a dedicated profile).
2. Point it at Ethereum via a public RPC (and know how to swap RPCs).
3. Open one historical public transaction on Etherscan and explain it in your notes — fields only, no secrets.
4. Optionally re-fetch the same tx via eth_getTransactionByHash against a public RPC to see explorer ↔ node parity.

No contract deployment required. No mainnet “test exploit.” No funding required beyond optional dust you can afford to lose forever on the burner.

Step 1 — Burner wallet setup (practical)

Use a mainstream wallet such as MetaMask (or another EOA wallet you already trust operationally). For hunting practice:

1. Separate profile / separate browser from your personal finance wallet when possible.
2. Create a new account. Write the seed on paper offline if you must keep it — not in this tutorial’s notes template.
3. Label it clearly: ANDRAX-BURNER-READ or similar.
4. Record in your notes only:

• Public address (0x…)
• Network name you will use (e.g. Ethereum Mainnet for read study)
• Date created
• “No private key stored in digital notes” checkbox

5. Optional: create a second burner for “I might click a dapp” vs “read-only study” — still never mix with cold storage.

Do not import this burner into production ops, CI, or shared team password managers without a deliberate secrets process. For this lab, paper or a password manager entry that you control is enough — still never paste keys into Andrax drafts.

Address literacy refresher: What is an Ethereum Address? (Etherscan Knowledge Base).

Step 2 — Public RPC for hunters (practical)

Wallets and Foundry both need an RPC URL. Per ethereum.org, applications talk to nodes through the JSON-RPC API. For beginners:

Practical steps:

1. Open Chainlist (or your wallet’s network settings) and confirm chain ID 1 for Ethereum mainnet when you only need to read public history.
2. Add or switch to a public HTTPS RPC your wallet accepts. Prefer endpoints you can also curl.
3. Sanity-check with a read-only call (example against a public gateway — swap URL if one provider rate-limits you):

curl -s -X POST https://cloudflare-eth.com \
 -H 'content-type: application/json' \
 -d '{"jsonrpc":"2.0","method":"eth_chainId","params":[],"id":1}'

Expected idea: "result":"0x1" for mainnet. If you get errors, switch provider — do not start spraying random IPs.

4. For Foundry later, you will set ETH_RPC_URL in a local env file that is gitignored. Today, prove you can reach a node without putting keys in the URL path casually pasted into chat.

Hunter rule: public RPCs are for read and for local fork backends later. They are not a free scanner farm against in-scope production systems. Immunefi and most program pages prohibit reckless automation and forbid mainnet exploit testing.

Step 3 — Etherscan & Sourcify as daily drivers (practical)

Open Etherscan and practice this navigation on any public verified contract you already know is famous (for example WETH’s token page code tab — study only):

1. Address page — balance, tx count, token holdings.
2. Contract tab — “Contract Source Code Verified” vs bytecode-only.
3. Read Contract — view/pure getters (safe curiosity).
4. Write Contract — do not connect your personal wallet; skip writes for this lab.
5. Events / Txns / Internal Txns — how value and calls actually moved.

Then open Sourcify / repo.sourcify.dev and search the same address when available. Sourcify’s model emphasizes exact verification metadata — useful when Etherscan UI and compiler settings disagree with what you see in a repo.

Etherscan for smart contract auditors checklist (copy into notes):

• Is source verified? Which compiler version / optimization?
• Proxy? Implementation address linked?
• Recent upgrades or admin txs?
• Are there failed txs that hint at access control or paused states?
• Can I get the same bytecode match on Sourcify?

Deeper reading of verified vs unverified contracts is next: How to Read Verified and Unverified Smart Contracts.

Lab — Explain one historical public transaction

Goal: prove you can read a transaction the way a hunter does — on a finished, public example — without touching any bounty target.

Chosen example: the sample transaction used in ethereum.org’s JSON-RPC documentation for eth_getTransactionByHash:

• Etherscan: 0x88df016429689c079f3b2f6ad39fa052532c56795b733da78a91ebe6a713944b
• Also documented under Ethereum JSON-RPC — eth_getTransactionByHash

What the fields mean (fill this table in your notes)

Verified via public RPC (eth_getTransactionByHash / eth_getTransactionReceipt on 2026-09-30) and the ethereum.org example object:

Optional RPC parity check

curl -s -X POST https://cloudflare-eth.com \
 -H 'content-type: application/json' \
 -d '{"jsonrpc":"2.0","method":"eth_getTransactionByHash","params":["0x88df016429689c079f3b2f6ad39fa052532c56795b733da78a91ebe6a713944b"],"id":1}'

Compare from, to, value, and input to the Etherscan UI. Matching them builds trust that explorers and nodes agree before you rely on either in a report.

What you are not doing

• Not re-sending this transaction
• Not phishing the from address
• Not using this pattern against an Immunefi asset
• Not storing any private key beside the hash in your notes

Background on transactions generally: ethereum.org — Transactions. Explorer API reference (when you automate public reads carefully): Etherscan docs.

Security habits checklist (pin this)

• Burner ≠ personal treasury
• Seed / private key never in markdown, CMS, git, or chat
• Screenshots cropped of secrets and QR seeds
• RPC API keys (if any) in local env only
• Explorer study on public history ≠ authorization to exploit
• Next tooling installs (Foundry/Slither) still use local forks for PoCs

Connecting Foundry later (preview only)

You are not installing Foundry in this spoke — that is a later tutorial — but your RPC and burner habits should already match how Foundry will behave:

• ETH_RPC_URL points at a public or API-key RPC for fork reads
• cast tx 0x88df…944b should show the same from / to / value you wrote in the lab table
• anvil --fork-url $ETH_RPC_URL becomes the place you flush PoCs — never cast send against a live in-scope contract for “quick confirmation”

If today’s curl eth_chainId check failed, fix RPC access before you touch foundryup. Broken RPC hygiene is how beginners paste API keys into public gists.

Browser / extension hygiene for hunters

• Prefer a dedicated browser profile with wallet extension installed only there
• Disable the burner profile’s cloud-sync of extensions if your threat model includes sync leaks
• When an explorer “Write Contract” prompts Connect, cancel unless you are on a disposable burner and a deliberately authorized action
• Treat sudden wallet pop-ups while reading docs as hostile until proven otherwise

These are operational security basics, not paranoia. Web3 hunting fails more often from account compromise than from missing a clever math bug on week one.

Common mistakes

1. One wallet for everything — a malicious “airdrop” site connected to your main seed is a career-ending own-goal, not a hunting win.
2. Private keys in lab notes — if your notes sync to the cloud, treat that as a leak.
3. Confusing Write Contract with a PoC — clicking Write on mainnet against in-scope code can be a ban. PoCs belong in Foundry on a fork (upcoming setup spoke).
4. Scraping explorers aggressively — rate limits and program anti-automation rules exist for a reason.
5. Skipping Sourcify — when verification metadata matters in a dispute, a second verifier helps.

Next steps in the Andrax Web3 path

• Prev (live): How to Start Web3 Bug Hunting in 2026
• Hub (live): Web3 Bug Hunting Learning Path 2026
• Next (live): Solidity Essentials for Bug Hunters (Read First, Write Second) — visibility, msg.sender vs tx.origin, call vs delegatecall
• Next tooling (live): Foundry + Slither Setup for Smart Contract Security (2026); then vuln-class tutorials

External companions remain Cyfrin Updraft, Ethernaut, and Damn Vulnerable DeFi — still local/CTF first.

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