Déployeur et premiers acheteurs

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

Objectifs d’apprentissage :

• Cartographier séparément payeur des frais, initialisateur, autorité et destinataire d’allocation.
• Identifier les achats précoces réussis à partir des résultats et effets d’exécution.
• Rapporter les premiers acheteurs visibles avec limites explicites de couverture et d’attribution.

Une transaction de lancement peut impliquer un payeur de frais, un initialisateur de mint, une adresse d’autorité, un programme et plusieurs comptes destinataires. Appeler une adresse « le déployeur » peut masquer ces rôles. De même, recevoir des jetons tôt ne signifie pas nécessairement les acheter. Cette leçon enseigne une carte des rôles étayée par les transactions et une liste soigneusement circonscrite d’acheteurs précoces.

Remplacer un libellé vague par des rôles spécifiques

Définir « déployeur » avant de l’utiliser. Pour un memecoin Solana, cela peut désigner le compte payant l’initialisation, le signataire autorisant l’émission ou l’opérateur utilisant une plateforme de lancement. Ces rôles ne sont pas nécessairement identiques. La documentation Solana distingue explicitement l’autorité de mint du compte créant ou payant le mint [S-TOKENS]. Un rôle peut aussi passer par un programme plutôt que révéler un compte humain.

Utiliser des libellés de rôle décrivant les preuves réelles : payeur de frais, initialisateur de mint, autorité de mint, destinataire d’allocation, compte de financement de pool et destinataire d’échange. Un champ d’autorité est une permission à une observation déclarée, pas une preuve de qui a construit un site. Une adresse peut détenir plusieurs rôles, mais chaque relation exige un pointeur de preuve.

L’étiquette « créateur » d’un explorateur peut être une interprétation commode d’indexeur. La comparer à l’instruction et à l’état pertinents. Si l’on ne peut inspecter ces enregistrements, rapporter le libellé comme déclaration de source plutôt que rôle vérifié. Le but n’est pas de se méfier de tout indexeur ; c’est de rendre la dépendance visible.

Distinguer intention d’instruction et effets réussis

Une transaction peut contenir une instruction d’échange mais échouer. Un destinataire peut recevoir des jetons par allocation, transfert ou échange. Examiner le résultat d’exécution et les variations de solde avant de compter les transactions réussies. La recherche de transaction Solana comprend les métadonnées de résultat et peut renvoyer null lorsqu’un enregistrement est indisponible au niveau d’engagement demandé [S-TRANSACTION]. Null ne prouve pas qu’une adresse n’a jamais agi.

Les soldes nets peuvent induire en erreur sans contexte d’instruction. Une transaction peut combiner création de compte, transfert, frais et échange. Recevoir des jetons n’est qu’une observation ; un achat économique exige aussi la preuve d’un mécanisme d’échange et de l’actif payé correspondant. Consigner explicitement les montants nets et bruts si des mouvements intermédiaires interviennent.

Une transaction échouée peut encore prouver qu’une tentative a eu lieu, et les frais peuvent rester pertinents. Ce n’est pas un achat réussi. Séparer un tableau des tentatives du tableau des achats réussis. Cela garde intact l’historique du lancement sans contaminer le classement.

Limiter « premier acheteur » à ce qui a réellement été recherché

Pour affirmer « premier », indiquer plateforme, actif, type d’événement, intervalle d’observation, convention d’ordre et couverture historique. Un achat de plateforme de lancement et un achat ultérieur de pool peuvent appartenir à des classements différents. Le premier enregistrement visible dans la fenêtre d’un fournisseur n’est pas automatiquement la première transaction sur chaîne.

L’historique des signatures d’adresse peut être paginé et est normalement renvoyé du plus récent au plus ancien [S-SIGNATURES]. Un chercheur ne doit pas interpréter le premier élément renvoyé comme le premier événement de tous les temps. La couverture des adresses référencées ne garantit pas non plus que toutes les transactions pertinentes sont capturées en inspectant une seule adresse. Un mint, marché, programme et les comptes associés peuvent avoir des besoins d’indexation différents.

Slots et horodatages affichés sont des aides distinctes à l’ordonnancement. Plusieurs événements peuvent partager une seconde affichée. La granularité d’horodatage d’un indexeur peut masquer l’ordre ; utiliser les indices de transaction lorsqu’ils sont disponibles et préserver l’incertitude sinon. Si l’ordre est non résolu, rapporter une cohorte précoce au lieu d’inventer un premier acheteur unique.

Interpréter le comportement précoce sans déduire de motif

Une adresse agissant tôt peut être un trader automatisé, un participant surveillant les événements publics de lancement, un teneur de marché ou une personne disposant d’informations privilégiées. Le moment seul ne départage pas ces explications. Un lien à une adresse de financement de pool peut justifier d’investiguer davantage mais ne résout pas une propriété humaine commune.

Un rapport utile a deux couches. La première est un tableau factuel de rôles/transactions. La seconde est un registre d’hypothèses circonscrit, nommant les interprétations possibles et les preuves qui les renforceraient ou affaibliraient. Ne pas promouvoir silencieusement une hypothèse en libellé d’adresse montré partout ailleurs.

Ces limites ne rendent pas l’activité précoce sans pertinence. Elles rendent la conclusion testable. « L’adresse B1 a reçu 10,000 unités dans le premier achat réussi de la fenêtre de plateforme fournie » est précis. « Le créateur a secrètement acheté en premier » introduit une identité, un motif et une affirmation d’accès exigeant plus que la transaction seule.

• Payeur de frais : compte payant les frais réseau de la transaction.
• Autorité : compte autorisé à approuver une opération spécifique.
• Destinataire d’allocation : compte recevant des unités distribuées sans preuve d’achat.
• Achat réussi : échange vérifié avec résultat réussi et effets pertinents.
• Fenêtre de couverture : historique borné réellement inspecté.
• Attribution de rôle : associer un rôle opérationnel observé à une adresse.

ILLUSTRATIVE EXEMPLE — FIX-P07-05. Les six lignes sont un jeu complet pour VENUE-A entre T+0 et T+5 relatifs. Identifiants et quantités sont fictifs.

Ces effets de transaction sont des enregistrements fictifs fournis, pas des sorties dérivées du pool de la leçon 3. Aucun modèle de réserves n’est fourni ici ; ne pas en importer.

OBSERVED: Le jeu assigne des rôles d’initialisation différents à F, C et A. B1 a le premier achat réussi dans la fenêtre VENUE-A fournie et apparaît deux fois.

INFERRED: Une carte des rôles représente utilement ces relations observées ; elle n’identifie pas leurs contrôleurs humains ultimes.

UNKNOWN: Plateformes/événements antérieurs hors du jeu, propriété humaine, communications privées et privilèges d’accès.

INSUFFICIENT EVIDENCE: L’allocation de R n’est pas un achat. BUY-FAIL n’est pas un achat réussi. Le moment de B1 ne peut établir un accès d’initié ni une relation à C.

Assimiler payeur de frais et créateur ; lister le destinataire d’allocation comme premier acheteur ; ignorer les résultats échoués ; compter les transactions comme acheteurs distincts ; interpréter à l’envers les enregistrements du plus récent au plus ancien ; et nommer un initié humain à partir du moment du lancement.

Construire la carte des rôles d’initialisation et classer les événements d’achat réussis dans la fenêtre fournie. Compter les adresses distinctes d’acheteurs réussis, additionner les dépenses de cotation et réceptions de jetons de B1, et réécrire « B1 était le premier acheteur initié du projet ».

• Définir explicitement chaque rôle opérationnel.
• Vérifier résultat, instruction et effets pertinents de solde.
• Distinguer allocation, transfert, tentative et échange réussi.
• Indiquer la couverture de plateforme/temps/historique pour chaque affirmation « premier ».
• Compter les adresses uniques séparément des événements de transaction.

Une investigation de lancement doit préserver les rôles distincts et les effets réussis. « Premier acheteur » n’a de sens que dans un périmètre documenté de recherche, et une adresse précoce n’est pas automatiquement un créateur ou initié.

Utiliser des cartes de rôles au lieu d’un libellé ambigu unique de déployeur. Conserver séparément les tentatives échouées. Le moment étaye la chronologie, pas le motif.

Tracer les rôles INIT-A comme arêtes étiquetées vers un nœud mint ; utiliser une chronologie distincte d’événements pour allocation, tentative échouée et échanges réussis. Montrer B1 répété sans créer un nouveau nœud d’adresse. Joindre les effets de cotation et de jetons du jeu et une limite visible de couverture VENUE-A.

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 WALLET_INTELLIGENCE 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.
• Solana getTransaction — Recherche de transaction confirmée et résultats transaction/temps/métadonnées pouvant être null. Vérifié le 2026-09-30.
• Solana getSignaturesForAddress — Signatures d’adresses référencées du plus récent au plus ancien et paramètres de pagination. Vérifié le 2026-09-30.
• Structures JSON RPC Solana — Signataires, instructions et métadonnées de solde/résultat des transactions. 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-L06 ; poursuivre après avoir terminé l’exercice et examiné chaque explication du quiz.