Contreparties

Source maître EN · P09-L04 · 45 minutes estimées · needs_review

Un portefeuille peut appeler un routeur, envoyer des jetons à une adresse de garde et recevoir un transfert non sollicité. Un graphe peut afficher les trois comme contreparties, bien qu’ils représentent des relations différentes. Les décrire comme partenaires ou affiliés invente un sens absent du registre.

Cette leçon construit un tableau typé des contreparties et un registre séparé d’étiquettes de fournisseur. Vous distinguerez interactions techniques, mouvements réussis et affirmations d’entité non vérifiées.

Définir une contrepartie par type d’événement

Pour un transfert direct de valeur, source et destination décodées sont les points de mouvement. Pour un appel de contrat, l’adresse appelée est un point d’exécution. Pour un journal de jeton, le contrat émetteur et les champs from/to ont des rôles différents. Préciser la relation mesurée.

Une liste de contreparties sans règle ne permet pas de comparaison reproductible. « Destinataires de transfert uniques » diffère de « tous les contrats appelés ». Une transaction peut contenir les deux catégories. Ne pas les réunir en un compte unique nommé nombre de relations commerciales.

Identité de l’actif et réseau restent nécessaires. Un transfert TOKEN-A et un transfert TOKEN-B sont des quantités séparées même avec le même destinataire. Un appel de valeur nulle peut établir une interaction d’exécution sans paiement natif.

Lire prudemment l’exécution imbriquée

Le callTracer de Geth représente les cadres d’appel et peut être configuré pour n’inclure que l’appel principal [S09-TRACES]. Une configuration de trace incomplète peut omettre les interactions imbriquées. Consigner si la source couvre la profondeur pertinente au lieu de supposer que le destinataire principal est le seul point d’exécution.

Un routeur peut déléguer ou acheminer l’activité par d’autres contrats. Le compte appelé par l’utilisateur n’est pas forcément celui recevant un mouvement final de jetons. Un graphe d’interaction doit conserver les deux arêtes avec types distincts au lieu de les présenter comme doublons ou relations économiques équivalentes.

Les journaux des reçus Ethereum portent le rattachement à la transaction et les informations d’événement [S09-RECEIPT]. Décoder un événement nécessite l’émetteur et la sémantique corrects. Un contrat émettant un événement Transfer de jetons n’est pas pour autant l’acheteur, le destinataire ou l’affilié de toutes les adresses citées.

Distinguer présence et relation volontaire

Sur Solana, une recherche de signatures trouve des transactions référençant une adresse dans accountKeys [S09-SIGNATURES]. La référence seule ne signifie pas que l’adresse a autorisé la transaction. Examiner signataires, instructions et effets avant d’attribuer un rôle actif.

Un transfert entrant peut être non sollicité. La seule réception ne prouve ni consentement, ni appartenance, ni partenariat. Même une interaction directe répétée peut correspondre à l’utilisation ordinaire d’un service public plutôt qu’à une affiliation.

Un transfert médié par contrat peut impliquer un délégué ou une politique d’application. Ne pas conclure que le détenteur visible a personnellement signé chaque mouvement. Les métadonnées de résultat séparent rôles des comptes et vues d’exécution [S09-STRUCTURES] ; l’intention humaine nécessite des preuves supplémentaires.

Stocker les étiquettes comme affirmations de source

Une étiquette de fournisseur doit avoir un éditeur, une adresse/un réseau exacts, un contexte de capture/mise à jour, une formulation, un fondement et un état de vérification. Signaler les champs absents. « Exchange-X » affiché à côté d’une adresse n’est pas une identité d’entité établie indépendamment.

Deux interfaces utilisant le même flux d’étiquettes sous-jacent ne fournissent pas deux confirmations indépendantes. Leur accord peut motiver une investigation en gardant explicite la dépendance. Si les sources se contredisent, conserver les deux étiquettes et leur conflit.

Même un mécanisme vérifié de dépôt auprès d’un service, lorsqu’il est réellement établi, n’identifierait pas l’utilisateur bénéficiaire du compte ni ne prouverait qu’un transfert était une vente. Affiliation technique, garde par un service et identité personnelle sont des questions séparées.

Compter l’unité visée

Utiliser des clés d’événements réussis uniques pour compter les mouvements. Utiliser des adresses de destination uniques pour compter les destinataires dans un actif/une fenêtre annoncés. Les envois répétés à une adresse comptent plusieurs événements, mais un seul destinataire unique.

Exclure les tentatives échouées des totaux de flux réussis en les gardant dans un tableau de tentatives. Ne pas les effacer de l’investigation. Si le résultat est indisponible, le garder non résolu ; une belle ligne d’interface ne permet de déduire ni réussite ni échec.

Dans un rapport par sens, distinguer arêtes entrantes et sortantes. Recevoir d’un contrat n’équivaut pas à l’appeler. Un aller-retour ne prouve ni propriété ni remboursement sans preuve de mécanisme à l’appui.

Préciser ce qui renforcerait l’affirmation

Pour un rôle technique, demander opérations décodées, code/interface binaire d’application (ABI) corrects, couverture des traces et soldes cohérents. Pour une identité de fournisseur, demander le fondement d’étiquetage et une corroboration indépendante. Pour une affiliation, préciser les preuves organisationnelles ou authentifiées nécessaires.

Ne pas rechercher une identité personnelle simplement parce qu’une adresse publique est intéressante. Garder la question proportionnée à l’objectif pédagogique. Cet exercice ne contient ni personnes réelles ni adresses utilisables et n’exige aucune investigation d’attribution au-delà des enregistrements fournis.

Un constat délimité comme « W a effectué deux envois TOKEN-A réussis vers X ; X est étiqueté Exchange-X par un flux partagé unique, non vérifié ici » est informatif. Il n’implique ni vente, ni partenariat, ni propriétaire commun.

Garder les limites causales et financières

Une interaction n’établit pas une affiliation. Un gros transfert vers un service étiqueté n’établit pas une opération de marché. Un graphique qui bouge ensuite n’établit pas que le transfert l’a causé. Ces conclusions nécessitent des preuves distinctes et ne se déduisent pas d’un nombre de contreparties.

Le but de la leçon est un vocabulaire exact des relations. Plus d’arêtes ne signifient pas forcément des preuves plus fortes d’une relation humaine. Parfois, plusieurs lignes révèlent simplement davantage de mécanismes internes d’une transaction publique unique.

• Point d’exécution : adresse appelée pendant l’exécution.
• Point de mouvement : source ou destination d’un transfert d’actif décodé.
• Émetteur : contrat produisant un journal d’événement.
• Destinataire unique : destination distincte selon une règle déclarée.
• Affirmation de fournisseur : étiquette publiée en attente d’évaluation du périmètre/de la provenance.
• Affiliation : relation organisationnelle nécessitant des preuves indépendantes.

ILLUSTRATIVE — FIX-P09-04. SIM-EVM-A, W, ordre synthétique T1–T4. Montants TOKEN-A normalisés. Tous les résultats listés sont fournis, pas mesurés.

Aucun enregistrement de vente, affiliation organisationnelle ou preuve de contrôle humain n’est fourni. Les étiquettes ont une capture synthétique T5 ; aucun horodatage réel n’existe.

OBSERVED dans le jeu : W appelle ROUTER ; interaction imbriquée POOL et deux envois TOKEN-A à X fournis. L1/L2 partagent une source d’étiquette ; L3 est en conflit.

INFERRED : total sortant TOKEN-A réussi 15, avec un destinataire réussi unique X dans cette fenêtre/selon cette règle. C6 ajoute un destinataire tenté Y, pas un flux réussi.

UNKNOWN : entité derrière X, consentement à la réception C5, motivations et propriétaires bénéficiaires.

INSUFFICIENT EVIDENCE : les interactions ROUTER/POOL ne prouvent pas d’affiliation. L1/L2 ne sont pas des preuves indépendantes d’identité ; L3 ne résout pas le conflit. La réception par X n’établit pas une vente.

Compter l’émetteur comme destinataire ; traiter les appels de routeur comme partenariats ; fusionner points imbriqués et directs sans types ; adopter des étiquettes copiées comme confirmations indépendantes ; interpréter une réception non sollicitée comme appartenance volontaire.

Produire un tableau typé de relations et une statistique des sorties TOKEN-A réussies. Séparer affirmations d’étiquette d’entité et enregistrements du registre. Réécrire « W a vendu15 à son affilié Exchange-X et reçu un paiement de partenaire ».

• Définir les règles de relation et de comptage.
• Séparer appelant, point imbriqué, émetteur et destinataire.
• Vérifier résultat et couverture des traces.
• Consigner les étiquettes avec dépendances de source.
• Préserver les possibilités de transfert non sollicité/d’intention inconnue.
• Éviter conclusions d’affiliation, de vente et d’identité sans preuve.

L’analyse des contreparties décrit des interactions précises. Participation technique et entités étiquetées n’établissent pas automatiquement de relations économiques ou organisationnelles.

L’interaction n’est pas l’affiliation. Les destinataires répétés diffèrent des événements répétés. Les étiquettes de fournisseur sont des affirmations avec provenance et conflits.

Employer des styles d’arêtes distincts pour appels et transferts avec identifiants d’enregistrement ; séparer l’émetteur TOKEN-A. Marquer C6 échoué, consentement C5 inconnu. Afficher les étiquettes X dans un registre de sources avec accolade de flux partagé L1/L2 et conflit L3, sans badge d’identité.

Types de contreparties illustratifs ; l’interaction ne prouve pas l’affiliation.

Utiliser du SVG/HTML déterministe ou des graphiques avec unités, repères de preuve et alternatives textuelles. Bleu marine/noir avec touches discrètes de cyan, bleu électrique et violet ; aucune capture d’explorateur décorative ou fabriquée. À 390px, empiler les annotations ; vérifier 768px, l’ordinateur et le RTL arabe lorsque les actifs seront réalisés. Conserver les identifiants LTR et les sens factuels du temps/des arêtes/des axes. Utiliser uniquement la marque officielle BlockAssay fournie. Les deux enregistrements visuels restent des spécifications.

WALLET_INTELLIGENCE correspond à l’inspection en lecture seule des enregistrements d’adresses publiques, des relations et de leur provenance. Vérifier le réseau pris en charge, les identifiants exacts, les champs et la couverture avant toute intégration à l’exécution ; aucune capacité de fournisseur en direct n’est revendiquée ici. Utiliser l’exercice hors ligne intégré si les données ou l’accès payant sont indisponibles. Aucune connexion de portefeuille, aucun identifiant de connexion, aucune clé privée, signature ou transaction de marché réelle n’est requis. Les données manquantes restent inconnues. La progression Academy, le statut de créateur, les paiements et les parrainages ne modifient jamais les preuves Radar.

• Traceurs intégrés de Geth — Périmètre de trace des cadres d’appel et configuration propre au traceur. Vérifié le 2026-09-30.
• API d’exécution Ethereum eth_getTransactionReceipt — Statut du reçu, rattachement à la transaction et journaux. Vérifié le 2026-09-30.
• Solana getSignaturesForAddress — Historique des signatures référençant l’adresse, ordre du plus récent au plus ancien et pagination. Vérifié le 2026-09-30.
• Structures JSON du RPC Solana — Métadonnées de résultat, frais, instructions et soldes comme vues distinctes. Vérifié le 2026-09-30.

Tous les enregistrements d’exemple sont des jeux originaux ILLUSTRATIVE, pas des mesures historiques/en direct de la chaîne. La documentation explique les mécanismes, pas les montants ou étiquettes inventés. La chronologie synthétique est explicitement délimitée ; observedAt=null est intentionnel. OBSERVED dans un exercice désigne un enregistrement du jeu fourni. Réexaminer la documentation et le décodage déployé avant publication. Les étiquettes de fournisseur n’établissent pas l’identité ; le contrôle d’une adresse et l’attribution humaine nécessitent des preuves distinctes.

P09-L05 après l’exercice corrigé et la révision des questions.