Je développe sur XRPL depuis un certain temps, et je vois encore des gens le rejeter parce qu’il n’est « ni proof-of-work ni proof-of-stake ». Comme si ces deux-là étaient les seules options valables. Ce n’est pas le cas. XRPL utilise un modèle de consensus fédéré. Un petit ensemble de validateurs de confiance doit s’accorder, avec un seuil de 80 %, avant que le registre ne soit clos. Pas de minage. Pas de récompenses en staking. Pas de concurrence entre validateurs. Juste un accord. Les critiques disent que cela le rend centralisé. Et honnêtement, cette critique n’est pas absurde. Mais voici ce qu’ils ignorent : Ripple ne contrôle pas ces validateurs. N’importe qui peut en faire tourner un. La liste par défaut de validateurs est un point de départ, pas un point de contrôle. Qu’est-ce que cela signifie concrètement pour les utilisateurs ? Une finalité en 3 à 5 secondes. Pas de fork. Pas de jeux de congestion du mempool. Lorsque je développe des logiques de trustline, je n’ai pas à prendre en compte les reorganizations ou les uncle blocks. C’est un avantage réel et pratique qui se perd dans le bruit du débat sur le consensus.