Un explorateur de transactions Solana transforme une signature brute en page lisible : la transaction a-t-elle réussi, qui l’a signée, combien a-t-elle coûté et quels tokens ont bougé ? Tous les explorateurs, de Solscan à l’explorateur officiel Solana Explorer en passant par notre propre outil de recherche, lisent le même enregistrement on-chain via la méthode RPC getTransaction. Une fois que vous savez ce que signifie chaque champ, vous pouvez donc les lire tous. Vous trouverez ci-dessous une routine en six étapes, le détail champ par champ d’une page de transaction, un exemple commenté à partir d’un vrai transfert de token SPL et une partie dépannage pour les transactions échouées, introuvables ou abandonnées.
Comment vérifier une transaction Solana en six étapes
Le moyen le plus rapide de vérifier une transaction consiste à copier sa signature, à la coller dans un explorateur réglé sur le bon cluster et à lire d’abord la ligne de statut. Tout le reste de la page explique pourquoi ce statut est ce qu’il est.
- Copiez la signature de la transaction. L’écran d’activité de votre wallet ou la notification de confirmation de la dApp propose un lien « view on explorer » ou un bouton de copie. La signature est un texte base58, généralement de 87 ou 88 caractères.
- Collez-la dans un explorateur. Utilisez l’outil de recherche Solscanner, Solscan ou Solana Explorer, et vérifiez que le cluster Mainnet est sélectionné, et non Devnet.
- Vérifiez le statut et la finalité. Succès ou échec, c’est l’information principale. Juste à côté, cherchez processed, confirmed ou finalized.
- Lisez les frais, le calcul et les signataires. Ils indiquent qui a payé, combien, et à quel point la transaction était lourde.
- Inspectez les instructions et les soldes. La liste des instructions et les variations de solde des tokens montrent ce qui a réellement circulé entre quels comptes.
- Expliquez les échecs grâce aux logs. En cas de problème, les logs des programmes nomment l’instruction fautive et l’erreur.
Cette routine répond en moins d’une minute à la plupart des questions du type « mon virement est-il arrivé ? ». La suite de ce guide détaille ce que vous voyez à chaque étape, pour que vous puissiez lire la page au lieu de deviner.
Que signifie chaque champ de la page d’une transaction Solana ?
La page d’une transaction dans un explorateur Solana comporte partout les mêmes champs de base : signature, résultat, niveau d’engagement, slot, heure du bloc, frais, compute units, signataires, blockhash récent, version, instructions, variations de solde et logs. Les mises en page diffèrent, mais les données proviennent toutes d’une seule réponse RPC. La plupart des explorateurs étant en anglais, nous indiquons aussi les intitulés d’origine.
Signature. Une signature de transaction est la signature Ed25519 de 64 octets du premier signataire, encodée en base58. Elle sert aussi d’identifiant unique à la transaction. Si une transaction a plusieurs signataires, elle porte plusieurs signatures, mais les explorateurs l’indexent par la première.
Statut (Status/Result). Soit un succès, soit une erreur comme InstructionError accompagnée de l’index de l’instruction en échec. Une transaction échouée est tout de même enregistrée on-chain et paie tout de même ses frais.
Niveau d’engagement (processed, confirmed, finalized). Ce sont les trois niveaux de finalité. Processed signifie que le nœud interrogé a vu la transaction dans un bloc, mais que ce bloc n’a pas encore fait l’objet d’un vote. Confirmed signifie qu’une supermajorité du stake a voté sur le bloc. Finalized signifie que le bloc a atteint le verrouillage maximal et ne peut plus être annulé. Lisez processed comme « probablement », confirmed comme « quasi certain » et finalized comme « c’est fait ». Alpenglow, en test sur testnet en septembre 2026 sans date annoncée pour le mainnet, vise à ramener la finalité à environ 150 ms : ces intitulés pourraient donc fusionner à l’avenir.
Slot et heure du bloc (Block time). Le slot est la fenêtre de temps du leader pendant laquelle la transaction a été incluse. Les slots durent désormais environ 250 à 300 ms, depuis que SIMD-0525 les a réduits de 400 ms en août et septembre 2026. L’heure du bloc est l’horodatage Unix estimé de ce bloc, affiché dans votre fuseau horaire par la plupart des explorateurs.
Frais et frais de priorité (Fee, Priority fee). Les frais de base sont de 5 000 lamports par signature (0,000005 SOL) ; 50 % sont brûlés et 50 % vont au validateur. Des frais de priorité facultatifs s’y ajoutent : prix par compute unit multiplié par la limite de compute units, divisé par 1 000 000, et ils reviennent entièrement au validateur. La formule complète figure dans la documentation Solana sur les frais. Certains explorateurs séparent les deux, d’autres n’affichent que le total.
Compute units. Les compute units consommées mesurent le coût d’exécution. Le budget par défaut est de 200 000 CU par instruction, et le plafond absolu de 1 400 000 CU par transaction. Une transaction qui utilise presque toute sa limite demandée laisse penser qu’elle a échoué faute de calcul.
Signataires et payeur des frais (Signers, Fee payer). Le premier signataire est le payeur des frais. Les autres ont autorisé des instructions précises, par exemple le propriétaire d’un compte de token débité.
Blockhash récent (Recent blockhash). Chaque transaction référence un blockhash récent valable 150 slots. Il empêche les rejeux et fixe une échéance : si la transaction n’est pas incluse avant l’expiration du blockhash, elle ne pourra jamais l’être.
Transactions versionnées et tables de correspondance d’adresses
Une transaction versionnée (affichée « v0 » ou « Version 0 ») peut référencer une table de correspondance d’adresses (address lookup table), un compte on-chain qui stocke une liste d’adresses. Au lieu d’écrire chaque adresse de 32 octets dans le message, la transaction pointe vers des entrées de la table. C’est ce qui permet aux gros swaps de tenir dans la limite de 1 232 octets. Les explorateurs signalent ces comptes par la mention « loaded from lookup table » dans la liste des comptes ; l’étiquette « legacy » désigne simplement l’ancien format, sans table. La documentation sur les transactions décrit la structure du message.
À noter : une transaction peut lister au maximum 64 comptes. Si la liste des comptes vous paraît plus longue que prévu, la plupart ont sans doute été chargés depuis une table de correspondance d’adresses plutôt qu’écrits dans le message lui-même.
Instructions, instructions internes et variations de solde des tokens
Les instructions sont les opérations proprement dites : chacune désigne un programme et les comptes qu’il touche. Les instructions internes (inner instructions) sont les appels qu’un programme a passés à un autre pendant l’exécution, et les variations de solde des tokens résument le résultat net.
Un simple transfert de SOL comporte une seule instruction du System Program. Un transfert de token appelle le programme SPL Token (TokenkegQfeZyiNwAJbNbGKPFXCWuBvf9Ss623VQ5DA) ou Token-2022 (TokenzQdBNbLqP5VEhdkAS6EPFLC1PHnBqCXEpPxuEb). Un swap passé par un agrégateur peut afficher une seule instruction de premier niveau et une douzaine d’instructions internes, le routeur appelant plusieurs pools de DEX qui appellent chacun le programme de token. Pour savoir ce qui s’est vraiment passé, c’est dans les instructions internes qu’il faut regarder. Pour les pools et les routeurs, notre guide des explorateurs DeFi explique comment suivre la liquidité d’un programme à l’autre.
La section des soldes de tokens en est le résumé en clair : solde avant, solde après et écart pour chaque compte de token touché. C’est la section à capturer quand on vous demande une preuve de paiement. Les comptes de tokens étant distincts des wallets, les lignes affichent les adresses des comptes de tokens avec leur propriétaire à côté ; le guide pour vérifier un wallet Solana détaille les comptes de tokens associés, et le guide pour analyser un token couvre les mints et les décimales.
Lire les logs des programmes
Les logs des programmes sont les messages texte qu’affichent les programmes pendant leur exécution. C’est le champ le plus utile quand une transaction échoue, car l’erreur est généralement écrite en toutes lettres dans les dernières lignes.
Les logs se lisent de haut en bas comme une pile d’appels : « Program X invoke [1] », des messages, « Program X consumed N of M compute units », puis « Program X success ». Une exécution ratée se termine par « failed: » suivi d’une erreur comme insufficient funds, slippage tolerance exceeded ou un code d’erreur personnalisé. Ces codes personnalisés sont propres à chaque programme ; décodez-les avec l’IDL du programme, que Solana Explorer et Orb affichent pour les programmes vérifiés.
Exemple concret dans un explorateur de transactions Solana : un vrai transfert SPL
Voici une vraie transaction du mainnet que vous pouvez ouvrir vous-même. Il s’agit d’un simple transfert de token SPL, un exemple propre pour apprendre la mise en page.
WdQE153MoVzxf54wemBxUPXo88x6FDC4VDX2B2zKR9tF2j42QyaM1ub4R8ww7iY2fPcJ3b9F15eMcxCyVu9Sn4X
Collez cette signature dans notre outil de recherche et vous verrez ces valeurs :
| Champ | Valeur | Ce qu’il vous apprend |
|---|---|---|
| Statut | Success | Toutes les instructions exécutées |
| Slot | 449 561 050 | Où elle a été incluse |
| Frais | 5 000 lamports | Frais de base seuls, une signature |
| Frais de priorité | 0 lamport | Aucune enchère en plus |
| Compute units | 13 594 | Travail léger du programme de token |
| Signataire | ATAPZ…edYj5 | Payeur des frais et autorité |
Lisez-la comme un ticket de caisse. Les frais font exactement 5 000 lamports, soit une signature au tarif de base : l’expéditeur n’a payé aucuns frais de priorité, et il n’y a qu’un seul signataire : ATAPZxbrc7BAiunpoQPeGiPUbQgx5mGTNgyZgMPedYj5. Ce compte a à la fois payé les frais et autorisé le débit de son compte de token. Les 13 594 compute units ne représentent qu’une petite fraction du budget par défaut de 200 000 CU, ce qui est typique d’un transfert unique via le programme de token. Dans la liste des instructions, vous verrez l’instruction transfer du programme de token, et dans les variations de solde, un compte baisse et un autre augmente du même montant. Ouvrez la même signature sur Solscan ou Solana Explorer : les chiffres concordent, car les trois lisent un seul et même registre.
Comment vérifier une transaction sur Solscan et les autres explorateurs
Solscan, Solana Explorer et Orb acceptent tous une signature dans leur champ de recherche principal, et chacun présente les mêmes champs avec des priorités différentes. Le choix dépend surtout de votre façon de lire.
Solscan place une carte de synthèse en haut de page et regroupe les transferts de tokens dans un onglet dédié, ce qui explique pourquoi tant de gens qui cherchent comment vérifier une transaction sur Solscan finissent par l’adopter. Notre avis sur Solscan détaille ses onglets. Solana Explorer, géré par la Solana Foundation, affiche les données brutes des instructions, le profilage des compute units et une option de simulation, appréciés des développeurs. Orb by Helius ajoute des résumés rédigés par IA qui expliquent en langage clair ce qu’a fait une transaction. Pour un verdict comparatif, consultez notre classement des meilleurs explorateurs Solana. Pour les bundles Jito, où plusieurs transactions sont incluses ensemble avec un tip, le guide de l’explorateur de bundles Jito est le meilleur point de départ.
Transaction introuvable, échouée ou abandonnée : que faire ?
« Not found » signifie généralement que la transaction n’a jamais été incluse, « failed » qu’elle l’a été mais qu’une instruction a renvoyé une erreur, et « dropped » qu’elle a expiré avant qu’un leader ne l’inclue. Chaque cas a sa solution.
Transaction introuvable
Écartez d’abord les erreurs simples. Vérifiez que vous avez copié la signature entière : s’il manque le dernier caractère, vous obtenez une chaîne d’apparence valide mais inconnue. Vérifiez le cluster : une signature devnet n’apparaîtra jamais sur le mainnet, et le guide de l’explorateur devnet liste les bonnes URL. Attendez ensuite quelques secondes et relancez la recherche, car un nœud en retard n’a peut-être pas encore indexé le bloc. Si elle reste introuvable une fois la fenêtre du blockhash écoulée (150 slots, bien moins d’une minute aux temps de slot actuels), la transaction n’a pas été incluse.
Transaction échouée
Une transaction échouée apparaît on-chain avec une erreur, et les frais sont prélevés. Descendez jusqu’aux logs et lisez la dernière ligne « failed ». Les causes courantes : slippage sur un swap, trop peu de SOL restant pour la rent, un compte de token qui n’existe pas encore ou un dépassement de la limite de calcul. Corrigez la cause et envoyez une nouvelle transaction. Renvoyer le même message signé ne servira à rien.
Transaction abandonnée
Une transaction abandonnée a été envoyée au réseau, mais aucun leader ne l’a incluse avant l’expiration de son blockhash récent. Elle n’a laissé aucune trace de signature : aucuns frais n’ont été prélevés et rien n’a bougé. La congestion et des frais de priorité à zéro en sont les causes habituelles. Votre wallet peut la renvoyer avec un nouveau blockhash et de petits frais de priorité. Si c’est l’explorateur qui semble en panne plutôt que la transaction, notre page explorateur en panne liste des alternatives, et la référence getTransaction montre ce que renvoie l’appel RPC sous-jacent.
Pourquoi un explorateur de transactions Solana vaut mieux que l’historique du wallet
La liste d’activité d’un wallet est un résumé rédigé par l’application ; un explorateur de transactions Solana montre la source de vérité on-chain. Quand les deux divergent, faites confiance à l’explorateur.
Les wallets masquent les instructions internes, arrondissent les soldes et étiquettent parfois à tort un swap comme un envoi. Ils ne vous aident pas non plus quand une contrepartie affirme vous avoir payé. Avec la signature en main, n’importe qui peut vérifier en quelques secondes le statut, la finalité et le mouvement exact des tokens, sans compte et sans devoir faire confiance à l’une ou l’autre partie. C’est tout l’intérêt d’un registre public, et cela prend une trentaine de secondes une fois que vous savez quels champs lire. Si vous débutez avec les explorateurs, commencez par comprendre ce qu’est un explorateur Solana, puis revenez ici pour les détails.
Par l’équipe de recherche SolscannerMis à jour le · Méthodologie d’évaluation