Counterparties

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

A wallet can call a router, send tokens to a custody address and receive an unsolicited transfer. A graph may display all three as counterparties, although they represent different relationships. Describing them as partners or affiliates invents a meaning the ledger does not provide.

This lesson builds a typed counterparty table and a separate provider-label register. You will distinguish technical interactions, successful movements and unverified entity claims.

Define a counterparty by event type

For a direct value transfer, the decoded source and destination are the movement endpoints. For a contract call, the called address is an execution endpoint. For a token log, the emitting contract and the from/to fields have different roles. Specify which relationship you are measuring.

A counterparty list without a rule cannot be compared reproducibly. “Unique transfer recipients” differs from “all contracts called.” A transaction might contain both categories. Do not combine them into one count and call it number of business relationships.

Asset identity and network remain necessary. A transfer of TOKEN-A and a transfer of TOKEN-B are separate quantities even when the recipient is the same. A zero-value call can establish execution interaction without establishing a native payment.

Read nested execution carefully

Geth callTracer represents call frames and can be configured to include only the top call [S09-TRACES]. An incomplete trace configuration can omit nested interactions. Record whether your source covers the relevant depth rather than assuming a top-level receiver is the only execution endpoint.

A router can delegate or route activity through other contracts. The account the user called may not be the account receiving an eventual token movement. An interaction graph should retain both edges with distinct types instead of pretending they are duplicates or equivalent economic relationships.

Ethereum receipt logs carry transaction linkage and event information [S09-RECEIPT]. Decoding an event requires the correct emitter and semantics. A contract emitting a token Transfer event is not thereby the purchaser, recipient or affiliate of every address named in that event.

Distinguish involvement from voluntary relationship

On Solana, a signature search finds transactions referencing an address in accountKeys [S09-SIGNATURES]. Reference alone does not mean the address authorized the transaction. Inspect signers, instructions and effects before assigning an active role.

An inbound transfer can be unsolicited. Mere receipt does not prove consent, membership or partnership. Even repeated direct interaction can be consistent with ordinary use of a public service rather than affiliation.

A contract-mediated transfer might involve a delegate or an application policy. Do not conclude that the visible holder personally signed every movement. Result metadata separates account roles and execution views [S09-STRUCTURES]; human intent requires additional evidence.

Store labels as source assertions

A provider label should have publisher, exact address/network, capture/update context, wording, basis and verification state. If those fields are absent, say so. “Exchange-X” displayed beside an address is not an independently established entity identity.

Two interfaces using the same underlying label feed do not provide two independent confirmations. Label agreement can motivate investigation while its dependency remains explicit. If sources conflict, retain both labels and the conflict.

A verified service deposit mechanism, when actually established, would still not identify the account's beneficial user or prove that a transfer was a sale. Technical affiliation, service custody and personal identity are separate questions.

Count the intended unit

Use unique successful event keys for movement counts. Use unique endpoint addresses for a recipient count within a stated asset/window. Repeated sends to one address count as multiple events but one unique recipient.

Exclude failed attempts from successful-flow totals while retaining them in an attempt table. Do not erase them from the investigation. If result is unavailable, keep it unresolved; neither success nor failure may be inferred from a pretty interface row.

For a direction-based report, distinguish incoming and outgoing edges. Receiving from a contract is not equivalent to calling it. A round trip does not prove ownership or refund purpose without supporting mechanism evidence.

State what would strengthen the claim

For a technical role, request decoded operations, correct code/application binary interface (ABI), trace coverage and coherent balances. For a provider identity, request the labeling basis and independent corroboration. For an affiliation claim, specify what organizational or authenticated evidence would be necessary.

Do not search for personal identity merely because a public address is interesting. Keep the question proportionate to the educational objective. This exercise contains no real people or usable addresses and requires no attribution investigation beyond supplied records.

A bounded finding such as “W made two successful TOKEN-A sends to X; X is labelled Exchange-X by one shared feed, unverified here” is informative. It does not imply a sale, a partnership or a common owner.

Keep causal and financial boundaries

Interaction does not establish affiliation. A large transfer to a labelled service does not establish a market trade. A chart moving afterward does not establish that the transfer caused it. These later conclusions require separate evidence and cannot be recovered from a counterparty count.

The purpose of the lesson is an accurate relationship vocabulary. More edges are not necessarily stronger evidence of a human relationship. Sometimes several lines simply expose more internal machinery for one public transaction.

• Execution endpoint: address called during execution.
• Movement endpoint: source or destination of a decoded asset transfer.
• Emitter: contract producing an event log.
• Unique recipient: distinct destination under a declared rule.
• Provider assertion: published label awaiting scope/provenance assessment.
• Affiliation: organizational relationship needing independent evidence.

ILLUSTRATIVE — FIX-P09-04. SIM-EVM-A, W, synthetic ordered T1–T4. TOKEN-A amounts normalized. All listed results are supplied, not measured.

No sale record, organizational affiliation or human-control evidence is supplied. Labels have synthetic capture T5; no real timestamp exists.

OBSERVED in fixture: W calls ROUTER; nested POOL interaction and two TOKEN-A sends to X are supplied. L1/L2 share a label source; L3 conflicts.

INFERRED: Successful outbound TOKEN-A total 15, with one unique successful recipient X under this window/rule. C6 adds an attempted recipient Y, not successful flow.

UNKNOWN: Entity behind X, receipt consent for C5, motives and beneficial owners.

INSUFFICIENT EVIDENCE: ROUTER/POOL interactions do not prove affiliation. L1/L2 are not independent identity proof; L3 does not resolve the conflict. X receipt does not establish a sale.

Counting emitter as recipient; treating router calls as partnerships; merging nested and direct endpoints without types; adopting copied labels as independent confirmation; and interpreting unsolicited receipt as voluntary membership.

Produce a typed relationship table and successful TOKEN-A outbound statistic. Separate entity-label assertions from ledger records. Rewrite “W sold15 to its Exchange-X affiliate and received a partner payment.”

• Define relationship and counting rules.
• Separate caller, nested endpoint, emitter and recipient.
• Verify result and trace coverage.
• Record labels with source dependencies.
• Preserve unsolicited/unknown-intent possibilities.
• Avoid affiliation, sale and identity conclusions without evidence.

Counterparty analysis describes specific interactions. Technical participation and labelled entities do not automatically establish economic or organizational relationships.

Interaction is not affiliation. Repeated recipients differ from repeated events. Provider labels are assertions with provenance and conflicts.

Use distinct call and transfer edge styles with record IDs; TOKEN-A emitter separate. Mark C6 failed, C5 consent unknown. Display X labels in source register with L1/L2 shared-feed bracket and L3 conflict, no identity badge.

Illustrative counterparty types; interaction does not prove affiliation.

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.

• Geth Built-in Tracers — Call-frame trace scope and tracer-specific configuration. Checked 2026-09-30.
• Ethereum Execution APIs eth_getTransactionReceipt — Receipt status, transaction linkage and logs. Checked 2026-09-30.
• Solana getSignaturesForAddress — Referenced-address signature history, newest-first order and pagination. Checked 2026-09-30.
• Solana RPC JSON Structures — Result metadata, fee, instructions and balances as distinct views. 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-L05 after the worked exercise and question review.