Les relevés de récompenses de Solana n’indiquent plus le taux de commission appliqué à chaque versement : un staker voit combien de SOL lui sont parvenus, mais ne peut plus lire dans ce relevé quel prélèvement a été opéré. Le changement vient de la pull request n° 12588 d’Agave, fusionnée le 20 mai 2026 et activée avec la mise à jour SIMD-0232. Le prestataire de staking P2P.org date l’effet du 8 septembre dans un rapport publié le 30 octobre, CryptoSlate a repris le sujet le 1er novembre, et les données de la blockchain concordent avec cette date.
smart contract holding reserves of two or more tokens, supplied by users, that a decentralized exchange uses to execute trades automatically at a price set by a formula.">pool diverge, compared with simply holding the same tokens in a wallet. It becomes permanent when the provider withdraws.">Il s’agit d’un défaut de transparence, pas d’un prélèvement abusif. Aucun des documents consultés ne nomme un validateur ni ne l’accuse d’en avoir trop pris. Le calcul des récompenses utilise toujours la commission, et les montants sont écrits comme avant. Le relevé a perdu le taux, et rien d’autre.
Récompenses de staking Solana : ce que le relevé montre encore, et ce qu’il ne montre plus
Dans le code d’Agave, le champ commission_bps devient facultatif dans les structures de récompenses du runtime et reste vide dès que la fonctionnalité custom_commission_collector est active. Un commentaire du code précise qu’il sera toujours vide après l’activation de SIMD-0232 et pourra être supprimé lors d’un nettoyage ultérieur. La pull request dit sans détour que cela touche l’extérieur du réseau : le même champ alimente la réponse RPC getBlock et le message blockSubscribe de Geyser.
Les montants, commission_lamports et stake_reward, ne bougent pas. La somme versée à un validateur et celle versée à un délégataire restent donc consignées. Le pourcentage qui les relie, lui, a disparu, et la pull request a été livrée sans ticket associé ni note de migration. Un champ vide ne signifie pas qu’un validateur n’a rien prélevé, ce que CryptoSlate souligne aussi.
Pour les novices, le staking sur Solana consiste à déléguer des SOL à un validateur, qui garde un pourcentage des récompenses d’inflation. Ce taux figurait jusqu’ici à côté de chaque versement, et les logiciels tiers n’avaient qu’à le lire.
Un retrait voulu et débattu en public
Le retrait est délibéré et a été relu publiquement. SIMD-0232 permet aux validateurs de désigner des comptes collecteurs distincts pour les revenus de blocs et pour la commission d’inflation. Son auteur, Justin Starry, d’Anza, laisse inchangé le calcul du taux de commission d’inflation, et le texte ne dit rien des champs de RPC ni de reporting.
L’auteur de la pull request, buffalojoec, a soutenu qu’un taux unique n’a plus beaucoup de sens dans une récompense cumulée dès lors que les collecteurs peuvent être combinés à volonté. Le relecteur AshwinSekar a convenu que le publier « n’a pas beaucoup de sens » dans ce cadre.
Les récompenses de stake ont été le seul point de discussion. Le relecteur joncinque a demandé s’il fallait y conserver le taux, puisqu’« il n’y aura aucun mélange » sur une récompense de stake tant que le multi-stake n’est pas là. L’auteur préférait tout retirer partout, et joncinque a approuvé quand même : « Si nous sommes sûrs de ne pas vouloir les publier pour les stakes, ça me va ! » L’auteur a aussi noté en cours de relecture que le champ « ne fait pas partie du consensus » : le vider ne change donc pas ce sur quoi les validateurs s’accordent.
Le partage des revenus de blocs prévu par SIMD-0123 est un chantier distinct et n’est pas en cause. Son ticket de suivi, le n° 13538, était encore ouvert le 1er novembre, et, dans la pull request voisine n° 13503, un relecteur a relevé que block_reward « est toujours à zéro ici ».
La date du 8 septembre donnée par P2P.org se vérifie sur la chaîne
« Depuis le 8 septembre, Solana a cessé d’enregistrer le taux de commission appliqué aux récompenses de chaque époque », écrit P2P.org. Le fichier SIMD-0232 affiche « Activated » sans donner ni époque ni date ; c’est donc la chaîne qu’il faut interroger. Le compte de la fonctionnalité custom_commission_collector indique une activation au slot 445 392 000, premier slot de l’époque 1031, horodaté à 17 h 11 UTC le 8 septembre.
Les données de récompenses basculent au même moment. Une interrogation d’un serveur RPC public de Solana le 1er novembre, sur getBlock et getInflationReward, donne ceci. Deux blocs du versement du 7 septembre, pour l’époque 1029, listaient commissionBps sur leurs récompenses de staking, tout comme la récompense du plus gros validateur en stake (700, soit 7 %). Deux blocs du versement du 8 septembre, pour l’époque 1030, n’avaient plus ce champ sur environ 6 000 récompenses, et les lignes du même validateur pour les époques 1030, 1031, 1032 et 1072 n’en avaient pas non plus. C’est un échantillon, pas un audit complet, mais il concorde avec P2P.org sur la date et sur l’atteinte des deux types de relevés, ceux des votes comme ceux du staking.
P2P.org a aussi un service à vendre. Son rapport, signé André Caldeira, affirme que l’entreprise a rebâti sa couche de données autour des transactions, revendique 99,9 % de concordance avec ses propres instantanés sur des millions de comptes, et se termine en renvoyant vers son offre de reporting de récompenses. Aucune méthode n’est donnée pour ce chiffre, qui n’a pas pu être vérifié. Sur le point central, le rapport reste sobre : « La commission est prélevée comme avant et les montants des récompenses se réconcilient toujours. »
Selon P2P.org, le changement est intervenu sans annonce, des guides de migration tiers ont continué d’afficher l’ancien format, l’entreprise l’a repéré dès la première époque touchée et en a saisi la Fondation Solana et Anza. Aucune réponse publique de l’une ou l’autre n’a été relevée.
Commission des validateurs Solana : ce que les stakers peuvent vérifier aujourd’hui
Ce qui reste vérifiable :
- Les SOL reçus par chaque compte de stake, d’après le montant et le solde après versement inscrits dans le relevé.
- La commission qu’un validateur fixe en ce moment, via la méthode RPC
getVoteAccounts. - Les réglages passés de commission, en rejouant l’historique des transactions d’un compte de vote ou en passant par un outil qui le conserve.
Ce qui ne se vérifie pas à partir du seul relevé de versement :
- Le taux appliqué à une récompense donnée. Il faut désormais le reconstituer à partir de l’historique, ce qui, d’après P2P.org, oblige aussi à recomposer la délégation de l’époque.
- La ventilation des montants quand plusieurs comptes de vote partagent un collecteur. P2P.org affirme que ces sommes mutualisées ne peuvent plus être séparées.
CryptoSlate recense des outils pour la voie de l’historique, avec leurs limites. Le Validator History Program de Jito documente jusqu’à 512 époques par validateur, mais une valeur stockée ne prouve pas à elle seule qu’elle égale le taux différé derrière un versement précis. L’analyseur d’instantanés de Marinade publie l’ancienneté de chaque valeur ; c’est une méthode de reconstitution, sans promesse de couverture complète des archives. La méthode APY de Trillium contourne le taux affiché et mesure la croissance des comptes de stake à partir de l’époque 1070. Aucun de ces outils n’a été testé ici.
P2P.org indique que les relevés antérieurs au 8 septembre sont intacts, ce que confirment les entrées de l’époque 1029 relevées plus haut. Aucun cas d’une plateforme, d’un conservateur ou d’un outil fiscal en panne à cause de ce changement n’a été signalé.
Un second angle mort : le taux affiché n’est pas forcément le taux appliqué
Un problème voisin se situe ailleurs, et les deux ne doivent pas être confondus. D’après SIMD-0249, que les participants au débat disent actif sur le mainnet, les récompenses de l’époque E sont calculées au début de E+1 avec la commission enregistrée au début de E-1. Ce délai laisse aux délégataires le temps de partir après un changement de taux. Il signifie aussi que le chiffre d’un tableau de bord peut différer de celui qui s’applique.
Le ticket n° 16135, ouvert le 18 octobre par ax-x2, explique que getVoteAccounts peut afficher un réglage à 0 % alors qu’Agave utilise un taux de 100 % mémorisé pour l’époque en cours. Le ticket esquisse un schéma : monter la commission à 100 % vers la fin d’une époque, ramener la valeur affichée à 0 % après l’instantané, puis recommencer. C’est une hypothèse. Aucun cas observé n’est rapporté, et CryptoSlate précise que l’exemple du ticket ne désigne aucun incident constaté et n’établit pas de prélèvement excessif.
L’utilisateur GitHub ripatel-fd a soulevé la question plus largement en juillet, dans la discussion n° 583 du dépôt SIMD : « Les utilisateurs n’ont pas d’API RPC pour voir la commission effective actuelle et les collecteurs d’un compte de vote. »
| Date (2026) | Événement |
|---|---|
| 20 mai | Fusion de la pull request n° 12588 d’Agave |
| 16 juillet | Ouverture de la discussion n° 583 sur l’état caché de la commission |
| 8 septembre | Les relevés cessent d’indiquer le taux selon P2P.org ; fonctionnalité active dès l’époque 1031 à 17 h 11 UTC, selon les données de la chaîne |
| 18 octobre | Le ticket n° 16135 réclame la commission effective dans le RPC |
| 30 octobre | P2P.org publie son rapport du troisième trimestre |
Plusieurs correctifs sont sur la table, aucun n’est déployé
Le ticket n° 16135 propose une option facultative includeCommissionContext pour getVoteAccounts, qui renverrait le taux effectif avec son époque et son slot. Le 1er novembre, il n’avait ni responsable, ni commentaire, ni pull request liée.
Dans la discussion n° 583, SIMD-0511 stockerait on-chain l’état de commission et de collecteur de chaque époque, et un autre participant a évoqué un champ provisoire dans le compte de vote. En juillet, Justin Starry et joncinque penchaient pour livrer les deux SIMD tels quels et corriger ensuite. Le dernier commentaire, daté du 5 octobre, voit joncinque proposer un nouveau SIMD pour exploiter les adresses de collecteurs en vigueur, ce qui ne supprimerait pas totalement les caches.
Pour les détenteurs de jetons de staking liquide sur Solana, comme pour ceux qui délèguent directement, rien dans les sources n’indique un changement de ce qui est versé. Le sujet est aussi distinct de l’incident du validateur Solflare de fin octobre.
P2P.org range, parmi ses points de vigilance du quatrième trimestre, une source reconnue pour les taux appliqués passés, ou une norme de reporting.