The On-Chain
Analyst's Path

A language model has never seen the blockchain. It was trained on text — millions of explorer pages, GitHub repos, forum posts, docs. When you ask Claude “how much pDAI does this wallet hold?”, a base model on its own does not query PulseChain. It cannot: it has no RPC connection, no node, no mempool of its own. (Even wired to tools, it never knows chain state from training — it must fetch it, and you must verify what it fetched.) It produces the most statistically plausible continuation of your question — a string of digits that looks like a balance, formatted like a balance, confident like a balance. The number is generated, not read. This is the single fact that everything else in this guide hangs on: the model pattern-matches; it does not observe. Treat it as a brilliant analyst intern who has read every finance textbook ever written and will never, ever say “I don't know” — it will invent a precise-looking answer and deliver it with a straight face.

The failure modes are specific and they rhyme every time. Hallucinated balances: asked for a holding it cannot see, the model emits a number anchored on nothing. Wrong decimals: raw on-chain integers carry no decimal point. A token balance comes back as 25612906953169653772259. Is that 25,612 tokens (18 decimals)? 25.6 quadrillion (6 decimals)? 25 sextillion (0 decimals)? The model guesses the decimal count from the token's name or vibe, and a wrong guess is off by a factor of a trillion or more. Wei vs. ether confusion: the same integer-with-no-point problem, one layer down — the model slides a decimal point to wherever looks reasonable. Invented addresses: ask for “the WPLS contract” or “the router” and it may produce a checksummed 42-character address (the 0x prefix plus 40 hex characters) that is structurally perfect and completely fake. EIP-55 checksumming is just mixed-case applied to those 40 hex characters — it makes a string look validated without proving it points at anything real. It looks exactly like a real address because looking like a real address is precisely what it was trained to do. None of these are bugs you can prompt away. They are what next-token prediction is when pointed at data it was never given.

There is a second, sharper edge on PulseChain specifically. PulseChain launched in May 2023 as a full fork of Ethereum — the entire account state (balances, contract code, storage) at the fork block was copied onto a new chain with its own genesis and config, including chain ID 369 and its own fee parameters and PLS distribution. That copy is a one-time snapshot. For any address or contract that has seen no post-fork PulseChain activity, its on-chain values still reflect that fork-time snapshot; anything touched by a native PulseChain transaction since — a transfer, a swap, a mint — has diverged from Ethereum and moved on its own. An AI trained on Ethereum data will happily report a wallet's “holdings” while silently conflating three different things: the Ethereum mainnet value, the untouched fork-mirror value, and the live PulseChain value. These can be wildly different numbers for the same address and the same token. The model has no concept of which chain's current state you mean, because it is reading none of them. This is exactly where confident-but-wrong does the most damage — the answer is plausible, internally consistent, and attached to the wrong reality.

So here is the contract you sign with yourself before you write a single command. Nothing the AI tells you about the chain is true until the chain says it is true. The AI's job is to be a force multiplier on your judgment: it writes the query, it explains the contract, it interprets the decoded output, it spots the pattern across twenty transactions faster than you could. What it does not get to do is be the source of a number. The number comes from an RPC call you ran, against an endpoint you chose, decoded by a tool that does the arithmetic. The discipline is not “distrust AI.” The discipline is separation of duties: the model reasons, the chain attests, and a tool — never your head, never the model's head — does the hex-to-decimal and wei-to-token math. Adopt this now and the rest of the path is mechanical. Skip it and you will post a number that a hostile expert disassembles in one reply. Every later stage is just tooling on top of this one rule.

The chain does not speak English. It speaks in 4-byte function selectors like 0xa9059cbb, 32-byte event topics like 0xddf252ad..., hex-encoded calldata, and integer amounts with implied decimals (18 for most ERC-20s, but ALWAYS read decimals() — never assume). Every wallet UI and explorer you've ever used is just a translation layer painted on top of this. The first job of an on-chain analyst is to read the raw layer directly — and this is exactly where an AI explainer earns its keep. Paste it a function signature, an event topic, a chunk of calldata, or a decompiled snippet and ask: what does this do, what is the risk, what would an attacker do with this? Claude is genuinely excellent at this because it's a concept and pattern question, not a state question. approve(address,uint256) means the same thing on every EVM chain in existence; explaining it requires zero live data.

Here is the discipline that separates an analyst from a mark. There are two completely different kinds of questions you can ask an AI, and they have opposite reliability profiles. Type A — 'what does this code/signature/pattern mean?' — is timeless knowledge baked into the model. Type B — 'what happened in transaction 0xabc...?' or 'how much of this token does this wallet hold?' — is live on-chain state the model has never seen. Ask Type B without attaching real fetched data and the model will fluently invent an answer: a plausible counterparty, a round-number amount, a confident story. It is not lying on purpose; it is pattern-completing in the absence of data, and the output is indistinguishable from a real finding until you check it against the chain. This is the single most dangerous failure mode in AI-assisted analysis. The rule is mechanical: concepts can be explained from knowledge; specific on-chain claims require data in the prompt or they are a guess.

So the workflow is never 'ask the AI what the transaction did.' It is: you fetch the raw bytes (raw curl + JSON-RPC to demystify what's really on the wire, then cast as the daily driver), you paste those bytes into the prompt, and the AI decodes and interprets what you gave it. The AI writes the command, you run it, the AI interprets the output — and you can always re-run the command yourself to confirm. Crucially, the AI never does the hex-to-decimal or wei-to-token arithmetic in its head; a tool computes (cast to-dec, cast from-wei, cast to-unit) and the AI explains the result. Models are unreliable at long-integer math, and there is no reason to trust a hallucinated number when a deterministic tool sits one command away. The head reasons; the tool calculates.

Good prompting for crypto is mostly about feeding context and forcing honesty. Don't ask 'is this token a scam?' — give the AI the contract's verified source or ABI, the relevant function bodies, the owner/admin addresses you pulled, and ask it to walk the privileged functions and flag what a malicious owner could do. Always add an explicit instruction: 'state your assumptions, flag anything you're inferring vs. reading, and say I-don't-know rather than guessing.' That single sentence converts the model from a confident bullshitter into a useful junior analyst. On PulseChain specifically, give it one extra piece of context it cannot know from training: the chain launched in May 2023 as a full fork-copy of Ethereum's entire state, so any token forked at launch STARTED as a mirror of Ethereum's May-2023 state — not live mainnet value. A balance is only still frozen if nothing on PulseChain has touched it since; supply or balances minted or moved here have diverged, and a diverged number can be inflated far past anything real. A well-prompted model usually reasons correctly about the mechanics, but will still tend to imply mainnet-scale dollar value unless you remind it the mirror is economically dead.

The chain is a public API, and eth_call is how you query state. PulseChain mainnet (chain id 369) runs a standard Ethereum JSON-RPC interface at https://rpc.pulsechain.com. You don't need a library, an SDK, an explorer, or an API key to read it — you POST a tiny JSON envelope and get a hex answer. Every read method shares one shape: {"jsonrpc":"2.0","method":"<method>","params":[...],"id":1}. The methods in the command list below are the entire vocabulary you need to see any wallet, token, contract, or transaction on the chain. eth_blockNumber tells you where the chain is. eth_chainId proves which network you're actually talking to. eth_getBalance reads native PLS. eth_call executes a read-only function (like balanceOf) against a contract without spending gas or sending a transaction. eth_getTransactionByHash and eth_getTransactionReceipt show you what a transaction requested versus what it did (the receipt carries status and the event logs). eth_getLogs is the firehose — every event the chain ever emitted, filterable by contract and topic. eth_getCode tells you if an address is a contract or an EOA. eth_getStorageAt reads raw contract storage slots — the getter-independent ground truth for the specific case where a contract lies through its public functions.

Why raw curl first, before any tool: it demystifies the machine. Every higher-level tool — cast, ethers.js, web3.py, the BlockScout UI — is ultimately wrapping these exact RPC calls. If you only ever use the wrapper, the chain stays a black box and you can't tell when the wrapper is wrong. Doing it once by hand, including building the balanceOf calldata yourself, removes the magic: you see that a contract call is nothing more than a 4-byte function selector followed by 32-byte-padded arguments, and that the answer is just a hex string you decode. That understanding is what lets you catch a tool — or an AI — when it hallucinates. Note one platform gotcha that bites PulseChain analysts specifically: Python's urllib/requests frequently chokes on TLS certificate verification in minimal environments, silently failing or erroring on the HTTPS handshake. curl is the reliable transport. Tell the AI to route RPC calls through curl, not hand-rolled Python HTTP.

The AI flow: AI writes the curl, you run it, AI interprets the hex — and you never trust a single uncorroborated read. This is the working loop for the whole bible. You describe what you want to know ('what's this wallet's WPLS balance at the latest block'); the AI produces an exact, copy-pasteable curl command; you run it in your own shell; you paste the raw hex result back; the AI decodes it. The discipline that makes this un-dunkable rather than just convenient: the AI never does the hex-to-decimal or wei-to-token arithmetic in its head, and you never present a number that came from one source. Decoding is a tool's job (Stage 3's cast to-dec / cast from-wei), and a finding worth stating out loud should be confirmed against more than one independent RPC endpoint. A single curl answer is a lead, not a fact. The chain doesn't lie, but a misread hex string, a stale block, or a flaky endpoint absolutely will.

Public RPC vs your own node — and why the explorer is a convenience, not an oracle. The public https://rpc.pulsechain.com is free and perfect for learning and light forensic work, but it's shared infrastructure: it rate-limits, it caps eth_getLogs ranges, and it can lag or drop under load. For serious or high-volume analysis you run your own PulseChain node (full archive if you need historical state) and point curl at http://localhost:8545 — then there are no limits and no third party between you and the truth. Critically, the RPC is the source of truth; the explorer (BlockScout at scan.pulsechain.com, API at api.scan.pulsechain.com/api/v2) is an indexer sitting on top of a node, and indexers can be incomplete, stale, or — on some instances — simply return 404 for an address they never indexed. When the RPC and the explorer disagree, the RPC is the layer to trust — it reads state directly while the explorer only indexes it. (A single RPC can still lag or misbehave; that is what the multi-endpoint cross-check in Stage 04 is for.)

One last framing on raw storage: it's a cross-check, not routine independence. It's tempting to call eth_getStorageAt a 'fully independent third source' alongside the public getter and the event log. For a vanilla, honest ERC-20 that isn't true — the getter and the raw slot read the same underlying storage, so they agree by construction and the slot adds nothing. Raw-slot reading earns its place only when the logic layer could be lying to you: a proxy whose implementation was swapped, an overridden getter, a hijacked contract. Then the slot — which the malicious logic can't fake without actually moving the value — becomes a genuinely independent check. Know which situation you're in before you claim 'triple-verified.'

Every contract call is a blob of hex calldata, and the first 4 bytes are the function selector — the leading 8 hex characters of the keccak-256 hash of the canonical function signature, e.g. transfer(address,uint256) -> 0xa9059cbb. Everything after those 4 bytes is the ABI-encoded arguments, packed in 32-byte (64-hex-char) words. Decoding calldata is a two-part move: identify the function from the selector, then decode the argument words against that function's input types. The selector is a one-way hash, so you can't recover the signature from it by math — you look it up in a public signature directory (current cast queries openchain.xyz, formerly sig.eth.samczsun.com), which cast 4byte and cast 4byte-decode query for you. Note there is more than one public signature directory — openchain.xyz (which cast uses) and the separate 4byte.directory — so the same selector can surface a different candidate set depending on the tool. Critical caveat: selectors are only 4 bytes, so collisions exist — a single selector can map to several different text signatures. The directory returns all candidates; you confirm which one is real by checking it against the actual contract's verified ABI or its known behavior, never by blindly trusting the first hit.

Event logs are the other half of decoding, and they work differently from calldata. Each log has up to 4 topics plus a data field. topics[0] is the event signature hash: the full keccak-256 of the canonical event signature — for ERC-20 that is Transfer(address,address,uint256) = 0xddf252ad1be2c89b69c2b068fc378daa952ba7f163c4a11628f55a4df523b3ef. Note this is the FULL hash, not truncated to 4 bytes like a function selector. The remaining topics carry the indexed parameters (for Transfer: from in topics[1], to in topics[2], each left-padded to 32 bytes), and the non-indexed parameters live ABI-encoded in data (for Transfer: the value). A frequent and embarrassing mistake is hashing Transfer(address,uint256) (two args) instead of the real three-argument event — you get a completely different topic0 and then filter for logs that never appear. Get the canonical signature exactly right: correct types, no spaces, no parameter names.

This is where cast (Foundry) graduates from optional to your daily driver. Raw curl taught you the chain is just JSON-RPC and hex; cast is the layer that decodes that hex without you ever doing base conversion or wei math in your head. The core verbs: cast call <addr> "<name>(<argTypes>)(<returnTypes>)" --rpc-url ... calls a read function and decodes the return for you — note the two SEPARATE parenthesized groups, arguments first then return types, e.g. symbol()(string) or balanceOf(address)(uint256); cast sig "<fn>" gives the 4-byte selector; cast keccak "<text>" and cast sig-event "<event>" give event topic hashes; cast 4byte <selector> and cast 4byte-decode <calldata> reverse-look-up unknown calldata; cast calldata-decode "<sig>" <calldata> decodes selector-prefixed input; cast abi-decode "<sig>" <data> decodes raw return data. The discipline that makes this un-dunkable: the tool computes, the head never does. You never eyeball 0xde0b6b3a7640000 and call it '1 token' — you run cast to-dec / cast from-wei and let the binary be right. The AI's job in this loop is to WRITE the cast command and INTERPRET the decoded result; the binary, not the model and not your mental arithmetic, produces the number.

Decoding is only useful if you know whose addresses you're looking at, so build a personal CONTEXT file — a plain-text or markdown address book mapping every full checksummed address to a human label (token contracts, routers, your own wallets, watched wallets, known bridges). You paste or feed this to the AI at the start of an analysis so when a decoded Transfer shows to = 0x..., the AI immediately tells you 'that's the PulseX Router' instead of leaving you a naked hex string. This is the single highest-leverage habit for AI-assisted analysis: the model is only as sharp as the labels you give it. But the address book is also where the worst trap lives — short labels. A nickname like 'ABCD' or 'the 5EF7 whale' is a human convenience that can silently point at the WRONG full address (a typo, a stale copy, a lookalike vanity prefix). Before you act on, post about, or alarm anyone over a label, resolve it back to the full 42-character checksummed address and verify that address on-chain. Always write addresses full-length, never truncated — a truncated address is unverifiable, and unverifiable equals non-existent.

Single source equals zero sources. An RPC endpoint is a server run by a person, and a server can be lagged, pruned, behind a stale cache, archive-incomplete, or quietly pointed at a different fork. When you query a value from ONE endpoint you have learned exactly one thing: what that one box said. That is not a property of the chain — it is a property of the box. The discipline is brutally simple: fire the SAME call at three INDEPENDENT operators (different parties, not three URLs from one company) and require the raw return bytes to be identical. On PulseChain that means hitting endpoints run by genuinely different people — e.g. rpc.pulsechain.com (core team), rpc-pulsechain.g4mm4.io (G4MM4), and pulsechain-rpc.publicnode.com (PublicNode/Allnodes) — and confirming all three hand back the exact same word. Run totalSupply() of the forked DAI token across all three and every one returns 0x00000000000000000000000000000000000000008f5582f6f8d989d812632a53, byte-for-byte. THAT is a triple-match. Anything less is a draft, not a finding. One honest caveat so you don't over-sell it to a hostile reader: byte-identical returns prove agreement, not true independence — the only real bedrock is your own synced archive node. Multi-RPC catches lag, cache staleness, and fork divergence; it does not catch a coordinated infra failure across providers. It is far stronger than one source and short of absolute. Claim exactly that much.

The getter can lie; the slot cannot. Most contracts you will touch on a fork are proxies, and many are hostile. A getter like implementation(), owner(), or balanceOf() is just code — and code can be written to return whatever its author wants. The storage slot underneath it is the ground the EVM actually stands on. That is your getter-INDEPENDENT third source. For any EIP-1967 proxy the implementation address lives at a fixed slot: 0x360894a13ba1a3210667c828492db98dca3e2076cc3735a920a3ca505d382bbc, which is keccak256('eip1967.proxy.implementation') minus 1 (verify it yourself: cast keccak 'eip1967.proxy.implementation' gives 0x...bbd, and the slot is that minus one, 0x...bbc — the offset exists specifically so the slot can never collide with a normally-mapped variable). Read that slot directly with eth_getStorageAt or cast storage and you see the real implementation regardless of what any getter claims. Read it on the live Aave aDAI mirror 0x018008bfb33d285247A21d44E50697654f754e63 and you get 0x0000000000000000000000007effd7b47bfd17e52fb7559d3f924201b9dbff3d — a 32-byte word whose last 20 bytes are the implementation the chain is actually executing. When a getter and its backing slot disagree, the slot wins and the getter is the story you write up.

Never do the math in your head, and never let the AI do it either. This is the single most common way analysts and LLMs post wrong numbers: hex-to-decimal and wei-to-token conversions done by hand or hallucinated. Language models are pattern matchers, not calculators — they will silently drop a digit, fumble 18 decimals, or confidently render 44359733562592918446387964499 with a digit missing and never flinch. The rule: the TOOL computes, the head narrates. cast to-dec turns 0x8f5582f6f8d989d812632a53 into 44359733562592918446387964499. cast from-wei turns that into a human token amount. A typed signature like 'totalSupply()(uint256)' makes cast call decode the return for you in the same step. Your job — and the AI's job — is to pick the command and read the result, never to perform the arithmetic. THE ONE FOOTGUN that will bite a Verify chapter if it isn't named: cast from-wei defaults to 18 decimals. On the forked USDC and USDT mirrors that litter PulseChain — which are 6-decimal tokens — bare from-wei is wrong by a factor of 1e12. So always read the token's real decimals on-chain first (cast call <token> 'decimals()(uint8)') and pass that count explicitly: cast from-wei <amount> <decimals>, e.g. cast from-wei 1000000 6 returns 1.000000. (A related precision point: cast to-unit only converts between ether/gwei/wei — it is not a general decimal-scaler, so don't reach for it on tokens.) If a number in your post wasn't printed by a tool with the right decimal count, it isn't a number, it's a guess.

Label every claim by its provenance: SELF-VERIFIED, TAKEN-FROM-OTHERS, or INFERRED. The thing that separates an analyst from a hype account is honesty about epistemic status. SELF-VERIFIED means you ran the calls yourself and got a triple-match — you can stake your name on the bytes. TAKEN-FROM-OTHERS means a block explorer, a Dune query, or another person told you and you're repeating it without independent confirmation — useful, but quarantined until you re-run it. INFERRED means you reasoned it out from verified facts but did not directly observe it — the riskiest tier, because plausible reasoning about WHY something happened is exactly where confident-and-wrong lives. Keep causality (the 'why') strictly separate from observation (the 'what'): you can prove a slot holds an address; you usually cannot prove the intent behind it. A revert is its own trap. A single endpoint returning 'execution reverted' (JSON-RPC error code -32000) is meaningless on its own — one node can revert on a state it hasn't fully synced, and some clients return empty data rather than a revert for a missing function. A revert only graduates to a finding when ALL your endpoints revert consistently. Mark it, match it, or don't claim it.

A hunt has exactly one starting point: one transaction hash or one address. Everything else is expansion. The receipt of a single tx is the richest object on the chain — it contains the from, the to, the gas actually burned, the status (1 = success, 0 = reverted), and the logs array, which is the event trail of every token that moved and every contract that fired. You never start by reading a wallet's 'token balances' page on an explorer; you start from one tx and let its logs hand you the next addresses to chase. eth_getTransactionReceipt is the seed; the logs are the branches. The discipline is: AI proposes the next address to pull, you run the call, AI reads the decoded output — the AI never asserts a transfer happened without the decoded log in front of it.

Decoding logs is the whole game, and it is mechanical, not magical. Every ERC-20 Transfer emits a log whose topics[0] is the fixed hash 0xddf252ad1be2c89b69c2b068fc378daa952ba7f163c4a11628f55a4df523b3ef — that is keccak256("Transfer(address,address,uint256)") and it is identical on every EVM chain. topics[1] is the sender, topics[2] is the receiver — both are 32-byte left-padded values, so the real 20-byte address is the last 40 hex characters. The data field is the amount, raw, in the token's smallest base units, which you must scale by the token's decimals before it means anything. A PulseX V2 swap emits a different fixed topic, 0xd78ad95fa46c994b6551d0da85fc275fe613ce37657fb8d5e3d130840159d822 = keccak256("Swap(address,uint256,uint256,uint256,uint256,address)"), and a pool reserve update emits Sync, 0x1c411e9a96e071241c2f21f7726b17ae89e3cab4c78be50e062b03a9fffbbad1 = keccak256("Sync(uint112,uint112)"). You don't memorize these — you have cast compute them (cast keccak "Transfer(address,address,uint256)") and you filter logs by them. The function selector 0x38ed1739 (swapExactTokensForTokens) as the first 4 bytes of a tx's input calldata, with the PulseX router as the to, is your tell that a wallet routed through PulseX rather than transferring directly.

Clustering is connecting addresses that move as one hand, and the evidence lives in the timeline. Pull the counterparties out of the decoded transfers, then for each one fetch its transaction list and look for: shared funding source (multiple addresses first funded by the same wallet within minutes), round-trip flows (A sends to B, B swaps, proceeds return to A), and tight time-correlation (a burst of txs from five addresses in the same two blocks). The single most clarifying operation is sorting every transfer you've collected by blockNumber ascending, breaking ties by logIndex — a flat list of hashes is noise; the same list ordered by block is a narrative. Block number is the canonical clock; wall-clock timestamps are derived from it (you confirm a block's time with eth_getBlockByNumber). Build the timeline first, draw conclusions second. The AI is excellent at taking a pile of decoded transfers and emitting a block-sorted table; it is forbidden from inventing an ordering you haven't fed it. Note that clustering produces hypotheses, not proof — shared funding and tight timing are strong signals, but a single funder can be an exchange hot wallet or a public router, so corroborate before you call it one hand.

Then the PulseChain-specific reckoning, and it is the thing the community must internalize or get rugged by its own portfolio: REAL value vs MIRROR value. PulseChain launched in May 2023 as a full copy of Ethereum's entire state. Essentially every token balance that existed on Ethereum at the fork block also appears on PulseChain — a May-2023 snapshot, frozen unless PulseChain activity has since moved or inflated it, and often attached to wallets whose owners never touched PulseChain. A wallet showing 5 billion of some forked stablecoin, or a Mainnet whale's gigantic PLS-side balance, is almost always fork reflection, not engagement and not wealth. The only value that is real is value you can actually sell — and on PulseChain the deepest, most reliable liquidity for most tokens is a PulseX pool against PLS, so that is where you price it (other venues exist, but a deep PulseX pool is the honest floor). So the final step of every hunt is not reading balanceOf; it is reading the pool. You call getReserves() on the actual PulseX pair, take the ratio of the two reserves, and that — not the token's face value, not its Ethereum price — is what one unit is worth in PLS on this chain. No pool, or a pool with dust reserves, means the balance is worth approximately zero no matter how many zeros it carries. One caveat to stay honest: a thin pool can be inflated to fake a price, so a real valuation weighs reserve depth, not just the ratio — a pool you could drain with one swap is not a price, it's a trap.

You already know the manual moves: read a balance over JSON-RPC, pull recent transfers, decode a calldata blob, cross-check the number on a second RPC. Stage 6 is the moment you stop typing those moves one at a time. An investigation you can reproduce by hand is a skill; an investigation a script reproduces identically on the 1st address and the 400th is leverage. The unit of work shifts from 'a transaction' to 'a wallet', and then to 'a watchlist'. The deliverable of this stage is a single file — call it probe.sh — that takes one address and runs the standard battery: native PLS balance, a fixed list of token balances via balanceOf, nonce, recent Transfer logs decoded to from/to/amount, all printed in a stable, greppable shape. AI writes that file; you read every line before you trust it; you run it; AI interprets the output. The script is the artifact, the AI is the orchestrator and the interpreter — never the unaudited author of a number you publish.

The trap that kills credibility at scale is subtle: automation does not reduce your error rate, it multiplies your throughput at whatever error rate you already have. If your manual process quietly trusted a single RPC, your script now trusts a single RPC four hundred times an hour and calls it a dataset. The fix is structural, not behavioral — you cannot 'remember to verify' across a cron job that fires at 3am. The multi-RPC cross-check has to be a function inside the script: query the same balanceOf against three independent endpoints (e.g. https://rpc.pulsechain.com, https://pulsechain-rpc.publicnode.com, and https://rpc-pulsechain.g4mm4.io — all three return chain id 369), compare the raw hex, and emit MATCH or a loud MISMATCH that flags the row instead of printing a number. A value that didn't pass through that function never reaches your output. This is the same triple-verify discipline from Stage 5, demoted from a habit to a line of code — which is the only place a habit is safe at scale.

Watchlists turn a one-shot probe into surveillance. Keep a flat file of addresses (one per line, full 42-character form, never truncated — truncation is how you key a snapshot to the wrong wallet). The monitor loop is brutally simple: for each address, snapshot the cheap, monotonic state signals — eth_getTransactionCount (nonce) and native balance — into a small store (a tab-separated file or SQLite row keyed by address). On the next run, diff against the stored snapshot. Nonce moved? The wallet sent a transaction. Balance moved? Value flowed. A diff is your trigger; everything expensive (pulling the actual txs, decoding them, summarizing) happens only on a triggered address, not on every address every minute. That keeps a 400-wallet watchlist cheap enough to run on a cron without hammering public RPCs into rate-limiting you. cron schedules it; the diff decides whether there's anything worth waking the AI for.

Agentic orchestration is the top layer, and it is where Claude earns its place: plan -> fetch -> decode -> verify -> summarize, as an explicit loop the model drives. You hand it a triggered address and the question ('this nonce jumped 12 in an hour — what did it do?'). It plans the calls, runs your verified primitives (it calls probe.sh and cast, it does not freehand arithmetic), pulls the Transfer logs, decodes them, runs the cross-check, and writes a human summary with every load-bearing number tagged by how it was established — self-verified across 3 RPCs, TAKEN-FROM-OTHERS, or inferred. The agent's judgment is allowed to be probabilistic; the numbers it cites are not. That separation — soft reasoning over hard, tool-computed, multi-sourced facts — is the whole methodology compressed into a workflow. One sharp edge to internalize before you automate log pulls: filtering Transfer events by a wallet is the single most error-prone primitive in this stage, because the cast logs argument modes are easy to mix up and a mixed invocation fails silently — it returns a full unfiltered dump that merely looks filtered. Get that primitive provably right (see the commands), bake it into the script, point the cron at your list, and let the model do the reading. That is what 'scale' means here: not more wallets per hour, but the same un-dunkable rigor per wallet, automatically.

Every on-chain claim secretly bundles three separate assertions, and the con works by making you accept all three when you only verified one. (1) MECHANISM: does the contract actually do X? (2) VALUE: is the thing it produces worth real money? (3) CAUSALITY: does X therefore imply the conclusion Y? These are independent. A flash-loan helper that genuinely executes is mechanism-real. The tokens it moves can still be a frozen mirror worth a few dollars (value-false). And 'it moved tokens, therefore the project is solvent' can be a non-sequitur (causality-false). The entire skill of judgment is refusing to let a verified mechanism smuggle in an unverified value or an unearned causal claim. When you read 'this contract drains the vault, so the token is backed,' your job is to split it into three lines and verify each on its own.

Here is the single cleanest live example on PulseChain, and you can run it yourself in ten seconds. The forked 'DAI' contract at 0x6B175474E89094C44Da98b954EedeAC495271d0F (PulseChain forked Ethereum's state and reuses its exact contract addresses, so this address queried against rpc.pulsechain.com is the independent forked-DAI contract, not mainnet DAI) reports a totalSupply of 44359733562592918446387964499 base units — i.e. ~44.36 billion whole tokens once you scale by its 18 decimals. That number is REAL: three independent RPCs return identical hex, it decodes cleanly, it is genuinely the value stored on chain. A hype analyst stops here: '44 billion DAI on PulseChain.' But PulseChain is a full state-copy of Ethereum from May 2023, and this number is not the mainnet number: real DAI on Ethereum is on the order of a few billion (~4.6B), and this forked token was ~5 billion right after the fork — both cross-chain / historical reads you should confirm against an Ethereum RPC, not measured by the command above — so the extra ~39 billion was minted on PulseChain since, so 44.36B is a PulseChain-side inflation, not a photocopy of mainnet. Mechanism-real (the supply reads back, every time, 3/3), value-false (there is no mainnet DAI behind it; the only price that exists is what PulseX will actually pay in PLS for one unit), and the causal leap 'therefore 44 billion dollars of DAI exist on PulseChain' is simply false. Same number, three completely different verdicts depending on which of the three questions you ask. The number was never the lie — the framing around it was.

Verification status must be visible in the output, not implied. 'pDAI supply is ~44.36B' is a weaker statement than '44359733562592918446387964499 base units (~44.36B tokens) — 3/3 RPCs agree, raw hex identical, self-verified.' The second is un-dunkable because a hostile expert can re-run it and land on your exact bytes. Make the seam between knowledge-grades explicit in every finding: SELF-VERIFIED (you ran the command and saw the bytes), TAKEN-FROM-OTHERS (a source said it and you are passing it through), INFERRED (you reasoned to it but did not measure it). Collapsing these three is the most common way good analysts get dunked — they present an inference with the same confidence as a measurement, and one counterexample takes down the whole thread. A finding that says 'mechanism self-verified ✓ / value inferred, not measured / causality is an open question' is bulletproof precisely because it claims only what it proved.

The AI's failure mode here is confident narration: ask it 'is this token backed?' and it will happily write a story where the verified supply number 'proves' backing. That is the exact trap. Use the AI as a command-writer and an output-interpreter, never as a verdict-giver. The discipline: make the AI produce the raw command, you run it, then force the AI to answer only the three split questions against the bytes it can see — 'which of mechanism/value/causality does this output actually establish, and which does it not touch?' When the AI wants to assert a cause ('the price moved because…'), demand the on-chain evidence for the 'because.' If there is none, the correct output is an open question, not an invented mechanism. The honest analyst's edge is not being smarter — it is refusing to print the third claim when only the first was measured. Over months, the hype accounts get caught by their own overreach; the account that always shipped 'mechanism ✓ / value ✗ / causality open' is the one people trust when it finally says 'this one is real.'