Funding source

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

“Funded by X” can mean an immediate sender, an earlier visible source, a service label or an ultimate human origin. Those are different claims. An incomplete history can support the first visible inbound event while leaving initial funds and upstream provenance unknown.

You will reconstruct a bounded funding path, distinguish native and token funding, and state missing prehistory. Common funding remains a relationship observation, not proof of a common owner.

Define funding for the question

Specify asset, target and purpose. Native units used to pay fees differ from tokens received for another activity. If a wallet receives a token but has no supplied native inflow, you cannot assume the token event explains its fee balance.

“First visible inbound native transfer” is a reproducible rule. “Original funder” is stronger: it requires prehistory and a clear definition of origin. A snapshot with an opening balance already establishes that the displayed window does not explain every unit.

Use the exact target address and any relevant token accounts. Solana owner-scoped token enumeration is filtered by mint or program [S09-OWNERS]; it supplies an account relationship, not the human behind funding. Do not merge assets simply because the same interface displays them.

Separate immediate source from upstream history

A successful direct transfer can identify the immediate source account under its decoded mechanism. It does not identify who instructed that account, whether it represents a service or where its funds ultimately came from.

A two-hop path A→HUB→W records two operations. In an account-based balance model, incoming funds may mix with earlier inventory. Showing a chronological path does not establish that the exact units received by W were uniquely those sent by A. Explain your allocation assumption if you attempt any flow attribution.

For this lesson, do not allocate particular units through the hub. Report the supplied path and its limits. A graph can be useful without pretending to track uniquely identifiable coins through fungible balances.

Distinguish event mechanisms

A token transfer, token mint, reward, refund and bridge-related operation can each change inventory. They are not interchangeable source edges. A decoded bridge-mint operation can identify a local mechanism without identifying the original cross-chain depositor.

A return transfer should not be named a refund solely because it follows an earlier outgoing transfer. The label requires mechanism or contextual evidence. Similarly, a payment from a labelled exchange address is a payment from that address plus an unverified label until provenance supports the service claim.

Instructions and result metadata provide the mechanism views used for such inspection [S09-STRUCTURES]. Documentation explains field interpretation; it does not authenticate a provider's economic labels or invented exercise records.

Record coverage before choosing the earliest event

Solana signature history is newest-first and paginated [S09-SIGNATURES]. The oldest item on one returned page is only the oldest item on that page. Search scope, pagination and provider retention determine what earlier activity could be missing.

Retrieve success and amounts separately from the discovery list. A null transaction result at the requested commitment is unavailable evidence [S09-TRANSACTION]. Do not place a guessed amount or sender on the funding graph just to connect a gap.

Pin the observation window. When initial balance is supplied but its origin is not, draw a labelled prehistory gap instead of treating the first later transfer as account creation. The earliest visible funding event is not necessarily the account's true first funding.

Reconcile a bounded balance

For a complete declared window, ending balance equals opening balance plus successful inbound movements minus successful outbound movements and applicable costs. State which costs are included. The fixture explicitly sets native fees and other effects to zero for this simplified model.

Gross inbound, gross outbound and net change remain separate. A wallet receiving6 and sending5 has net increase1. It did not “receive only1,” and it did not gain6 after ignoring its outgoing activity.

Reconciliation supports the accounting explanation within the window. It cannot establish motives, legitimacy or economic ownership of the opening balance. If the records are not complete, preserve an unexplained delta rather than assigning it to a guessed upstream account.

Interpret common source without merging people

If HUB sends to several addresses, the observed relationship is common immediate funding. Possible explanations include one operator, a shared service, public distribution or unrelated withdrawals. The mere existence of alternatives does not prove any one; it prevents one explanation from becoming exclusive proof.

A provider label might help formulate a next check. Capture its publisher, evidence basis and scope. Multiple interfaces copying the same label do not add independent identity evidence. Do not create a person node based on a common source.

Write the claim at its supported level

Prefer “F1 is the first successful native inbound event visible within SIM-DAY5–8; opening 3 units have unknown provenance” to “HUB created W.” The narrow sentence remains useful and testable.

If the target is a funding mechanism rather than an identity, ask for transaction result, decoded transfer path and matching balances. If the target is an upstream association, additional source/control evidence is needed. A funding path does not issue a BUY/SELL signal or establish market causality.

• Immediate source: account directly supplying a decoded movement.
• Upstream source: earlier point in an observed path.
• Opening balance: inventory at the window's start.
• Prehistory gap: unavailable records before the window.
• Funding mechanism: transfer, mint or another specified operation.
• Allocation assumption: rule for tracing fungible quantities through mixed inventory.

ILLUSTRATIVE — FIX-P09-03. SIM-CHAIN-A / W. SIM-DAY numbers are invented calendar-day offsets. Complete native effects in SIM-DAY5–8; opening 3 NATIVE units, zero fees/other effects in this model.

F0 is a supplied upstream record outside the target window, not complete HUB history. F5 is a separate asset; source-chain deposit linkage is absent. A provider labels HUB “exchange,” with no authentication.

OBSERVED in fixture: F1 supplies5 native units directly from HUB; F3 returns1 from B; F5 supplies a local mint operation.

INFERRED: Within the native window, inbound 6, outbound 5, net+1 and ending 4. F1 is first visible inbound native event in that window.

UNKNOWN: Origin of opening 3, upstream humans, HUB service identity and F5's original depositor.

INSUFFICIENT EVIDENCE: F0/F1 do not uniquely allocate A's50 to W. F3's order cannot prove refund semantics. HUB common funding cannot establish shared human ownership.

Calling the oldest returned row true first funding; ignoring opening inventory; adding bridge tokens to native units; allocating fungible hub units without assumptions; and adopting provider source labels as identity proof.

Draw the supplied native path with a prehistory gap, compute W's window reconciliation and identify its first visible native source. Classify the refund, exchange and original bridge-depositor claims.

• Define target asset and funding rule.
• Separate immediate and upstream observations.
• Preserve opening-balance provenance gaps.
• Verify successful mechanism, not just labels.
• Reconcile gross and net within coverage.
• Never merge owners from common funding.

Funding analysis reconstructs available paths and quantities. Its strongest honest conclusion may be a first visible source with explicit prehistory gaps.

Immediate source is not ultimate origin. A path is not unique allocation through a hub. Common funding and provider labels do not prove identity.

Directed native graph F0–F4 with quantities and day offsets; mark unknown HUB prehistory and W opening 3. Put bridge mintF5 in separate asset lane with missing source-chain edge. Reconciliation panel6 in/5 out/net+1/end4; provider labels dashed.

Illustrative funding path; shared sources do not establish ownership.

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 getSignaturesForAddress — Referenced-address signature history, newest-first order and pagination. Checked 2026-09-30.
• Solana getTransaction — Transaction lookup, commitment and nullable data/time fields. Checked 2026-09-30.
• Solana RPC JSON Structures — Result metadata, fee, instructions and balances as distinct views. Checked 2026-09-30.
• Solana getTokenAccountsByOwner — Owner-scoped holdings enumeration with mint/program filters. 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-L04 after the worked exercise and question review.