Wallet anatomy

EN source master · P09-L01 · 45 minutes estimated · needs_review

A wallet page can combine an address, several token accounts, contract calls and provider labels into one screen. That convenience does not make them one ledger object or one person. Before reading history, define what the page actually represents.

You will map account roles and reconcile supplied holdings without attributing identity. This is the entry skill for the program: every later funding, age and relationship claim depends on choosing the correct observation unit.

Separate the interface from the object

A wallet application is an interface, while an account is a ledger object; Ethereum documentation makes this distinction explicitly [S09-ETHACCOUNTS]. One interface can display multiple accounts and networks. One account can be accessible through multiple interfaces. Neither relationship identifies a unique human.

Use network plus full address as the starting identifier. A shortened label cannot establish equality. The same displayed text on different chains is not a shared accounting object. A provider's “wallet” grouping may include inferred relationships; inspect its definition before treating it as an owner total.

In real work validate address encoding and record the selected network. The exercise deliberately uses invalid labels, so comparisons are educational only and no transaction can target these identifiers.

Identify the account's role

Solana accounts store state at addresses and have a program-owner field [S09-ACCOUNTS]. That field is not a human identity. A token account separately records its mint and owner authority [S09-TOKENS]. Do not read the Token Program's base ownership as meaning that program is the beneficiary of every token balance.

An authority can own multiple token accounts for one mint. Aggregate only exact mint, matching context and supported authority fields. A native balance and a token balance are different units. Never add them as if they were one asset or convert to dollars without an explicit valuation source.

Record whether an address names a program, a token account, a mint or another state account. The same relationship graph can contain all these node types. A graph showing five nodes does not show five wallets, much less five people.

Understand program-controlled activity

Solana program-derived addresses (PDAs) are derived from a program ID and seeds and have no private key; the deriving program can sign for them through the runtime mechanism [S09-PDA]. Derivation alone is not a claim that an account is already allocated at that address. Verify both the address relationship and the relevant account state.

Program signing and human signing should not be collapsed into one field. A program-mediated authority may serve many users. Its application rules determine what requests cause it to act; a PDA label cannot establish an individual user or unrestricted control.

On EVM networks distinguish ordinary key control, contract logic and supported delegation mechanisms. An externally owned account (EOA) is controlled by a private key; supported delegation can determine the code it executes. EIP-7702 permits code delegation for EOAs on supporting networks [S09-DELEGATION]. Consequently, code presence alone is not a universal “this cannot be an EOA” rule. Inspect network rules and account state at the requested context.

A code-bearing account can execute instructions without proving which human benefits. A multisig contract may represent several signing accounts, but counting signers does not prove independent people. Keep control mechanism and human attribution separate.

Build a role map before an ownership map

Use node type, exact identifier, network, context and evidence locator. Use edges such as token-account-owner, mint-reference, program-derivation and code-delegation. These edges have specific meanings. A generic “related to” edge hides why nodes are linked.

Do not turn every edge into common ownership. Mint-reference connects all holders of an asset without making them one controller. Program-derivation connects an address to a mechanism, not necessarily to the program operator's personal inventory.

Provider labels belong in a separate annotation with provenance and verification status. “Custody service” might be a useful lead, but the label's publisher, update date and basis need inspection. Record it as a provider assertion until sufficiently corroborated.

Reconcile the supplied holdings

The fixture gives an exhaustive set of token accounts for authority W and one target mint at S0. That completeness is an exercise assumption, not a capability claimed for Wallet Intelligence. Sum the two valid account balances only after confirming their owner and mint.

A third account holding the same mint under a program-derived authority is not W's holding simply because it appears on the same application screen. A holding under a different mint cannot enter the target total. Native units remain separate.

If real records are partial, report a returned balance total and coverage limitation. Do not silently promote it to “all holdings.” A failed query is unavailable evidence, not zero inventory. A zero supplied amount is a measurement under its stated scope.

State the limits constructively

A good anatomy finding can say “W is the supplied authority for T1/T2 holding MINT-A; P1 is a separate program-mediated authority. Human control is unknown.” It answers the account question without solving an unsupported identity question.

The next evidence request should match the gap: complete owner/mint enumeration for missing holdings, derivation/state records for a PDA classification, and application authorization for mediated control. A request for a person's name does not substitute for these technical checks.

No account role produces a BUY/SELL signal. Having a contract, PDA or token account tells you how observations are organized. It does not establish legitimacy, intent or future market behavior.

• Address: network-scoped identifier.
• Account: state object at an address.
• Wallet interface: application displaying or interacting with accounts.
• Owner authority: field governing a specified token account.
• PDA: program-derived address with runtime signing.
• Delegation: account execution relationship, not personal affiliation.

ILLUSTRATIVE — FIX-P09-01. SIM-SOL-A at fictional S0; balances already normalized. Target authority W, target mint MINT-A. T1/T2 are stipulated exhaustive for W/MINT-A.

A 7 is a separate network example. No identity, valuation, signature threshold or application authorization records are supplied.

OBSERVED in fixture: W is owner authority for T1/T2; P1 is a distinct program-derived authority for T4. The provider publishes A 8.

INFERRED: W's supplied MINT-A holdings total 200 tokens. Its native 2 and MINT-B50 are separate quantities.

UNKNOWN: Human identity behind W/P1/E1, application-control rules and beneficial ownership.

INSUFFICIENT EVIDENCE: A 8 cannot establish Alice's identity. The shared mint cannot merge W and P1. Code delegation does not establish affiliation with LOGIC-D's publisher.

Treating a wallet UI as one person; confusing base program owner with token owner authority; adding different units; merging same-mint holders; and applying obsolete code/no-code classification without network context.

Draw a typed role map from A 1–A 7. Calculate W's target holdings. Classify A 8 and explain why T4 must stay outside W's total. Identify two missing checks for program-controlled activity.

• Select exact network and observation unit.
• Type every node and relationship.
• Keep native and mint balances separate.
• Aggregate only supported owner fields.
• Distinguish program/key/delegated control.
• Preserve labels as assertions until corroborated.

Wallet anatomy is a map of ledger objects and control mechanisms. It establishes what to inspect, without equating addresses with people.

An interface is not an account or a person. Typed relationships prevent false aggregation. Provider labels and code behavior do not prove identity.

Draw typed W,T1,T2,T3,P1,T4 and mint nodes with labelled authority/mint/derivation edges. Highlight target200 only. Isolate native and MINT-B units and separate EVM delegation. Put A 8 in unverified-label annotation.

Illustrative account anatomy; graph nodes are not people.

Use deterministic SVG/HTML or charts with units, evidence locators and text alternatives. Navy/black with restrained cyan, electric blue and violet; no decorative or fabricated explorer screenshots. At 390px stack annotations; verify 768px, desktop and Arabic RTL when assets are implemented. Keep identifiers LTR and factual time/edge/axis directions unchanged. Use only the official supplied ZECOIN mark. Both visual records remain specifications.

WALLET_INTELLIGENCE maps to read-only inspection of public address records, relationships and provenance. Verify supported network, exact identifiers, fields and coverage before any runtime integration; no live provider capability is claimed here. Use the embedded offline exercise if data or paid access is unavailable. No wallet connection, credentials, private key, signature or live trade is required. Missing data stays unknown. Academy progress, creator status, payments and referrals never alter Radar evidence.

• Solana Accounts — Addressed state and program-owner field. Checked 2026-09-30.
• Solana Assets — Mint, token account and owner-authority distinctions. Checked 2026-09-30.
• Solana Program Derived Addresses — Program-derived addresses and program signing; no PDA private key. Checked 2026-09-30.
• Ethereum accounts — Account/interface distinction and account types. Checked 2026-09-30.
• EIP-7702 Set Code for EOAs — EOA code delegation; code presence alone is not a universal EOA classification rule. Checked 2026-09-30.

All example records are original ILLUSTRATIVE fixtures, not historical/live chain measurements. Documentation explains mechanisms, not invented amounts or labels. Synthetic chronology is explicitly bounded; observedAt=null is intentional. OBSERVED in an exercise means a supplied fixture record. Re-review documentation and deployed decoding before publication. Provider labels do not establish identity; address control and human attribution require distinct evidence.

P09-L02 after the worked exercise and question review.