Mint et identité exacte

Source maître EN · P07-L02 · 45 minutes estimées · needs_review

Objectifs d’apprentissage :

• Résoudre l’identité d’actif avec les identifiants complets de réseau et de mint.
• Distinguer les rôles de mint, compte de jetons, pool et portefeuille.
• Écrire une conclusion d’identité circonscrite sans déduire de fraude ni de sécurité.

Une analyse peut être mathématiquement correcte et décrire pourtant le mauvais actif. Noms, symboles, images et identifiants sociaux sont des libellés de présentation copiables. Avant d’interpréter un graphique de liquidité ou un tableau de détenteurs, établir exactement quel réseau et quel mint concernent les preuves. Cette leçon enseigne la résolution d’identité et la capacité à s’arrêter lorsqu’elle reste ambiguë.

Distinguer l’identifiant du récit qui lui est attaché

Pour l’analyse de jetons Solana, le réseau et l’adresse du mint identifient l’actif investigué. Un compte de jetons détient des unités associées à un mint ; ce n’est pas le mint lui-même [S-TOKENS]. Une adresse de portefeuille, une adresse de pool et un mint peuvent apparaître sur une même page d’explorateur, mais répondent à des questions différentes. Un logo d’apparence correcte ne corrige pas l’emploi du mauvais type de compte.

Un relevé d’investigation sûr nomme donc la chaîne/le cluster, l’identifiant complet d’actif, le type attendu de compte/programme, la source et le contexte d’observation. Ne pas réduire cela à une adresse tronquée. La troncature est utile pour l’affichage mais inadaptée à la comparaison d’identifiants ressemblants. Stocker la valeur complète et montrer une chaîne copiable et isolée lorsqu’une future interface prend le relevé en charge.

Le compte sur chaîne prouve qu’un actif particulier existe selon des règles particulières. Il n’établit pas qu’un projet, une communauté ou une marque le soutient. Inversement, une page de projet peut déclarer une adresse sans prouver chaque champ technique de cette adresse. Garder identité technique et affiliation déclarée comme des affirmations distinctes, avec des sources distinctes.

Croiser les sources sans compter deux fois les déclarations copiées

Imaginons que trois sites répètent la même adresse. Ce peuvent être des publications indépendantes ou toutes peuvent copier un flux compromis. Trois apparitions ne font pas automatiquement trois confirmations indépendantes. Écrire une chaîne de provenance : qui a initialement déclaré l’identifiant, quand la déclaration était disponible et quel enregistrement technique le chercheur a inspecté.

Une source atteinte par une publicité de recherche ou un message transféré n’est pas automatiquement le canal officiel de l’organisation. Inspecter le domaine exact et l’origine de la référence. Une orthographe similaire, un compte renommé ou un sous-domaine sans rapport peuvent induire en erreur. Même lorsqu’un canal officiel est établi, étiqueter sa déclaration d’adresse DECLARED à moins que les vérifications indépendantes prévues aient réellement été effectuées.

« Vérifié » est aussi ambigu. Un badge peut concerner un compte social, une liste d’explorateur ou une soumission de métadonnées. Indiquer ce qui a été vérifié au lieu d’utiliser le badge comme approbation générale de l’actif. Une conclusion utile est « l’identifiant complet déclaré correspond au mint inspecté sur le réseau précisé », pas « ce jeton est légitime ».

Les permissions et métadonnées répondent à des questions plus étroites

Une autorité de mint et une autorité de gel représentent des permissions spécifiques. Retirer une autorité choisie n’efface pas tous les risques possibles [S-AUTHORITY]. Les métadonnées et extensions de jetons exigent leur propre inspection ; les champs de base seuls n’épuisent pas les comportements additionnels du jeton [S-EXTENSIONS]. Un analyste doit préserver ces distinctions au lieu de les combiner en un libellé vert de sécurité.

Pour cette leçon, vous n’avez pas besoin de réaliser un audit de sécurité de contrat. Vous devez vérifier que les preuves prévues appartiennent réellement à l’actif affirmé. Si une source décrit un jeton standard mais qu’un compte inspecté utilise un autre programme ou des extensions non examinées, consigner l’écart et s’arrêter avant de supposer le comportement des transferts.

Refuser de terminer prématurément une identification est un résultat utile. UNKNOWN dit qu’un fait pertinent n’a pas été obtenu. INSUFFICIENT EVIDENCE dit que les faits collectés ne peuvent étayer une affirmation particulière. Ils ne sont pas interchangeables avec « faux ». Une discordance peut justifier de rejeter un candidat comme actif exact déclaré sans justifier une accusation de fraude contre son créateur.

Rendre la décision reproductible

Utiliser une matrice d’identité avec une ligne par candidat. Consigner l’identifiant complet, le réseau, le type de compte, la correspondance à la déclaration et les questions non résolues. La règle de décision doit être fixée avant d’examiner la popularité ou la performance de marché : un candidat doit correspondre au réseau et au mint complet requis, et son type doit être interprétable. Si plusieurs candidats subsistent, décrire l’ambiguïté et demander la déclaration ou l’enregistrement technique manquant.

Cette procédure évite un piège comportemental courant : choisir un candidat parce que son graphique paraît plus plausible. L’évolution des prix ne peut désambiguïser un identifiant d’actif. Le travail d’identité précède aussi la fusion d’enregistrements de plusieurs fournisseurs. Un symbole partagé n’autorise pas à combiner le profil social d’un candidat avec la distribution des détenteurs d’un autre.

• Identité exacte : identifiant complet réseau-et-actif, pas correspondance de symbole.
• Mint : compte identifiant le jeton dans le périmètre Solana de cette leçon.
• Compte de jetons : compte porteur d’un solde associé à un mint.
• Déclaration : affirmation d’une source sur l’affiliation ou l’identité.
• Corroboration : vérification croisée explicitement décrite, avec provenance.
• Autorité : permission spécifique, pas identité générale de personne/projet.

ILLUSTRATIVE EXEMPLE — FIX-P07-02. MINT-A et MINT-B sont des libellés d’adresses fictives délibérément invalides. Ne jamais les coller dans un explorateur comme des adresses réelles.

La déclaration fournie du projet fictif est « training-cluster-A / MINT-A ». Le candidat A correspond à ce jeu. B est un mint différent, C échoue au contrôle de réseau et D a le mauvais rôle de compte. Aucune ligne n’établit l’opérateur humain ni la qualité d’investissement.

OBSERVED: A correspond à la déclaration complète et à l’enregistrement de type de compte fournis dans le jeu.

INFERRED: A est l’enregistrement adapté à cette analyse étroitement définie, à condition que la déclaration fournie soit la référence voulue.

UNKNOWN: Si la déclaration du projet fictif était autorisée par une organisation réelle ; authenticité des sources au-delà du jeu fourni.

INSUFFICIENT EVIDENCE: Correspondre à un identifiant ne peut établir la sécurité du projet, une distribution équitable, l’honnêteté du créateur ou un rendement futur. Un candidat différent n’est pas automatiquement frauduleux.

Utiliser une recherche de symbole comme identification finale ; ne comparer que les premiers/derniers caractères ; fusionner les données entre réseaux ; confondre comptes de jetons et mints ; compter des déclarations copiées comme vérifications indépendantes ; et traiter le retrait d’une autorité comme une vérification complète de sécurité.

Avec FIX-P07-02, sélectionner le candidat correspondant et écrire une conclusion circonscrite en une phrase. Expliquer chaque candidat rejeté. Puis réécrire « B est une arnaque » et « A est vérifié sûr » en affirmations étayées par le jeu. Lister les deux contrôles requis avant d’utiliser une déclaration officielle réelle.

• Faire correspondre le réseau et l’identifiant complet.
• Confirmer le rôle mint/compte avant de lire les indicateurs.
• Garder déclaration et preuves techniques distinctes.
• Consigner l’indépendance des sources et le contexte d’observation.
• Indiquer les questions non résolues d’identité et d’autorité/extension.

L’identité exacte est un préalable à chaque mesure ultérieure. Résoudre l’actif avec des identifiants complets et des rôles de compte explicites, puis décrire l’affiliation et les contrôles techniques comme des affirmations probatoires distinctes.

Un symbole n’est pas une clé d’identité. L’accord avec une déclaration est une correspondance circonscrite, pas un verdict de sécurité. L’ambiguïté doit arrêter la fusion de données sans rapport.

Dessiner quatre cartes comparatives à partir de FIX-P07-02. Mettre en évidence réseau, identifiant synthétique complet et type de compte ; marquer les champs correspondants séparément des affirmations d’affiliation. Ne montrer aucun bouclier de sécurité ni indice de prix. Un second panneau doit expliquer pourquoi le compte de jetons D n’est pas le mint.

Règles de livraison visuelle : bleu marine foncé/noir, accents cyan/bleu électrique/violet, unités et incertitude explicitement étiquetées. Utiliser des graphiques déterministes ou du SVG, pas des captures fabriquées. À 390 px, empiler les annotations et fournir le tableau de données comme alternative textuelle ; vérifier 768 px et l’ordinateur plus tard. En arabe, localiser les libellés et la mise en page en RTL natif, tout en isolant les adresses/hachages en LTR et en conservant le sens réel des transferts et la chronologie. Utiliser uniquement le logo officiel BlockAssay fourni si une identité de marque est ajoutée. Aucun actif visuel ni rendu mobile/RTL n’est revendiqué prêt.

Utiliser RADAR uniquement lorsque le réseau exact, l’actif et les champs requis sont pris en charge et que leur provenance est visible. C’est une inspection pédagogique en lecture seule, pas une transaction ni un lancement de jeton. Utiliser le jeu hors ligne fourni si l’accès ou les données sont indisponibles ; les informations manquantes restent inconnues. Une future action Ouvrir dans BlockAssay exige un routage d’exécution et une couverture de sources validés. Aucun appel à l’action d’actif exécutable n’est fourni pour les identifiants illustratifs. La participation à Academy et le statut commercial ne changent jamais les observations Radar.

• Actifs Solana : mint et comptes de jetons — Identité du mint, propriété des comptes de jetons et rôles distincts de mint/création. Vérifié le 2026-09-30.
• Définir l’autorité Solana — Rôles spécifiques d’autorité et retrait d’une autorité choisie. Vérifié le 2026-09-30.
• Extensions de jetons Solana — Le comportement additionnel des jetons exige une inspection propre aux extensions. Vérifié le 2026-09-30.

Les tableaux et jeux d’exercice sont du matériel pédagogique original sauf désignation explicite HISTORICAL. Les identifiants fictifs sont délibérément invalides comme adresses de blockchain. La documentation étaye les définitions des mécanismes, pas les valeurs inventées des exercices. L’inspection des sources est une recherche éditoriale, pas une mesure de chaîne en direct. Les sources peuvent changer ; les réexaminer avant publication.

P07-L03 ; poursuivre après avoir terminé l’exercice et examiné chaque explication du quiz.