Transaction Solana échouée : comment savoir si votre échange est réellement passé

Si votre échange sur Solana s’affiche en rouge dans l’explorateur, la réponse courte est la suivante : la transaction a bien été intégrée à un bloc, mais son instruction n’a pas été exécutée. Votre solde est inchangé, les frais ont tout de même été prélevés et une seconde tentative est permise. Cryptoticker.io a mesuré lui-même la fréquence du phénomène le 14 septembre 2026 : sur 36 blocs consécutifs de la chaîne principale de Solana, entre une transaction sur huit et une transaction sur deux ont échoué, selon le bloc.

Il ne s’agit ni d’une situation exceptionnelle ni d’une panne du réseau. C’est le fonctionnement ordinaire d’une chaîne dont une large part du trafic provient de programmes de négociation automatisés qui perdent sciemment plus souvent qu’ils ne gagnent. Pour vous, investisseur, cela emporte une conséquence pratique : une ligne rouge dans l’explorateur ne signifie presque jamais qu’un problème affecte votre portefeuille.

Transaction Solana échouée : ce que le statut signifie réellement

Une transaction Solana franchit deux obstacles distincts. Le premier est l’intégration dans un bloc : un validateur reçoit votre transaction, vérifie la signature et l’inscrit dans le prochain créneau dont il a la charge. Le second obstacle est l’exécution : le programme sollicité déroule l’instruction et détermine si elle est valide.

Échouée signifie toujours, sur Solana, que le premier obstacle a été franchi et le second non. La transaction figure durablement dans la chaîne, avec horodatage, signature et objet d’erreur. Elle se distingue ainsi d’une transaction qui n’est jamais arrivée : celle-ci n’apparaît pas du tout dans l’explorateur, ayant été écartée avant qu’un validateur ne l’inscrive dans un bloc.

Cette différence compte davantage qu’il n’y paraît. Chez Bitcoin, une transaction reste bloquée dans le mempool et attend confirmation, parfois pendant des heures. Sur Solana, cet état d’attente n’existe quasiment pas : en quelques secondes, il est tranché si votre transaction a réussi, a échoué ou n’a tout simplement pas été reprise.

Pourquoi votre solde reste inchangé après un échec

Solana exécute chaque transaction de manière atomique. Ou bien toutes les instructions qu’elle contient passent, ou bien aucune. Si une instruction s’interrompt sur une erreur, l’environnement d’exécution annule l’intégralité des modifications de comptes de la transaction. L’échange n’a pas lieu, les jetons restent où ils étaient.

Ce qui n’est pas annulé, ce sont les frais. Ils rémunèrent le fait que les validateurs ont vérifié votre transaction et consacré du temps de calcul, et cette charge a été engagée indépendamment de la validité finale de l’instruction.

Notre mesure : combien de transactions Solana ont échoué dans la fenêtre observée

Pour cet article, nous avons analysé le 14 septembre 2026 trois fenêtres temporelles distinctes de la chaîne principale de Solana, toutes situées dans l’époque 1034, autour du créneau 446 981 000. Nous avons interrogé le point d’accès RPC public du réseau et examiné l’objet d’erreur de chaque transaction des blocs concernés.

Les transactions de vote des validateurs ont été retirées du calcul. Elles représentent sur Solana une grande partie du volume, fonctionnent de façon entièrement automatique et n’échouent pratiquement jamais. Dans notre première fenêtre, elles étaient 9 390, dont 36 ont échoué, soit un taux de 0,38 %. Les compter revient à obtenir un chiffre dénué de sens pour les utilisateurs.

Restent les transactions que des personnes et des programmes de négociation envoient réellement. Nous en avons analysé 17 987 réparties sur 36 blocs :

• Fenêtre 1, 14 blocs, 7 905 transactions : 41,9 % d’échecs
• Fenêtre 2, 10 blocs, 4 133 transactions : 22,0 % d’échecs
• Fenêtre 3, 12 blocs, 5 949 transactions : 29,6 % d’échecs

Sur les trois fenêtres réunies, cela donne 33,2 %. Ce chiffre ne doit pas se lire comme une constante. Certains blocs affichaient 13,2 %, d’autres 66,1 %, et l’écart entre les trois fenêtres montre l’ampleur des variations en quelques minutes. Ce qui tient, c’est l’ordre de grandeur : grossièrement, une transaction hors vote sur trois ne passe pas sur Solana.

Pourquoi une transaction Solana échouée coûte malgré tout des frais

Les frais de base sur Solana s’élèvent à 5 000 lamports par signature. Un lamport correspond à un milliardième de SOL ; les frais de base représentent donc 0,000005 SOL. Au cours du SOL de 87,79 euros le 14 septembre 2026 selon CoinGecko, cela représente environ 0,0004 euro, soit une fraction de centime.

Dans notre troisième fenêtre, 0,1371 SOL au total ont été versés en frais. Sur ce montant, 0,0416 SOL revenaient à des transactions ayant ensuite échoué, soit une part de 30,4 %. Converti, cela représente quelque 3,65 euros sur douze blocs, un ordre de grandeur qui, rapporté à une journée, compte pour le réseau et ne compte pas pour vous personnellement.

Le préjudice économique d’un échec se situe donc ailleurs. Ce qui fait mal, c’est le cours plutôt que les frais : si votre vente échoue à un prix donné et que vous renvoyez l’ordre trente secondes plus tard, vous négociez au prix qui s’applique alors. Qui échoue plusieurs fois de suite sur un marché rapide paie la différence.

Frais de priorité et taux d’échec : ce que la mesure dit du supplément

La règle empirique répandue veut qu’en cas de difficulté, il suffise d’augmenter les frais de priorité. Les frais de priorité constituent un supplément facultatif aux frais de base, par lequel vous signalez au validateur qu’il doit traiter votre transaction en priorité. Dans notre troisième fenêtre, nous avons calculé pour chacune des 5 949 transactions le supplément versé au-delà des frais de base et établi le taux d’échec par tranche de prix.

Le résultat contredit la règle empirique. Les transactions sans aucun supplément ont échoué le plus rarement dans notre fenêtre, celles assorties d’un petit supplément le plus souvent. Au sein du groupe payant, le taux d’échec diminue à mesure que le supplément augmente, sans jamais retomber au niveau du groupe qui ne paie rien.

Il ne s’ensuit pas qu’un supplément nuise. Ce que nous mesurons ici relève de la composition, non de l’effet. Qui paie un supplément a généralement une raison de le faire : il se bat contre d’autres programmes pour le même prix et accepte de perdre souvent la course. Qui n’en paie aucun envoie typiquement un simple virement, où il n’y a rien à perdre. Les deux groupes font des choses différentes, et cela explique l’écart mieux que le prix.

Concrètement : un supplément plus élevé vous aide à être intégré lorsque la chaîne est saturée. Contre une instruction rejetée sur le fond, il ne sert à rien. Le supplément médian s’établissait dans notre fenêtre à 163 lamports, le quatre-vingt-dixième centile à 12 011 lamports, et 31,0 % de l’ensemble des transactions n’ont versé aucun supplément.

Lire une InstructionError : ce que révèlent l’indice d’erreur et le code personnalisé

Lorsque vous cliquez dans l’explorateur sur une transaction en échec, vous voyez un objet d’erreur de forme fixe, par exemple InstructionError: [3, {"Custom": 6001}]. Il contient deux indications, toutes deux utiles.

Le premier nombre est l’indice d’erreur : la position, comptée à partir de zéro, de l’instruction qui s’est interrompue au sein de votre transaction. Un trois signifie que les trois premières instructions se sont déroulées et que la quatrième a échoué. Dans un échange, les premières instructions sont souvent des préparatifs, comme la fixation du budget de calcul, et l’instruction de négociation proprement dite vient plus loin.

La seconde indication est le code personnalisé : un numéro d’erreur qui ne provient pas du réseau mais du programme ayant rejeté l’instruction. Un même numéro recouvre deux réalités différentes dans deux programmes différents. Les codes les plus fréquents dans notre première fenêtre étaient le 11 avec 631 occurrences, le 6001 avec 394 occurrences réparties sur deux indices d’erreur, le 1 avec 173 occurrences et le 7 avec 124 occurrences.

Codes d’erreur Anchor à partir de 6000 : pourquoi le nombre seul n’explique rien

Une partie de ces codes se laisse situer sans connaître le programme concerné. Beaucoup de programmes Solana sont bâtis avec le cadre de développement Anchor, qui attribue des plages de numéros selon un schéma fixe : à partir de 100 les erreurs d’instruction, à partir de 2000 les erreurs de condition, à partir de 3000 les erreurs de compte, et à partir de 6000 commencent les erreurs propres à chaque programme.

Un code comme 6001 provient donc de la plage que le programme s’est lui-même attribuée. Sa signification concrète figure dans la description d’interface de ce programme, que l’explorateur affiche pour les programmes qu’il connaît. Les codes bas comme 1 ou 11 émanent en revanche le plus souvent de programmes extérieurs à ce cadre, la gestion des jetons du réseau par exemple.

Pour vous, cela signifie : relevez l’indice d’erreur et le code, mais n’en déduisez aucune cause à partir du seul nombre. C’est l’explorateur qui fournit la correspondance, non le numéro.

Vérifier soi-même le statut d’une transaction : signature, explorateur et getSignatureStatuses

Avant de répéter une transaction, établissez son statut. Une seconde tentative alors que la première est encore en cours peut, au pire, faire passer les deux et vous faire échanger deux fois.

La voie simple passe par la signature, l’identifiant unique de votre transaction. Chaque portefeuille l’affiche après l’envoi, le plus souvent sous forme d’une longue chaîne assortie d’un lien vers l’explorateur. Si vous y trouvez la signature avec une coche verte, l’opération a eu lieu. Si elle y figure comme ayant échoué, l’échec est définitif et vous pouvez renvoyer sans risque.

Si vous ne trouvez pas du tout la signature, votre transaction n’a jamais été intégrée à un bloc. Là aussi, une seconde tentative est sûre, car chaque transaction Solana contient un hachage de bloc récent et expire dès que celui-ci devient trop ancien. La fenêtre est courte et se situe autour d’une minute et demie.

Qui veut davantage de précision interroge directement le réseau. La méthode RPC getSignatureStatuses de la documentation Solana renvoie pour une signature le degré de confirmation et, le cas échéant, l’objet d’erreur. C’est le jeu de données dont provient également notre mesure.

L’affichage que votre portefeuille vous propose varie considérablement. Certains programmes indiquent seulement « réussi » ou « échoué », d’autres font apparaître directement le code d’erreur et l’étape d’instruction concernée. Un coup d’œil au comparatif des portefeuilles logiciels vaut donc aussi sous cet angle.

Tolérance de prix, hachage de bloc et provision du compte : les causes les plus courantes

Trois causes couvrent l’essentiel des échecs que les particuliers rencontrent réellement.

La première est la tolérance de prix, autrement dit la fourchette que vous acceptez encore lors d’un échange. Les programmes de négociation sur Solana vérifient cette limite à la fin du calcul. Si le cours a bougé, entre l’envoi et l’exécution, davantage que ce qui est autorisé, l’instruction s’interrompt. C’est une fonction de protection et non un défaut. Une limite très serrée vous protège des mauvais cours et augmente en même temps le nombre d’échecs.

La deuxième est le hachage de bloc expiré. Chaque transaction renvoie à un bloc produit récemment et n’est valable que pour un nombre limité de blocs ensuite. Si vous confirmez dans votre portefeuille avec du retard, parce que vous avez posé l’appareil entre-temps, elle peut expirer avant d’arriver. Dans ce cas, elle n’apparaît même pas dans l’explorateur.

La troisième est la provision insuffisante du compte, et non pas sur le jeton négocié mais sur le SOL lui-même. Chaque transaction a besoin de SOL pour les frais, et l’ouverture d’un nouveau compte de jetons exige en plus un dépôt minimal. Qui échange la totalité de son SOL ne peut plus envoyer la moindre transaction ensuite. Laisser une petite réserve sur le compte évite cette situation.

Si vos fonds proviennent d’une plateforme de négociation, il vaut la peine, avant le premier échange, de regarder quelles voies de retrait votre prestataire propose et quels frais il applique. Notre comparatif des plateformes crypto classe les prestataires courants selon ces critères.

Format de transaction v1 : ce que la mise à niveau de Solana change et ce qu’elle ne change pas

Depuis le 9 septembre 2026, un nouveau format de transaction est actif sur Solana ; il porte la taille maximale d’une transaction de 1 232 à 4 096 octets. Nous avons décrit en détail cette bascule et ses conséquences par avance. Notre mesure intervient cinq jours plus tard et montre une chaîne en fonctionnement ordinaire.

Le format ne change guère le taux d’échec, ce à quoi il fallait s’attendre. Une transaction plus volumineuse peut contenir davantage d’instructions, mais elle n’en est pas acceptée plus facilement. Qu’un programme rejette votre échange parce que le prix s’est envolé ne dépend pas du nombre d’octets qu’occupe l’instruction.

La prochaine intervention d’ampleur est le mécanisme de consensus Alpenglow, annoncé pour octobre 2026, qui doit raccourcir sensiblement le délai jusqu’à l’irrévocabilité d’une transaction. Les exploitants d’un nœud doivent s’y préparer ; pour vous, utilisateur, le déroulement ne change pas. Là encore, une irrévocabilité plus rapide raccourcit l’attente, elle ne transforme pas une instruction rejetée en instruction valide.

Limites de la mesure : ce que cette analyse ne montre pas

Notre relevé porte sur 36 blocs issus de trois fenêtres temporelles d’une seule journée. Cela suffit à établir l’ordre de grandeur, et ne suffit pas à énoncer une moyenne hebdomadaire ou mensuelle. L’écart de 13,2 à 66,1 % entre blocs montre à quelle vitesse la valeur se déplace.

Nous n’avons pas pu déterminer non plus quelle proportion des transactions en échec émanait de particuliers et quelle proportion de programmes de négociation automatisés. Cette distinction ne se tire pas proprement des données de blocs, les deux sollicitant les mêmes programmes. L’appréciation répandue selon laquelle la part prépondérante relève de l’arbitrage automatisé concorde avec la structure de nos données, sans que cette méthode permette de l’établir.

Le taux d’échec réel pour une personne qui déclenche un échange de temps à autre devrait donc se situer nettement en dessous de notre valeur d’ensemble. De combien, la question reste ouverte.

Ce qui demeure inchangé, en revanche, c’est le mécanisme, et il constitue le véritable propos de cet article : l’intégration et l’exécution sont deux étapes, seule la seconde décide de votre échange, et l’explorateur vous dit sans ambiguïté laquelle des deux a lâché.

Cryptoticker.io a réalisé lui-même cette analyse le 14 septembre 2026.

Vérifier le taux d’échec sur Solana : ce qu’il faut retenir

1. Vérifiez la signature avant de renvoyer. Coche verte signifie effectué, marquage rouge signifie échec définitif, absence totale d’entrée signifie jamais arrivé. Dans les trois cas, vous savez si une seconde tentative échangerait deux fois. Quel portefeuille vous affiche réellement le code d’erreur et l’étape d’instruction figure dans le comparatif des portefeuilles logiciels.
2. Traitez la tolérance de prix comme un réglage et non comme une source d’erreurs. Si votre échange échoue plusieurs fois au même endroit, la limite est trop serrée pour le mouvement de marché en cours. L’élargir signifie plus de risque de prix, la resserrer signifie plus d’échecs. Qui échange régulièrement des montants importants examine les conditions des places de négociation dans le comparatif des plateformes.
3. Gardez une réserve de SOL sur le compte. Sans SOL pour les frais et le dépôt de compte, aucune transaction ne passe, pas même celle censée résoudre le problème. Qui laisse tourner ses échanges en automatique doit prévoir fermement ce matelas ; les outils qui le gèrent figurent dans le comparatif des robots de trading.

(Au 14 septembre 2026. Cet article ne constitue pas un conseil en investissement. Les cours et les grilles tarifaires évoluent ; vérifiez les conditions auprès du prestataire avant tout achat.)