How to research an address using onchain data

Start an onchain investigation with three facts: the network, the address or transaction hash, and the interval you want to inspect. Without them, an agent can return a detailed report about a different chain or a partial history that looks complete.

This tutorial produces a public-data evidence table. It does not move funds, sign messages or identify a person behind an address. You can use it to understand a known payment, inspect a bounded activity period or prepare questions for a deeper review.

1. Define the unit of research

Choose either one transaction or one address over a bounded range. A single transaction is usually easier to check than an open-ended request to explain an address's entire history.

After connecting Vaaya, give your agent this brief:

Inspect [public address or transaction hash] on [exact network].
Limit address history to [date/block range] and [maximum records].
Read public data only. Do not sign, send funds or change approvals.
Use Vaaya's current catalog to choose the correct chain-specific route.
Stay within [budget] and keep source URLs, hashes and block numbers.
Distinguish transactions, token transfers, balances and inferred labels.
Return incomplete coverage and unsupported fields explicitly.

Never paste a seed phrase as an input. The public identifier is enough to define the lookup.

2. Choose the right chain and record type

The live catalog includes Heurist routes for Etherscan address history, ERC-20 transfers and transaction details. It also lists a Base USDC profile route and separate wallet analysis tools. These are different retrieval paths, not interchangeable names for universal chain coverage.

Have consult return the current service, endpoint and parameters for the chosen task. The route is selected through heurist/agent; its endpoint-specific inputs must be checked before running. Do not assume that an empty top-level required-parameter list means an address is optional.

Confirm supported networks and pagination from the actual route documentation. If the requested chain is unsupported, retain that gap instead of querying another network with the same hexadecimal address.

3. Preserve the raw observations

For a transaction, keep its hash, block, status, sender, destination, value and any relevant transfer events. Preserve the source's units. A token amount expressed in base units needs the token's decimals before it can be displayed meaningfully; a symbol alone is insufficient to identify the asset.

Ethereum's transaction documentation describes the distinction between submitted transaction fields and what happens when the network processes them. In your report, keep a submitted or pending record separate from a confirmed outcome. A block number without an accompanying finality check is not a universal guarantee that the observation will never change.

For address history, keep page or cursor information and the oldest/latest observations returned. Reaching a page limit should produce an incomplete-coverage note, not a declaration that the wallet has no earlier activity.

4. Normalize without merging unlike records

Use separate tables where the record types differ. This schema is illustrative; no wallet was analyzed for this article.

Record	Fields to retain
Transaction	Network, hash, block, status and source link
Token transfer	Transaction hash, event position, contract and units
Balance snapshot	Asset contract, amount, block or observation time
Address label	Label text, assigning source and evidence limits

Deduplicate transaction rows by network and hash. Token events within a transaction need their own event identifier or position. If a provider omits one, preserve that uncertainty rather than deleting rows because their amounts happen to match.

Keep fees separate from transferred asset amounts. Describe a contract interaction as the source supports it; do not turn every movement into a payment, sale or profit.

5. Verify one row before expanding

Open an appropriate explorer link for one returned record and compare the hash, network, status and amounts. Check the original event details when the summarized report seems surprising. If the provider and explorer differ, record both timestamps and investigate coverage or interpretation before choosing a preferred answer.

Return the table, source files and remaining questions together. End the run at the requested boundary, with the last cursor or block recorded so a later review can continue without paying to retrieve the same history again.

Questions

Does reading a public address require its private key?

No. This research workflow uses public chain data. Never supply a seed phrase or signing key to retrieve it.

Can an address label prove who owns the wallet?

A label is a claim from a source. Record its provenance and confidence. Shared services, custodians and smart contracts can make ownership inferences unreliable.

Why can transaction count and token-transfer count differ?

They describe different records. A transaction may contain several token-transfer events, while a token-transfer endpoint may cover only selected assets or event types.