Same tools, real money: reading Ethereum mainnet

Nothing about the tooling changes. That is the whole point. The only thing that changes is the URL behind one environment variable. By the end you will have dissected a real USDC transfer from raw bytes, decoded a live stablecoin movement from the newest block on the chain, and — almost by accident — watched fresh USDC being created out of nothing. You will also have collected the single most important caveat in stablecoin analytics, which Chapter 3 then quantifies.

What we skip on purpose: writing or deploying contracts, signing anything on mainnet, proxy internals, historical log pagination, reorg handling, entity attribution. Read side only, current data only.

In Chapter 1 the stack was:

Cast → JSON-RPC → Anvil (local chain, chainId 31337)

This chapter’s stack:

Cast → JSON-RPC over HTTPS → RPC provider → Ethereum Mainnet (chainId 1)

Anvil wasn’t a toy imitation of Ethereum — it exposed the same interface real nodes expose. So graduating to mainnet is one line:

export ETH_RPC_URL="https://ethereum-rpc.publicnode.com"   # example public endpoint — can change or rate-limit

cast chain-id --rpc-url $ETH_RPC_URL      # → 1
cast block-number --rpc-url $ETH_RPC_URL  # → 25729619

Two lessons arrived immediately, both operational:

1. The provider is a gateway, not the network. Our first endpoint choice was down (a tunnel error). Ethereum was fine; our chosen door into it wasn’t. Payments translation: your processor’s API being down does not mean the card network has failed. For any production monitoring system, RPC provider selection — retention, rate limits, archive access, fallbacks — is a real architecture decision, not plumbing detail.

2. The chain moves while you look at it. Two block-number queries seconds apart returned 25,729,619 and then 25,729,627. latest is a moving reference, like asking “what’s the current FX rate” — the answer has a timestamp, not permanence. Every “latest” query in this chapter carries that asterisk.

One mechanical note, taught once and then assumed: raw JSON-RPC speaks hexadecimal ("0x1889a5b" = 25,729,627). Cast decodes it for you; when we drop to raw RPC calls, we decode it ourselves.

We took a real deposit address issued by a Binance account (Ethereum network selected) and asked the chain directly:

export ADDRESS=0x3e0a…195b   # substitute your own deposit address

cast balance $ADDRESS --ether --rpc-url $ETH_RPC_URL   # → 0.000000000000000000
cast nonce $ADDRESS --rpc-url $ETH_RPC_URL             # → 0

The Binance app says the customer owns ETH. Ethereum says this address holds zero and has never sent a transaction. Both are true.

A custodial exchange runs an internal customer ledger and separately manages the actual on-chain assets across wallets it controls — deposits are detected, credited internally, then often swept into consolidated treasury wallets. Payments professionals already know this structure by name: it’s an omnibus account. The customer’s claim lives in the institution’s books; the settlement-rail position lives somewhere else entirely.

customer account ledger  ≠  external settlement-rail position

This distinction does heavy lifting later: reconciliation, treasury wallet identification, and why “on-chain volume” systematically misses activity that never leaves an exchange’s internal ledger.

One precision worth keeping: nonce = 0 means the address never originated a transaction. It can still have received ETH, received tokens, or appeared in logs — receiving does not increment a nonce.

For the rest of the chapter we use one real mainnet transaction as our specimen: 0x8552…5382. The transaction object contains a surprise if you’re expecting Chapter 1’s simple transfer:

from   = 0x6872…f7dE
to     = 0xA0b86991c6218b36c1d19D4a2e9Eb0cE3606eB48   ← the USDC contract
value  = 0 ETH
input  = 0xa9059cbb…                                   ← 68 bytes of calldata

The sender did not send anything to the recipient. They sent zero ETH to a smart contract, with an encoded instruction attached. The USDC contract executed that instruction and updated its own internal accounting.

USDC balances are contract state. A USDC transfer is an Ethereum transaction that calls the USDC contract.

Decoding the instruction

The calldata splits into three parts, decodable locally without touching the chain. The selector is the first 4 bytes of the hashed function signature — the contract’s routing key for which function to run. This is your first contact with ABI literacy; Chapter 3 makes it systematic.

cast tx $TX --rpc-url $ETH_RPC_URL   # fetch the transaction (needs RPC)
cast 4byte-calldata 0xa9059cbb…      # decode calldata (purely local — no chain needed)

The receipt: two currencies in one payment

The receipt (cast receipt $TX) confirms execution: status 1, gasUsed 62,260 against a gas limit of 1,050,000. Chapter 1’s fee arithmetic applies unchanged — but now with a payments twist. This single payment involves two economically distinct values in two different assets:

18.567969 USDC   → the payment value
≈ 0.00070 ETH    → the network execution fee (≈ $2.10 at an illustrative $3,000/ETH)

The payer needs a balance in both. This mismatch is why “gas abstraction” (someone else sponsoring the fee) is an active product battleground in stablecoin payment UX.

Trap callout — cumulativeGasUsed: the receipt also shows ~20.3M gas. That’s the running total for the whole block up to this transaction (ours sat at index 72), not our cost. For per-transaction analysis, gasUsed is the field.

And the standing caveat from Chapter 1 still applies: status = 1 proves blockchain execution succeeded. It says nothing about off-ramp, FX, compliance release, or beneficiary credit. On-chain success ≠ payment completion.

The receipt carried one log, emitted by the USDC contract. ERC-20 defines Transfer(address indexed from, address indexed to, uint256 value). Ethereum stores it with topics[0] as the keccak256 hash of the canonical signature Transfer(address,address,uint256) — the event’s fingerprint, identical for every ERC-20 token on every chain. Indexed parameters go into topics (so they can be filtered); the rest goes into data.

Verifying the amount ourselves

The raw value 0x11b5321 = 18,567,969 raw units. Raw units of what? We ask the contract directly:

cast call $USDC "symbol()(string)" --rpc-url $ETH_RPC_URL    # → "USDC"
cast call $USDC "decimals()(uint8)" --rpc-url $ETH_RPC_URL   # → 6

18,567,969 ÷ 10^6 = 18.567969 USDC

Never assume 18 decimals — USDC uses 6, other tokens differ. Decimals are contract metadata you must fetch, not convention you may assume.

Intent vs. evidence

Now hold the calldata and the log side by side:

CALLDATA — what the caller requested:  transfer(Bob, amount)
LOG      — what the contract emitted:  Transfer(Alice, Bob, amount)

Related, but not the same object. Calldata proves intent; logs prove execution. A monitoring system built on calldata alone counts requests; one built on logs counts outcomes. Every serious tracker is built on logs.

So far every log we’ve seen was reached via a known transaction hash. Monitoring works the other way around: start from criteria, find matching logs. The RPC method for that is eth_getLogs, and it’s the foundation of every transfer tracker, mint/burn monitor, and freeze-event alert we’ll build.

We asked mainnet: give me every USDC Transfer event in the latest block.

cast rpc eth_getLogs \
  '{"fromBlock":"latest","toBlock":"latest","address":"0xA0b86991c6218b36c1d19D4a2e9Eb0cE3606eB48","topics":["0xddf252ad1be2c89b69c2b068fc378daa952ba7f163c4a11628f55a4df523b3ef"]}' \
  --rpc-url $ETH_RPC_URL

It returned a large array of live stablecoin movements. We decoded one by hand — from 0x51c7… to 0xe055…, raw value 0x79c8d25a = 2,043.204186 USDC — reconstructing a real dollar movement from raw bytes, independently of any explorer or vendor. That is the analyst capability this whole series is building toward.

Three findings in that single block preview everything Chapter 3 formalizes:

1. One transaction, multiple transfers. The same transaction hash appeared in two Transfer logs (A→B, then B→C, same amount) — a routed movement. Another single transaction emitted many Transfer events. 1 transaction = 1 payment is dead on arrival.

2. We caught a mint. One log showed from = 0x0000…0000 — the zero address. By ERC-20 convention, a Transfer from the zero address is token creation: 4,171.03 USDC minted into existence while we watched. The inverse (transfer to the zero address) is a burn. Neither is a payment, yet both are Transfer events.

3. Therefore:

transaction count ≠ Transfer-event count ≠ economic payment count

Transfer events include mints, burns, exchange sweeps, DeFi routing, and treasury shuffling. On-chain transfer evidence must be economically classified before anyone calls it payment volume. This is the on-chain twin of Episode 2’s volume-collapse ladder, and Chapter 3’s closing lesson quantifies it.

One production caveat before we go. When we tried the same query against a historical block, our free provider refused: archive access requires authentication. Supporting the JSON-RPC standard does not mean unrestricted access to all history. Providers differ on retention, log-range limits, rate limits, and pricing — which is why the corridor monitor will treat provider selection as an architecture decision with a fallback, not a config value.

Glossary — Chapter 2 additions

Only terms new since Chapter 1; the full series glossary lives at the series level.

Bridge to Chapter 3

Everything you did manually here has a one-line programmatic equivalent:

cast tx      → getTransaction()
cast receipt → getTransactionReceipt()
cast call    → readContract()
eth_getLogs  → getLogs()

Same JSON-RPC underneath, same objects, same caveats. Chapter 3 rebuilds this chapter in TypeScript — because a monitoring system can’t type Cast commands at 3 a.m.