Block Explorers

:::section{mins=3} What Is a Block Explorer :::

:::lead A [[gloss:block|block]] explorer is not the [[gloss:blockchain|blockchain]]. It is a website that runs a full [[gloss:node|node]], indexes everything that [[gloss:node|node]] sees, and renders the result as searchable pages. The chain owes you nothing. The explorer is a company. Most of the time the two agree – but the moments when they don't are the moments worth understanding. :::

:::p{html} You have tapped a link to Etherscan dozens of times. The [[gloss:wallet|wallet]] shows a [[gloss:transaction|transaction]] [[gloss:hash|hash]], you click it, and a page loads with fifteen fields and four tabs. Most of those fields are familiar from 3.3 §1: from, to, value, [[gloss:gas|gas]], [[gloss:nonce|nonce]]. Some of them are decoded from data into a readable function call. Some are not – the field labelled "Input Data" still shows raw hex if Etherscan does not recognize the contract. This card is the manual you never read for that page, and for the sibling pages an explorer shows for an address, a contract, a [[gloss:block|block]], a token. :::

:::p{html} The [[gloss:blockchain|blockchain]] itself is dense binary. Every [[gloss:block|block]] is a list of [[gloss:transaction|transactions]]; every [[gloss:transaction|transaction]] is RLP-encoded fields and an [[gloss:ecdsa|ECDSA]] signature; every contract storage slot is a 32-byte word with no native label saying what it means. A full [[gloss:node|node]] verifies all of this and stores it locally. To look at it through a [[gloss:node|node]] directly, you call JSON-RPC methods like eth_getTransactionByHash and get back raw structures that nobody reads for pleasure. The explorer's job is the same one a librarian does for a library: take the books that are already on the shelves and build a catalog with search, cross-references, and human-readable summaries. The books – the chain – exist either way. The catalog is the difference between "anyone can read this" in theory and "anyone can read this" in practice. :::

:::p{html} An explorer is built on three layers. At the bottom is a full [[gloss:node|node]] – usually Geth, Reth, Erigon, or a managed equivalent – that participates in the network and stores the canonical chain. In the middle is an indexer: a custom database that watches the [[gloss:node|node]], decodes events and call traces, and writes them into tables optimised for queries like "every transfer of this token in the last hour" or "every address that ever called this function". On top sits the web UI and a public API. Etherscan, the dominant [[gloss:ethereum|Ethereum]] explorer, has been running this stack since 2015 from Kuala Lumpur as a private company; Blockscout is the open-source explorer engine that competes with it and that any project can self-host on its own chain. Solscan does the same job for [[gloss:solana|Solana]] and was acquired by the Etherscan team in early 2024. [[gloss:mempool|Mempool]].space does it for [[gloss:bitcoin|Bitcoin]], focused on the [[gloss:utxo|UTXO]] model and the public [[gloss:mempool|mempool]]. The explorer is not a neutral utility; it is software run by an organisation with downtime, ad revenue, and incentives. :::

:::p{html} Because it is software, the explorer can be wrong. Usually the way it is wrong is boring: a five- to fifteen-second lag behind the canonical head, a token logo that didn't load, a contract not yet verified. Sometimes it is interesting. In April 2024 Etherscan briefly served phishing ads aggregated through the Coinzilla and Persona networks; the links led to drainer sites – fake pages that, once you connect a [[gloss:wallet|wallet]], trick you into a signature and siphon out the funds. The ads came down within hours, but for a window the most-visited explorer in crypto was walking its own users onto pages built to rob them. In February 2024 the Angel Drainer group exploited Etherscan's policy of automatically marking Safe (Gnosis Safe) vault contracts as verified: they deployed a malicious Safe vault, got 128 [[gloss:wallet|wallets]] to sign Permit2 messages targeting it, and drained $403,000. The contract was verified. The contract was malicious. Verification, in Etherscan's sense, only proves the published source code matches the on-chain [[gloss:bytecode|bytecode]]. It is a low bar. Anything else – audited, safe, ownership renounced, not a drainer – is an inference you layer on top of that one fact. :::

:::p{html} For everyday use this distinction does not matter – Etherscan and the chain agree, the UI loads, the page is correct. The distinction matters when something is at stake: a large [[gloss:transaction|transaction]], a suspicious airdrop, an unfamiliar contract, an incident in progress. In those moments it helps to remember that what you are reading is one company's view of the chain, and that the chain itself can be read by other means: a different explorer (Blockscout, Etherscan's open competitor on the same chain), your own [[gloss:node|node]] via RPC, or a multi-source aggregator. The rest of this card is about getting fluent with the explorer's view, but the foundation underneath is that the chain is the source of truth, and the explorer is one rendering of it. :::

:::callout{icon=💡} The catalog system in a large public library. The books are real, on shelves, in fixed locations – anyone with a reader's card can walk in and find one. But the catalog is what makes the library usable: a database of titles, authors, subject headings, and shelf locations, maintained by librarians who walk the stacks every day to keep it current. When the catalog is wrong – a card filed under the wrong heading, a book marked "available" when it's actually being repaired – the books themselves don't change. You can still walk to the shelf and check. The catalog is convenient; the shelf is canonical. An explorer is the catalog. The chain is the shelf. Almost always they agree, and when they don't, the shelf is the one that matters. :::

:::keypoints{label="Key Points"}

• Every surface that shows you a balance – your [[gloss:wallet|wallet]], Etherscan, a portfolio app – is reading its own snapshot at its own moment, and they drift apart by seconds. So when two of them disagree, "refresh harder" is the wrong instinct; the question is which source is closest to the chain right now. The [[gloss:move|move]] that ends the argument is to query an independent RPC directly and call balanceOf yourself: that hits canonical state and owes nothing to anyone's indexer.
• Every major [[gloss:evm|EVM]] chain has its own explorer in the Etherscan family – Arbiscan for Arbitrum, Basescan for Base, Optimistic Etherscan for Optimism, Polygonscan for Polygon, BscScan for BNB Chain. Same UI, same tabs, same search bar. Solscan covers [[gloss:solana|Solana]] under the same ownership since 2024. The skill transfers; what changes is the underlying account model, not the page layout.
• The most useful thing verification gives you is the Read Contract panel – worth more than the checkmark itself. For free, with no [[gloss:wallet|wallet]] connected, you can call owner() (is there one [[gloss:private key|private key]] behind this, or a [[gloss:multisig|multisig]]?), paused(), check whether an upgradeTo method exists, read your own current allowance. Five seconds tells you who can change this contract out from under you, and how – exactly what a "verified" tag says nothing about. Don't read the checkmark as the answer; use it as the key to the door the answers are behind.
• A second source is for moments that are worth the friction, not for everyday checks – moving size, signing against something you don't recognise, watching an incident unfold. The skill is reading the result: two independent sources (a rival explorer like Blockscout, or a raw eth_getTransactionByHash from your own RPC) agreeing raises your confidence; them disagreeing is the more valuable signal – it means at least one is wrong, and you act on neither until you know which. The cost is one minute; the thing it protects can be your whole balance. :::

:::details{badge=Practice title="Verifying that your explorer's UI hasn't been tampered with"} :::p{html} Browser-side tampering is rare but real. A compromised browser extension, a hijacked DNS, or a malicious ad served by the explorer itself (the April 2024 Etherscan incident) can show you a page that looks correct but isn't. The cheapest cross-check is to open the same [[gloss:transaction|transaction]] on a different surface and compare two specific fields: the from/to pair and the value (or token-transfer amount on the Token Transfers tab). :::

:::p{html} Pick a second source. Blockscout for [[gloss:ethereum|Ethereum]] [[gloss:l1|L1]] sits at [[gloss:ethereum|eth]].blockscout.com and indexes from independent infrastructure. For [[gloss:layer 2|L2s]], Blockscout is usually the canonical alternative: arbitrum.blockscout.com, base.blockscout.com, optimism.blockscout.com. If you have an Alchemy or Ankr API key, paste the [[gloss:transaction|transaction]] [[gloss:hash|hash]] into a curl request to eth_getTransactionByHash and read the JSON directly – the from, to, value and input fields are right there, unrendered. Two sources agreeing is a strong signal. Two sources disagreeing is a stronger signal – it means at least one of them is wrong, and you should not act on either until you know which. :::

:::p{html} 浏览器端篡改很少见但确实存在。被入侵的浏览器扩展、被劫持的DNS、或浏览器本身提供的恶意广告（2024年4月Etherscan事件）都可能显示一个看起来正确但实际不正确的页面。最便宜的交叉检查是在不同来源上打开同一笔交易，比较两个特定字段：from/to对和value。 :::

:::p{html} 选择第二个来源。[[gloss:ethereum|Ethereum]] [[gloss:l1|L1]]的Blockscout位于[[gloss:ethereum|eth]].blockscout.com，从独立基础设施索引。对于[[gloss:layer 2|L2]]，Blockscout通常是规范替代方案。如果你有Alchemy或Ankr API密钥，可以将交易哈希粘贴到eth_getTransactionByHash的curl请求中直接读取JSON。两个来源一致是强信号。两个来源不一致是更强的信号––意味着至少一个是错的。 ::: :::

:::details{badge=Advanced title="The indexer problem: why an explorer always lags the chain"} :::p{html} An explorer doesn't just mirror the [[gloss:node|node]] – it processes the [[gloss:node|node]]'s output. Every new [[gloss:block|block]] triggers work: decode every [[gloss:transaction|transaction]], expand internal call traces, parse event logs against known ABIs, update token-balance snapshots, refresh per-address statistics, fan-out into push notifications and webhooks. On a normal [[gloss:ethereum|Ethereum]] [[gloss:block|block]] (12 seconds, 150–200 [[gloss:transaction|transactions]], a few thousand events) this takes 3–8 seconds on Etherscan's infrastructure. On a busy [[gloss:layer 2|L2]] [[gloss:block|block]] (Arbitrum aggregating hundreds of [[gloss:transaction|transactions]] per second), the indexer is structurally further behind – typically 5–15 seconds, sometimes more during [[gloss:nft|NFT]] mint storms. :::

:::p{html} The practical consequence is that "I just sent it and it's not on Etherscan yet" is almost always normal. The [[gloss:transaction|transaction]] is in the [[gloss:mempool|mempool]] or already in a [[gloss:block|block]]; the indexer hasn't caught up. Refreshing harder doesn't help. The right [[gloss:move|move]] is to wait one or two [[gloss:block|block]]-times (about 30 seconds on [[gloss:mainnet|mainnet]], longer on a busy [[gloss:layer 2|L2]]), and if it's still not there, open the same [[gloss:hash|hash]] on a second explorer or query RPC directly. The opposite case – Etherscan shows a [[gloss:transaction|transaction]] the chain doesn't – only happens if the explorer is hallucinating, which is exceedingly rare and obvious when it does. :::

:::p{html} 浏览器不仅仅是镜像节点––它处理节点的输出。每个新区块触发工作：解码每笔交易、展开内部调用追踪、解析事件日志、更新代币余额快照、刷新地址统计。在正常的[[gloss:ethereum|Ethereum]]区块（12秒，150-200笔交易）上，Etherscan基础设施需要3-8秒。在繁忙的[[gloss:layer 2|L2]]区块上，索引器结构性地更落后––通常5-15秒。 :::

:::p{html} 实际后果是"我刚发送了但Etherscan上还没有"几乎总是正常的。交易在内存池中或已经在区块中；索引器还没跟上。正确的做法是等一两个区块时间（主网约30秒），如果仍然没有，在第二个浏览器上打开相同哈希或直接查询RPC。 ::: :::

:::quiz{id=q-3-4-s1 correct=3 explanation="Correct. MetaMask reads through whatever RPC is configured (Infura by default); Etherscan reads from its own indexer on top of its own [[gloss:node|node]]. Both can be 5–15 seconds behind a [[gloss:block|block]], and either can be wrong – Etherscan during indexer outages, MetaMask if the configured RPC lags or returns stale data. The right [[gloss:move|move]] is to query an independent RPC directly (any Alchemy/Ankr key, or a public endpoint) and call balanceOf on the USDC contract. That hits the canonical state. In practice, the discrepancy is almost always a brief indexer lag and resolves within a [[gloss:block|block]]; the discipline is to not assume one screen is "the truth"."} You open the same address in MetaMask and on Etherscan. MetaMask says your USDC balance is 1,200. Etherscan says 1,400. Which number is right?

• Etherscan, because it runs a full archival [[gloss:node|node]] with its own indexer, while MetaMask only relays calls through a third-party RPC
• MetaMask, because it holds your [[gloss:private key|private key]] and reads the balance directly from your own [[gloss:wallet|wallet]] state
• Whichever source was refreshed more recently, because a fresher cache is closer to the actual chain state
• Neither is automatically right – both are reading their own data source; the canonical answer is on the chain via RPC :::

:::section{mins=5} Etherscan Masterclass :::

:::lead Etherscan handles roughly a million queries per hour and most of its users touch a fraction of what it can do. The search bar takes more than addresses, the tabs each show something different, and the labels are Etherscan's opinion rather than a fact from the chain – not something to lean on as proof. The same UI, meanwhile, works on Arbitrum, Base, Polygon, and [[gloss:solana|Solana]] under different domains. The point of this section is to make Etherscan read at a glance from here on, instead of having to be decoded. :::

:::p{html} Open etherscan.io and the page divides into three zones. The top is a strip of network statistics – latest [[gloss:block|block]], current [[gloss:gas|gas]] price in Gwei, [[gloss:ethereum|ETH]] price, market cap – that exists mostly as a landing-page feature; you stop looking at it after a week. The middle is the search bar, which is the only thing you really use. The bottom is the activity feed: a live list of the most recent [[gloss:block|blocks]] and [[gloss:transaction|transactions]], mostly noise. The page you arrive at is a thin doorway. Everything useful happens after you paste something into the search bar. :::

:::p{html} What goes into the search bar tells Etherscan what to do. The system auto-detects the input format and routes you to the right page type, of which there are essentially five: :::

:::p{html}

:::p{html} A few less-known formats work too – worth learning once, then they keep paying off. A function selector – the first four bytes of a contract call, e.g. 0xa9059cbb for transfer(address,uint256) – pasted into search returns the matching function signature and recent [[gloss:transaction|transactions]] that called it. Useful when a [[gloss:wallet|wallet]] shows you raw data and you want to know which function the caller is invoking. A method ID with arguments goes to a decoder page. Pasting a raw signed [[gloss:transaction|transaction]] (rare but possible) decodes its fields. The search bar is more of a query interface than a "find page" – Etherscan treats whatever you paste as a question and tries to figure out which kind. :::

:::p{html} Once you are on an address or contract page, the tabs do not show overlapping information – they show different lenses on the same data, and missing this is the most common mistake new users make. The three that get confused for each other: :::

:::p{html}

• [[gloss:transaction|Transactions]] – lists [[gloss:transaction|transactions]] where this address is the from or the to of the outermost call. This excludes most of the activity that involves the address only indirectly.
• Internal [[gloss:transaction|Transactions]] – lists contract-to-contract calls that touched this address: it received [[gloss:ethereum|ETH]] from a contract, or a contract executed on its behalf.
• ERC-20 Token Transfers – lists any token [[gloss:movement|movement]] involving this address, regardless of who triggered it.

:::p{html} So if you sent 1,000 USDC through a DEX router, your "main" [[gloss:transaction|Transactions]] tab shows your call to the router, the Internal [[gloss:transaction|Transactions]] tab is empty (no [[gloss:ethereum|ETH]] moved internally to or from you), and the ERC-20 tab shows the USDC outflow. Three tabs, three different views, all true. New users look at the first tab, see nothing they expected, and conclude "Etherscan is wrong." It isn't. :::

:::p{html} The labels Etherscan attaches to addresses are the most opinion-laden surface on the page. A green checkmark next to an address means the contract is verified – source code matches [[gloss:bytecode|bytecode]]. A label like "Binance: Hot [[gloss:wallet|Wallet]] 14" or "Uniswap V3: Router 2" is editorial: Etherscan's team added it based on public information, on-chain analysis, or a request from the entity. A "Phish/Hack" tag on an address is added after the community reports activity and Etherscan confirms. The absence of a phish tag is therefore not safety; many active drainer contracts wear no tag at all because they're new. Tags are useful for confirming what you already suspect, not for clearing what you don't know. They are also network-specific – a labeled address on Etherscan may have no label on Arbiscan even though it's the same address with the same [[gloss:bytecode|bytecode]], because the Arbiscan team labels independently. :::

:::p{html} One last piece worth knowing: Etherscan has an API. The same data the UI shows is accessible at api.etherscan.io under endpoints like module=account&action=txlist ([[gloss:transaction|transactions]] for an address), module=contract&action=getabi (ABI for a verified contract), module=gastracker (current [[gloss:gas|gas]] prices). The free tier permits five requests per second; paid tiers reach 100 req/s. Most [[gloss:wallet|wallets]] you use rely on this API behind the scenes – Rabby's "contract security check" before a [[gloss:transaction|transaction]] calls Etherscan for the contract's age and verification status. Knowing the API exists turns "I wish I had a list of every ERC-20 transfer above $10,000 for this address in the last month" from a wish into a one-line script. The UI is a polished face; the API is the same data raw, and for any repeated workflow the API is the right surface. :::

:::callout{icon=💡} A full bloodwork panel a doctor prints after a routine checkup. Forty numbers across five pages: complete blood count, lipid panel, kidney markers, liver enzymes, thyroid. All real, all from the same vial of blood drawn the same morning. The patient who looks at the front page and sees "Total Cholesterol: 195" assumes everything is fine. The clinician knows to flip to page three and read the HDL/LDL split, because the headline number can hide the actual story. The data is not wrong; the reader is unpracticed. Etherscan is the same - every tab is real, every field is correct, and the difference between a fluent reader and a confused one is knowing which tab to flip to for which question. :::

:::keypoints{label="Key Points"}

• Treat the search bar as a free decoder for whatever your [[gloss:wallet|wallet]] won't explain. When a signature prompt shows an opaque hex [[gloss:blob|blob]] and no human-readable action, copy its leading four bytes into search: Etherscan names the function and shows real calls that have used it, so you learn what you're about to authorize without signing to find out. Almost everything else on Etherscan is used after the fact, to examine what happened; this one works the other way – before you sign, while there's still nothing to confirm.
• An empty tab is the single most misread signal on Etherscan. Someone checks one tab, finds none of what they were after, and decides the explorer is broken or the [[gloss:transaction|transaction]] failed – when in fact they're holding the wrong lens to the right event. Train one reflex against this: before you conclude "nothing happened," ask which tab would record the thing you're looking for, and check that one. Absence on the tab you happened to open proves nothing.
• Let labels [[gloss:move|move]] you in one direction only. A present warning label should stop you cold – it cost someone a loss to earn that tag, so respect it. But a missing label must never advance you: it means "no one has reported this yet," which is the default state of every fresh drainer, not a clean bill of health. The asymmetry is the whole point – a red flag is information, a blank space is just silence.
• The signal that you've outgrown the UI is repetition: the second time you find yourself clicking the same tabs to answer the same question, that question is a one-line API call. Reframing "I wish I could see every transfer over $10k this month" as a query you run instead of a page you scroll is the actual skill jump. And it costs no new trust – the API returns the same chain data the UI renders, just without the clicking, so nothing about your verification discipline changes. :::

:::details{badge=Practice title="Etherscan URL parameters – power-user navigation without clicking"} :::p{html} Etherscan exposes a usable URL grammar. Once you know the parameters, you can construct deep links by hand instead of clicking through the UI. The most useful ones live on the /txs and /address routes. :::

:::p{html}

• etherscan.io/address/0xABC...?a=0xDEF – filters the address page to interactions with a second address 0xDEF. Useful when you want every [[gloss:transaction|transaction]] between yourself and a specific contract.
• etherscan.io/txs?[[gloss:block|block]]=22500000 – all [[gloss:transaction|transactions]] in one specific [[gloss:block|block]].
• etherscan.io/txs?a=0xABC&p=3 – page 3 of the [[gloss:transaction|transactions]] tab. Pagination is in the URL, which lets you write scripts that walk history without scraping.
• etherscan.io/tokentxns?a=0xABC&toaddress=0xDEF – every ERC-20 transfer where 0xABC sent tokens to 0xDEF.
• etherscan.io/advanced-filter – the full filter UI: by method, by token, by amount range, by date. The same filters appear in URL parameters after you apply them, so you can bookmark a complex query.

:::p{html} The savings add up. "Show me every interaction my address ever had with Uniswap V3 Router" is one URL away instead of five tabs and a page-by-page scroll. Treat these as keyboard shortcuts: invisible until you learn them, painful to live without after. :::

:::p{html}

• etherscan.io/address/0xABC...?a=0xDEF – фильтр страницы адреса по взаимодействиям со вторым адресом 0xDEF. Удобно, когда нужны все транзакции между вами и конкретным контрактом.
• etherscan.io/txs?[[gloss:block|block]]=22500000 – все транзакции одного конкретного блока.
• etherscan.io/txs?a=0xABC&p=3 – страница 3 вкладки транзакций. Пагинация в URL – значит, можно писать скрипты, которые проходят историю без скрейпинга.
• etherscan.io/tokentxns?a=0xABC&toaddress=0xDEF – все ERC-20 переводы, где 0xABC отправил токены 0xDEF.
• etherscan.io/advanced-filter – полноценный UI фильтра: по методу, по токену, по диапазону сумм, по дате. После применения фильтры остаются в URL-параметрах, и сложный запрос можно сохранить в закладки.

:::details{badge=Advanced title="The Etherscan family: who runs Arbiscan, Basescan, Polygonscan"} :::p{html} "Etherscan" is the brand for [[gloss:ethereum|Ethereum]] [[gloss:l1|L1]], but the company behind it (Etherscan Pte Ltd, Kuala Lumpur, founded 2015 by Matthew Tan) operates an entire constellation of chain-specific explorers under different domains. Arbiscan (Arbitrum), Basescan (Base), Optimistic Etherscan (Optimism), Polygonscan (Polygon [[gloss:proof of stake|PoS]]), BscScan (BNB Chain), FtmScan (Fantom), Snowtrace ([[gloss:avalanche|Avalanche]]) – same team, same codebase, same UI, separate per-chain databases and labels. In early 2024 the same company acquired Solscan, extending the brand to [[gloss:solana|Solana]] (a non-[[gloss:evm|EVM]] chain that needs a different data model – see §5). :::

:::p{html} The practical consequence is that learning Etherscan is genuinely a transferable skill across at least a dozen chains. The same search bar, the same tabs, the same "verified contract" tag mechanic. Where the family breaks down is in the labels – each chain's address-labeling is a separate editorial effort, and Arbiscan's coverage of, say, [[gloss:mev|MEV]] bots is typically thinner than Etherscan's. The other place it breaks down is when an [[gloss:layer 2|L2]] prefers to run its own canonical explorer instead of the Etherscan-family one: zkSync Era's explorer.zksync.io and Starknet's starkscan.co are first-party, not Etherscan-derived. Those still look broadly familiar but have their own quirks. ::: :::

:::quiz{id=q-3-4-s2 correct=2 explanation="Correct. The main [[gloss:transaction|Transactions]] tab shows [[gloss:transaction|transactions]] where this address is the outermost from or to – meaning [[gloss:ethereum|ETH]]-style transfers and direct contract calls. An ERC-20 token transfer is a call to the token's contract; the recipient address is encoded in the call's arguments, not in the [[gloss:transaction|transaction]]'s to field. To Etherscan, the "[[gloss:transaction|transaction]]" was the sender calling USDC's transfer() function – the recipient address doesn't appear in the main tab at all. It does appear on the ERC-20 Token Transfers tab, which indexes every token [[gloss:movement|movement]] involving the address regardless of who triggered it. This is the single most common confusion new users have with Etherscan, and it's not a bug – it's a literal reading of the chain."} You opened an address on Etherscan. Balance shows 0 [[gloss:ethereum|ETH]] and 0 in the [[gloss:transaction|Transactions]] tab – yet you know you sent 1,000 USDC there yesterday. What's going on?

• Etherscan's indexer is lagging – refresh the page
• The [[gloss:transaction|transaction]] reverted and was rolled back
• USDC transfers don't show in the main [[gloss:transaction|Transactions]] tab – they live on the ERC-20 Token Transfers tab
• USDC sent through a DEX doesn't show on Etherscan at all :::

:::section{mins=4} Reading a Transaction :::

:::lead A [[gloss:transaction|transaction]] page is dense – fifteen fields in the overview, an Internal [[gloss:transaction|Transactions]] tab, an ERC-20 Token Transfers tab, a State tab, and a Logs tab where most of the actual narrative lives. The fields you saw in 3.3 §1 are all here, but now you're reading them after the fact, with the answers in hand. This section is which field answers which question. :::

:::p{html} Paste a [[gloss:transaction|transaction]] [[gloss:hash|hash]] into Etherscan's search bar and you land on a page split into five tabs. The default tab is Overview, the headline view. It tells you whether the [[gloss:transaction|transaction]] succeeded, which [[gloss:block|block]] it landed in, who sent it, what they sent to, how much they paid, and what they called. That's the ten-second version. The other tabs – Internal [[gloss:transaction|Transactions]], ERC-20 Token Transfers, State, Logs, Comments – each unfold a different layer of the same [[gloss:transaction|transaction]]. Reading them in order, when you need to, is how you go from "it happened" to "here is exactly what happened, and to whom." :::

:::p{html} The Overview tab has a layout worth memorising, because every [[gloss:transaction|TX]] page looks the same: the two big readouts up top ([[gloss:transaction|Transaction]] [[gloss:hash|Hash]] and Status), an accounting middle, and Input Data at the bottom – the most important field on the page, with a button to decode it. Most readers stop at From / To / Value in the middle and never scroll down, which is exactly backwards. The table below is the field-by-field reference; the one habit to take from it is that the answer you usually want lives lower than where your eye lands. :::

:::p{html}

:::p{html} Status: Success does not mean what you wanted happened. A [[gloss:transaction|transaction]] can be Success at the outermost level while a specific step inside it silently does nothing (it runs but changes no state) or routes funds somewhere unexpected. The classic case is a multicall: one call that bundles several actions, where one sub-call can fail without reverting the whole [[gloss:transaction|transaction]] depending on the contract's error-handling. Etherscan will show "Success" because the outer call returned without reverting. To confirm "the thing I wanted happened" you have to go to the Logs tab and look for the specific event you expected – a Transfer to your address, a Swap on the right pool. The Overview tells you the call succeeded; only the logs tell you what the call did. :::

:::p{html} Input Data is the source of truth for "what was actually called". Etherscan shows it twice: as raw hex and as a decoded view if the contract has been verified and its ABI is on file. The decoded view turns 0xa9059cbb000000000000000000000000abc... into transfer(0xAbc..., 1000000) – recipient and amount, human-readable. The catch is that the decoding depends on Etherscan having the ABI. For an unverified contract you see only hex, and you can still read the first four bytes as the function selector (paste them into search – see §2). Even for verified contracts, the decoded view can hide dynamics: a multicall(bytes[]) shows you "multicall was called with these N parameters" but the parameters themselves are encoded calls that need their own decoding. The raw hex is unambiguous; the decoded view is convenient. When something looks off, go back to the hex. :::

:::p{html} The Logs tab is the most underused part of the page, yet it's the one that everything reading the chain from outside depends on. As a function runs it can leave events – short structured "this happened" records: a USDC transfer leaves a Transfer record (who, to whom, how much), a Uniswap swap leaves a Swap, an [[gloss:nft|NFT]] sale leaves OrderFulfilled. The key point is that outside services – [[gloss:wallet|wallets]], portfolio trackers, analytics dashboards, search indexes like The Graph – read these events, not the raw [[gloss:transaction|transactions]]. So in practice, to confirm a swap really executed at the price you expected, you read it in Logs; the Overview only tells you the call returned without an error. :::

:::callout{icon=💡} The itemized receipt from a long meal at a restaurant. The top line is total: $187.50. The bottom line is what your card got charged. Between them are the actual items - appetizers, mains, the bottle of wine, the side of fries someone ordered and forgot about - plus the tax line and the tip. The total is what you remember, but the items are what tell you whether the kitchen sent out the dish you asked for, the bartender poured the right vintage, the server caught the substitution. The Overview tab of a [[gloss:transaction|transaction]] is the total. The Logs tab is the itemized list. The thing you wanted to happen is on the itemized list - or it is not, and the total is right but the dinner went wrong. :::

:::keypoints{label="Key Points"}

• Before you treat a [[gloss:transaction|transaction]] as done, decide in advance which single event would prove it – the incoming Transfer you expect, or the Swap on the exact pool you chose – then open Logs and check that event is there. The green badge is the weakest evidence on the page; the event you predicted is the strongest. This habit catches the silent failures (a wrapped call that runs but changes nothing, funds routed elsewhere) that "Success" hides by design.
• A failed [[gloss:transaction|transaction]] still charges [[gloss:gas|gas]]. Etherscan shows the revert reason in the Status field when the contract emitted one – strings like "Insufficient allowance", "Slippage too high", "ERC20: transfer exceeds balance". No reason shown means either an old contract that doesn't emit revert strings or a low-level revert from out-of-[[gloss:gas|gas]]; in that case check the [[gloss:gas|gas]]-used percentage.
• When a decoded call looks wrong, don't trust the pretty view – it's only as honest as the ABI behind it. There's a check that never fails you: the first four bytes are the function selector, and pasting them into search names the function even on a contract no one verified. So a "nice" decode you can't reconcile with those four bytes is the decode to distrust, and a multicall hides its real actions one layer down where you have to decode each inner call yourself.
• If your [[gloss:wallet|wallet]], a marketplace, or a portfolio app insists something didn't happen while you're sure it did, the event log is the tiebreaker – those tools believe logs, not your memory and not the Success badge. The flip side is a quiet rule: an action that emits no log effectively didn't happen for anything downstream, no matter what the Overview tab says. When you and a dashboard disagree, open Logs and let the events settle it. :::

:::details{badge=Practice title="Reading a Uniswap V3 swap from its logs"} :::p{html} Take any swap [[gloss:transaction|transaction]] on Uniswap V3 and open the Logs tab. You see something like six to nine event entries, in execution order. The pattern repeats across DEXes, so once you can read this one, you can read most. A typical USDC→[[gloss:ethereum|ETH]] swap through the V3 router produces: :::

:::p{html}

• Transfer from your address to the Pool – the USDC moving in. Topic 0 is the keccak [[gloss:hash|hash]] of Transfer(address,address,uint256); the indexed args are from and to; the data is the amount.
• Swap emitted by the Pool – the actual exchange event with amount0, amount1, the new pool price, and the liquidity. This is the line that confirms execution at a specific price.
• Transfer from WETH to the Pool, or Pool to WETH – depending on which side is the input, this is the wrapping/unwrapping step. WETH is an ERC-20 wrapper around [[gloss:ethereum|ETH]].
• Withdrawal on WETH – when the router unwraps WETH back to [[gloss:ethereum|ETH]] at the end.
• Transfer from the router to your address – the final [[gloss:ethereum|ETH]] (or its WETH form) delivered.

:::p{html} If the swap got sandwich-attacked, you'll also see two more swaps in the same [[gloss:block|block]] (the attacker's front-run buy and back-run sell), but those are in other [[gloss:transaction|transactions]] in the same [[gloss:block|block]] – not in your [[gloss:transaction|transaction]]'s logs. Read the Pool's Swap event for the realized price; compare it to what your [[gloss:wallet|wallet]] showed at signing time; the difference is your slippage cost. :::

:::p{html}

• Transfer с вашего адреса в Pool – USDC уходит. Topic 0 это keccak-хеш Transfer(address,address,uint256); индексированные аргументы – from и to; data – сумма.
• Swap, эмитированный Pool'ом – собственно событие обмена с amount0, amount1, новой ценой пула и ликвидностью. Это строка, которая подтверждает исполнение по конкретной цене.
• Transfer с WETH в Pool или с Pool в WETH – в зависимости от того, какая сторона входная, это шаг wrap/unwrap. WETH это ERC-20 обёртка над [[gloss:ethereum|ETH]].
• Withdrawal на WETH – когда роутер в конце разворачивает WETH обратно в [[gloss:ethereum|ETH]].
• Transfer от роутера на ваш адрес – финальный [[gloss:ethereum|ETH]] (или его WETH-форма), доставленный.

:::details{badge=Advanced title="Internal Transactions vs the full CALL trace"} :::p{html} Etherscan's "Internal [[gloss:transaction|Transactions]]" tab shows only a filtered part of the contract-to-contract calls a [[gloss:transaction|transaction]] made – specifically, calls that moved [[gloss:ethereum|ETH]] or were SELFDESTRUCTs or contract creations. That covers most of what users want to see, but it is not the full call trace. A [[gloss:transaction|transaction]] can have dozens of internal CALL, DELEGATECALL, and STATICCALL operations that don't [[gloss:move|move]] [[gloss:ethereum|ETH]] and don't show up in this tab. The complete picture is the geth debug trace: every [[gloss:opcode|opcode]], every call stack frame, every read of storage and every write. Etherscan exposes a "Geth Debug Trace" view on the State tab for verified contracts, but it is dense and hard to read without tooling. :::

:::p{html} For most reverts and most "why did this fail" questions, the right answer is to take the [[gloss:transaction|transaction]] [[gloss:hash|hash]] to Tenderly (covered in §6) and let it render the full trace with state changes and [[gloss:gas|gas]] costs per step. Tenderly does the same work Etherscan does, but oriented for debugging instead of for browsing. The mental model: Etherscan Internal [[gloss:transaction|Transactions]] = "[[gloss:ethereum|ETH]] [[gloss:movement|movement]] between contracts during this call". Tenderly call trace = "every single thing the [[gloss:evm|EVM]] did during this call". The first answers most user questions. The second answers "why exactly did this revert at step 17." ::: :::

:::quiz{id=q-3-4-s3 correct=1 explanation="Correct. Status: Success only confirms that the outermost call didn't revert. In a multicall or a contract that catches sub-call failures, individual steps can silently fail without rolling back the whole [[gloss:transaction|transaction]]. The canonical way to confirm "the thing I wanted actually happened" is to look at the event logs. A USDC claim should emit a Transfer(from, your_address, 500e6) event. If that event isn't there, the claim function returned without doing the transfer – likely because of a check inside the contract (e.g. "already claimed", "vesting not yet eligible") that the contract caught and silently returned from instead of reverting. Internal [[gloss:transaction|Transactions]] tab is for [[gloss:ethereum|ETH]]-moving sub-calls, not ERC-20 transfers; those live on Token Transfers, but Logs is the authoritative place because it shows the events that off-chain systems read."} A [[gloss:transaction|transaction]] shows Status: Success on Etherscan. [[gloss:gas|Gas]] used: 75%. But your USDC balance didn't change – you expected to receive 500 USDC from a vesting claim. Where do you look first to figure out what happened?

• Refresh – the indexer is just slow
• The Logs tab – look for a Transfer event sending USDC to your address; if it's missing, the claim function ran without doing anything inside a multicall
• The Internal [[gloss:transaction|Transactions]] tab – that's where ERC-20 transfers show up
• Just trust the Status: Success – the claim happened, your [[gloss:wallet|wallet]] UI is wrong :::

:::section{mins=5} Reading an Address and Contract :::

:::lead An address page is a dossier, public by default. A contract page is a dossier plus the program's source code and a console that calls it from your browser. Reading both fluently is what separates "should I sign this?" from "I have no way to know." It's a small skill that pays off out of all proportion to its size. :::

:::p{html} Paste any address into Etherscan and the page that opens depends on whether the address is an [[gloss:eoa|EOA]] (a regular [[gloss:wallet|wallet]] – controlled by a [[gloss:private key|private key]]) or a contract (controlled by code). The split is binary at the protocol level, and Etherscan reads it from a single check: does the address have non-empty [[gloss:bytecode|bytecode]] at the latest [[gloss:block|block]]? Empty [[gloss:bytecode|bytecode]] = [[gloss:eoa|EOA]]. Non-empty [[gloss:bytecode|bytecode]] = contract. That binary, post [[gloss:eip-7702|EIP-7702]] in May 2025, has gotten interesting: a regular [[gloss:eoa|EOA]] can temporarily attach code to itself for a single [[gloss:transaction|transaction]] (see 3.3 §1). But for the purposes of the address page, you'll see "[[gloss:eoa|EOA]]" or "Contract" labeled at the top, and the rest of the page changes based on which. :::

:::p{html} For an [[gloss:eoa|EOA]] the page is mostly history. The top shows the [[gloss:ethereum|ETH]] balance and an approximate dollar value, plus a side panel listing every ERC-20 token the address holds with its dollar value (this is the "Token Holdings" widget – it queries every known token contract for the address's balance). Below that come the tabs: [[gloss:transaction|Transactions]] (already covered in §2), Internal [[gloss:transaction|Transactions]], ERC-20 Token Txns, ERC-721 ([[gloss:nft|NFTs]]), ERC-1155, and on more advanced setups a Multichain Portfolio link. Two timestamps in the header are worth noticing: First seen (when the address received its first [[gloss:transaction|transaction]]; effectively, when the [[gloss:wallet|wallet]] became active on this chain) and Last activity. A [[gloss:wallet|wallet]] first seen yesterday with no prior history that suddenly receives $500K is a different kind of address than one with five years of activity. The history is public; how you weigh it is up to you. :::

:::p{html} For a contract address, additional structure appears. The top of the page shows a "Contract" tag instead of a [[gloss:wallet|wallet]] icon. A new tab – Contract – appears next to [[gloss:transaction|Transactions]]. Inside that tab live four sub-tabs that are the heart of contract analysis: Code, Read Contract, Write Contract, and (for proxies) Read as Proxy / Write as Proxy. The Code sub-tab shows the verified source if it exists, the compiler version, optimization settings, the license declared, and the constructor arguments. If the contract is unverified, this entire sub-tab degrades to "Are you the contract creator? Verify and Publish your contract source code today!" plus a Decompile [[gloss:bytecode|Bytecode]] button. Unverified is not by itself fatal – many real contracts are unverified – but it's a strong signal to be careful before interacting. :::

:::p{html} The Read Contract sub-tab is the single most underused feature of Etherscan and one of the tools that gives the most back for the least effort. It lists every view or pure function the contract exposes – functions that read state but don't change it – and lets you call them directly from your browser, for free, no [[gloss:wallet|wallet]] connection required. You can check the owner of a contract, the current totalSupply of a token, the allowance a specific address has granted to a spender, whether a contract is paused, the address of a proxy's implementation. Before you sign a [[gloss:transaction|transaction]] that involves a contract you don't know, you can ask the contract itself a series of free questions – and the answers come straight from the chain, they're facts the contract reports about itself, not a label someone applied by hand. The Write Contract sub-tab is the same, but for state-changing functions; using it requires connecting a [[gloss:wallet|wallet]] and sending a [[gloss:transaction|transaction]]. It's essentially a fallback dApp UI built into Etherscan: if the official front-end is down or compromised, you can still call the contract by hand. :::

:::p{html} Proxy contracts deserve their own paragraph because they confuse everyone the first time. A proxy is a forwarding contract: it does almost nothing itself and passes every call to a separate contract that holds the real logic (the implementation). The proxy's address never changes while the logic behind it can be swapped – that's the point: everyone talks to one fixed address, and the team upgrades the code underneath it. Etherscan detects common proxy patterns ([[gloss:eip|EIP]]-1967, [[gloss:eip|EIP]]-1822 UUPS, Diamond/[[gloss:eip|EIP]]-2535) and shows a banner: "This contract is a proxy." When it does, open Read as Proxy – that shows the functions of the real logic in the implementation (see 3.3 §4). Plain Read Contract on a proxy is nearly useless: it shows only the wrapper's functions, with almost none to show. Two consequences. First, reviewing a proxy means checking both the proxy and the implementation. Second, verified today doesn't mean verified tomorrow: the admin can swap in an unverified implementation, and any allowance you gave the proxy now points at the new logic. Not theoretical – it's the mechanism behind the February 2025 Bybit hack: the attacker tricked Safe [[gloss:multisig|multisig]] signers into a delegatecall that rewrote the Safe's own implementation. :::

:::callout{icon=💡} An inspection report before buying a house. The structural section confirms the foundation matches the building permits filed – the house is built where the paperwork says it is built. That is verification. It tells you nothing about whether the wiring is up to code, whether the previous owner buried a tank in the yard, whether the basement floods in spring. Permits filed do not equal house good. The age of the building, the history of repairs, the number of owners and how long each stayed, the architect of record – all of that is in the file, separate from the [[gloss:permit|permit]] check. A verified contract on Etherscan is the [[gloss:permit|permit]]. The age, the holder count, the deployer's other deployments, the owner's powers – those are the rest of the file. Buying the house on the [[gloss:permit|permit]] alone is not how anyone competent does it. :::

:::keypoints{label="Key Points"}

• Verification is the first check, not the last. Before signing anything against an unfamiliar contract, look at three numbers together: deployment date (a contract created hours ago is suspicious), holder count for tokens (10 holders = almost always a scam), and [[gloss:transaction|transaction]] count (single-digit [[gloss:transaction|transactions]] = brand new, no community pressure-test). "Verified + young + tiny holder base" is the recipe for the Angel Drainer pattern from §1.
• Read Contract is your free oracle. Before granting an allowance to a spender – or even before signing the underlying approve – open that spender's contract on Etherscan and call its public read functions: who is the owner? Is the contract paused? Does it have an upgradeTo method? For ERC-20 tokens you can also query allowance(spender, your_address) to see what you previously granted. Free, immediate, no [[gloss:transaction|transaction]], no [[gloss:wallet|wallet]] connection.
• A proxy has two source codes – the proxy itself (rarely changes) and the implementation (can be swapped). The "Read as Proxy" button is what surfaces the implementation's functions; plain "Read Contract" shows only the proxy's thin shell. Both can change behavior overnight if the admin points the proxy at new logic. An allowance you granted a proxy yesterday applies to whatever logic sits behind it today, and that swap-the-logic [[gloss:move|move]] is the mechanism behind multiple high-profile contract takeovers.
• A contract's owner or admin field tells you who can upgrade it, pause it, or change its parameters. If owner is an [[gloss:eoa|EOA]], one [[gloss:private key|private key]] controls those powers. If owner is a [[gloss:multisig|multisig]] (a Safe address, for example), the threshold tells you how many of N signers must agree. If owner is 0x000…000, ownership has been renounced and no one can change anything. Read Contract → call owner() takes five seconds and is the single most informative free query you can run on a [[gloss:smart contract|smart contract]]. :::

:::details{badge=Practice title="Verifying a contract you wrote – and what verification actually checks"} :::p{html} If you deploy a contract and want users (or the tools that read from Etherscan – Rabby, Tenderly, security scanners) to be able to read its source, you submit it for verification. The page is etherscan.io/verifyContract. You provide the contract address, the [[gloss:solidity|Solidity]] compiler version (exact patch – v0.8.24+commit.e11b9ed9, not just 0.8.24), optimization settings (was the contract compiled with the optimizer? at what runs value?), and the source code itself. Etherscan compiles your source with those settings and compares the resulting [[gloss:bytecode|bytecode]] to what's deployed on-chain. If they match byte-for-byte (allowing for the metadata [[gloss:hash|hash]] difference at the end), you get the green checkmark. :::

:::p{html} What this actually proves: the deployed code is the code on the page. What it does not prove: the code does what its function names suggest. An ERC-20 named "USDC" with a verified contract can still have a transfer function that quietly skims 10% to the deployer. Names and comments are free; behavior is in the body. A reader who reaches "Verified ✓" and clicks away has confirmed exactly one technical fact and inferred a great many things they have no evidence for. The verification badge is a tool for source-code review, not a substitute for it. ::: :::

:::details{badge=Advanced title="EIP-1967 storage slots – finding the implementation by hand"} :::p{html} Etherscan auto-detects most proxies by looking up well-known storage slots. [[gloss:eip|EIP]]-1967 standardized two specific slots – derived from keccak [[gloss:hash|hashes]] of human-readable strings – at which a proxy stores its implementation address and its admin address. The implementation slot is 0x360894a13ba1a3210667c828492db98dca3e2076cc3735a920a3ca505d382bbc (keccak256("eip1967.proxy.implementation") - 1). The admin slot is 0xb53127684a568b3173ae13b9f8a6016e243e63b6e8ee1178d6a717850b5d6103. When Etherscan's auto-detection fails – happens occasionally for custom proxies – you can read these slots directly using eth_getStorageAt through any RPC, or through Etherscan's own contract Read interface if a wrapping ABI exists. :::

:::p{html} Practically: in a [[gloss:node|Node]] REPL with ethers.js, provider.getStorage('0xProxyAddress', '0x360894a13ba1a3210667c828492db98dca3e2076cc3735a920a3ca505d382bbc') returns the implementation address as the last 20 bytes of a 32-byte word. Strip the leading zeros and you have it. If you don't have a [[gloss:node|Node]] setup, the same call works as a curl to any public [[gloss:ethereum|Ethereum]] RPC with the JSON-RPC method eth_getStorageAt – the data is in the chain, the proxy is just hiding which contract is the current implementation, and the storage slot is the address of that hidden information. For most users this is overkill; for unusual proxies or for verifying Etherscan's auto-detection, it's the canonical bypass. ::: :::

:::quiz{id=q-3-4-s4 correct=3 explanation="Correct. Each red flag taken alone is manageable; together they're the signature pattern. Verified only proves source matches [[gloss:bytecode|bytecode]] – a malicious contract can be verified, and Angel Drainer in February 2024 did exactly this with a malicious Safe vault. 4 hours old means no community has had time to find anything wrong. 32 holders for a pair token is single-digit serious users plus the deployer's own [[gloss:wallet|wallets]]. Single-key owner means one [[gloss:private key|private key]] controls upgrades, parameters, and any pause/blacklist powers the contract may have. New + verified + tiny + single-key is not a DEX you discovered early; it's the staging environment of a planned drainer. The right [[gloss:move|move]] is to wait, watch the contract for a week, see what other addresses do, and re-evaluate. The opportunity is rarely real; the risk usually is."} You're about to swap on a new DEX you found through a Twitter link. Etherscan says the router contract is verified. Holders of the underlying pair token: 32. Contract deployment: 4 hours ago. Owner (read from Read Contract): a 1-of-1 "[[gloss:multisig|multisig]]" – single [[gloss:eoa|EOA]]. Proceed?

• Yes – the contract is verified, that's the main check
• Yes if you're swapping a small amount – 32 holders is enough community pressure
• Yes – Twitter links from people you follow are usually safe
• No – verified is the lowest bar; 4 hours old + 32 holders + single-key owner is the exact profile of a fresh drainer :::

:::section{mins=3} Explorers for Other Networks :::

:::lead [[gloss:evm|EVM]] [[gloss:layer 2|L2s]] reuse the Etherscan UI almost line-for-line, so the skill from §2 transfers immediately. [[gloss:bitcoin|Bitcoin]], [[gloss:solana|Solana]], [[gloss:cosmos|Cosmos]], [[gloss:ton|TON]] each have their own data model, and their explorers reflect those models. This section is the map: which tool reads which chain, and what changes between them beyond cosmetics. :::

:::p{html} Within the [[gloss:evm|EVM]] family the skill is one. Same search bar, same tabs, same "Read Contract" sub-tab, same "Token Holdings" panel, same labels infrastructure. What changes is the network being indexed, the [[gloss:gas|gas]]-price units (Gwei on [[gloss:mainnet|mainnet]], fractional Gwei on most [[gloss:layer 2|L2s]]), and the labels database (an address tagged "Binance" on Etherscan may not yet be tagged on a fresh [[gloss:layer 2|L2]]). The dominant pairs as of mid-2026 are below. :::

:::p{html}

:::p{html} [[gloss:bitcoin|Bitcoin]] reads differently because [[gloss:bitcoin|Bitcoin]] is different. An address on [[gloss:bitcoin|Bitcoin]] doesn't have a "balance" stored anywhere on chain; what it has is a set of unspent outputs (UTXOs) locked to it, and the balance is the sum of those outputs at any given moment. [[gloss:mempool|Mempool]].space surfaces this directly: an address page lists every [[gloss:utxo|UTXO]] with its [[gloss:block|block]] height and amount, and "spend" is the moment when one [[gloss:utxo|UTXO]] is consumed as input to a new [[gloss:transaction|transaction]]. The mental shift from "the account has 1.5 [[gloss:bitcoin|BTC]]" to "the account has three UTXOs worth 0.7, 0.5, 0.3" matters because every [[gloss:bitcoin|Bitcoin]] [[gloss:transaction|transaction]] selects specific UTXOs to spend and any "change" goes to a new address you control. [[gloss:mempool|Mempool]].space also has the best public [[gloss:mempool|mempool]] UI in crypto – a fee-per-vbyte heat map that visualizes which [[gloss:transaction|transactions]] are competing for the next [[gloss:block|block]]. Reading it is faster than reading any [[gloss:l1|L1]] fee oracle, and it's free. :::

:::p{html} [[gloss:solana|Solana]] reads differently again. The unit on [[gloss:solana|Solana]] is not a contract call but a program instruction; a [[gloss:transaction|transaction]] is a list of instructions, each invoking a program ([[gloss:solana|Solana]]'s word for a [[gloss:smart contract|smart contract]]) with a set of accounts it'll read or write. Solscan and the others render this as a sequence of "Inner Instructions" inside the [[gloss:transaction|transaction]] view. A Jupiter swap touches five or six programs (Jupiter aggregator → individual DEXes → token program → associated token accounts), and a generic [[gloss:evm|EVM]]-style explorer can't render that – you'd see a flat call without any structure. [[gloss:solana|Solana]]-native explorers know to expand the structure, label each program, and show which accounts each instruction touched. The cognitive load is higher because the data is richer. Solscan since 2024 has been under Etherscan ownership; SolanaFM was acquired by Jupiter in September 2024, which slowed independent development; Helius's Orb and the official [[gloss:solana|Solana]] Explorer at explorer.[[gloss:solana|solana]].com are the other serious options. :::

:::p{html} Cross-chain portfolio views are their own category. Debank aggregates [[gloss:evm|EVM]] positions – across [[gloss:ethereum|Ethereum]] [[gloss:l1|L1]], every major [[gloss:layer 2|L2]], and the major sidechains – into a single page showing your full [[gloss:defi|DeFi]] exposure: token balances, lending positions, LP positions, staked tokens, [[gloss:nft|NFT]] holdings. Zerion does similar work with a slightly different chain mix and a polished mobile app. DefiLlama goes one level up and shows [[gloss:tvl|TVL]] across chains and protocols, useful for sanity-checking "is this chain real" before bridging significant funds to it. These are not explorers in the strict sense – they're aggregators that read from explorers' indexers (and from RPC and from their own indexing). They're useful for overview, less useful for audit; when something is wrong with one of the underlying chains, the aggregator inherits that wrongness silently. For "what's my overall exposure?" they're irreplaceable. For "is this specific [[gloss:transaction|transaction]] what I think it is?" go to the chain's primary explorer. :::

:::callout{icon=💡} Public transit across different cities. Within the [[gloss:evm|EVM]] family it's the same system in different paint: New York's subway and Washington's Metro both have stations, lines, transfer points, and a swipe-in turnstile – learn one, navigate either. [[gloss:bitcoin|Bitcoin]] and [[gloss:solana|Solana]] are not subways. [[gloss:bitcoin|Bitcoin]] is a fleet of taxis: every ride is its own vehicle with a meter, and the city government doesn't keep a ledger of "who has how many taxis right now." [[gloss:solana|Solana]] is more like a high-frequency commuter rail with shared platforms: one train ([[gloss:transaction|transaction]]) carries instructions for multiple destinations, and you read the dispatch board to know which car gets off where. The map is the same idea – get from A to B – but the diagram, the legend, and the timing read completely differently. :::

:::keypoints{label="Key Points"}

• Same chain family, same explorer skill. Arbiscan, Basescan, Optimistic Etherscan, Polygonscan, BscScan, FtmScan – all the same team, same UI, same patterns. If you can read Etherscan, the only thing you have to learn on each new [[gloss:layer 2|L2]] is the chain's specific quirks: [[gloss:sequencer|sequencer]] status page, withdrawal mechanism, native bridge UI. The explorer itself transfers for free.
• [[gloss:bitcoin|Bitcoin]] explorers show a [[gloss:utxo|UTXO]] model, not a balance per address. What looks like a "balance" is really a pile of unspent outputs sitting at that address; spending picks specific ones and sends the leftover back to a fresh address of yours. [[gloss:mempool|Mempool]].space surfaces that structure directly and pairs it with the sharpest fee view in crypto – a vbyte-priced heat map that out-predicts any [[gloss:l1|L1]] fee oracle on what clears the next [[gloss:block|block]].
• On a [[gloss:solana|Solana]] explorer your Etherscan reflexes misfire: there's no single "to" address to anchor on and no Read Contract tab to interrogate. The [[gloss:move|move]] that ports over is the discipline, not the buttons – find the action by its instructions and the explicit account list each one carries, and expect one user action (a Jupiter swap) to touch five or six programs at once. If you read it expecting one call to one contract, you'll conclude the explorer is broken; it isn't, the model is.
• Cross-chain portfolio trackers (Debank, Zerion) aggregate by reading underlying explorers and RPCs. They're handy for the big picture ("what's my full [[gloss:defi|DeFi]] exposure right now?") but inherit any errors of the source. For a single specific question – "did this [[gloss:transaction|transaction]] do what I think it did?" – always go to the source chain's primary explorer. The aggregator is a dashboard, not a source of truth. :::

:::details{badge=Practice title="Mempool.space – reading the Bitcoin fee market in real time"} :::p{html} Open [[gloss:mempool|mempool]].space and the landing page shows a row of upcoming [[gloss:block|blocks]] as colored rectangles, each one a stack of [[gloss:transaction|transactions]] sized by their fee rate (satoshis per virtual byte). The leftmost [[gloss:block|block]] is "the next one" – the one a miner is about to mine. The [[gloss:block|blocks]] after it are "the queue": at current fee rates, this is the order [[gloss:transaction|transactions]] are expected to clear. Hover over a [[gloss:block|block]] and you see the fee range it contains; click and you see every [[gloss:transaction|transaction]] it would hold. This visualization is what people mean when they say "[[gloss:block|block]] space is a market." You can see the market in motion. :::

:::p{html} For estimating the right fee on a [[gloss:bitcoin|Bitcoin]] [[gloss:transaction|transaction]], the priority buttons (Low / Medium / High / No Priority) on the right give you the satoshi-per-vbyte you'd need to land in the corresponding queue depth. The "No Priority" rate is what gets you into a [[gloss:block|block]] in the next several hours – useful for non-urgent [[gloss:transaction|transactions]]. The "High Priority" rate gets you in the next [[gloss:block|block]] but you pay for it. The heat map updates in real time and is more honest than any fee oracle that returns a number, because the data feeding it is the actual [[gloss:mempool|mempool]] at this exact second, not a smoothed average. For anyone running a [[gloss:bitcoin|Bitcoin]] [[gloss:wallet|wallet]], [[gloss:mempool|mempool]].space replaces three other things. ::: :::

:::details{badge=Advanced title="Why Solana explorers don't feel like Etherscan"} :::p{html} Three things make [[gloss:solana|Solana]] explorers structurally different from Etherscan. First, there is no per-contract storage in the [[gloss:evm|EVM]] sense. A [[gloss:solana|Solana]] program is stateless code; the data it operates on lives in separate accounts that the caller specifies in the instruction. To "read a contract's storage" you have to know which account holds the data and what the layout is – an Anchor IDL or a documented schema. Without the IDL, Solscan shows you the account's raw bytes. With it, the structure is decoded. Second, [[gloss:transaction|transactions]] are not single calls – they're lists of instructions, and each instruction has its own program, its own accounts, and its own compute-unit budget. A "swap" is rendered as a sequence of nested inner instructions, not as one decoded function call. Third, there are no event logs in the [[gloss:ethereum|Ethereum]] sense. [[gloss:solana|Solana]] programs emit "program logs" – printf-style strings written to a side channel of the [[gloss:transaction|transaction]] – that are best-effort, not load-bearing infrastructure. To track activity on [[gloss:solana|Solana]], indexers parse logs and inner instructions; on [[gloss:ethereum|Ethereum]], they parse Transfer and Swap events from receipts. :::

:::p{html} The practical consequence: a Solscan [[gloss:transaction|transaction]] view is more verbose than its Etherscan equivalent and demands more interpretation. Jupiter swaps, in particular, can span ten or more inner instructions across multiple programs (Jupiter v6 → Whirlpool → Token program → ATA program → [[gloss:solana|SOL]] wrapping/unwrapping). The fluency is real but takes longer to build, and the patterns are [[gloss:solana|Solana]]-specific – there's no "read it like Etherscan and you're fine" shortcut. Helius's Orb attempts to bridge this with AI-generated summaries ("Swapped 10 [[gloss:solana|SOL]] for 1,500 BONK via Jupiter"), which is helpful for the casual case but should not replace reading the actual instructions when stakes are real. ::: :::

:::quiz{id=q-3-4-s5 correct=2 explanation="Correct. [[gloss:solana|Solana]] addresses are 32-byte [[gloss:ed25519|ed25519]] public keys encoded as base58 – they look nothing like [[gloss:ethereum|Ethereum]]'s 20-byte hex addresses, and Etherscan can't even parse them. The chain has its own explorer family: Solscan (now under Etherscan ownership, the most polished general explorer), the official [[gloss:solana|Solana]] Explorer at explorer.[[gloss:solana|solana]].com (sparse but canonical), SolanaFM (since Jupiter acquired it in 2024, slower-moving), and Orb by Helius (newer, with AI-generated [[gloss:transaction|transaction]] summaries). On any of them, the address page shows [[gloss:spl|SPL]] token holdings per token account – USDC on [[gloss:solana|Solana]] is an [[gloss:spl|SPL]] token at mint EPjFWdd5AufqSSqeM2qN1xzybapC8G4wEGGkZwyTDt1v, and your friend's holdings of it live in an associated token account, not directly on the [[gloss:wallet|wallet]] address. Etherscan's tools fail at every layer here; you need [[gloss:solana|Solana]]-native infrastructure."} You want to track a friend's USDC activity on [[gloss:solana|Solana]]. They sent you their address. Where do you go?

• Etherscan – paste the address into search and see the USDC activity
• [[gloss:mempool|Mempool]].space – that has the best UI for token tracking
• Solscan or the official [[gloss:solana|Solana]] Explorer – [[gloss:solana|Solana]] addresses don't work on [[gloss:ethereum|Ethereum]] tools, and Solscan shows [[gloss:spl|SPL]] token activity per account
• DeBank – it aggregates portfolios across all chains, including [[gloss:solana|Solana]], and will show the full picture of token activity :::

:::section{mins=4} Advanced Tools :::

:::lead Etherscan shows you what happened. Tenderly shows you what would happen if you sent a specific [[gloss:transaction|transaction]]. Arkham shows you who owns the address. Nansen shows you whose [[gloss:wallet|wallets]] to watch. Dune lets you write SQL when none of the dashboards already exist. None of these replaces Etherscan; each answers a question Etherscan answers badly or not at all. :::

:::p{html} Once Etherscan stops being the limiting factor – when you can read the tabs fluently, find verified contracts, decode logs – a second tier of tools starts paying off. Each of them is specialised: they don't try to be a generic explorer, they try to be the best answer to one specific question. The four worth knowing are Tenderly (simulation), Arkham (entity labels and intelligence), Nansen (Smart Money flow), and Dune (custom SQL on indexed chain data). DeBank and Zerion belong in this tier too for portfolio aggregation, already covered in §5. :::

:::p{html} Tenderly is the simulator. Paste a [[gloss:transaction|transaction]] [[gloss:hash|hash]] and it re-executes the [[gloss:transaction|transaction]] against a forked copy of the chain at the original [[gloss:block|block]], showing every internal call, every state change, every [[gloss:gas|gas]] cost step by step. That alone replaces a lot of debugging. The more useful mode is the other direction: paste a pending [[gloss:transaction|transaction]] (or construct one by hand – from, to, value, calldata) and Tenderly tells you what would happen if you sent it. The answer comes with the full call trace and the post-execution state diff, before you commit a single Gwei of [[gloss:gas|gas]]. For a suspicious [[gloss:transaction|transaction]] the [[gloss:wallet|wallet]] wants you to sign – a [[gloss:permit|permit]] you didn't expect, an approve to a contract you don't recognize – running it through Tenderly first is the closest thing the [[gloss:evm|EVM]] has to a try-before-you-buy. As of 2026, Tenderly's free tier allows roughly 50 simulations per month and 109 supported networks, which covers any individual user's reasonable use; the paid tiers are aimed at protocols and infrastructure teams. :::

:::p{html} Arkham is the entity-labeling layer. Etherscan tags a handful of well-known addresses; Arkham tags hundreds of millions. The product is built around the claim that "this address belongs to Justin Sun" or "these 47 addresses are all controlled by Wintermute" – labels derived from on-chain clustering, public filings, exchange leaks, and human research. The free tier as of 2026 shows entity tags directly on address pages and supports basic filtering; the platform crossed 3 million users by February 2026. The catch is that labels are inferences, not proofs. Arkham's confidence in an attribution is not displayed as a probability; an address tagged "Alameda Research" is Arkham's analyst's best guess based on the available evidence, which is sometimes very strong and sometimes circumstantial. For investigations, Arkham is the fastest way to go from "unknown address" to "candidate entity"; the verification step still belongs to you. The platform also runs a token (ARKM) and a bounty market where users can propose attributions for rewards – useful context for understanding what kind of evidence the platform values. :::

:::p{html} Nansen sells a different commodity: which [[gloss:wallet|wallets]] are worth watching. Their flagship label is Smart Money – a curated set of addresses (institutional desks, profitable [[gloss:defi|DeFi]] users, [[gloss:nft|NFT]] whales) that have demonstrated good outcomes over time. The pitch is that you can see in real-time when Smart Money addresses start buying or selling a token, often before the wider market notices. The reality is that "Smart Money" is a leading indicator only sometimes – these [[gloss:wallet|wallets]] are also wrong, also exit-liquidity, also subject to herding. As a signal it's one input among many; as a substitute for thinking it's worse than nothing. Nansen has a free tier introduced in late 2024 with limited features; the paid tier is $49 per month annual or $69 per month monthly as of 2026, which puts it in the discretionary-tool category for individuals. :::

:::p{html} Dune Analytics is the SQL layer over the indexed chain. Where Etherscan has hand-built dashboards for predetermined views, Dune lets you write a query against decoded tables ([[gloss:ethereum|Ethereum]] [[gloss:transaction|transactions]], ERC-20 transfers, every Uniswap V3 swap as structured rows) and produce your own dashboard. The query language is standard PostgreSQL with a few extensions. The data is pre-decoded by Dune's team for major protocols, which means a query like "every Uniswap V4 swap in the last 30 days with output greater than $100K" is one SQL statement, not a scraping pipeline. The community publishes thousands of dashboards – most are public, forkable, and editable. For one-off questions ("how much volume did this pool see in the hour around this hack?") Dune is faster than any UI. For an active workflow it pays for itself in a week. The free tier is generous; paid tiers exist for higher query frequency. :::

:::p{html} The order in which you reach for these tools is roughly cost-shaped. Etherscan and Read Contract first – free, fast, sufficient for most questions. Tenderly when "what would happen" matters more than "what did happen" – still free for the volumes any individual needs. Arkham and Nansen when "who is this" or "who else is moving" becomes the question – free tiers helpful, paid tiers a serious tool if your workflow is professional. Dune when the question is novel enough that no dashboard answers it and you need to compose your own – free tier sufficient, paid tier for sustained work. Each is a specific blade, sharper than any generalist tool for its one job. :::

:::callout{icon=💡} A homicide unit pulling into a major investigation. The patrol officer has the radio and the report book – Etherscan, basic and present at every scene. Then specialists arrive: a ballistics tech with a comparison microscope (Tenderly, simulating what specific evidence implies), a records analyst with access to the entity database (Arkham, putting names to faces), an intel detective who knows which criminal networks tend to [[gloss:move|move]] money where (Nansen, watching the patterns of known actors), a data analyst pulling SQL queries against years of case archives (Dune, asking "have we seen this signature before?"). Each tool was built for a specific question. The patrol officer can handle the routine call alone. The murder case needs the full toolkit, used in the right order. :::

:::keypoints{label="Key Points"}

• Simulation answers one question precisely – "what does this [[gloss:transaction|transaction]] do right now" – and it's easy to over-trust it for a different one. A clean simulation proves this call won't drain you on execution; it does not prove the contract is safe to hold an allowance in tomorrow, because an upgradeable contract can change behavior after you've signed. So a green simulation lowers the risk of this click, not the risk of the relationship. Read it as "safe to send," never as "safe to trust."
• Not all Arkham labels carry the same weight, and the platform doesn't show you which is which. A label like "Binance 14" rests on years of confirmed deposit patterns; a label naming an individual behind a fresh [[gloss:wallet|wallet]] may rest on a single bounty submission. Since the confidence isn't displayed, calibrate it yourself from the kind of claim: an exchange hot [[gloss:wallet|wallet]] is near-certain, a named person tied to recent activity is a lead to check. The error to avoid is treating a famous name on a label as if the platform had proven it.
• There's a structural reason a "Smart Money is buying" signal disappoints, beyond those [[gloss:wallet|wallets]] being fallible. By the time the label resolves and the dashboard shows it, the entry price is already gone – and the signal is reflexive: enough people watching the same feed and copying it [[gloss:move|move]] the price themselves, so the edge erodes precisely because it's visible. The useful way to read Smart Money is backwards – as a map of who to study and why a [[gloss:move|move]] happened – not forwards as a buy trigger.
• You almost never start from a blank query. The realistic entry path is to find a public dashboard close to your question, [[gloss:fork|fork]] it, and change one line – a contract address, a date range – which means basic SQL reading beats SQL writing as the skill that matters. The deeper unlock is just knowing the decoded tables exist: once you know "every Uniswap swap is already a queryable row," a class of questions you'd have given up on becomes a five-minute edit instead of a scraping project. :::

:::details{badge=Practice title="Pre-signing simulation: the 30-second workflow with Tenderly"} :::p{html} The [[gloss:wallet|wallet]] is showing you a [[gloss:transaction|transaction]] to sign. The summary panel says "Approve to 0xAbc…123" or "[[gloss:permit|Permit]] on USDC to 0xDef…456" and you don't recognise the recipient. The simulator-features built into Rabby and the latest MetaMask catch most cases (see 3.3 §8), but their depth is shallow – they show direct state changes, not the consequences of the contract's logic. Tenderly's "[[gloss:transaction|Tx]] Builder" gives you the full version of the same check. :::

:::p{html} If the simulation shows your address sending out tokens you didn't expect – to an address that isn't the contract you thought you were interacting with – that's the answer. The [[gloss:wallet|wallet]] was about to sign a drainer; close the [[gloss:wallet|wallet]] prompt without confirming. Cost of the simulation: zero [[gloss:gas|gas]], ~10 seconds. Cost of skipping the simulation when it would have caught a drainer: everything in the [[gloss:wallet|wallet]]. ::: :::

:::details{badge=Advanced title="Why no single tool covers everything"} :::p{html} It's tempting to ask why we don't just have one explorer that does all of this – labels and simulation and SQL and portfolio aggregation, all in one polished UI. The answer is that the underlying engineering problems are different shapes and trade off against each other. Etherscan optimises for fast lookups on canonical chain data; adding deep entity research would slow the index and dilute the team's focus. Tenderly optimises for accurate simulation; that requires running a forked [[gloss:evm|EVM]] per request, which costs orders of magnitude more compute than reading an index. Arkham optimises for attribution research; that means a team of analysts and a different data ingestion pipeline, not just [[gloss:node|nodes]]. Nansen optimises for behavioural labels and curated lists; that's a research operation, not a database. Dune optimises for flexible SQL; the trade-off is that the data is up to 30 minutes behind real-time during peak load. :::

:::p{html} The market has settled on specialists for a reason. Each tool has a different cost structure, a different team specialisation, and a different definition of "good." A combined product would be slower at everything and would inherit the worst constraints of each component. The cost of using four tools instead of one is learning four UIs – which is real, but bounded. The cost of one tool trying to do four jobs is mediocrity across all four. For the user, the practical [[gloss:move|move]] is to know which question goes to which tool, and to internalise that as part of the skill rather than wishing the unification existed. It probably never will, and that's fine. ::: :::

:::quiz{id=q-3-4-s6 correct=1 explanation="Correct. Tenderly is the right tool because the question is "what will happen if I sign this", and that's exactly what Tenderly simulates. Pasting the [[gloss:transaction|transaction]] data into its [[gloss:transaction|Tx]] Builder runs the call against a [[gloss:fork|fork]] of the current chain state and shows the asset-change diff for your address – if signing would let the recipient pull your USDC, the diff will show it as a future outflow when the spender exercises the [[gloss:permit|permit]]. Etherscan (option A) is useful for context but only tells you about the contract's metadata, not what your specific signature would enable. Arkham (C) – the absence of a label is meaningless; drainers start unlabeled because they're new. Nansen (D) – Smart Money flags [[gloss:wallet|wallets]], not drainer contracts, and "no Smart Money outflow yet" is consistent with both safe and unsafe scenarios. Simulation is the only one of these four that answers the specific question being asked."} A [[gloss:wallet|wallet]] you're about to sign with shows: "[[gloss:permit|Permit]] on USDC to 0x9F7B…1234, amount: unlimited." The contract is unfamiliar. What's the most efficient way to find out what would actually happen if you signed?

• Open Etherscan on the contract address and check verification + holders
• Paste the unsigned [[gloss:transaction|transaction]] into Tenderly's [[gloss:transaction|Tx]] Builder and simulate – the asset-changes panel will show whether USDC is about to leave your [[gloss:wallet|wallet]]
• Look up the recipient address on Arkham – if there's no entity label, it's safe
• Check Nansen – Smart Money would have flagged a drainer already :::

:::section{mins=5} Investigating a Suspicious TX :::

:::lead Sections 1 through 6 covered the tools one at a time; this section puts them together. We walk through a real 2024 case – the Angel Drainer Safe-vault attack, $403K drained from 128 [[gloss:wallet|wallets]] – using only the tools introduced earlier, in the order a careful investigator would actually use them. The point is not the specific case. The point is the shape of the work. :::

:::p{html} The investigation usually starts with a symptom, not a cause. Someone wakes up and their MetaMask shows zero. Or a Telegram message arrives: "I think I just got drained." Or a Discord channel lights up about a project whose treasury is moving. The [[gloss:hash|hash]] of the bad [[gloss:transaction|transaction]] is the thread. Pull it gently, and the whole carpet unravels – but only if you pull it in the right direction. The wrong direction is to start chasing the attacker. The right direction is to start at the victim, document everything that's already happened, and only then trace outward. The case below – Angel Drainer's February 12, 2024 operation – followed exactly this structure when the security teams at MetaSleuth, Scam Sniffer, and Blockfence put it together over the following 48 hours. :::

:::p{html} Stage one: confirm the loss is real and document the canonical facts. The victim says "all my USDC is gone." Step one is to verify on chain, not in their [[gloss:wallet|wallet]] UI. Take the address, open Etherscan, go to the ERC-20 Token Transfers tab (§2 covered why this tab and not the main [[gloss:transaction|Transactions]] tab). The outflows show up as Transfer events from the victim's address to a recipient address, with timestamps. In Angel Drainer's case the pattern was distinctive: a single outbound Transfer of the entire USDC balance, in one [[gloss:block|block]], to an address with two hours of history and a contract code suggesting Permit2-style approvals. The victim's panic version of events ("everything is gone") is now a concrete chain of three facts: which token, what amount, who received it, in which [[gloss:block|block]]. Save the [[gloss:hash|hash]]. Everything downstream chains off it. :::

:::p{html} Stage two: read the malicious [[gloss:transaction|transaction]] itself. Open the [[gloss:transaction|transaction]] [[gloss:hash|hash]] in Etherscan (§3). The Overview shows Status: Success – the attack worked. The From is the victim. The To is Permit2's known canonical address (0x000000000022D473030F116dDEE9F6B43aC78BA3) – Permit2 is Uniswap's [[gloss:permit|permit]] aggregator, used by many dApps and known to be safe in itself; the abuse is in how Angel Drainer convinced the victim to sign. Input Data, decoded, shows a call to permitTransferFrom with the victim's signature, naming a "spender" address that turns out to be the drainer's contract. The Logs tab shows the actual USDC transfer event, sourced from the USDC contract, recipient = drainer address. The trace is now complete on the technical level – we know what was signed, who executed it, where it went. We do not yet know why the victim signed. :::

:::p{html} Stage three: investigate the drainer's contract. Take the drainer's address, paste it into Etherscan. The first thing the page shows is the green checkmark – verified. This is the trap the entire attack hinged on. Etherscan's auto-verification policy for Safe (Gnosis Safe) vault contracts treated the drainer's deployment as a vanilla Safe and stamped it verified within seconds of deployment. Read Contract (§4) shows it had been deployed two hours before the first victim signed, with one owner, no public activity, and no holders. Three signals in one page: verified-but-young + zero history + the source code that the auto-verifier accepted matches the standard Safe interface, but the deployment salt and the proxy initialization data point at a malicious implementation. None of this is hidden – it's all on the page – but reading "verified" and stopping there is how 128 [[gloss:wallet|wallets]] reached signing day. :::

:::p{html} Stage four: trace outward, both directions in time. Backward: where did the victim's funds come from in the hours and days before the drain? On Etherscan this is the upper half of the Token Transfers tab. In the Angel Drainer case, victims came from many sources – exchanges, other [[gloss:wallet|wallets]], [[gloss:defi|DeFi]] positions – but they shared a behaviour: they had recently visited a fraudulent dApp pretending to be a token-claim site for various airdrop campaigns. That's not visible on-chain; it's reconstructed from the victims comparing notes off-chain. But on-chain the pattern that is visible is that all victim addresses signed Permit2 messages targeting the same drainer address within a 36-hour window. Forward: where did the funds go from the drainer? Each victim's USDC moved to the drainer's collection address, which then routed everything through Tornado Cash and a series of bridges to obfuscate. Arkham (§6) eventually labeled the collection address as belonging to the Angel Drainer cluster, having seen the same address pattern across roughly $25 million in losses from ~35,000 [[gloss:wallet|wallets]] over the preceding twelve months. :::

:::p{html} Stage five: confirm the vector and write it down. The signed message in the Logs tab decodes to a Permit2 SignatureTransfer structure: the victim authorized the drainer to pull a specific amount of USDC, signed off-chain, executed on-chain by the drainer when the signature reached them. Permit2 is well-designed; the cryptographic primitive is sound; what failed was the victim reading "Sign to claim your airdrop" in a [[gloss:wallet|wallet]] popup and not parsing what the signed structure authorized. The fraudulent site looked like a legitimate claim page; the [[gloss:wallet|wallet]] showed "[[gloss:eip-712|EIP-712]] signature request" with a vague title; the victim approved. The vector was social, the execution was technical, and the trap was Etherscan's auto-verification policy. Writing this up – vector, execution, trap, blast radius (128 [[gloss:wallet|wallets]], $403,000) – is the deliverable. The point of the investigation is not catching the attacker; the point is making sure the same trap doesn't catch someone else who reads the writeup. The writeup is the only durable defence. :::

:::callout{icon=💡} Forensic accounting after a fraud at a small firm. The bookkeeper notices a number that's wrong; that's the symptom. A forensic accountant doesn't start by asking "who did this" – that's police work, and it comes later. They start by reconstructing the books: every [[gloss:transaction|transaction]] that touched the suspect account, in order, with corresponding paperwork. They establish the canonical timeline. They identify the specific entries that fail the audit – the wires to an unfamiliar vendor, the invoices that don't match deliveries. They trace outward in time: how did the firm end up in a relationship with this vendor in the first place, and where did the money go after the vendor received it. Only at the end, with the timeline and the entries and the trace assembled, do they hand the file to investigators. The file is the deliverable, not the arrest. On-chain investigation has the same shape: tools, sequence, deliverable. Catching the attacker is rare and downstream. Documenting the trap is the work, and it's what protects everyone else. :::

:::keypoints{label="Key Points"}

• The instinct to chase the attacker first is the expensive mistake. While you're hunting an identity, the clock that actually matters is running: stolen funds are often still moving, and the only window to flag them with an exchange or get ahead of a bridge closes fast. Worse, starting from the victim's panicked story bakes their guesses into your facts. Spend the first minutes establishing what the chain shows – token, amount, destination, [[gloss:block|block]], [[gloss:hash|hashes]] – and you keep both your timeline and your facts clean.
• Tracing backward and forward answer two different goals – know which you're after. Backward – reconstructing where the victim's funds and approvals originated – reconstructs how they got in, which is what prevents the next victim. Forward (where did the loot go?) is about recovery – it's the only path to a centralized exchange or bridge that might still freeze the funds, and it's time-critical. If money might still be saved, go forward first; if it's already laundered, backward is where the lasting value is.
• Most investigations are finished on Etherscan alone, and knowing when you're done is its own skill. Once you can state the token, the amount, the destination, and what the victim signed, you have the answer for almost every drained-[[gloss:wallet|wallet]] case – the fancier tools are for the rare question that remains. Reaching for Tenderly or Arkham before you've exhausted the free, fast view usually means you're adding depth you don't need instead of closing the case you already cracked.
• A writeup only protects the next person if it captures the moment of deception, not just the damage. Hashes, amounts, and the attacker's address are easy to record and useless for prevention – stale the moment the attacker rotates [[gloss:wallet|wallets]]. The reusable part is the gap: what the [[gloss:wallet|wallet]] popup said ("Sign to claim"), versus what the signature actually authorized (drain this token). Write that gap down precisely and the next reader recognizes the trap; list only the forensic facts and you've documented a theft no one can learn from. :::

:::details{badge=Practice title="Templates for the four most common investigations"} :::p{html} Most investigations fall into one of four shapes. Knowing the shape upfront saves time and prevents you from wandering. :::

:::p{html}

• "My [[gloss:wallet|wallet]] got drained." Etherscan → victim address → Token Transfers tab → find the outflow → open the [[gloss:transaction|transaction]] → read From/To/Logs → identify which approve or [[gloss:permit|permit]] was the entry point → trace allowance history backward to find the malicious approval [[gloss:transaction|transaction]]. The malicious signature is usually 1–48 hours before the drain; the social-engineering happened before that. Revoke remaining allowances via revoke.cash (covered in 3.3 §7) before anything else.
• "This contract feels off." Etherscan → contract address → Code tab (verified? when deployed?) → Read Contract (who is owner? is it paused? is it a proxy?) → if proxy, Read as Proxy → Read the deployer's other deployments (link in the "Contract Creator" field on the overview). A deployer with five contracts deployed in the last week, all small, none with significant usage, is a different signal than a deployer with two years of legitimate history.
• "This [[gloss:transaction|transaction]] didn't do what I expected." Etherscan → [[gloss:transaction|transaction]] [[gloss:hash|hash]] → Logs tab (the event you expected – is it there? is the amount what you expected?) → if not, check Internal [[gloss:transaction|Transactions]] for [[gloss:ethereum|ETH]] [[gloss:movement|movement]] → if still unclear, paste the [[gloss:hash|hash]] into Tenderly and read the full call trace to see exactly which sub-call failed silently or returned without effect.
• "Did this project just rug?" Etherscan on the token contract → Holders tab (did the top holders all dump at once?) → Token Tracker → trace where the LP tokens went. DefiLlama → search for the project → check if [[gloss:tvl|TVL]] collapsed. Twitter is downstream; on-chain shows it first.

:::p{html}

• «У меня дрейнули кошелёк». Etherscan → адрес жертвы → вкладка Token Transfers → найти отток → открыть транзакцию → прочитать From/To/Logs → понять, какой approve или [[gloss:permit|permit]] стал точкой входа → проследить историю allowance назад, чтобы найти вредоносный approval. Вредоносная подпись обычно за 1–48 часов до drain'а; социальная инженерия – раньше. Отозвать оставшиеся allowance через revoke.cash (разобрано в 3.3 §7) прежде всего остального.
• «Этот контракт выглядит подозрительно». Etherscan → адрес контракта → вкладка Code (verified? когда задеплоен?) → Read Contract (кто owner? на паузе? proxy?) → если proxy, Read as Proxy → посмотреть другие деплои создателя (ссылка в поле «Contract Creator» в overview). Создатель с пятью контрактами за последнюю неделю, все маленькие, без значимой активности – это другой сигнал, чем создатель с двухлетней легитимной историей.
• «Транзакция сделала не то, что я ждал». Etherscan → хеш → вкладка Logs (то событие, которого вы ждали – оно там? сумма та?) → если нет, проверить Internal [[gloss:transaction|Transactions]] на движение [[gloss:ethereum|ETH]] → если всё ещё непонятно, вставить хеш в Tenderly и прочитать полный call trace, чтобы увидеть, какой именно подвызов тихо упал или вернулся без эффекта.
• «Этот проект только что сделал rug?» Etherscan на контракте токена → вкладка Holders (топ-холдеры все одновременно вышли?) → Token Tracker → проследить, куда ушли LP-токены. DefiLlama → найти проект → проверить, не схлопнулся ли [[gloss:tvl|TVL]]. Twitter – вниз по течению; на цепи это видно первым.