Attribution limits and evidence reporting

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

A wallet report can contain accurate transfers and still make unsupported claims about a person, affiliation or market intent. The final skill is preserving an evidence chain while keeping facts, calculations, hypotheses and unknowns distinct.

You will produce a bounded wallet report from a partial dataset. This is separate from P08's asset-control report: the focus here is account activity, relationships, coverage and attribution limits. No personal identity, trading instruction or certificate is issued.

State scope before interpretation

Name network, full target address, relevant asset, time/context cutoff and investigation question. A question such as “what activity and relationships are supplied for W?” is answerable. “Who is W and what will it trade next?” requires evidence the dataset does not provide.

Declare the observation unit. An address is not a person; an authority relationship is not beneficial ownership. The report should not silently switch from address movement to human conduct in its conclusion.

Record as-of state separately from source capture and report-generation time. A later report can describe earlier activity, but later knowledge cannot be treated as available beforehand. Synthetic example times remain explicitly synthetic.

Build the evidence register

Give every row a locator, source, exact object, context, result, amount/units and limitation. Include unverified labels as source assertions, not ledger facts about an entity. Documentation explains parsing; it does not authenticate these labels.

Solana transaction lookup can be unavailable at a requested commitment, with nullable event-time metadata [S09-TRANSACTION]. Missing records remain unresolved. Signature history is paginated and newest-first [S09-SIGNATURES], so the oldest returned event does not establish complete origin.

Tie calculations to their inputs. A before/after balance difference and a transfer record are different views; agreement is a reconciliation check, not necessarily an independent provider. State when several fields share one export.

Use all four evidence states

OBSERVED describes an inspectable record under declared scope. For this exercise it means a supplied fictional row. INFERRED describes explicit reasoning, such as a percentage or plausible mechanism. UNKNOWN marks unavailable information. INSUFFICIENT EVIDENCE classifies a proposed claim that existing observations cannot establish.

An identity claim can be insufficiently supported while transfers remain observed. A common-source pattern can be inferred without supporting common ownership. Do not combine these states into one identity confidence score.

Specify the tested proposition: “X is an authenticated project treasury” is stronger than “Feed-L labels X treasury.” The latter is observed as a provider assertion. The former needs independent corroboration. Both can appear in a report with different classifications.

Separate control from identity

A signature or authorization record can support a particular control action under its mechanism and context. It does not independently establish the human's legal identity, continuous ownership or beneficial interest. Contract or delegated activity adds further authorization layers [S09-ETHACCOUNTS; S09-DELEGATION].

A future attribution investigation would need appropriately authenticated, scope-matched evidence for the association being tested. A public declaration, cryptographic control demonstration and corroborated organizational identity answer different questions; none should be substituted for all the others.

This exercise requests no signature from the learner or anyone else. Do not ask for seeds, private keys or account connection. The required result is a read-only analysis of supplied material with identities unresolved.

Preserve conflicting labels and coverage

If two interfaces copy the same label feed, their agreement is one upstream assertion. If another feed disagrees, retain the conflict. Do not choose the label that best supports a dramatic narrative or invent a confidence percentage.

An interval with missing records is unknown activity, not inactivity. An oldest visible record gives an observed-since interval within the query, not actual creation time. A source may cover one address but omit related token-account events.

A partial transfer table cannot establish a complete trading history. Even a correct observed balance change does not establish why funds moved. Keep a missing-record list alongside successful and failed events.

Reconcile what is actually supplied

Normalize amounts and compare coherent contexts. Owner-scoped token accounts can support a holdings view under a mint/program filter [S09-OWNERS]; they do not supply every person's assets.

If the supplied token snapshots differ by 4000 and one successful transfer is 4000, report numerical consistency. If history is partial, do not claim that you ruled out every other mechanism. Failed attempts do not become successful outflows just because they appear beside them.

Do not combine token movement with a native fee. Fee payer may differ from the target. A sponsored operation does not prove the sponsor is the user's owner or employer. A source-labeled service interaction does not establish affiliation.

Write findings with propositions and limits

Each finding should contain a narrow proposition, record pointers, data status, context and boundary. A report may say “R4's returned balance is 6000; complete holdings coverage is not established.” This is more defensible than “W has only6000 assets left.”

Use neutral language for hypotheses and give alternatives. Receiving from HUB can be consistent with common control or a shared service; supplied records may not distinguish them. Do not turn compatibility into a verdict.

A transfer to X and a later market move do not establish a BUY/SELL signal or causal effect. State this directly when correcting the proposed headline. Labels, wealth, social visibility and commercial relationships cannot improve evidence.

Make next checks targeted

Request complete paginated scope, related-account coverage, matching transaction decoding and label provenance. For a specific control hypothesis, ask for evidence that would distinguish it from alternatives. Each request should explain which uncertainty it addresses.

Mark report contentVersion and needs_review truthfully. Editorial review status is not an identity or risk judgment on W. A future Passport or Wallet Intelligence screen needs its own runtime verification; this lesson does not claim live monitoring, exported artifacts or provider completeness.

• Attribution: supported association between action/account and actor.
• Control evidence: proof relevant to a specified authorization action.
• Proposition: exact claim being tested.
• Source dependency: shared upstream evidence between displays.
• Coverage boundary: what a dataset includes and omits.
• Evidence register: reproducible record list behind findings.

ILLUSTRATIVE — FIX-P09-08. SIM-CHAIN-A / W / MINT-R, supply 1,000,000 normalized tokens. Synthetic day offsets and capture markers only. Partial query covers days 12–30 with gap[16,18); related-account completeness unknown. Analysis day30.

No trade execution, creation record, authenticated entity declaration, complete native reconciliation or market-cause evidence is supplied.

OBSERVED in fixture: R1–R5 supply activity/results and returned balances; R6–R8 supply conflicting/dependent labels.

INFERRED: Returned token delta−4000 is consistent with R3; balance share 1%→0.6%. First returned inbound is 18 synthetic days before analysis.

UNKNOWN: Human identity, actual creation, missing activity, complete holdings, X's entity and native balance history.

INSUFFICIENT EVIDENCE: Treasury affiliation, shared human ownership, completed sale and market causality are not established. R6/R7 are not independent confirmations.

Turning returned balances into all assets; reporting first seen as birth; converting provider assertions into identity; adding failed transfers; naming a sponsor employer; and writing financial or causal conclusions from movements.

Write a report with scope, evidence register, four-state findings, limitations and three next checks. Correct: “W is a 18-day-old person-owned trader, funded by its employer, who sold5000 to the project treasury.”

• Name network, target, asset and cutoff.
• Attach source/context/result to every claim.
• Keep labels and human associations separate.
• Publish gaps and provider dependencies.
• Reconcile successful effects without double counting.
• Retain OBSERVED/INFERRED/UNKNOWN/INSUFFICIENT EVIDENCE.
• End with evidence requests, not trading or identity verdicts.

A wallet report is an evidence chain with bounded claims. It can establish activity and quantities while leaving identity, affiliation and intent unresolved.

Address control is not personal identity. Common funding and interaction do not prove ownership or affiliation. Missing data, transfer chronology and labels cannot supply market signals or causal conclusions.

Evidence register R1–R8 with source/context and shared Export-A/Feed-L brackets. Four-state panel bound to claims; gap[16,18) UNKNOWN; successful 4000 separate from failed1000 and native 0.01. First-returned interval 18 explicitly synthetic, no human node.

Illustrative wallet report; attribution, trade purpose and affiliation unresolved.

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 getTokenAccountsByOwner — Owner-scoped holdings enumeration with mint/program filters. 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 is complete. Review the claim-by-claim wallet report, then return to the Academy dashboard. Separate labs retain their listed prerequisites.