AIE - Wallet Insight | Multichain Wallet Analysis - Full Public Case Study

Continuing the discussion from AIE - Airdrop Integrity | Private Institutional Airdrop Analysis: # AIE - Wallet Insight

Multichain Wallet Analysis - Full Public Case Study

A wallet address is easy to look up.

Understanding what that wallet actually did is a different problem.

For protocols, treasuries, exchanges, auditors, investigators, security teams, funds, counterparties and users preparing high-value transfers, an explorer page is not enough when a decision depends on the difference between:

  • an address appearing on a network and actually using that network;
  • an inbound transfer and an owner-originated action;
  • a displayed token and an economically qualified asset;
  • an explorer valuation and defensible portfolio value;
  • a bridge appearance and a reconstructed cross-chain journey;
  • unsolicited dust and genuine wallet behavior;
  • a generic risk label and evidence that can actually be reviewed.

AIE - Wallet Insight is built for that distinction.

Rather than describing the service abstractly, below is a complete public multichain case study showing the type of result a client receives.


Subject

Address: 0xd8dA6BF26964aF9D7eEd9e03E53415D37aA96045

Environment: EVM Multichain
Analysis: AIE - Wallet Insight
Evidence level: EVIDENCE ANCHORED
Wallet connection required: No
Signature required: No
Private key or seed phrase required: Never

The address is public and carries the public explorer label vitalik.eth / Vb 5.

The identity label is not used as analytical evidence. The analysis concerns the public blockchain address and its observable activity.


Executive Conclusion

A conventional multichain explorer currently presents this address as having token holdings across 31 networks, more than 100,000 address-associated records, and approximately $1.13M of raw aggregated portfolio value.

Those numbers are real explorer outputs.

They are not the AIE conclusion.

AIE separates four questions:

NETWORK PRESENCE → CONTROL EVIDENCE → ASSET PROVENANCE → QUALIFIED VALUE

The same hexadecimal address appearing on multiple EVM networks does not prove that the address actively used every one of those networks.

Anyone can send ETH, tokens, NFTs or dust to a public address.

Likewise, a token appearing in an explorer does not prove that the controller intentionally acquired it, and an explorer-supplied price does not automatically make that token part of a defensible portfolio valuation.

Primary findings

Multichain presence: CONFIRMED

Active multichain use: CONFIRMED, but materially narrower than raw network presence

Ethereum activity: CONFIRMED

Base activity: CONFIRMED

Optimism activity: CONFIRMED

Arbitrum activity: CONFIRMED

Historical activity on additional networks: CONFIRMED

Large passive/inbound footprint: CONFIRMED

Unsolicited-token contamination: HIGH

Raw explorer portfolio reliability: LOW WITHOUT ASSET QUALIFICATION

Delegated account behavior: CONFIRMED

DeFi interaction: CONFIRMED

Current compromise: NOT ESTABLISHED

Mixer exposure: NOT ESTABLISHED IN THIS BASE REVIEW

Sanctions determination: NOT ISSUED WITHOUT QUALIFIED REFERENCE EVIDENCE

The result is therefore not reduced to a single arbitrary Risk Score.

The client receives the individual findings, their evidence status and the distinction between what the wallet demonstrably did and what merely appeared around it.


1. Multichain Discovery

The current Blockscan view exposes 34 explorer/network entries and token holdings across 31 networks.

At the time of this case-study snapshot, the largest raw explorer-displayed values are approximately:

Network Raw displayed value
Ethereum $857K+
Blast $128K+
Base $86K+
BNB Chain $52K+
Optimism $7K+
Arbitrum One $859
Polygon $699
Taiko $192
World $123
Unichain $63
Linea $19
Additional networks smaller balances

These figures are discovery data.

They are not automatically accepted as AIE-qualified owner holdings.

That distinction becomes important immediately.


2. Presence Is Not Usage

AIE does not mark a network as actively used simply because the same address exists there or because tokens have been sent to it.

For every network, we independently look for address-originated evidence.

The classification model is:

ACTIVE - CONTROL CONFIRMED

The address has initiated activity that demonstrates use of the account on that network.

HISTORICAL ACTIVE

Outgoing use is established, but the activity belongs to an earlier period.

PRESENCE ONLY

Assets or transactions involving the address exist, but local owner-originated activity has not been established.

UNQUALIFIED

The network requires additional evidence before a behavioral conclusion is issued.

This prevents the common but incorrect transformation:

same address found on 31 chains

into:

owner actively uses 31 chains

Those are not equivalent statements.


3. Ethereum

Ethereum is the largest network by raw displayed value in the current explorer portfolio.

The address has genuine owner-originated activity and contract interaction history.

Therefore:

Presence: CONFIRMED
Control/use: CONFIRMED
Activity: ACTIVE
Contract interaction: CONFIRMED
Native asset presence: CONFIRMED

But Ethereum also demonstrates the asset-qualification problem.

Several tokens account for a very large share of the raw explorer valuation. Current explorer allocation data includes very large nominal values attributed to tokens such as WHITE, CATE, MOO DENG and KNC.

AIE does not simply copy those balances into:

“Verified owner wealth: $1.13M.”

For every material asset, the analytical questions are different:

  • What is the exact token contract?
  • How did the asset arrive?
  • Was it acquired through an address-originated transaction?
  • Was it transferred unsolicited?
  • Does a legitimate market exist for this exact contract?
  • Is the explorer price mapped to the correct asset?
  • Is there sufficient liquidity to treat the displayed price as economically meaningful?
  • Has the subject ever interacted with the token?

Until those questions are qualified, the value remains displayed value, not qualified owner value.


4. Base - Active Use Confirmed

Base gives strong evidence of actual control and use.

The explorer records address-originated transactions and a substantial contract-interaction history.

On 1 May 2026 alone, the address executed a compact sequence of transactions involving Uniswap V2 Router02 and Uniswap V3 Swap Router02, including multiple ETH-valued transactions within minutes.

The Base history also contains interactions with LI.FI Diamond.

Therefore:

Base presence: CONFIRMED
Base control: CONFIRMED
Address-originated activity: CONFIRMED
DEX interaction: CONFIRMED
DeFi activity: CONFIRMED
Cross-chain infrastructure interaction: OBSERVED

This is fundamentally stronger evidence than merely receiving a token on a network.


5. Delegated Account State

The address cannot be treated everywhere as a simple traditional EOA and analyzed solely as:

private key → transaction

Current explorer state identifies it as an Authority with delegated execution state, including an EIP-7702 delegation on Base and other observed networks.

AIE classification

Traditional EOA-only model: NOT SUFFICIENT

Delegated account behavior: CONFIRMED

Execution-model complexity: ELEVATED

Compromise indication from delegation alone: NONE

Delegation is not itself malicious.

It means that a professional wallet review must understand the current execution model of the account instead of stopping after identifying the hexadecimal address.


6. Blast - The Valuation Anomaly

Blast is one of the clearest examples in this case.

The explorer currently shows approximately $128,205 of token holdings for the address.

Approximately 190 million DUCKIE account for almost all of that displayed value.

At the same time, BlastScan reports:

Transactions Sent: N/A

The same address page also contains unsolicited-looking token/NFT material with reward and promotional naming.

A naive portfolio interpretation could therefore produce:

“The owner uses Blast and owns approximately $128K there.”

AIE does not make that statement.

The evidence supports:

Blast presence: CONFIRMED

Inbound asset presence: CONFIRMED

Address-originated Blast transaction: NOT OBSERVED IN THE BASE REVIEW

Intentional DUCKIE acquisition: NOT ESTABLISHED

Owner-qualified Blast portfolio value: NOT DERIVED FROM THE RAW EXPLORER FIGURE

This one network represents more than ten percent of the raw multichain portfolio display while local owner-originated use is not established.

That is the difference between displaying blockchain data and interpreting it.


7. Passive Networks and Unsolicited Assets

The address has additional networks where assets exist but owner-originated activity is absent or not sufficiently established in the base review.

AIE keeps those networks in the wallet record.

It does not silently promote them into behavioral history.

The correct distinction is:

Asset received: YES

does not imply:

Owner chose this asset: YES

and:

Address exists on network: YES

does not imply:

Owner actively used network: YES

This matters particularly for highly visible public addresses because they attract:

  • unsolicited tokens;
  • promotional NFTs;
  • dust;
  • vanity transfers;
  • address-poisoning attempts;
  • fake reward assets;
  • memecoins;
  • automated distribution campaigns;
  • transfers made purely because the address is publicly known.

These events remain evidence.

They are simply evidence of incoming activity, not automatically evidence of subject behavior.


8. Dust and Micro-Transfer Discipline

AIE records incoming micro-transfers without assigning them to the wallet controller.

For a typical event:

external address → 0.00001 ETH → subject

the base finding is:

Transfer: CONFIRMED
Direction: INBOUND
Subject initiated transaction: NO
Relationship to sender: NOT ASSUMED
Sender intent: NOT ATTRIBUTED IN BASE WALLET INSIGHT

This prevents inbound dust from contaminating the wallet biography.

If the client needs to know who is sending the dust and why, that becomes a different investigative question.


9. Dust / Spam Attribution - Extended Investigation

A Wallet Insight identifies and separates unsolicited activity.

A deeper investigation can then move outward from the subject wallet and examine the infrastructure behind it.

That expansion can determine:

  • originating addresses;
  • repeated sender clusters;
  • common funding sources;
  • token and NFT deployers;
  • identical campaigns across networks;
  • automated distribution infrastructure;
  • address-poisoning patterns;
  • phishing-style token/NFT campaigns;
  • repeated timing signatures;
  • shared contract relationships;
  • links between apparently unrelated sender addresses;
  • attributable entities where evidence supports attribution.

The result can move from:

“Unsolicited transfers detected.”

to:

“These transfers were generated by this sender cluster, funded through this path, using these contracts, across these networks.”

This is separately scoped because the object of investigation has expanded beyond the subject wallet.


10. Cross-Chain / Bridge Layer

The public history contains interactions involving cross-chain infrastructure, including LI.FI and other bridge-related systems.

AIE does not turn the mere appearance of a bridge contract into a fabricated journey.

For example, seeing:

subject ↔ bridge infrastructure

is not yet sufficient to claim:

Ethereum → Bridge → Base → Swap

A complete cross-chain journey requires correlation of:

  • source transaction;
  • source asset;
  • source amount;
  • bridge/router event;
  • timing;
  • destination settlement;
  • destination asset;
  • destination transaction;
  • subsequent movement.

Each link receives an evidence state:

CONFIRMED

EVIDENCE-SUPPORTED

UNRESOLVED

Base Wallet Insight

Bridge infrastructure involvement: OBSERVED

Extended Cross-Chain Reconstruction

A complete reconstruction can produce:

source chain

source transaction

bridge/router

destination settlement

destination wallet state

subsequent transaction

This is particularly useful when an investigation cannot be understood correctly from a single chain.


11. DeFi Footprint

The wallet has genuine DeFi activity.

Current multichain explorer data identifies Uniswap positions, while Base independently shows owner-originated Uniswap interactions.

Therefore:

DeFi participation: CONFIRMED

DEX activity: CONFIRMED

Uniswap interaction: CONFIRMED

Again, this conclusion is based on address-originated evidence.

It is not inferred from somebody sending a DeFi-related token to the address.


12. Approval and Execution Exposure

Wallet security cannot be determined from balances alone.

Depending on the network and account state, exposure can also exist through:

  • ERC-20 allowances;
  • unlimited token approvals;
  • ERC-721 operator approvals;
  • ERC-1155 operator approvals;
  • delegated execution;
  • spender contracts;
  • smart-account authorization state.

Approvals are network-specific.

An Ethereum approval is not automatically a Base approval.

A Base approval is not automatically an Arbitrum approval.

A full Approval Exposure expansion can produce:

network → asset → spender → allowance → limited/unlimited → spender identity → current relevance → evidence

This is available when the client’s question requires full authorization mapping rather than base wallet characterization.


13. Transaction Count Integrity

Blockscan currently reports more than 100,000 address-associated records in its multichain view.

That must not be converted into:

“The wallet performed more than 100,000 transactions.”

For a widely known public address, a large proportion of the observable record can consist of activity toward or around the address, not activity initiated by it.

AIE therefore keeps separate counts for:

Explorer-associated records

and

Address-originated actions

Incoming noise does not become owner behavior merely because it appears on the same explorer page.


14. Raw Portfolio vs Qualified Portfolio

This case demonstrates one of the most important Wallet Insight rules.

Explorer view

Raw multichain net worth: approximately $1.13M

AIE view

That number is not automatically accepted as verified owner wealth.

AIE separates:

Confirmed native balance

Economically supported holdings

Assets with unresolved provenance

Unsolicited assets

Dust/spam assets

Unverified token valuations

Passive-network receipts

Assets requiring liquidity/market qualification

Only after qualification can these components be consolidated into an evidence-backed portfolio view.

Portfolio verdict

Raw explorer value: AVAILABLE

Raw explorer value accepted as qualified owner wealth: NO

Unsolicited/unqualified asset contamination: HIGH

Qualified aggregate value: DERIVED ONLY AFTER ASSET-PROVENANCE FILTERING


15. Risk Summary

Dimension Assessment
Multichain control CONFIRMED, SELECTIVE
Ethereum activity ACTIVE
Base activity ACTIVE
Optimism activity CONFIRMED
Arbitrum activity CONFIRMED
Additional historical network use CONFIRMED
Passive-network footprint LARGE
Unsolicited asset contamination HIGH
Raw portfolio reliability LOW WITHOUT QUALIFICATION
Delegated-account complexity ELEVATED
DeFi activity CONFIRMED
Current compromise NOT ESTABLISHED
Mixer exposure NOT ESTABLISHED IN BASE REVIEW
Illicit-owner attribution NOT ESTABLISHED
Sanctions determination NOT ISSUED IN THIS PUBLIC CASE STUDY

AIE does not substitute a single unexplained number such as:

Risk Score: 87

for these independent findings.

A decision-maker receives the actual dimensions, evidence and unresolved areas.


16. What This Case Demonstrates

A conventional explorer can show that:

  • an address appears across many networks;
  • thousands of tokens have reached it;
  • more than 100,000 records are associated with it;
  • the displayed portfolio is worth approximately $1.13M.

Wallet Insight answers different questions:

Which networks show actual control?

Which transactions were initiated by the subject?

Which assets merely arrived from third parties?

Which holdings have defensible provenance?

Which valuations can be qualified?

Which DeFi interactions are real subject behavior?

Which cross-chain relationships are actually proven?

Which events are noise, dust or unsolicited activity?

Where does the evidence stop?

That distinction is the product.


17. Beyond Wallet Insight

Wallet Insight is one entry point into the wider AIE analytical environment.

When the problem extends beyond a single wallet, additional work can cover:

Transaction Journey / Provenance

Reconstruction of the movement of assets through addresses, contracts, services and networks.

Counterparty & Entity Graph

Recurring counterparties, concentration, transaction direction, relationship structure and evidence-supported entity attribution.

Cross-Chain Journey Reconstruction

Source-chain transaction through bridge/router infrastructure to destination settlement and subsequent movement.

Dust / Spam / Poisoning Attribution

Sender infrastructure, clusters, deployers, campaign relationships and funding paths.

Approval Exposure

Network-by-network reconstruction of token, NFT and delegated execution permissions.

Mixer / Flow Investigation

Expansion of transaction provenance where obfuscation infrastructure or complex flow decomposition requires dedicated analysis.

AML / Sanctions Evidence Layer

Separate qualification against appropriate evidence sources and frozen reference states when compliance conclusions are required.

Airdrop Integrity

Independent analysis of distribution structure, wallet relationships, Sybil/coordinated behavior and reviewable evidence - the AIE service linked to this topic.

The analytical question determines the scope.

A client does not need to purchase an unnecessary investigation simply because the capability exists.


18. Who This Is For

Wallet Insight is designed for cases where a wallet address is part of an actual decision.

Examples include:

  • a protocol evaluating a wallet or counterparty;
  • a treasury before a significant transfer;
  • a fund reviewing historical wallet behavior;
  • an exchange or compliance team requiring an independent second view;
  • an investigator following assets across chains;
  • a project reviewing participants or counterparties;
  • a security team investigating suspicious inbound activity;
  • an auditor who needs blockchain evidence rather than a screenshot;
  • a user who wants to know what is actually behind an address before sending substantial funds.

The input can be as simple as:

one public wallet address + the question that needs to be answered.


19. Evidence Standard

The base result distinguishes between:

CONFIRMED

Direct evidence supports the finding.

EVIDENCE-SUPPORTED

Multiple observable facts support the conclusion, but the result remains qualified.

UNRESOLVED

Available evidence is insufficient for attribution or conclusion.

NOT ESTABLISHED

The reviewed evidence does not establish the claimed condition.

The purpose is not to fill every field.

The purpose is to avoid turning missing evidence into invented certainty.

Reproducibility classification for this public demonstration

EVIDENCE ANCHORED

This public case study does not claim full REPLAY CAPABLE status because a frozen raw RPC/reference-snapshot bundle is not being distributed with the forum post.


Final Client Verdict

Subject: 0xd8dA6BF26964aF9D7eEd9e03E53415D37aA96045

Multichain presence: CONFIRMED

Active use of every observed network: NO

Active multichain use: CONFIRMED

Large passive/inbound footprint: CONFIRMED

Raw explorer portfolio: approximately $1.13M at snapshot

Raw portfolio accepted as owner-qualified wealth: NO

Unsolicited/unqualified asset contamination: HIGH

Delegated account behavior: CONFIRMED

DeFi activity: CONFIRMED

Current compromise: NOT ESTABLISHED

Key Finding

31 networks with displayed holdings do not mean 31 actively used networks.

More than 100,000 associated records do not mean more than 100,000 owner-originated actions.

Approximately $1.13M displayed by an explorer does not automatically mean approximately $1.13M of evidence-qualified owner assets.

Inbound dust, tokens and NFTs do not become owner behavior simply because they reached the address.

AIE separates those questions and returns the evidence behind each answer.


Availability for the Arbitrum Community

AIE - Wallet Insight is available for wallet-level analysis.

Forum users, protocols, organizations and teams can submit a public wallet address together with the question they need answered.

No wallet connection is required.

No signing request is required.

No access to the wallet is required.

No private key or seed phrase is ever requested.

The base analysis remains focused on the subject wallet.

Investigations that expand into external addresses, sender infrastructure, bridge paths, counterparties, mixer/provenance analysis, approval mapping or attribution are separately scoped according to the analytical work required.


Response Time

Requests are acknowledged within minutes.

For a standard AIE - Wallet Insight, once the public wallet address and analytical scope are confirmed, the result is normally delivered on a minutes-scale.

More extensive graph reconstruction, cross-chain attribution or third-party infrastructure investigations are handled separately according to depth.

Send the public wallet address and the question you need answered.

AIE

Interesting breakdown. From a user-support perspective, it is important to remind people that receiving an unknown token or NFT does not mean they need to interact with it.

Clear network labels and simple warnings can make a big difference, especially for users managing assets across several chains.

I work with Gem Wallet, and this is useful feedback for wallet teams as well.

That point has its place, but it stops at the warning layer. Most users do not read every warning, and they should not have to become transaction analysts simply to keep their assets safe.

Warnings tell a user where danger may be. They do not prevent danger from becoming execution.

I went further. I built a protection architecture in which, under one operating rule, a protected asset cannot be stolen. Whether the initiating cause is an honest mistake or malicious control is irrelevant: the forbidden state transition cannot complete.

After your comment, I reviewed the relevant public transaction-state code paths in Gem and the current issue/patch chain. The recurring failures do not form a set of isolated UI defects. They converge on one deeper architectural break: transaction identity, origin, local semantics, polling lifetime and wallet state are not carried by one canonical transaction object under one state authority from request through final history.

An audit can identify individual manifestations, and a local patch can close each observed symptom. But when state ownership remains fragmented, every new exception adds another branch around the same unresolved boundary and makes the architecture harder to reason about as a whole.

The next step is therefore not another warning and not another isolated patch. It is one execution invariant that cannot be bypassed.

Where, in Gem’s current architecture, is the boundary that makes an unauthorized transfer impossible rather than merely warning the user before it happens?

1 Like

Thanks for taking the time to review this. I work in BD and user support, so I’m not able to confirm or discuss architecture or security findings here.

If you have a reproducible issue, affected version, and relevant code references, please send the details to security@gemwallet.com under Gem Wallet’s security policy. This allows the security team to review it responsibly.

I’ll also make sure your concern is passed on. Gem Wallet

My review of Gem’s public code, issue history, and patch sequence points to one shared architectural discontinuity, not a collection of isolated bugs. The failures surface in different places, but converge on transaction identity, provenance, state ownership, synchronization, and lifecycle. Treating them as separate tickets can close individual symptoms while leaving the common cause intact.

This is an architectural problem expressed through a chain of related failures, not a conventional isolated vulnerability. If Gem wants to examine the full dependency chain and the existing protection model, the person responsible for Gem’s architectural direction can contact directly. This requires architectural work rather than being a conventional bug-bounty submission.

1 Like