L'activation du format de transaction v1 de Solana est prévue le 9 septembre. Les programmes qui le liront mal ne renverront pas d'erreur, ils renverront zéro.

Un système public qui change la forme de ce qu'il écrit ne peut pas obliger ceux qui le lisent à changer avec lui. La seule chose qu'il décide, c'est comment le lecteur retardataire tombera en panne. Il peut le faire échouer bruyamment, en lui envoyant quelque chose qu'il ne reconnaît pas, et l'erreur remonte dans l'heure. Ou il peut le laisser échouer en silence, en lui envoyant quelque chose qu'il croit reconnaître, où le champ déplacé ne se trouve simplement plus. Le lecteur n'y trouve rien, écrit un zéro, et rien ne s'allume.

Une chaîne ne choisit pas qui la lit, elle choisit comment ils tombent en panne

Le chiffre qu'une institution reçoit de son fournisseur de données, puis inscrit dans un rapport, n'a pas été lu sur la chaîne par elle. Il a été fabriqué par une file de programmes qui ont ouvert un message, cherché un champ, et recopié ce qu'ils y ont trouvé. Ils sont des milliers, appartiennent à des équipes qui ne se connaissent pas, ne signent aucun bloc, et personne ne peut leur imposer un calendrier.

Le zéro est la panne coûteuse, parce qu'elle est légitime. Une erreur remonte : elle interrompt un traitement, elle réveille quelqu'un, elle se corrige le jour même. Un zéro passe le contrôle de cohérence, puisque c'est une valeur que des millions de messages portent réellement, et il entre dans la base, puis dans le rapport, puis dans la décision, sans que personne n'ait de raison d'y revenir.

La différence entre les deux ne tient pas à la qualité du code de celui qui lit. Elle se décide au dessin du format, à la question de savoir si un message annonce sa propre version ou s'il faut la deviner à la forme de son contenu. Quand elle se devine, la règle de devinette doit être réécrite à la main à chaque nouveau format, et rien n'oblige quiconque à l'écrire.

Ce que le format v1 déplace, et où il est réellement arrivé

Solana ajoute un troisième format de transaction, v1, reconnaissable à un octet en tête, 129, placé en position zéro pour être identifié sans rien désérialiser. Ce qu'il change, tel que le décrit la spécification SIMD-0385, tient en quatre lignes.

Le déplacement décisif est le dernier. En v1, le budget de calcul et le frais de priorité vivent dans un masque de configuration de quatre octets porté par l'en-tête, et les instructions du programme ComputeBudget sont ignorées pour la configuration, même invalides. Elles ne disparaissent pas de la transaction : elles cessent d'être lues.

Reste l'état réel du calendrier, et il ne correspond pas à ce qui circule. Les mesures CDR sur la porte de fonctionnalité, prises le 5 septembre 2026, donnent une activation sur testnet le 2 septembre et sur devnet le 3. Sur le réseau principal, la porte n'est pas inactive : le compte n'existe pas, et l'appel qui devrait le lire ne renvoie rien. L'activation n'a donc encore rien déclaré, ce qui compte, puisque le mécanisme publié par CDR le 22 août veut qu'une porte se déclare au premier slot d'une epoch et prenne effet une epoch plus tard. La date du 9 septembre, elle, vient d'un message publié le 29 août 2026 par un développeur d'Anza sur un réseau social, et aucun document de la Solana Foundation ni d'Anza consulté le 5 septembre ne la porte : c'est une cible annoncée, appuyée sur une source unique.

Deux réserves à joindre. La page de la Fondation, portant la mention d'une mise à jour en août 2026, affiche déjà le devnet comme actif quand la mesure place son activation au 3 septembre : deux explications tiennent, une mise à jour de page postérieure à son propre horodatage ou une réinitialisation du réseau, et aucune n'est prouvée. Et les sondages CDR qui n'y trouvent aucune transaction v1 portent sur huit blocs finalisés par réseau, le 5 septembre : ils autorisent « aucune dans cet échantillon », jamais « aucune sur la chaîne ». Que le testnet ne porte quasiment aucun trafic applicatif suffit toutefois à poser ce qui compte : la première transaction v1 que rencontrera la plupart des lecteurs de la chaîne sera une transaction de production.

Le réseau s'est fait prendre deux fois avant d'envoyer les autres

La panne silencieuse n'est pas une projection. Elle a eu lieu, deux fois, dans les implémentations de référence du réseau lui-même, et les numéros sont publics.

Le 13 août 2026, yellowstone-grpc, le canal de flux le plus utilisé de l'écosystème, corrige chez lui une conversion qui relisait toute transaction v1 comme une v0, sans erreur. Treize jours plus tard, Anza ouvre l'issue #14873 sur le même défaut dans son propre code d'archivage : les messages v1 y étaient décodés en v0 en jetant silencieusement leur configuration, les deux moitiés du travail ayant été ajoutées dans le même commit sans que le sens lecture soit traité. Correction fusionnée le 28 août, rétroportée le jour même dans les deux branches de production. Quinze jours séparent les deux corrections ; la première tombe vingt-sept jours avant la date d'activation annoncée, la seconde douze.

Le dégât documenté va plus loin qu'un chiffre faux. Anza l'écrit noir sur blanc : un message v1 reconstruit en v0 ne correspond plus aux octets qui ont été signés, sa re-sérialisation produit une empreinte différente, et la signature attachée ne se vérifie plus contre lui. Une archive mal décodée ne rend pas seulement un mauvais chiffre, elle rend une transaction qui ne prouve plus rien.

La Fondation nomme la cause dans sa section destinée aux indexeurs, et la formulation est franche : les flux Geyser et gRPC n'ont aucune barrière de version, il n'existe aucun champ de version au protobuf, et un consommateur périmé n'échoue pas sur une v1, il la relit en silence comme une v0 avec un budget de calcul vide. La correction structurelle, ajouter ce champ pour que l'oubli devienne une erreur de compilation, est proposée dans une issue Anza ouverte le 27 août et toujours ouverte au 5 septembre 2026. Son auteur y résume le dossier : rien n'oblige la règle à être écrite, et le compilateur s'est tu quand le lecteur v1 a été oublié.

Ce qui casse est ce qu'une transaction a demandé, pas ce qu'elle a payé

La couverture décrit correctement le mode de défaillance. Ce qui manque partout, c'est l'endroit où il atterrit, et il est plus étroit que ce qu'on lui prête.

L'adaptateur public qui produit la série de frais de Solana chez DefiLlama, lu le 5 septembre 2026, ne lit aucune instruction ComputeBudget. Il additionne le champ fee des transactions brutes, pose les frais de base à cinq mille lamports par transaction et déduit la part de priorité par soustraction. Il mesure ce qui a été payé. Cette série ne casse donc pas par le chemin du scan des instructions ComputeBudget, et la borne s'arrête là : la manière dont le fournisseur de données en amont traite les lignes v1 n'est publiée nulle part, et c'est l'unique dépendance de cette série. La méthode des autres tableaux de bord de frais de Solana n'étant pas documentée publiquement, rien de ce qui précède ne se généralise à eux.

Le paiement est inscrit dans un champ que le changement de format ne déplace pas, et une chaîne a tout intérêt à ne jamais y toucher. La demande, elle, a changé d'adresse. Et c'est la demande qui alimente tout ce qui parle du marché des frais : estimation de priorité, mesure de congestion, plafond de dépense d'un relayeur, garde-fou d'un programme qui conditionne son exécution au budget qu'il lit, comparaison historique du coût d'accès au bloc. Ces séries-là peuvent devenir fausses sans qu'aucune alarme ne se déclenche, parce que l'attention aura porté sur le revenu.

Deux corruptions distinctes s'y superposent, et les confondre coûte la moitié du sujet. La première vient d'un défaut de mise à jour et rend zéro. La seconde est un changement d'unité et n'épargne personne : v0 déclare un frais de priorité en micro-lamports par unité de calcul, donc un prix, v1 déclare un total en lamports, donc une quantité. Additionner les deux sans conversion revient à mélanger un prix et un total, dans un pipeline parfaitement à jour.

L'enjeu en volume n'est pas théorique. La série de frais de Solana chez DefiLlama, relevée le 5 septembre 2026, porte 249 millions de dollars sur douze mois. C'est le dénominateur qui sert aux multiples de valorisation.

Trois changements de couche basse en trois semaines, et ce qu'ils ont en commun

Le point de comparaison n'est pas une autre chaîne, c'est le même geste ailleurs. L'autre grande chaîne avait averti ses portefeuilles, ses indexeurs et ses estimateurs de frais trois semaines plus tôt qu'un nombre figé depuis 2015 cessait d'être universel, et la réserve tenue alors vaut ici mot pour mot : le nombre ne disparaissait pas, il cessait d'être vrai pour tout le monde, comme les instructions ComputeBudget ne disparaissent pas mais cessent d'être lues. Le 21 août, Solana raccourcissait la durée de ses blocs, et CDR posait le lendemain que le réseau ne devenait pas plus gros, mais plus rapide à se modifier lui-même, avec deux constats qui tiennent toujours : le débit par seconde ne bouge pas, et la mesure réelle donnait alors 366 ms là où la spécification annonçait 350. La durée de slot mesurée le 5 septembre sur le réseau principal, 315 ms sur cent mille slots, est une mesure neuve sur une autre fenêtre.

La qualité de la panne sépare pourtant ce troisième cas des deux premiers. Sur le gas d'Ethereum comme sur la durée de bloc de Solana, un lecteur retardataire obtient un chiffre faux mais plausible, qu'un contrôle de cohérence peut attraper. Ici, il obtient zéro, valeur parfaitement légitime, que rien ne relève.

Le fil qui relie ces épisodes à la lecture publiée par CDR le 1er juin sur SIMD-547 mérite d'être nommé, pour éviter la confusion. Juin portait sur le modèle de frais, quand la rareté de SOL cessait d'être un paramètre figé. Septembre porte sur la mesure des frais et sur son changement d'unité. Ce ne sont pas deux jugements contraires, ce sont deux étages du même objet.

Reste l'antécédent le plus engageant. CDR a mesuré sept chaînes, SOL comprise, et le multiple de revenu qu'il publie pour elle est bâti sur une série de frais douze mois, quand un multiple de revenu vaut ce que vaut la série qui lui sert de dénominateur. Cet article n'en retire rien : il y ajoute le contrôle qui manquait, celui de la robustesse d'une série au changement de format de la chaîne qu'elle mesure. Même chose pour les séries de revenu prises par le bon bout, où un flux ne se juge qu'une fois son émission déduite : la question n'est pas de savoir si ces séries valent quelque chose, mais où elles tiennent et où la dépendance reste ouverte.

Ce qui se jouera le 9 septembre, si la date tient, n'est donc pas la taille des transactions. C'est qu'un format qui ne dit pas sa propre version fait dépendre l'exactitude de milliers de chiffres publics de la lecture attentive d'une page de documentation par des équipes qui ne se connaissent pas. La correction existe, elle tient en un champ, elle n'a pas été retenue. La prochaine fois se prépare exactement de la même façon.

Questions fréquentes

Le format de transaction v1 est-il actif sur le réseau principal de Solana ?
Non. Au 5 septembre 2026, la porte de fonctionnalité n'existe pas sur le réseau principal : le compte n'est pas seulement inactif, il n'est pas créé, et l'appel qui devrait le lire ne renvoie rien. L'activation est prévue le 9 septembre, date annoncée le 29 août par un développeur d'Anza sur un réseau social et absente de tout document de la Solana Foundation comme d'Anza. Le format est actif sur testnet depuis le 2 septembre et sur devnet depuis le 3, mesures CDR sur la porte elle-même.

Les séries de revenus on-chain de Solana vont-elles devenir fausses ?
La série publique la plus citée mesure ce qui a été payé : son adaptateur, lu le 5 septembre 2026, n'ouvre aucune instruction ComputeBudget et déduit la part de priorité par soustraction. Elle ne casse donc pas par le chemin du scan des instructions ComputeBudget. Ce qui reste ouvert, et c'est sa seule dépendance, est le traitement des lignes v1 par le fournisseur de données en amont, qui n'est publié nulle part. Ce que le changement de format atteint, c'est ce qu'une transaction a demandé.

Un pipeline à jour est-il à l'abri ?
Pas entièrement. La première corruption vient d'un défaut de mise à jour et rend zéro. La seconde ne dépend d'aucune mise à jour : v0 exprime le frais de priorité en micro-lamports par unité de calcul, donc un prix, v1 en lamports au total, donc une quantité. Additionner les deux sans conversion mélange un prix et un total.

Comment un lecteur de la chaîne échoue-t-il bruyamment plutôt qu'en silence ?
Côté RPC, le mode bruyant existe et il est borné : sans le paramètre maxSupportedTransactionVersion réglé sur l'entier 1, getTransaction renvoie l'erreur -32015, getBlock échoue sur le bloc entier sans résultat partiel, et blockSubscribe se bloque au premier slot v1. Côté flux, il n'existe pas : aucun champ de version au protobuf, et un consommateur périmé relit une v1 comme une v0 avec un budget vide. La correction structurelle est proposée dans une issue Anza ouverte le 27 août, toujours ouverte au 5 septembre 2026.