Source de financement

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

« Financé par X » peut désigner un expéditeur immédiat, une source antérieure visible, une étiquette de service ou une origine humaine ultime. Ce sont des affirmations différentes. Un historique incomplet peut étayer le premier événement entrant visible tout en laissant inconnus les fonds initiaux et leur provenance amont.

Vous reconstruirez un chemin de financement délimité, distinguerez financement natif et en jetons et énoncerez le préhistorique manquant. Un financement commun reste une observation de relation, pas la preuve d’un propriétaire commun.

Définir le financement pour la question

Préciser actif, cible et objet. Les unités natives servant aux frais diffèrent des jetons reçus pour une autre activité. Si un portefeuille reçoit un jeton sans entrée native fournie, on ne peut supposer que l’événement de jetons explique son solde pour les frais.

« Premier transfert natif entrant visible » est une règle reproductible. « Financeur d’origine » est plus fort : cela nécessite le préhistorique et une définition claire de l’origine. Un instantané avec un solde d’ouverture établit déjà que la fenêtre affichée n’explique pas toutes les unités.

Utiliser l’adresse cible exacte et les comptes de jetons pertinents. L’énumération de jetons Solana par propriétaire est filtrée par mint ou programme [S09-OWNERS] ; elle fournit une relation de compte, pas l’humain derrière le financement. Ne pas fusionner des actifs parce qu’une interface les affiche ensemble.

Séparer source immédiate et historique amont

Un transfert direct réussi peut identifier le compte source immédiat selon le mécanisme décodé. Il n’identifie ni qui a instruit ce compte, ni s’il représente un service, ni l’origine ultime de ses fonds.

Un chemin en deux étapes A→HUB→W enregistre deux opérations. Dans un modèle de solde par compte, les fonds entrants peuvent se mélanger à l’inventaire antérieur. Montrer un chemin chronologique n’établit pas que les unités exactes reçues par W sont uniquement celles envoyées par A. Expliquer toute hypothèse d’allocation en cas de tentative d’attribution de flux.

Dans cette leçon, ne pas allouer d’unités particulières à travers le hub. Rapporter le chemin fourni et ses limites. Un graphe peut être utile sans prétendre suivre des pièces identifiables de manière unique à travers des soldes fongibles.

Distinguer les mécanismes d’événement

Transfert de jetons, création de jetons, récompense, remboursement et opération liée à un pont peuvent tous modifier l’inventaire. Ce ne sont pas des arêtes de source interchangeables. Une opération décodée de création par pont peut identifier un mécanisme local sans identifier le déposant cross-chain d’origine.

Un transfert de retour ne doit pas être appelé remboursement seulement parce qu’il suit une sortie antérieure. Cette étiquette nécessite une preuve de mécanisme ou de contexte. De même, un paiement provenant d’une adresse étiquetée plateforme d’échange reste un paiement de cette adresse avec une étiquette non vérifiée jusqu’à ce que la provenance étaye le service revendiqué.

Les instructions et métadonnées de résultat fournissent les vues de mécanisme utilisées pour cette inspection [S09-STRUCTURES]. La documentation explique les champs ; elle n’authentifie ni les étiquettes économiques d’un fournisseur ni les enregistrements d’exercice inventés.

Consigner la couverture avant de choisir l’événement le plus ancien

L’historique des signatures Solana est paginé et ordonné du plus récent au plus ancien [S09-SIGNATURES]. L’élément le plus ancien d’une page retournée est seulement le plus ancien de cette page. Le périmètre de recherche, la pagination et la rétention du fournisseur déterminent quelle activité antérieure peut manquer.

Récupérer réussite et montants séparément de la liste de découverte. Un résultat de transaction null à l’engagement demandé est une preuve indisponible [S09-TRANSACTION]. Ne pas placer un montant ou un expéditeur supposé sur le graphe de financement pour relier une lacune.

Fixer la fenêtre d’observation. Si le solde initial est fourni sans son origine, dessiner une lacune de préhistorique étiquetée plutôt que de traiter le premier transfert ultérieur comme création du compte. Le premier financement visible n’est pas nécessairement le véritable premier financement du compte.

Réconcilier un solde délimité

Dans une fenêtre déclarée complète, le solde final égale le solde d’ouverture plus les entrées réussies moins les sorties réussies et les coûts applicables. Préciser les coûts inclus. Le jeu fixe explicitement les frais natifs et les autres effets à zéro pour ce modèle simplifié.

Entrées brutes, sorties brutes et variation nette restent séparées. Un portefeuille qui reçoit6 et envoie5 augmente de1 net. Il n’a pas « reçu seulement1 » et n’a pas gagné6 en ignorant les sorties.

La réconciliation étaye l’explication comptable dans la fenêtre. Elle n’établit ni motivations, ni légitimité, ni propriété économique du solde d’ouverture. Si les enregistrements sont incomplets, préserver une variation inexpliquée plutôt que l’attribuer à un compte amont supposé.

Interpréter la source commune sans fusionner les personnes

Si HUB envoie à plusieurs adresses, la relation observée est un financement immédiat commun. Les explications possibles incluent un opérateur unique, un service partagé, une distribution publique ou des retraits sans lien. L’existence d’alternatives ne prouve aucune d’elles ; elle empêche une explication de devenir preuve exclusive.

Une étiquette de fournisseur peut aider à formuler une prochaine vérification. Consigner son éditeur, son fondement probant et son périmètre. Plusieurs interfaces copiant la même étiquette n’ajoutent pas de preuve indépendante d’identité. Ne pas créer de nœud de personne sur la base d’une source commune.

Rédiger au niveau étayé

Préférer « F1 est le premier événement natif entrant réussi visible dans SIM-DAY5–8 ; les 3 unités d’ouverture ont une provenance inconnue » à « HUB a créé W ». La phrase étroite reste utile et testable.

Si la cible est un mécanisme de financement plutôt qu’une identité, demander le résultat de transaction, le chemin de transfert décodé et les soldes concordants. Pour une association amont, des preuves supplémentaires de source/contrôle sont nécessaires. Un chemin de financement ne donne aucun signal BUY/SELL et n’établit pas de causalité de marché.

• Source immédiate : compte fournissant directement un mouvement décodé.
• Source amont : point antérieur d’un chemin observé.
• Solde d’ouverture : inventaire au début de la fenêtre.
• Lacune de préhistorique : enregistrements indisponibles avant la fenêtre.
• Mécanisme de financement : transfert, création ou autre opération précisée.
• Hypothèse d’allocation : règle de traçage des quantités fongibles à travers un inventaire mélangé.

ILLUSTRATIVE — FIX-P09-03. SIM-CHAIN-A / W. Les nombres SIM-DAY sont des décalages inventés en jours calendaires. Effets natifs complets dans SIM-DAY5–8 ; ouverture de 3 unités NATIVE, frais/autres effets nuls dans ce modèle.

F0 est un enregistrement amont fourni hors de la fenêtre cible, pas l’historique complet de HUB. F5 est un actif distinct ; le lien avec le dépôt sur la chaîne source est absent. Un fournisseur étiquette HUB « plateforme d’échange » sans authentification.

OBSERVED dans le jeu : F1 fournit5 unités natives directement de HUB ; F3 retourne1 depuis B ; F5 fournit une opération de création locale.

INFERRED : dans la fenêtre native, entrée 6, sortie 5, net+1 et solde final 4. F1 est le premier événement natif entrant visible dans cette fenêtre.

UNKNOWN : origine des 3 unités d’ouverture, humains en amont, identité du service HUB et déposant d’origine de F5.

INSUFFICIENT EVIDENCE : F0/F1 n’allouent pas de manière unique les50 de A à W. L’ordre de F3 ne prouve pas un remboursement. Le financement commun de HUB n’établit pas une propriété humaine partagée.

Appeler la ligne retournée la plus ancienne le véritable premier financement ; ignorer l’inventaire d’ouverture ; additionner jetons de pont et unités natives ; allouer des unités fongibles de hub sans hypothèses ; adopter les étiquettes de source du fournisseur comme preuve d’identité.

Dessiner le chemin natif fourni avec une lacune de préhistorique, calculer la réconciliation de la fenêtre de W et identifier sa première source native visible. Classifier les affirmations de remboursement, de plateforme d’échange et de déposant d’origine du pont.

• Définir actif cible et règle de financement.
• Séparer observations immédiates et amont.
• Préserver les lacunes de provenance du solde d’ouverture.
• Vérifier le mécanisme réussi, pas seulement les étiquettes.
• Réconcilier brut et net dans la couverture.
• Ne jamais fusionner les propriétaires à partir d’un financement commun.

L’analyse du financement reconstruit les chemins et quantités disponibles. Sa conclusion honnête la plus forte peut être une première source visible avec des lacunes de préhistorique explicites.

La source immédiate n’est pas l’origine ultime. Un chemin n’est pas une allocation unique à travers un hub. Financement commun et étiquettes de fournisseur ne prouvent pas l’identité.

Graphe natif orienté F0–F4 avec quantités et décalages de jours ; marquer le préhistorique inconnu de HUB et l’ouverture de W de 3. Mettre la création par pontF5 dans une voie d’actif distincte avec arête manquante de chaîne source. Panneau de réconciliation6 entrants/5 sortants/net+1/final4 ; étiquettes de fournisseur en pointillés.

Chemin de financement illustratif ; les sources partagées n’établissent pas la propriété.

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.

• 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.
• Solana getTransaction — Recherche de transaction, engagement de confirmation et champs de données/temps pouvant être nuls. 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.
• Solana getTokenAccountsByOwner — Énumération des avoirs par propriétaire avec filtres de mint/programme. 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-L04 après l’exercice corrigé et la révision des questions.