Historique des transactions

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

Une page de transaction peut montrer un transfert, son instruction, un résumé décodé et une variation de solde. Ce sont parfois plusieurs vues d’un même événement. Additionner toutes les lignes gonfle l’activité ; ignorer le statut d’exécution peut transformer des tentatives échouées en transferts réussis.

Cette leçon enseigne un registre historique séparant identité des événements, réussite, activité imbriquée et frais. Elle prépare l’analyse du financement sans supposer que toute référence d’adresse correspond à un paiement.

Définir la couverture historique

Consigner réseau, adresse cible, comptes de jetons liés, fenêtre demandée et méthode de collecte. Solana getSignaturesForAddress retourne les signatures référençant l’adresse demandée dans accountKeys, des plus récentes aux plus anciennes, avec paramètres de pagination [S09-SIGNATURES]. Une page retournée est une liste de découverte, pas un registre complet des transferts.

Une adresse référencée n’est pas nécessairement signataire ou destinataire. Les instructions peuvent référencer des programmes, comptes de données et états en lecture seule. Examiner le rôle de l’enregistrement avant de compter sa présence comme action. Interroger une adresse propriétaire peut aussi manquer des opérations sur des comptes de jetons distincts ; examiner la couverture visée au lieu de déclarer l’historique complet.

Dédoublonner les signatures entre pages qui se chevauchent, mais préserver les instructions distinctes d’une même transaction. Le tri doit respecter l’ordre disponible des slots/blocs et les preuves éventuelles d’ordre interne au contexte. L’ordre affiché par une interface n’est pas automatiquement l’ordre exact d’exécution.

Vérifier le résultat avant de compter les effets

Récupérer les métadonnées d’exécution des enregistrements découverts. Solana getTransaction peut retourner null à l’engagement demandé et ses champs de temps ou de métadonnées peuvent être nuls [S09-TRANSACTION]. Traiter une récupération manquante comme non résolue, pas comme un événement échoué ou inexistant.

Un enregistrement confirmé/inclus peut encore contenir une opération échouée. Consigner la réussite séparément de la finalité. Le montant soumis décrit une intention ; un effet réussi sur le solde décrit une exécution. Pour T2 échoué du jeu, les effets de transfert de jetons sont explicitement nuls tandis que les frais natifs fournis restent facturés.

Ne pas généraliser des énoncés simplifiés d’annulation à toute fonctionnalité de chaîne. L’exercice exclut les changements d’autorisation et les autres mécanismes hors transfert. Son tableau de résultats fournit directement les effets pertinents. En analyse réelle, examiner les règles du protocole et les différences d’état effectives.

Séparer identité de l’événement et lignes affichées

Choisir une clé d’événement : réseau, signature/hachage de transaction et chemin d’instruction ou indice de journal, selon le cas. Une instruction de transfert, son résumé décodé et la variation de solde correspondante peuvent corroborer un événement. Ce ne sont pas trois transferts distincts.

Une variation de solde est un résultat net. Si un compte envoie 10 et reçoit 4 dans une fenêtre, sa variation est−6 tandis que la sortie brute est 10. Cette variation n’efface pas le transfert entrant ; additionner mouvement brut et variation nette compte deux fois.

Les appels imbriqués ont leur propre sémantique. Le callTracer de Geth décrit les cadres d’appel avec un périmètre configurable [S09-TRACES]. Un appel interne appartient à une transaction parente, pas à une transaction signée séparément. Certains cadres transportent une valeur native ; d’autres appels transportent zéro et exécutent du code. Ne pas compter chaque appel comme paiement.

Distinguer appels, journaux et mouvements de jetons

Un reçu EVM fournit rattachement à la transaction, statut et journaux [S09-RECEIPT]. Un journal d’événement de jeton et un appel avec valeur native sont des enregistrements différents. Le contrat de jeton émettant un journal Transfer n’est pas nécessairement le destinataire économique.

Sur Solana, les métadonnées de résultat distinguent instructions, instructions internes, frais et soldes [S09-STRUCTURES]. Une instruction interne peut identifier un mécanisme à l’intérieur d’une opération parente. Un résumé de cette instruction doit utiliser le même repère d’événement.

Un appel de contrat avec journal de transfert de jetons peut être un mouvement économique de jetons et une relation d’appel, plutôt que deux mouvements de jetons. Préserver les deux observations dans des tableaux typés, puis choisir l’unité de comptage adaptée à la question.

Garder les frais séparés

Les frais utilisent l’actif natif du réseau et ont un payeur précis. Ce ne sont pas des transferts du jeton cible. La documentation Solana décrit un mécanisme de frais de transaction natifs [S09-FEES]. Ne pas supposer que toute adresse visible paie les frais ou que toute tentative échouée est gratuite.

Compter les frais une fois par résultat de transaction fourni, pas une fois par instruction ou ligne de résumé. Convertir les unités brutes avec la précision native si le jeu réel la fournit. Cet exercice donne des unités de frais fictives normalisées sans conversion de prix.

Réconcilier séparément mouvements de jetons et coûts natifs. Une variation de jetons peut être correcte tandis que le solde natif comporte du loyer, des dépôts ou des effets sans lien. Le jeu exclut explicitement ces effets ; les enregistrements réels nécessitent une réconciliation supplémentaire.

Construire un tableau historique délimité

Utiliser des colonnes pour repère d’événement, rôle de l’objet, résultat, actif, sens, montant brut, payeur des frais et incertitude. Tenir une liste distincte des enregistrements non résolus. Ne pas supprimer les enregistrements manquants pour faire paraître complet le nombre visible de réussites.

Le nombre de transactions réussies de transfert de jetons diffère du nombre d’événements de transfert de jetons. Une transaction peut contenir plusieurs événements. Préciser la statistique rapportée. Une tentative échouée peut compter parmi les tentatives tout en contribuant zéro au mouvement réussi.

La description finale doit nommer la fenêtre d’observation et la couverture fournie. L’historique enseigne ce qui s’est produit dans les enregistrements disponibles, pas pourquoi un acteur l’a choisi. Un transfert réussi n’est ni preuve d’affiliation ni signal de prix.

• Résultat d’exécution : réussite/échec de l’opération inspectée.
• Repère d’événement : transaction et chemin d’instruction/journal.
• Cadre d’appel : exécution imbriquée dans une transaction.
• Flux brut : somme des mouvements dans un sens.
• Variation nette : solde final moins solde initial.
• Payeur des frais : compte supportant le coût natif fourni.

ILLUSTRATIVE — FIX-P09-02. SIM-SOL-A / W / MINT-T. Effets complets uniquement pour T1–T3, ordre synthétique S1,S2,S3. Frais natifs normalisés et payés par W. Aucun autre effet dans la fenêtre. Solde initial de jetons : 100.

Dans l’exemple SIM-EVM-A distinct, E1 réussit avec appel principal W-E→ROUTER de valeur0 ; appel imbriqué ROUTER→C-E de valeur native2 et un journal Transfer de jetons pour7 unités de W-E vers C-E. Le jeu stipule des actifs/effets distincts et une couverture complète des appels. Aucun montant de frais n’est fourni pour E1.

OBSERVED dans le jeu : les trois vues de T1 décrivent un transfert de10 jetons ; T2 échoue ; T3 reçoit 4. E1 contient un appel de valeur nulle, un mouvement natif de 2 et un journal de 7 jetons.

INFERRED : sortie cible réussie 10, entrée 4, net−6 ; solde final 94. Les frais natifs T1–T3 totalisent 0.04.

UNKNOWN : historique antérieur, opérateurs humains, frais de E1 et motivations.

INSUFFICIENT EVIDENCE : H2/H3 ne peuvent ajouter20 jetons transférés supplémentaires. La tentative T2 ne compte pas comme sortie réussie de 20 jetons. L’appel imbriqué de E1 n’est pas une deuxième transaction signée indépendamment.

Additionner résumés et variations aux transferts ; assimiler inclusion et réussite ; traiter toute référence d’adresse comme action ; mélanger frais natifs et montants de jetons ; exclure des enregistrements indisponibles d’une affirmation de couverture.

Construire un registre de jetons dédoublonné pour T1–T3. Calculer flux bruts et net, solde final et frais. Classifier l’appel et les mouvements d’actifs de E1 sans totaliser des actifs différents.

• Consigner découverte et couverture historique.
• Vérifier le résultat d’exécution séparément de la finalité.
• Identifier les événements par transaction et chemin.
• Réconcilier flux bruts et solde net.
• Compter les frais une fois et préserver payeur/actif.
• Distinguer appels, journaux et attribution humaine.

La reconstruction historique est une comptabilité d’événements, pas un comptage de lignes. Mouvements réussis, tentatives échouées et frais répondent à des questions différentes.

Plusieurs vues peuvent décrire un transfert. Les appels imbriqués ne sont pas des transactions signées séparément. Les enregistrements manquants restent non résolus plutôt qu’absents.

Chronologie T1–T3 regroupant H1/H2/H3 en un événement, T2 échoué avec frais toujours fournis, T3 entrant4. Montrer flux10/4/net−6/solde final 94 et panneau distinct de frais 0.04. Séparer l’arbre d’appels E1 des lignes de montants natifs/de jetons.

Comptabilité d’événements illustrative ; les lignes et appels imbriqués ne sont pas des transactions indépendantes.

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.
• Frais Solana — Mécanisme des frais de transaction natifs ; ni mouvement de jetons ni modèle universel de coût. Vérifié le 2026-09-30.
• Traceurs intégrés de Geth — Périmètre de trace des cadres d’appel et configuration propre au traceur. Vérifié le 2026-09-30.
• API d’exécution Ethereum eth_getTransactionReceipt — Statut du reçu, rattachement à la transaction et journaux. 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-L03 après l’exercice corrigé et la révision des questions.