XRP Ledger : la délégation de droits ne peut être active avant le 8 octobre

Une extension de protocole est sur le point d'être activée sur le XRP Ledger : elle permettra à des comptes de céder des droits isolés à d'autres comptes sans livrer leur propre clé principale. L'amendement s'appelle PermissionDelegationV1_1 et porte le numéro de spécification XLS-75. De nombreux médias spécialisés ont avancé ces derniers jours la date du 5 octobre 2026, certains à la minute près, à 11 h 18 UTC.

Le registre lui-même dit autre chose. La majorité sur laquelle repose le délai de deux semaines n'y est consignée que depuis le 24 septembre 2026, 21 h 25 UTC. L'amendement ne peut donc entrer en vigueur au plus tôt que le 8 octobre 2026 vers 21 h 25 UTC, soit trois bons jours plus tard qu'annoncé. Cryptoticker.io a réalisé lui-même cette analyse le 1er octobre 2026. Elle s'appuie sur les données d'amendements du XRP Ledger, vérifiées auprès de deux sources indépendantes l'une de l'autre. Les 113 amendements que le réseau comporte actuellement ont tous été examinés, dont quatre avec un vote en cours ou encore ouvert.

Pour vous, détenteur de XRP, c'est plus qu'une question de calendrier. Autour des mises à jour de protocole, les places de négociation et les conservateurs suspendent régulièrement les dépôts et les retraits pour un court moment, et celui qui a la mauvaise date en tête planifie un virement en plein dans la fenêtre où il restera bloqué. Le XRP se négocie à 1,48 dollar, soit 1,32 euro, en baisse de près de 2 % en une journée, pour une capitalisation d'environ 93,5 milliards de dollars.

PermissionDelegationV1_1 : l'amendement réunit 29 validateurs sur 35

Les modifications du XRP Ledger sont votées par les validateurs du réseau ; aucune entreprise ne les active. Un amendement est une modification de protocole soumise au vote de ces validateurs, qui ne prend effet qu'après avoir réuni assez longtemps une majorité qualifiée.

PermissionDelegationV1_1 atteint actuellement 29 des 35 validateurs de confiance, soit 82,9 %. Le seuil que le réseau applique lui-même à cet amendement s'établit à 28 voix. L'écart avec le seuil est donc d'une seule voix : si un validateur décroche ou change de position, l'extension est sur le fil.

L'extension a été introduite avec la version 3.3.0 du logiciel serveur de référence ; dans le réseau, les nœuds de tête tournent entre-temps en 3.4.1. Le prédécesseur mérite d'être relevé : un amendement plus ancien, de même nom et portant le même numéro de spécification XLS-75, figure encore au registre, mais ne réunit qu'une seule voix et est signalé comme dépassé. La première tentative de cette fonction a donc échoué, et ce qui attend aujourd'hui l'activation est la deuxième version, remaniée.

Pourquoi une voix fait la différence

Le seuil de 80 % et plus est délibérément élevé : il doit empêcher qu'une majorité étroite modifie les règles d'une chaîne sur laquelle des paiements sont réglés. L'effet secondaire : un amendement peut aussi perdre sa majorité juste avant le but, et c'est manifestement ce qui s'est produit ici.

Deux dates en circulation : le 8 octobre figure au registre, le 5 dans les dépêches

Le calcul avancé dans de nombreuses dépêches commence le 21 septembre, lorsque l'amendement a atteint la phase de deux semaines. Quatorze jours plus tard, cela donne le 5 octobre. La mention portée au registre indique toutefois le 24 septembre, 21 h 25 UTC, et c'est de ce moment que le délai est effectivement compté.

La règle du réseau explique comment les deux dates peuvent apparaître. Si un amendement perd le soutien nécessaire pendant l'attente, il est provisoirement rejeté et le délai de deux semaines repart à zéro. Plusieurs services spécialisés avaient rapporté la même semaine que la tentative avait été relancée ; la date, elle, n'a souvent pas suivi. Celui qui s'en tient au 5 octobre se fie à une horloge entre-temps remise en arrière.

La contre-épreuve fait partie du tableau : le 8 octobre est la date la plus proche possible, pas un engagement. Si le soutien reste au-dessus du seuil jusque-là, le réseau active l'extension. S'il baisse avant, le délai repart, et la date glisse de deux semaines supplémentaires.

Registre de scrutin et délai de deux semaines : le chemin d'un amendement vers l'activation

Le XRP Ledger compte les voix à intervalles fixes. Chaque 256e bloc est un registre de scrutin, c'est-à-dire un bloc où le réseau dépouille les voix sur les amendements. Cela survient toutes les quelques minutes, et l'opération se répartit sur quatre blocs consécutifs : dans le bloc précédent, les validateurs déposent leurs voix ; dans le registre de scrutin, elles sont comptées ; dans le bloc suivant, l'activation est inscrite ; et dans le bloc d'après, la modification prend effet.

Concrètement, pour le 8 octobre, cela signifie : l'extension prendra effet au premier registre de scrutin dépouillé après 21 h 25 UTC, donc peut-être quelques minutes plus tard. Pour la planification, l'indication du soir du 8 octobre suffit, soit, en heure d'Europe centrale, la fin de soirée du même jour.

La description officielle de cette procédure figure dans la documentation du XRP Ledger consacrée aux amendements. On y trouve aussi la règle selon laquelle le délai repart en cas de retombée sous le seuil.

DelegateSet : dix droits par délégataire, la clé principale reste au compte

Techniquement, la nouveauté passe par un type de transaction propre, nommé DelegateSet. Avec lui, un compte attribue des pouvoirs isolés à un autre compte, les modifie plus tard ou les retire. La délégation de droits désigne exactement ce principe : un compte autorise un autre à soumettre certaines transactions en son nom, sans transmettre sa propre clé de signature.

Le plafond est de dix pouvoirs par entrée de délégation. Celui qui en veut davantage est renvoyé dans la documentation vers la signature multiple, qui existe déjà. Cela ressemble à une note en marge, mais c'est le véritable cas d'usage : une entreprise peut autoriser son service des paiements à déclencher des virements et son service de conformité à les approuver, sans que l'un ou l'autre mette la main sur la clé du compte global.

La clé elle-même reste au compte qui délègue. C'est précisément pour cela que la fonction intéresse les conservateurs, les prestataires de paiement et les places de négociation, qui travaillent aujourd'hui soit avec des comptes collectifs, soit avec de lourdes signatures multiples. La manière dont vous conservez vos propres clés n'en est pas affectée ; qui veut comparer les appareils trouvera le panorama dans le comparatif des portefeuilles matériels.

Ce qui change pour un compte privé

Pour un compte XRP ordinaire, rien ne change dans un premier temps. Tant que vous n'installez vous-même aucune délégation, votre compte s'utilise comme avant. L'extension crée une possibilité, non une obligation. Elle devient pertinente pour vous en deux endroits : le logiciel avec lequel vous accédez au compte, et le service qui conserve vos XRP.

Droits non délégables : l'échange de clés et l'octroi de droits restent verrouillés

La spécification trace une limite décisive pour l'appréciation de la sécurité. Certains pouvoirs ne peuvent expressément pas être cédés, parmi lesquels ceux qui permettraient à un délégataire d'échanger les clés du compte ou de s'octroyer lui-même des droits supplémentaires. Si une transaction tente malgré tout de le faire, le réseau la rejette par un message de transaction mal formée.

Cette limite empêche l'attaque la plus évidente. Sans elle, un droit partiel une fois accordé pourrait être étendu jusqu'à la prise de contrôle complète d'un compte, puisque le délégataire se ferait lui-même détenteur de la clé. Avec elle, une délégation reste révocable, et par le seul compte qui l'a accordée.

La liste complète des pouvoirs exclus figure dans la spécification XLS-75 sur la délégation de droits. Qui exploite un logiciel de portefeuille ou prépare une intégration ne peut faire l'économie de ce document.

PaymentBurn : la réserve de la documentation XRPL sur les jetons nouvellement émis

La description technique de la transaction DelegateSet comporte une mention qui échappe facilement à une lecture rapide. Tant qu'un autre amendement déterminé n'est pas activé, un délégataire doté du pouvoir strictement défini PaymentBurn peut, dans certaines circonstances, créer aussi de nouveaux jetons négociables. La documentation la présente comme une réserve, non comme un défaut.

Le point a une portée pratique pour les émetteurs de jetons propres sur le XRP Ledger, non pour vous en tant que détenteur de XRP. Celui qui détient en revanche des jetons d'un émetteur travaillant avec des délégations à partir du jour d'activation a ici une question à lui poser : quels pouvoirs sont accordés, à qui, et comment sont-ils révoqués.

La réserve montre aussi pourquoi de telles extensions arrivent par étapes. Une seule modification de protocole intervient dans un corps de règles composé de dizaines de modifications antérieures, et les interactions ne sont pas toujours établies d'emblée.

BatchV1_1 et LendingProtocolV1_1 : les autres amendements dans la fenêtre

La délégation de droits n'est pas la seule modification dans la file. En octobre, trois délais courent en parallèle, et un quatrième vote n'en est qu'au début. Le tableau reflète la situation au 1er octobre 2026.

BatchV1_1 regroupe plusieurs transactions en un paquet traité d'un bloc, et réunit 30 voix. Le correctif qui l'accompagne porte le soutien le plus large des quatre, avec 34 voix sur 35. Les deux prendraient effet un jour après la délégation de droits, le 9 octobre.

Le cas du protocole de prêt LendingProtocolV1_1, dont il a beaucoup été question dernièrement, est tout autre : il en est à 5 voix sur 35 et n'a pas atteint la majorité. Aucune activation ne s'y dessine dans les prochaines semaines, et il n'existe pas de date. Celui qui lit des dépêches annonçant un prêt imminent sur le XRP Ledger peut leur opposer ce chiffre.

Conservation et compte de plateforme : le jour de l'activation pour les détenteurs en Allemagne

La journée elle-même se déroule sans relief pour la plupart des détenteurs, à une exception près : les places de négociation et les conservateurs suspendent parfois pendant quelques heures les dépôts et les retraits en XRP autour des mises à jour de protocole, le temps que la transition passe. C'est une routine et non un incident, mais cela touche quiconque a prévu un virement ce soir-là.

Celui qui laisse ses XRP chez un prestataire voit habituellement une annonce dans l'espace d'état ou par notification, le plus souvent un à trois jours à l'avance. Celui qui conserve lui-même a besoin d'un logiciel de portefeuille capable de traiter le nouveau type de transaction ; les versions anciennes peuvent n'afficher un type inconnu pas du tout, ou de façon erronée. Quels prestataires sont agréés en Allemagne au titre du règlement européen sur les marchés de crypto-actifs, et en quoi ils diffèrent sur les frais et la conservation, le comparatif des plateformes crypto le montre.

Sur le plan fiscal, une mise à jour de protocole ne change rien

L'activation d'un amendement n'est ni un encaissement, ni une cession, ni un nouveau jeton. Votre délai de détention continue de courir sans changement, et aucun fait générateur d'impôt n'apparaît. Il en irait autrement seulement si une chaîne venait à se scinder ; rien ne l'indique ici, puisque l'extension avance avec une large majorité et sans contre-proposition.

Hameçonnage aux droits de délégation : un nouveau schéma d'autorisations falsifiées

Chaque nouvelle fonction d'autorisation dans une chaîne apporte avec elle une nouvelle escroquerie. Sur Ethereum, le même schéma a suivi l'introduction des comptes délégués : une prétendue page d'autorisation demande une signature, et la signature n'accorde pas un paiement mais des droits durables sur un compte.

Pour le XRP Ledger, cela signifie, dès le jour de l'activation : une invitation à signer une transaction DelegateSet fait partie des opérations où il vaut la peine de regarder à deux fois. Un compte auquel vous accordez des droits peut agir dans le cadre de ces droits jusqu'à ce que vous les révoquiez. Comme l'échange de clés reste exclu de la délégation, le dommage est borné ; il n'en est pas agréable pour autant.

Une telle invitation ne vous parvient jamais d'un réseau lui-même. Ni le XRP Ledger ni un portefeuille ne vous envoie de message indiquant que vous devriez confirmer des droits pour qu'une modification de protocole prenne effet. Ce message est un faux, sans exception.

Délégation de droits : vos trois prochaines étapes

1. Mettre à jour le logiciel de portefeuille avant le 8 octobre. Une version qui connaît DelegateSet vous présente une transaction de délégation comme telle, au lieu de la ranger parmi les types inconnus. Quels programmes sont entretenus et lesquels sont à l'arrêt depuis des mois, le comparatif des portefeuilles logiciels l'indique.
2. Vérifier la fenêtre auprès de votre conservateur. Si vous avez prévu un dépôt ou un retrait en XRP pour le 8 ou le 9 octobre, déplacez-le à un autre jour, ou relevez d'abord l'avis d'état de votre prestataire. Qui songe de toute façon à changer trouvera les prestataires agréés dans le comparatif des plateformes.
3. Tenir les avoirs importants hors de portée de la fonction d'autorisation. Un compte qui ne délègue jamais ne peut pas non plus être attaqué par cette voie. Pour les montants que vous ne déplacez pas, la conservation sur un appareil qui vous appartient reste la solution la plus tranquille ; les appareils et leurs différences figurent dans le comparatif des portefeuilles matériels.

La date demeure mobile jusqu'au bout. Tant que le soutien se tient au-dessus du seuil de 28 voix, le soir du 8 octobre fait foi ; s'il passe en dessous, le délai de deux semaines repart. Cela s'observe au décompte des voix des validateurs, qui évolue en continu dans le réseau.

(Au 1er octobre 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.)