How to Analyze an EVM Wallet with WalletGenome

WalletGenome is an analytics and forensics tool for observable public activity on Ethereum, Base, Arbitrum, and Optimism. A scan assembles returned transactions, native and token transfers, contract calls, counterparties, protocol labels, gas use, ERC-20 approval history, and available public identity records. The report also derives activity, capital-flow, risk, and Sybil signals when their required datasets are available.

The report describes the address and networks you selected. It cannot see off-chain agreements, private exchange records, a person’s intent, or activity on unsupported networks. WalletGenome does not provide custody, trading, transaction execution, or investment advice.

The screenshots below were captured from the public WalletGenome site on 27 September 2026. The report example uses the saved vitalik.eth demo dated 26 August 2026. Its history is partial, and the images illustrate the interface. They make no finding about the person named in the demo.

Begin with one question: which protocols and recurring counterparties appear in the returned history, or which observed approvals need a current on-chain check? The question tells you which parts of the report to inspect and keeps the charts in context.

1. Choose Single Wallet

   Open the wallet scanner and keep the single-wallet mode selected. Cluster mode answers a different question about relationships among several submitted addresses.

2. Enter an address or supported name

   Use the EVM address under investigation. An ENS name can be resolved when the configured identity service returns a valid address.

3. Select the relevant networks

   Choose Ethereum, Base, Arbitrum, Optimism, or a combination. Include every supported network relevant to the question so the aggregate view does not omit known activity.

4. Run the scan and retain the scope

   Fresh scans require an authenticated session. Google sign-in or Ethereum wallet authentication establishes access to the scan. Wallet authentication requests a login message. It does not request a transaction, token approval, private key, spending permission, or chain switch.

Provider responses determine what the report can support. WalletGenome distinguishes complete, partial, and unavailable data. Read the status and warning panels before comparing totals or drawing conclusions. A provider can return normal transactions while token transfers, internal transfers, identity records, prices, or blacklist checks remain incomplete.

• Complete means the required returned dataset passed the report’s completeness rule. It does not mean every real-world action by the wallet is known.
• Partial means some usable records were returned and a stated part of the requested evidence is missing.
• Unavailable means the report cannot publish that result from the available inputs.
• A current-price subtotal counts only returned transfer legs with reliable quotes. Missing history and unpriced legs remain outside that subtotal.

Begin with transaction activity. Review the active dates, cadence, failed transactions, categories, and network distribution. The activity heatmap uses UTC, so a visible hour-of-day pattern needs timezone context before it supports a behavioral interpretation.

Behavioral DNA summarizes DeFi diversity, activity, capital efficiency, risk appetite, maturity, and network breadth. Use the radar and chain activity panel to choose follow-up questions. A calculated dimension or protocol badge describes returned records; it does not identify an operator or establish intent.

Next, inspect transfers and capital flows. Separate inbound from outbound legs, identify recurring counterparties, and check whether labels connect an address to a known exchange, bridge, or protocol. A label describes a configured address match. It does not prove the purpose of every transfer. USD flow and protocol volume value returned activity at current prices; missing quotes reduce coverage, and these figures are not wallet holdings or profit.

Use the Flow Graph network and minimum-volume filters to narrow visible relationships. Historically priced transfer volume can count assets as they move repeatedly. It does not establish wallet balance or profit. When pricing or history is incomplete, the summary labels its values as lower bounds and identifies excluded transfer legs.

Review gas behavior beside activity. Gas totals, failed gas, monthly patterns, and transaction categories can show how frequently the address uses contracts and where execution fails. High gas use can come from active use, expensive periods, complex calls, or repeated failures. The surrounding transactions provide the useful context.

Then inspect approvals. WalletGenome decodes ERC-20 approval calls and reconstructs the latest non-revoked state observed in returned history for each token and spender pair. This is historical reconstruction. It is not a live allowance query. The exposure estimate uses reconstructed positive token balances and available current prices, capped by the observed allowance when finite. Unknown balances or prices leave exposure unavailable.

Identity records add public context from available naming and social services. Treat a resolved name, avatar, or linked profile as a provider-returned record. Compare the record with the address and chain evidence before using it in an attribution decision.

The security risk score summarizes configured approval, failed-transaction, stale-approval, and unknown-contract factors for each chain. The aggregate headline uses the highest selected-chain score when wallet history is complete. Use the factor list to locate the transactions and approvals that deserve review.

Sybil analysis has two evidence families. Public-list and blacklist checks report source-specific matches. A separate local MEDIA-style behavioral heuristic evaluates engagement, diversity, cross-chain breadth, wallet age, and a monetary dimension when pricing permits. These states answer different questions. Neither one proves common ownership, coordinated control, malicious intent, or wrongdoing.

For a fuller explanation of these outputs, read Understanding Wallet Risk Signals.

Write down the observation first: chain, transaction hash, timestamp, direction, asset, counterparty, decoded method, label, status, and data provenance. Add the interpretation in a separate sentence. This discipline makes uncertainty visible and gives another reviewer a path back to the source record.

• Observation: the returned Optimism history contains five failed contract calls within one hour. Interpretation: the pattern may deserve review for automation or repeated execution errors.
• Observation: an unlimited approval to an unidentified spender remains the latest observed state in returned history. Interpretation: current allowance state should be verified on-chain before any remediation decision.
• Observation: current quotes cover 64 of 80 eligible transfer legs. Interpretation: the current-price USD subtotal excludes 16 unpriced legs.

• Which selected chains returned complete transaction, transfer, and pricing data?
• Does activity cluster around one period, protocol, counterparty, or network?
• Which inbound sources appear before major protocol activity or outbound transfers?
• Do repeated counterparties have configured labels, and can the underlying transactions confirm the apparent role?
• Which failed calls, unknown contracts, or stale approvals contribute to the risk factors?
• Are approval rows current enough for the question, or is a separate live allowance check required?
• Does a Sybil result come from a source match, the behavioral heuristic, or both?
• Which conclusions change if every partial or unavailable dataset is removed from consideration?

1. Define the question

   Example: identify the address’s main protocols, funding paths, and observed approval exposure across the four supported networks.

2. Record the coverage

   Note every complete, partial, and unavailable dataset before reading aggregate figures.

3. Build the activity picture

   Use transaction cadence, transfers, counterparties, protocol labels, and gas behavior to describe the returned history chain by chain.

4. Inspect security evidence

   Open the risk factors and approval rows. Trace each relevant item to its chain, spender, transaction, age, and completeness state.

5. Review identity and Sybil context

   Keep public identity records, list matches, and behavioral heuristics as separate evidence types.

6. Write a bounded finding

   State what the returned evidence shows, which data is missing, and which interpretation still needs external verification.