Anatomie d’un portefeuille

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

Une page de portefeuille peut réunir sur un écran une adresse, plusieurs comptes de jetons, des appels de contrat et des étiquettes de fournisseur. Cette commodité n’en fait ni un objet unique du registre ni une personne unique. Avant de lire l’historique, définir ce que représente réellement la page.

Vous cartographierez les rôles des comptes et réconcilierez les avoirs fournis sans attribuer d’identité. C’est la compétence d’entrée du programme : toute affirmation ultérieure sur le financement, l’ancienneté ou les relations dépend du choix de la bonne unité d’observation.

Séparer l’interface de l’objet

Une application de portefeuille est une interface, tandis qu’un compte est un objet du registre ; la documentation Ethereum distingue explicitement les deux [S09-ETHACCOUNTS]. Une interface peut afficher plusieurs comptes et réseaux. Un compte peut être accessible par plusieurs interfaces. Aucune de ces relations n’identifie un être humain unique.

Utiliser le réseau et l’adresse complète comme identifiant de départ. Une étiquette abrégée ne permet pas d’établir l’égalité. Un texte affiché identique sur différentes chaînes ne constitue pas un objet comptable partagé. Le regroupement « portefeuille » d’un fournisseur peut inclure des relations déduites ; examiner sa définition avant d’en faire un total par propriétaire.

En pratique, valider l’encodage de l’adresse et consigner le réseau choisi. L’exercice emploie délibérément des étiquettes invalides : les comparaisons sont uniquement pédagogiques et aucune transaction ne peut cibler ces identifiants.

Identifier le rôle du compte

Les comptes Solana stockent un état à une adresse et possèdent un champ de programme propriétaire [S09-ACCOUNTS]. Ce champ n’est pas une identité humaine. Un compte de jetons enregistre séparément son mint et son autorité propriétaire [S09-TOKENS]. Ne pas interpréter la propriété de base du Token Program comme signifiant que ce programme est bénéficiaire de tous les soldes de jetons.

Une autorité peut posséder plusieurs comptes de jetons d’un même mint. N’agréger qu’avec un mint exact, un contexte concordant et des champs d’autorité étayés. Solde natif et solde de jetons ont des unités différentes. Ne jamais les additionner comme un actif unique ni les convertir en dollars sans source de valorisation explicite.

Consigner si une adresse désigne un programme, un compte de jetons, un mint ou un autre compte d’état. Un même graphe de relations peut contenir tous ces types de nœuds. Un graphe de cinq nœuds ne représente pas cinq portefeuilles, encore moins cinq personnes.

Comprendre l’activité contrôlée par programme

Les adresses Solana dérivées de programme (PDA) proviennent d’un identifiant de programme et de graines et n’ont pas de clé privée ; le programme dérivant peut signer pour elles par le mécanisme d’exécution [S09-PDA]. La dérivation seule ne signifie pas qu’un compte est déjà alloué à cette adresse. Vérifier à la fois la relation entre adresses et l’état du compte pertinent.

Ne pas fusionner signature par programme et signature humaine dans un champ unique. Une autorité médiée par programme peut servir de nombreux utilisateurs. Les règles de son application déterminent quelles requêtes la font agir ; une étiquette PDA n’établit ni utilisateur individuel ni contrôle sans restriction.

Sur les réseaux EVM, distinguer contrôle ordinaire par clé, logique de contrat et mécanismes de délégation pris en charge. Un compte externe (EOA) est contrôlé par une clé privée ; une délégation prise en charge peut déterminer le code qu’il exécute. EIP-7702 permet la délégation de code des EOA sur les réseaux compatibles [S09-DELEGATION]. La seule présence de code n’est donc pas une règle universelle « ceci ne peut pas être un EOA ». Examiner les règles du réseau et l’état du compte dans le contexte demandé.

Un compte doté de code peut exécuter des instructions sans prouver quel humain en bénéficie. Un contrat multisig peut représenter plusieurs comptes signataires, mais compter les signataires ne prouve pas des personnes indépendantes. Séparer mécanisme de contrôle et attribution humaine.

Construire une carte des rôles avant une carte de propriété

Utiliser le type de nœud, l’identifiant exact, le réseau, le contexte et le repère de preuve. Employer des arêtes telles que propriétaire de compte de jetons, référence de mint, dérivation de programme et délégation de code. Elles ont des significations précises. Une arête générique « lié à » masque la raison de la liaison.

Ne pas convertir chaque arête en propriété commune. Une référence de mint relie tous les détenteurs d’un actif sans en faire un seul contrôleur. La dérivation de programme relie une adresse à un mécanisme, pas nécessairement à l’inventaire personnel de l’opérateur du programme.

Placer les étiquettes de fournisseur dans une annotation séparée avec provenance et statut de vérification. « Service de garde » peut être une piste utile, mais il faut examiner l’éditeur, la date de mise à jour et le fondement de l’étiquette. La consigner comme affirmation du fournisseur jusqu’à corroboration suffisante.

Réconcilier les avoirs fournis

Le jeu fournit un ensemble exhaustif de comptes de jetons pour l’autorité W et un mint cible à S0. Cette exhaustivité est une hypothèse d’exercice, pas une capacité revendiquée de Wallet Intelligence. Additionner les deux soldes de comptes valides uniquement après confirmation de leur propriétaire et de leur mint.

Un troisième compte du même mint sous une autorité dérivée de programme ne fait pas partie des avoirs de W simplement parce qu’il figure sur le même écran d’application. Les avoirs d’un autre mint ne peuvent pas entrer dans le total cible. Les unités natives restent séparées.

Si les enregistrements réels sont partiels, présenter un total des soldes retournés et une limite de couverture. Ne pas le promouvoir silencieusement en « tous les avoirs ». Une requête en échec est une preuve indisponible, pas un inventaire nul. Un montant nul fourni est une mesure dans le périmètre annoncé.

Énoncer les limites de manière constructive

Un bon constat d’anatomie peut dire : « W est l’autorité fournie pour T1/T2 détenant MINT-A ; P1 est une autorité distincte médiée par programme. Le contrôle humain est inconnu. » Il répond à la question sur le compte sans résoudre une question d’identité non étayée.

La prochaine demande de preuve doit correspondre à la lacune : énumération complète propriétaire/mint pour les avoirs manquants, enregistrements de dérivation/état pour classifier une PDA et autorisation de l’application pour le contrôle médié. Demander le nom d’une personne ne remplace pas ces vérifications techniques.

Aucun rôle de compte ne produit un signal BUY/SELL. La présence d’un contrat, d’une PDA ou d’un compte de jetons indique l’organisation des observations. Elle n’établit ni légitimité, ni intention, ni comportement futur du marché.

• Adresse : identifiant délimité par réseau.
• Compte : objet d’état à une adresse.
• Interface de portefeuille : application affichant des comptes ou interagissant avec eux.
• Autorité propriétaire : champ régissant un compte de jetons donné.
• PDA : adresse dérivée de programme avec signature à l’exécution.
• Délégation : relation d’exécution du compte, pas affiliation personnelle.

ILLUSTRATIVE — FIX-P09-01. SIM-SOL-A au S0 fictif ; soldes déjà normalisés. Autorité cible W, mint cible MINT-A. T1/T2 sont stipulés exhaustifs pour W/MINT-A.

A 7 est un exemple sur un réseau distinct. Aucun enregistrement d’identité, de valorisation, de seuil de signature ou d’autorisation d’application n’est fourni.

OBSERVED dans le jeu : W est l’autorité propriétaire de T1/T2 ; P1 est une autorité distincte dérivée de programme pour T4. Le fournisseur publie A 8.

INFERRED : les avoirs MINT-A fournis de W totalisent 200 jetons. Ses 2 unités natives et MINT-B50 sont des quantités séparées.

UNKNOWN : identité humaine derrière W/P1/E1, règles de contrôle de l’application et propriété bénéficiaire.

INSUFFICIENT EVIDENCE : A 8 n’établit pas l’identité d’Alice. Le mint partagé ne permet pas de fusionner W et P1. La délégation de code n’établit pas d’affiliation avec l’éditeur de LOGIC-D.

Traiter une interface de portefeuille comme une personne ; confondre programme propriétaire de base et autorité propriétaire de jetons ; additionner des unités différentes ; fusionner les détenteurs du même mint ; appliquer une classification code/sans code obsolète sans contexte de réseau.

Dessiner une carte typée des rôles à partir de A 1–A 7. Calculer les avoirs cibles de W. Classifier A 8 et expliquer pourquoi T4 doit rester hors du total de W. Identifier deux vérifications manquantes pour l’activité contrôlée par programme.

• Choisir le réseau exact et l’unité d’observation.
• Typer chaque nœud et chaque relation.
• Séparer soldes natifs et soldes de mint.
• N’agréger que les champs de propriétaire étayés.
• Distinguer contrôle par programme/par clé/délégué.
• Conserver les étiquettes comme affirmations jusqu’à corroboration.

L’anatomie d’un portefeuille cartographie les objets du registre et les mécanismes de contrôle. Elle établit quoi inspecter sans assimiler les adresses aux personnes.

Une interface n’est ni un compte ni une personne. Les relations typées empêchent les fausses agrégations. Les étiquettes de fournisseur et le comportement du code ne prouvent pas l’identité.

Dessiner des nœuds typés W,T1,T2,T3,P1,T4 et de mint avec arêtes étiquetées d’autorité/de mint/de dérivation. Mettre en évidence uniquement le total cible200. Isoler les unités natives et MINT-B et séparer la délégation EVM. Placer A 8 dans l’annotation d’étiquette non vérifiée.

Anatomie de compte illustrative ; les nœuds du graphe ne sont pas des personnes.

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.

• Comptes Solana — État adressé et champ du programme propriétaire. Vérifié le 2026-09-30.
• Actifs Solana — Distinctions entre mint, compte de jetons et autorité propriétaire. Vérifié le 2026-09-30.
• Adresses Solana dérivées de programme — Adresses dérivées de programme et signature par programme ; aucune clé privée de PDA. Vérifié le 2026-09-30.
• Comptes Ethereum — Distinction compte/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 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-L02 après l’exercice corrigé et la révision des questions.