Wallet clusters and funding

EN source master · P07-L06 · 45 minutes estimated · needs_review

Learning objectives:

• Construct a funding graph from explicitly supplied successful transfers.
• Separate common-funder cohorts from shared-control hypotheses.
• Calculate gross flows and conditional ending balances without double-counting.

Funding graphs can reveal relationships that a holder table misses, but they can also create convincing false identities. A common funder might be a custody service, a faucet, a payroll account or a launch operator. The practical skill is to preserve transfer edges while treating shared-control interpretations as hypotheses with alternatives.

Define nodes and edges precisely

A funding graph starts with an observed transfer: source address/account, destination, asset, amount, event identifier, result and time context. An arrow should mean something specific, such as “successful transfer of five quote units,” not merely “these wallets look connected.” A graph with beautiful lines but unspecified edge meaning is not reproducible evidence.

In the Solana scope, transaction structures distinguish account keys, signer information, instructions and result/balance metadata [S-STRUCTURE]. Reading them supports an operational transfer reconstruction. A token account's controlling owner can be queried separately [S-OWNERS]. Neither a signer flag nor an account-owner field supplies a passport identity.

Distinguish a direct funding edge from a route with intermediaries. If F→A→B appears, it is not identical to F→B. The intermediate account may combine funds from unrelated origins or act for several users. Unless the tracing model and complete flows justify it, do not describe the final amount as the same uniquely identifiable coins.

Separate three relationship types

A funding relationship records asset movement. An operational relationship can record common signing authority or a shared program role supported by explicit data. A human-control relationship is a much stronger claim. Keep different edge styles or tables for each. Never turn all three into one generic “linked wallet” label.

Shared funding is useful for generating hypotheses. It is not enough to conclude common control. The same service can fund many independent customers. Conversely, independently funded addresses can still share a controller. Both directions show why an automated cluster membership should preserve its rule and confidence instead of claim certainty.

Declare the clustering rule before inspecting the conclusion. For example: “group addresses receiving quote units directly from the same source in the supplied window.” That rule creates a funding cohort. It does not assert a human-identity cluster. Rename the output accordingly so a downstream report does not accidentally inherit an overstated label.

Test hypotheses against alternatives

For each inferred relation, list an alternative and the evidence that would distinguish it. If three wallets receive similar amounts and trade soon after, coordinated activity is a candidate explanation. Independent customers withdrawing from a shared service is another. An indexer might also assign a source label incorrectly. The analyst should ask which observation actually discriminates among these explanations.

More of the same weak clue is not always a stronger clue. Ten transfers from a custody hub to ten customers do not become identity proof because the graph is dense. Different evidence can be more informative: explicit shared authority for a particular account, independently corroborated disclosure or a verified operational mechanism. Even these can support joint operations without identifying one individual.

Repeated timing can be described without interpreting intent. A graph can report that funding preceded a launch trade by a short observed interval. “They knew the launch in advance” is a separate claim. A latency assumption, missing history or coarse timestamp can change the apparent interval.

Bound graph coverage and tracing quantities

Every graph has a scope: network, asset set, observation window, maximum hop count, provider coverage and exclusions. A three-hop diagram with no history before its first node shows the earliest visible source in that analysis, not necessarily the ultimate origin. Include unresolved inbound paths at the boundary.

Balances and throughput differ. Adding all incoming transfers can double-count funds that move back and forth. Summing overlapping cluster flows can double-count the same amount at multiple hops. Say whether a total is gross inbound flow, net flow or end-of-window balance. A useful graph caption names both edge units and aggregation rules.

Service labels also need a status. If F is merely “declared exchange,” preserve that uncertainty. Use the transfer evidence regardless of the label, but test the interpretation with and without service classification. False entity labels can contaminate many downstream conclusions at once.

The output is a relationship report that is honest about what was seen and what was inferred. A cluster is a research device. It is not an investment signal, proof of collusion or permission to expose private identities.

• Direct edge: one supplied transfer between specified nodes.
• Funding cohort: addresses grouped by an explicit funding rule.
• Cluster hypothesis: a proposed relationship, not an identity finding.
• Boundary node: node with relevant history outside available coverage.
• Gross flow: sum of transfers without netting returns.
• Net flow: directional inflow minus outflow for the specified asset/window.

ILLUSTRATIVE EXAMPLE — FIX-P07-06. All labels, quote amounts and times are fictional. Only these supplied transfers are covered.

HUB has an uncorroborated custody-service label. No signer-sharing record, human identification or earlier HUB history is supplied. OUT is an unresolved boundary node.

OBSERVED: HUB funds all three addresses; W1 and W2 exchange one unit in each direction; W3 transfers two units to OUT.

INFERRED: W1/W2/W3 form a common-direct-funder cohort under the stated rule. This is not common-human control.

UNKNOWN: HUB's ultimate funding origin and the human controllers of W1, W2, W3 or OUT.

INSUFFICIENT EVIDENCE: Equal funding plus reciprocal transfers cannot establish a single operator, coordinated manipulation or an insider network. A custody label does not prove a customer relationship either.

Labelling a common funding source as the creator; assuming equal transfers imply one controller; colouring all hypothesis edges as observed; summing gross transfers as balances; and tracing “ultimate origin” past missing history.

Apply the direct-HUB-funding rule. Calculate HUB's gross outflow and W1/W2/W3 end-of-window balances under the explicit assumption that each starts at zero and these are the only relevant transfers, excluding fees. Compare W1's gross inflow with its ending balance. Write two alternative explanations for the cohort.

• Specify the unit and event behind each observed edge.
• Preserve network, coverage window and hop boundary.
• Separate common funding, operational roles and human identity.
• Distinguish gross/net flows and ending balances.
• Record competing explanations and unverified source labels.

A funding graph is strongest when its edge semantics, scope and uncertainties are explicit. Shared funding supports a reproducible cohort, but shared human control requires additional evidence.

Cluster by a disclosed rule. Keep hypotheses visible as hypotheses. A missing upstream path is an unknown, not proof of an ultimate origin.

Draw FIX-P07-06 as a directed funding graph with amounts/times on solid transfer edges. Keep HUB service label hatched and OUT as an unresolved boundary. Place a separate dashed hypothesis bracket around the direct-funder cohort labelled 'not human ownership'. Include gross inflow versus ending balance sidebars.

Visual delivery rules: dark navy/black, cyan/electric-blue/violet accents, units and uncertainty explicitly labelled. Use deterministic charts or SVG, not fabricated screenshots. At 390 px stack annotations and provide the data table as a text alternative; verify 768 px and desktop later. In Arabic localize labels and layout with native RTL, while isolating addresses/hashes LTR and retaining the actual direction of transfers and chronology. Use only the supplied official ZECOIN logo if branding is added. No visual asset or mobile/RTL rendering is claimed ready.

Use WALLET_INTELLIGENCE only when the exact network, asset and needed fields are supported and their provenance is visible. This is a read-only educational inspection, not a trade or a token launch. Use the supplied offline dataset if access or data is unavailable; missing information remains unknown. A future Open in ZECOIN action needs validated runtime routing and source coverage. No executable asset CTA is supplied for illustrative identifiers. Academy participation and commercial status never change Radar observations.

• Solana RPC JSON Structures — Transaction signers, instructions and balance/result metadata. Checked 2026-09-30.
• Solana getTokenAccountsByOwner — Token-account enumeration by account owner; ownership field is not human identity. Checked 2026-09-30.
• Solana getSignaturesForAddress — Newest-first referenced-address signatures and pagination parameters. Checked 2026-09-30.

The tables and exercise fixtures are original educational material unless explicitly designated HISTORICAL. Fictional identifiers are deliberately invalid as blockchain addresses. Documentation supports mechanism definitions, not the invented exercise values. Source inspection is editorial research, not a live-chain measurement. Sources may change; re-review before publication.

P07-L07; proceed after completing the exercise and reviewing each quiz explanation.