Une fonctionnalité discrète enfouie dans le code du XRP Ledger prend les développeurs au dépourvu. Hussein Zangana, connu dans la communauté sous le nom de Vet, a signalé publiquement le problème — avertissant que la fonction de paiement partiel peut être exploitée pour tromper les échanges et les nouveaux projets en leur faisant créditer plus de fonds qu’ils n’en ont réellement reçus.
Les mécanismes ici ne sont pas compliqués, mais ils sont faciles à manquer. Sur le XRP Ledger, un paiement partiel permet à une transaction d’être marquée comme réussie même lorsqu’elle livre moins que le montant indiqué. Ce n’est pas un bug. C’est une conception intentionnelle — utile, en fait, pour retourner des paiements sans engendrer de coûts supplémentaires. Mais si une plateforme suppose que le montant total indiqué est arrivé dans leur portefeuille, elle donne essentiellement aux acteurs malveillants un laissez-passer gratuit pour réclamer un crédit pour de l’argent qui n’est jamais arrivé.
Ce n’est pas un problème nouveau. Ce n’est pas non plus un problème résolu.
Le piège du champ « Amount »
Le XRP Ledger possède deux champs pertinents dans les métadonnées des transactions : le champ « Amount » et le champ « delivered_amount ». Le champ « Amount » montre ce que l’expéditeur a prétendu envoyer. Le champ « delivered_amount » montre ce qui a réellement été transféré. Ces deux chiffres peuvent être très différents, et c’est dans cet écart que réside l’exploitation.
Le point de Vet était assez direct : quiconque construit sur le XRP Ledger doit extraire le champ « delivered_amount » pour confirmer ce qui a vraiment atteint leur compte. Se fier uniquement à « Amount » revient à faire confiance à l’expéditeur pour être honnête — ce qui, dans un réseau financier sans permission, n’est pas une grande supposition.
La documentation du XRPL le précise. Elle dit d’utiliser « delivered_amount » pour vérifier le montant réellement reçu, pas « Amount ». Ce n’est pas une note de bas de page subtile. C’est une pratique de sécurité fondamentale. Mais les nouvelles équipes, progressant rapidement, intégrant rapidement, passent souvent à côté.
Et les frais n’aident pas à clarifier les choses. Les coûts de transaction sur le XRP Ledger sont déduits du compte de l’expéditeur indépendamment de la résolution du paiement. Ils ne sont pas inclus dans le montant indiqué du paiement. Ainsi, un projet déjà confus par « Amount » par rapport à « delivered_amount » a maintenant une variable supplémentaire qui embrouille la comptabilité. Les chiffres peuvent sembler corrects en surface et être complètement faux.
Pourquoi les nouveaux projets sont le maillon faible
Les grandes plateformes d’échange ont probablement déjà réglé ce problème. Elles existent depuis assez longtemps, ont vu suffisamment de cas particuliers, et ont des équipes d’ingénierie qui lisent effectivement la documentation avant de livrer. Ce sont les nouvelles plateformes où les choses deviennent risquées — les startups construisant des portefeuilles, des intégrations DeFi, des passerelles de paiement, tout ce qui touche aux flux entrants de XRP sans une base de connaissances institutionnelle approfondie.
Vet a spécifiquement souligné le risque pour les nouveaux projets, et c’est une préoccupation légitime. Le drapeau de paiement partiel est quelque chose que l’expéditeur active. Le récepteur ne le contrôle pas. Ainsi, un projet pourrait tout faire correctement de son côté et se faire encore avoir si son système n’est pas configuré pour détecter la différence entre ce qui a été prétendu et ce qui a été livré.
C’est la partie inconfortable. Ce n’est même pas une attaque sophistiquée. Quelqu’un envoie un paiement partiel, la plateforme réceptrice crédite le montant total « Amount », et l’attaquant repart avec plus de crédit qu’il n’a financé. Rincer, répéter. Petits montants, multiples comptes, et cela s’additionne rapidement avant que quiconque ne s’en aperçoive.
Des pratiques rigoureuses de développement logiciel sont ici plus importantes que les gens ne l’admettent généralement. Analyser correctement les métadonnées des transactions n’est pas un travail glamour. Cela ne fait pas l’objet d’une annonce de lancement de produit. Mais se tromper peut entraîner de réelles pertes financières, et dans le domaine des cryptos, ces pertes sont généralement irréversibles.
La documentation du XRP Ledger est détaillée à ce sujet. Elle est là. Les conseils existent. Les suivre de manière cohérente — pas seulement au lancement mais à travers chaque mise à jour d’intégration — est ce qui sépare les plateformes qui restent sécurisées de celles qui deviennent des récits de mise en garde.
Ce qui doit être fait
Les nouvelles plateformes intégrant le XRP Ledger doivent construire leur traitement des paiements autour de « delivered_amount » dès le premier jour. Pas comme une réflexion après coup, pas comme un correctif après que quelque chose tourne mal. Dès le premier jour. Chaque crédit sur un compte utilisateur doit être basé sur ce qui a été réellement livré, point final.
L’avertissement de Vet n’est pas exactement une nouvelle fracassante dans les cercles de développeurs du XRPL, mais il continue de revenir parce que de nouvelles équipes continuent de faire la même erreur. Le XRP Ledger est un choix d’infrastructure populaire pour les applications financières — rapide, relativement bon marché, bien documenté. Mais une infrastructure populaire vous mord toujours si vous ne lisez pas le manuel.
La fonction de paiement partiel, utilisée correctement, est vraiment utile. Retourner des fonds sans coût supplémentaire est un véritable avantage pratique. Mais cette même flexibilité est une responsabilité lorsque le côté récepteur ne le prend pas correctement en compte.
Le champ « delivered_amount » est la réponse. Il a été là tout le temps.
Hub : Prix, actualités et analyses du XRP
Hub: XRP : prix, actualités et analyse
Questions Fréquentes
Qu’est-ce que la fonction de paiement partiel du XRP Ledger ?
C’est une fonction qui permet de marquer une transaction comme réussie même si elle livre moins que le montant indiqué, ce qui peut être utile pour retourner des paiements mais risqué si les récepteurs ne vérifient pas le montant réellement livré.
Quel champ de métadonnées les développeurs devraient-ils utiliser pour vérifier les paiements XRP ?
Les développeurs devraient utiliser le champ « delivered_amount », et non le champ « Amount », pour confirmer combien de XRP a été réellement reçu dans une transaction.
