Table des matières:
XRP Ledger : l’amendement fixCleanup3_3_0 pourrait être activé le 11 septembre 2026
Selon CryptoTicker, l’amendement fixCleanup3_3_0 du XRP Ledger pourrait être activé le 11 septembre 2026 à 11 h 15 UTC, soit 13 h 15 en heure d’été d’Europe centrale. Cette date représente le moment d’activation le plus précoce possible, sous réserve que le soutien des validateurs reste supérieur à 80 % pendant quatorze jours sans interruption.
L’analyse publiée le 9 septembre 2026 indique que l’amendement constitue principalement un ensemble de correctifs techniques. Les détenteurs de XRP utilisant une plateforme d’échange ou une application de portefeuille entretenue n’auraient généralement aucune action à effectuer, tandis que les exploitants de nœuds, les utilisateurs d’interfaces auto-hébergées et les détenteurs de positions AMM doivent vérifier leur environnement.
« Le 11 septembre 2026 à 11 h 15 UTC, l’amendement fixCleanup3_3_0 peut être activé sur le XRP Ledger. » — CryptoTicker
À retenir : l’échéance concerne avant tout la maintenance des infrastructures et des fonctions avancées du XRP Ledger, plutôt que les paiements ordinaires ou les soldes en XRP.
Un ensemble de correctifs portant sur six domaines du protocole
CryptoTicker décrit fixCleanup3_3_0 comme un ensemble de correctifs et non comme une nouvelle fonctionnalité. Les modifications concernent les Single Asset Vaults, le Lending Protocol, les Automated Market Makers, le Permissioned DEX, les Checks et les pseudo-comptes.
Le correctif harmonise notamment les contrôles de gel lors des transferts depuis des pseudo-comptes et rejette dès la vérification préalable les identifiants de Check mal formés. Il corrige également une erreur dans la suppression d’offres hybrides et ajoute un contrôle des pertes d’arrondi lors des dépôts, retraits et reprises dans les pools AMM, lorsque l’amendement fixAMMv1_3 est lui aussi actif.
- Harmonisation des contrôles de gel liés aux pseudo-comptes.
- Rejet des identifiants de Check mal formés.
- Correction d’une erreur dans la suppression d’offres hybrides.
- Contrôle des pertes d’arrondi dans certaines opérations AMM.
- Ajout de l’invariante ObjectHasPseudoAccount.
La nouvelle invariante ObjectHasPseudoAccount doit garantir que la suppression d’une entrée du registre entraîne également la disparition du pseudo-compte associé. D’après CryptoTicker, ces changements relèvent davantage de la maintenance interne que d’une évolution directement visible par la majorité des utilisateurs.
À retenir : fixCleanup3_3_0 vise six catégories d’objets et renforce plusieurs contrôles de cohérence, notamment autour des pseudo-comptes et des pools AMM.
La règle des 80 % et le délai de quatorze jours
La procédure d’activation décrite par CryptoTicker exige qu’un amendement obtienne le soutien de plus de 80 % des validateurs écoutés par un serveur pendant deux semaines sans interruption. Si le soutien retombe à 80 % ou en dessous, le délai repart de zéro.
Le vote est mesuré lors des « flag ledgers », qui apparaissent tous les 256 ledgers, soit en moyenne toutes les quinze minutes. Au flag ledger, les validateurs votent ; un ledger plus tard, le réseau inscrit une pseudo-transaction avec le résultat ; deux ledgers après le flag ledger, la nouvelle règle peut produire ses effets sur les transactions.
| Élément | Valeur indiquée par CryptoTicker |
|---|---|
| Seuil requis | Plus de 80 % |
| Durée du soutien | Deux semaines |
| Intervalle des flag ledgers | Tous les 256 ledgers |
| Rythme moyen | Environ quinze minutes |
Cette procédure signifie que le 11 septembre constitue une date la plus précoce possible et non une garantie absolue d’activation. Une baisse du soutien au seuil requis ou en dessous avant l’échéance ferait disparaître l’entrée de majorité et relancerait le décompte.
À retenir : l’activation dépend du maintien du soutien au-dessus de 80 % pendant quatorze jours consécutifs, avec une vérification régulière lors des flag ledgers.
État mesuré du registre : 93 amendements actifs et onze en attente
CryptoTicker indique avoir interrogé un nœud XRPL public le 9 septembre 2026 à 00 h 52 UTC. Ce nœud portait alors le registre validé numéro 106 856 830 et annonçait la version de serveur 3.3.0.
L’analyse a utilisé un appel feature pour obtenir la liste des amendements connus du serveur ainsi qu’un appel ledger_entry sur l’objet Amendments du registre. Sur les 104 amendements connus du serveur, 93 étaient actifs et onze en attente.
| Indicateur | Valeur |
|---|---|
| Amendements connus du serveur | 104 |
| Amendements actifs | 93 |
| Amendements en attente | onze |
| Amendements en attente avec une entrée de majorité | un |
| Amendement concerné | fixCleanup3_3_0 |
| Date de clôture enregistrée | 28 août 2026, 11 h 15 UTC |
| Activation la plus précoce possible | 11 septembre 2026 à 11 h 15 UTC |
Selon la source, le registre situe l’atteinte de la majorité au 28 août 2026, et non au 6 août comme cela a pu être indiqué dans certains comptes rendus. CryptoTicker précise également que l’heure enregistrée est en UTC, ce qui place l’échéance à 13 h 15 en heure d’été d’Europe centrale.
Le taux d’approbation rapporté en dernier lieu était de 82,86 % pour 29 voix favorables. CryptoTicker précise toutefois que cette donnée provient d’analyses tierces et constitue un instantané, qui ne garantit pas le maintien du seuil jusqu’au 11 septembre.
À retenir : le registre mesuré par CryptoTicker affichait 93 amendements actifs, onze en attente et une seule entrée de majorité, celle de fixCleanup3_3_0.
Les fonctions Single Asset Vault et Lending Protocol ne sont pas encore actives
CryptoTicker souligne que SingleAssetVault et LendingProtocol figuraient eux-mêmes parmi les onze amendements en attente. Ils n’étaient donc pas activés sur le réseau principal au moment de la mesure.
La même situation concernait ConfidentialTransfer, DynamicMPT, BatchV1_1, Sponsor, XChainBridge, PermissionDelegationV1_1, CryptoConditionsSuite et fixXChainRewardRounding. Aucun de ces dix amendements ne portait alors d’entrée de majorité.
La source en déduit qu’une personne ne pouvait pas détenir, sur le réseau principal, une position de crédit directement liée au protocole XRPL, puisque cette fonction n’était pas active. Le correctif intervient donc avant l’ouverture de la fonction, dans une phase de préparation technique.
- SingleAssetVault : en attente.
- LendingProtocol : en attente.
- ConfidentialTransfer : en attente.
- DynamicMPT : en attente.
- BatchV1_1 : en attente.
- Sponsor : en attente.
- XChainBridge : en attente.
- PermissionDelegationV1_1 : en attente.
- CryptoConditionsSuite : en attente.
- fixXChainRewardRounding : en attente.
À retenir : CryptoTicker conteste l’idée qu’il serait déjà nécessaire de sécuriser une position de coffre ou de prêt native sur le réseau principal, puisque ces fonctions n’étaient pas actives au moment de l’analyse.
Les nœuds obsolètes risquent l’état « amendment blocked »
Un serveur qui ne connaît pas une règle devenue active sur le réseau passe dans l’état « amendment blocked », explique CryptoTicker. Dans cette situation, il ne peut plus valider de registres, soumettre ou traiter des transactions, participer au consensus ni voter sur les amendements à venir.
Le serveur suit les amendements activés par le reste du réseau, même si son propre vote était négatif. Un vote contre ne permet donc pas de continuer à fonctionner avec une version obsolète ; seule une mise à jour peut éviter le blocage.
Le nœud public interrogé par CryptoTicker fonctionnait en version 3.3.0 et ne signalait aucun blocage au moment de la mesure. La source recommande aux opérateurs de vérifier la version de leur serveur avant l’activation éventuelle de fixCleanup3_3_0.
À retenir : un nœud non mis à jour peut sortir du consensus et cesser de traiter les transactions après l’activation d’un amendement qu’il ne connaît pas.
Plateformes d’échange : l’obligation de mise à jour revient au prestataire
Lorsque les XRP sont conservés sur une plateforme de négociation, le nœud appartient au prestataire. CryptoTicker indique que l’obligation de mise à jour lui incombe et que le changement devrait généralement passer inaperçu pour le client.
La source recommande néanmoins de consulter la page d’état ou les annonces de la plateforme afin de vérifier si une fenêtre de maintenance est prévue le 11 septembre. Les plateformes peuvent suspendre temporairement les dépôts et les retraits d’une chaîne pendant une mise à niveau.
CryptoTicker conseille également d’examiner les opérations programmées autour de cette date, notamment les plans d’investissement automatiques et les retraits récurrents. La source invite enfin les utilisateurs à identifier précisément les comptes et solutions de conservation où se trouvent leurs XRP.
À retenir : les clients d’une plateforme n’ont normalement pas à mettre à jour un nœud, mais ils peuvent vérifier les annonces de maintenance et les opérations programmées.
Portefeuilles personnels et infrastructures auto-hébergées
Les utilisateurs qui exploitent leur propre infrastructure doivent effectuer une vérification de version. Cette catégorie comprend notamment les personnes utilisant un portefeuille auto-hébergé avec leur propre accès au réseau, traitant des paiements via leur propre interface ou faisant tourner un nœud pour un service.
CryptoTicker recommande d’utiliser l’appel server_info afin de consulter le champ build_version ainsi que le champ amendment_blocked. La source indique que la version 3.3.0 ou supérieure connaît l’amendement.
- Interroger le serveur et vérifier build_version ainsi que amendment_blocked.
- Contrôler le numéro de version du portefeuille dans ses réglages.
- Vérifier les scripts, outils comptables et suiveurs de portefeuille qui disposent de leur propre accès au réseau.
Un portefeuille mis à jour automatiquement par sa boutique d’applications est généralement moins exposé à un retard de version, tandis qu’une version de bureau entretenue manuellement nécessite une vérification directe. CryptoTicker avertit également qu’un nœud bloqué peut simplement cesser de répondre sans afficher un message d’erreur explicite.
À retenir : les utilisateurs disposant d’un accès réseau auto-hébergé doivent contrôler la version du serveur, du portefeuille et des outils intermédiaires.
Les positions AMM : un contrôle supplémentaire contre les pertes d’arrondi
Les Automated Market Makers du XRP Ledger sont déjà actifs sur le réseau principal. CryptoTicker décrit ces pools comme des espaces de négociation dans lesquels deux actifs sont déposés et dont les prix sont déterminés par une formule fixe.
Le correctif ajoute un contrôle des pertes d’arrondi lors des dépôts, retraits et reprises, à condition que fixAMMv1_3 soit également actif. La source explique que ces pertes apparaissent lorsqu’un calcul effectué avec un nombre limité de décimales tronque des chiffres après la virgule, en particulier pour des montants très faibles ou très inégalement répartis.
L’activation ne modifierait pas les parts détenues dans un pool AMM. En revanche, une transaction auparavant acceptée pourrait être rejetée après l’activation si elle échoue au nouveau contrôle, ce qui pourrait nécessiter une nouvelle tentative ajustée.
À retenir : les détenteurs de parts AMM ne devraient pas voir leur position modifiée, mais certaines opérations peuvent être soumises à un contrôle plus strict.
Comment confirmer l’activation de fixCleanup3_3_0
Jusqu’à l’échéance, le réseau continue d’atteindre un flag ledger environ toutes les quinze minutes et les validateurs poursuivent leur vote. Si l’approbation reste supérieure à 80 %, l’entrée de majorité subsiste ; si elle tombe à 80 % ou en dessous, le décompte de quatorze jours recommence.
Après l’activation, fixCleanup3_3_0 doit passer de la liste des amendements en attente à celle des amendements actifs dans la requête feature. Le nombre d’entrées actives dans l’objet Amendments doit alors passer de 93 à 94.
| Vérification après activation | État attendu |
|---|---|
| Présence de fixCleanup3_3_0 | Liste des amendements actifs |
| Nombre d’amendements actifs | Passage de 93 à 94 |
À retenir : la requête feature et l’objet Amendments permettent de vérifier directement si l’amendement est passé de l’état « en attente » à l’état « actif ».
Pas d’indication directe sur le cours du XRP
CryptoTicker estime qu’un ensemble de correctifs internes ne permet pas de déduire une direction de cours. L’amendement n’augmente pas la capacité de transaction, ne réduit pas les frais et n’ouvre pas de nouvelle fonction.
Son effet potentiel est indirect : il corrige certaines briques techniques qui doivent soutenir les fonctions encore en attente liées aux coffres et au crédit. La source distingue donc la maintenance du protocole d’un événement de marché et considère que la description de « grande mise à niveau » ne correspond pas au contenu de l’ensemble de correctifs.
À retenir : l’article ne présente pas fixCleanup3_3_0 comme un signal permettant de prévoir l’évolution du cours du XRP.
Les vérifications recommandées avant le 11 septembre
CryptoTicker recommande en premier lieu de déterminer où sont conservés les XRP. Sur une plateforme, il convient de consulter la page d’état et les annonces du prestataire ; en conservation personnelle, la mise à jour de l’infrastructure relève de l’utilisateur.
Les détenteurs qui disposent d’un serveur personnel doivent vérifier build_version et amendment_blocked avec server_info. La source indique que la version 3.3.0 ou supérieure est l’état sûr mentionné dans l’analyse.
- Identifier le lieu de conservation des XRP.
- Consulter les annonces de la plateforme utilisée.
- Vérifier la version des serveurs et des portefeuilles personnels.
- Contrôler les outils qui dialoguent directement avec le réseau.
- Éviter de planifier des réallocations AMM serrées le jour de l’activation éventuelle.
- Examiner avec prudence les offres présentant un prêt directement actif sur le XRP Ledger.
La source conseille enfin de décaler les réallocations prévues au 10 ou au 12 septembre lorsqu’elles concernent des parts AMM ou des mouvements importants. CryptoTicker rappelle que ses informations sont arrêtées au 9 septembre 2026 et que l’article ne constitue pas un conseil en investissement.
Infobox — points essentiels : l’activation la plus précoce possible est fixée au 11 septembre 2026 à 11 h 15 UTC ; le seuil requis est supérieur à 80 % pendant deux semaines ; 93 amendements étaient actifs et onze en attente lors de la mesure ; la version 3.3.0 ou supérieure est indiquée comme sûre pour les serveurs concernés.
