Limites de l’attribution et rédaction d’un rapport de preuves

Source maîtresse EN · P09-L08 · durée estimée : 45 minutes · needs_review

Un rapport sur un portefeuille peut décrire correctement des transferts tout en formulant des affirmations non étayées sur une personne, son affiliation ou ses intentions sur le marché. La compétence finale consiste à préserver une chaîne de preuves en distinguant les faits, les calculs, les hypothèses et les inconnues.

Vous produirez un rapport délimité à partir d’un jeu de données partiel. Il est distinct du rapport sur le contrôle d’un actif de P08 : ici, l’analyse porte sur l’activité des comptes, les relations, la couverture et les limites de l’attribution. Aucune identité personnelle, consigne de négociation ou certification n’est délivrée.

Définir le périmètre avant d’interpréter

Indiquez le réseau, l’adresse cible complète, l’actif concerné, la limite temporelle ou contextuelle et la question de l’enquête. Une question comme « quelles activités et relations sont fournies pour W ? » permet une réponse. « Qui est W et que négociera-t-il ensuite ? » exige des preuves absentes du jeu de données.

Déclarez l’unité d’observation. Une adresse n’est pas une personne ; une relation d’autorité n’est pas la propriété effective. La conclusion ne doit pas passer silencieusement de mouvements d’une adresse à la conduite d’un être humain.

Consignez séparément l’état à la date de référence, la capture de la source et la génération du rapport. Un rapport ultérieur peut décrire une activité antérieure, mais des connaissances acquises plus tard ne peuvent pas être présentées comme disponibles auparavant. Les heures fictives restent explicitement synthétiques.

Constituer le registre des preuves

Attribuez à chaque ligne un repère, une source, l’objet exact, le contexte, le résultat, le montant et ses unités, ainsi qu’une limite. Présentez les étiquettes non vérifiées comme des assertions de leurs sources, et non comme des faits du registre sur une entité. La documentation explique l’interprétation des données ; elle n’authentifie pas ces étiquettes.

Sur Solana, une recherche de transaction peut être indisponible au niveau de confirmation demandé, et les métadonnées temporelles de l’événement peuvent être nulles [S09-TRANSACTION]. Les enregistrements manquants restent non résolus. L’historique des signatures est paginé, avec les événements les plus récents en premier [S09-SIGNATURES] ; le plus ancien événement retourné n’établit donc pas une origine complète.

Reliez les calculs à leurs données d’entrée. Une différence de solde avant/après et un enregistrement de transfert sont deux vues différentes ; leur concordance constitue un contrôle de rapprochement, sans nécessairement provenir d’un fournisseur indépendant. Précisez quand plusieurs champs partagent le même export.

Utiliser les quatre états de preuve

OBSERVED (OBSERVÉ) décrit un enregistrement inspectable dans le périmètre déclaré. Dans cet exercice, il s’agit d’une ligne fictive fournie. INFERRED (INFÉRÉ) décrit un raisonnement explicite, comme un pourcentage ou un mécanisme plausible. UNKNOWN (INCONNU) signale une information indisponible. INSUFFICIENT EVIDENCE (ÉLÉMENTS DE PREUVE INSUFFISANTS) classe une affirmation proposée que les observations existantes ne permettent pas d’établir.

Une affirmation sur l’identité peut être insuffisamment étayée alors que les transferts restent observés. Un schéma de source commune peut être inféré sans étayer une propriété commune. Ne fusionnez pas ces états en un score de confiance sur l’identité.

Précisez la proposition testée : « X est une trésorerie de projet authentifiée » est plus fort que « Feed-L étiquette X comme trésorerie ». La seconde formulation est observée en tant qu’assertion d’un fournisseur. La première exige une corroboration indépendante. Les deux peuvent figurer dans un rapport, avec des classifications différentes.

Distinguer le contrôle de l’identité

Une signature ou un enregistrement d’autorisation peut étayer une action de contrôle particulière, dans son mécanisme et son contexte. Il n’établit pas à lui seul l’identité juridique de la personne, une propriété continue ou un intérêt économique effectif. L’activité de contrats ou l’activité déléguée ajoutent d’autres couches d’autorisation [S09-ETHACCOUNTS; S09-DELEGATION].

Une future enquête d’attribution aurait besoin de preuves convenablement authentifiées, adaptées au périmètre de l’association testée. Une déclaration publique, une démonstration cryptographique de contrôle et une identité organisationnelle corroborée répondent à des questions différentes ; aucune ne doit se substituer à toutes les autres.

Cet exercice ne demande de signature ni à l’apprenant ni à quiconque. Ne demandez pas de phrases de récupération, de clés privées ou de connexion à un compte. Le résultat attendu est une analyse en lecture seule du matériel fourni, dont les identités restent non résolues.

Préserver les étiquettes contradictoires et les limites de couverture

Si deux interfaces recopient le même flux d’étiquettes, leur accord représente une seule assertion en amont. Si un autre flux la contredit, conservez le conflit. Ne choisissez pas l’étiquette qui favorise un récit spectaculaire et n’inventez pas de pourcentage de confiance.

Une période dont les enregistrements manquent correspond à une activité inconnue, pas à une absence d’activité. Le plus ancien enregistrement visible donne une durée depuis la première observation dans la requête, pas une date de création réelle. Une source peut couvrir une adresse tout en omettant les événements de comptes de jetons associés.

Un tableau partiel de transferts ne peut pas établir un historique complet de négociation. Même une variation de solde correctement observée n’établit pas pourquoi les fonds ont été déplacés. Conservez une liste des enregistrements manquants aux côtés des événements réussis et échoués.

Rapprocher les éléments effectivement fournis

Normalisez les montants et comparez des contextes cohérents. Les comptes de jetons associés à un propriétaire peuvent étayer une vue des avoirs dans le cadre d’un filtre de mint ou de programme [S09-OWNERS] ; ils ne fournissent pas l’ensemble des actifs de chaque personne.

Si les instantanés de jetons fournis diffèrent de 4000 et qu’un transfert réussi porte sur 4000, signalez la cohérence numérique. Si l’historique est partiel, n’affirmez pas avoir exclu tous les autres mécanismes. Des tentatives échouées ne deviennent pas des sorties réussies simplement parce qu’elles figurent à côté.

Ne combinez pas un mouvement de jetons avec des frais en actif natif. Le payeur des frais peut différer de la cible. Une opération sponsorisée ne prouve pas que le sponsor est le propriétaire ou l’employeur de l’utilisateur. Une interaction avec un service étiqueté par une source n’établit pas une affiliation.

Rédiger les constats avec leurs propositions et leurs limites

Chaque constat doit comporter une proposition restreinte, les repères des enregistrements, le statut des données, le contexte et la limite. Un rapport peut indiquer : « le solde retourné par R4 est de 6000 ; la couverture complète des avoirs n’est pas établie ». Cette formulation est plus défendable que « W n’a plus que 6000 actifs ».

Formulez les hypothèses de manière neutre et proposez des alternatives. Recevoir des fonds de HUB peut être compatible avec un contrôle commun ou avec un service partagé ; les enregistrements fournis ne permettent pas forcément de les distinguer. Ne transformez pas cette compatibilité en verdict.

Un transfert vers X et un mouvement ultérieur du marché n’établissent pas un signal BUY/SELL ni un effet causal. Indiquez-le directement lorsque vous corrigez le titre proposé. Les étiquettes, la richesse, la visibilité sociale et les relations commerciales ne peuvent pas renforcer les preuves.

Cibler les vérifications suivantes

Demandez une pagination complète dans le périmètre défini, la couverture des comptes associés, un décodage cohérent des transactions et la provenance des étiquettes. Pour une hypothèse précise de contrôle, demandez des preuves qui la distingueraient des alternatives. Chaque demande doit expliquer quelle incertitude elle traite.

Indiquez honnêtement contentVersion et needs_review pour le rapport. Le statut de révision éditoriale ne constitue pas un jugement sur l’identité ou le risque de W. Un futur écran Passport ou Wallet Intelligence nécessite sa propre vérification à l’exécution ; cette leçon ne revendique ni surveillance en direct, ni export d’artefacts, ni exhaustivité des fournisseurs.

• Attribution : association étayée entre une action ou un compte et un acteur.
• Preuve de contrôle : preuve pertinente pour une action d’autorisation précisée.
• Proposition : affirmation exacte soumise à l’examen.
• Dépendance entre sources : preuve commune en amont de plusieurs affichages.
• Limite de couverture : ce qu’un jeu de données inclut et omet.
• Registre des preuves : liste reproductible des enregistrements derrière les constats.

ILLUSTRATIVE — FIX-P09-08. SIM-CHAIN-A / W / MINT-R, offre de 1,000,000 jetons normalisés. Décalages en jours et repères de capture exclusivement synthétiques. La requête partielle couvre les jours 12–30 avec une lacune [16,18) ; l’exhaustivité des comptes associés est inconnue. Analyse au jour 30.

Aucune exécution de négociation, aucun enregistrement de création, aucune déclaration d’entité authentifiée, aucun rapprochement complet de l’actif natif et aucune preuve de causalité sur le marché ne sont fournis.

OBSERVED dans le jeu fictif : R1–R5 fournissent l’activité, les résultats et les soldes retournés ; R6–R8 fournissent des étiquettes contradictoires ou dépendantes.

INFERRED : la variation des jetons retournée, −4000, est cohérente avec R3 ; la part du solde dans l’offre passe de 1%→0.6%. La première entrée retournée précède l’analyse de 18 jours synthétiques.

UNKNOWN : identité humaine, création réelle, activité manquante, avoirs complets, entité correspondant à X et historique du solde en actif natif.

INSUFFICIENT EVIDENCE : l’affiliation à une trésorerie, une propriété humaine commune, une vente achevée et une causalité sur le marché ne sont pas établies. R6/R7 ne sont pas des confirmations indépendantes.

Assimiler les soldes retournés à la totalité des actifs ; présenter la première observation comme une naissance ; transformer les assertions des fournisseurs en identité ; additionner les transferts échoués ; qualifier un sponsor d’employeur ; et tirer des conclusions financières ou causales de simples mouvements.

Rédigez un rapport avec son périmètre, un registre des preuves, des constats classés dans les quatre états, ses limites et trois vérifications suivantes. Corrigez : « W est un portefeuille de négociation détenu par une personne, vieux de 18 jours, financé par son employeur, qui a vendu 5000 à la trésorerie du projet. »

• Indiquer le réseau, la cible, l’actif et la limite temporelle.
• Joindre la source, le contexte et le résultat à chaque affirmation.
• Distinguer les étiquettes des associations à des personnes.
• Publier les lacunes et les dépendances entre fournisseurs.
• Rapprocher les effets réussis sans double comptage.
• Conserver OBSERVED/INFERRED/UNKNOWN/INSUFFICIENT EVIDENCE.
• Terminer par des demandes de preuves, pas par des verdicts de négociation ou d’identité.

Un rapport sur un portefeuille est une chaîne de preuves assortie d’affirmations délimitées. Il peut établir des activités et des quantités tout en laissant l’identité, l’affiliation et l’intention non résolues.

Le contrôle d’une adresse n’est pas une identité personnelle. Un financement commun et une interaction ne prouvent pas la propriété ou l’affiliation. Les données manquantes, la chronologie des transferts et les étiquettes ne peuvent pas fournir de signaux de marché ni de conclusions causales.

Registre des preuves R1–R8 avec source et contexte, et regroupements signalant les sources communes Export-A/Feed-L. Panneau des quatre états rattachés aux affirmations ; lacune [16,18) UNKNOWN ; transfert réussi de 4000 séparé de la tentative échouée de 1000 et des frais en actif natif de 0.01. L’intervalle de 18 depuis la première entrée retournée est explicitement synthétique ; aucun nœud représentant une personne.

Rapport illustratif sur un portefeuille ; attribution, objet de la négociation et affiliation non résolus.

Utiliser des SVG/HTML déterministes ou des graphiques avec unités, repères des preuves et alternatives textuelles. Bleu marine et noir avec cyan, bleu électrique et violet mesurés ; aucune capture d’explorateur décorative ou fabriquée. À 390px, empiler les annotations ; vérifier 768px, l’affichage de bureau et l’arabe en RTL lors de la réalisation des visuels. Conserver les identifiants en LTR et les directions factuelles du temps, des liens et 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 d’enregistrements publics d’adresses, de 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 à un portefeuille, aucun identifiant de connexion, aucune clé privée, aucune signature ni négociation en direct ne sont nécessaires. Les données manquantes restent inconnues. La progression dans Academy, le statut de créateur, les paiements et les recommandations commerciales ne modifient jamais les preuves de Radar.

• Solana getSignaturesForAddress — Historique des signatures référençant une adresse, ordre des plus récentes aux plus anciennes et pagination. Vérifié le 2026-09-30.
• Solana getTransaction — Recherche de transaction, niveau de confirmation et champs de données ou de temps pouvant être nuls. Vérifié le 2026-09-30.
• Solana getTokenAccountsByOwner — Énumération des avoirs dans le périmètre d’un propriétaire, avec filtres de mint ou de programme. Vérifié le 2026-09-30.
• Comptes Ethereum — Distinction entre compte et interface, et types de comptes. Vérifié le 2026-09-30.
• EIP-7702 : définition de code pour les EOA — Délégation de code des EOA ; la seule présence de code n’est pas une règle universelle de classification des EOA. Vérifié le 2026-09-30.

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

P09 est terminé. Relisez le rapport sur le portefeuille affirmation par affirmation, puis revenez au tableau de bord Academy. Les laboratoires distincts conservent les prérequis qui leur sont indiqués.