Dans mon billet précédent, j’expliquais pourquoi les banques ne veulent pas partager un même livre comptable avec leurs partenaires. Une fois l’article terminé, une question m’est venue à l’esprit : si chacun conserve son propre livre, comment les transactions entre deux banques sont-elles réellement exécutées ? L’argent et les actifs sont consignés séparément dans deux livres qui ne communiquent pas : on dirait que c’est tout simplement impossible. Cet article vise à clarifier précisément ce processus.
Le lien de l’article précédent est ici : (Pourquoi les banques ne veulent pas partager un livre comptable avec un partenaire)
Commencez par figer le contexte : sinon, l’explication risque d’être trop vague.
Supposons qu’il y ait deux banques dans la même juridiction. La banque A doit payer : elle utilise un dépôt tokenisé qu’elle a émis. La banque B doit livrer un actif tokenisé. Les deux parties ne veulent pas partager les informations clients, les soldes et la logique métier entre elles, ni les confier à un tiers de conservation. C’est l’exemple le plus typique d’un « titre contre paiement », autrement dit, le DvP (Delivery versus Payment).
La méthode traditionnelle consiste soit à passer par un médiateur qui centralise le passage au journal, soit à tenir chacun son propre livre puis à rapprocher les comptes. La première approche introduit un tiers de confiance et un risque pour la contrepartie ; la seconde crée une fenêtre de risque où l’un a donné, mais où l’autre n’a pas encore donné.
Que fait chacun des trois niveaux ?
L’approche de Sovereign consiste à découper le problème en trois couches, avec des responsabilités différentes à chaque niveau.
Tout en bas, il y a le livre comptable propre à l’institution. Il est hébergé dans le cloud de l’institution ou dans ses propres infrastructures locales ; l’institution est le seul opérateur. L’identité des clients, les soldes, les détails des transactions et la logique métier restent entièrement à cette couche : ils ne sortent pas. Les dépôts tokenisés de la banque A sont émis sur son propre livre ; les actifs tokenisés de la banque B sont émis sur son propre livre ; ils ne sont jamais visibles l’un pour l’autre.
L’intermédiaire, c’est le réseau privé de Rayls. Les institutions participantes d’une même juridiction se connectent à cette couche. Les règlements entre institutions ont lieu ici ; et ce qui sort des livres respectifs, ce ne sont que les informations nécessaires chiffrées et des preuves. L’exemple officiel mentionne les preuves à divulgation nulle de connaissance (zero-knowledge proofs). Autrement dit, la banque B n’a pas besoin de savoir qui est le client de la banque A, ni combien il reste sur le compte : elle peut confirmer que le paiement est valide.
Tout en haut, il y a la blockchain publique Rayls : les institutions s’y connectent à la demande à la liquidité publique. Cette couche est optionnelle ; un règlement purement réalisé entre deux institutions relevant de la même juridiction n’a pas besoin de passer par la blockchain publique.
Sur quoi repose réellement l’atomicité ?
Le sens d’un règlement atomique est très simple : l’argent et les actifs se déplacent soit tous ensemble, soit rien ne bouge ; il n’existe aucun état intermédiaire où l’un serait arrivé sans que l’autre soit arrivé.
Le point clé n’est pas de fusionner deux livres comptables en un seul, mais d’adosser deux opérations à un même règlement, réalisé ensemble dans le même bloc de confirmation. Si l’un des deux côtés ne se réalise pas, l’ensemble échoue : les livres comptables de chaque partie ne laissent alors aucun état « à moitié fait ».
Voilà pourquoi le caractère de finalité est particulièrement important dans les scénarios institutionnels. Si une chaîne ne fournit qu’une finalité probabiliste, alors avant que le règlement soit considéré comme suffisamment sûr, les institutions doivent garder cette exposition et les fonds au bilan. C’est à la fois un risque et un coût du capital immobilisé. Dans son introduction de Sovereign, l’équipe officielle de Rayls liste clairement la finalité probabiliste comme un problème des plateformes existantes. La finalité déterministe signifie que « une fois le règlement terminé, il est terminé » : les fonds et la gestion des risques peuvent alors être libérés immédiatement.
Un détail facile à inverser
Sur le réseau privé et les Privacy Nodes, ce type de transaction ne coûte pas de gas.
Ce point mérite d’être dit séparément, car beaucoup de gens supposent par défaut que « toute transaction sur une blockchain nécessite de payer des frais en jetons ». Dans l’architecture de Rayls, les institutions n’ont pas besoin de payer du gas pour leurs activités sur leur propre livre comptable et sur le réseau privé. Le gas est nécessaire pour la blockchain publique Rayls, et les jetons de gas sur la blockchain publique sont USDr, pas RLS.
En distinguant bien ces deux choses, on peut comprendre correctement le coût d’usage réel pour les institutions dans ce système.
Quel est le résultat concret ?
L’impact sur l’activité se traduit par trois points très concrets.
Le règlement n’a plus besoin d’un tiers de confiance central. Les deux banques n’ont confié aucun livre comptable, aucune n’a vu les données clients de l’autre, mais la transaction peut être exécutée de manière atomique.
La réglementation obtient ce dont elle a besoin. Selon l’approche officielle, la conformité et l’accès des régulateurs sont intégrés à la couche centrale du protocole, et non ajoutés a posteriori comme une étape de contrôle. Cela signifie que la « capacité d’audit » n’est pas due à la bonne volonté des institutions à soumettre des rapports, mais que l’architecture permet elle-même l’accès selon le périmètre autorisé.
Amélioration de l’efficacité du capital. Grâce à la finalité déterministe, le règlement achevé libère immédiatement les fonds : il n’est plus besoin de mobiliser des fonds supplémentaires ni des expositions supplémentaires liées au risk management pour attendre une confirmation probabiliste.
À quel niveau cela est-il déployé ?
Cette architecture n’est pas qu’un dessin sur papier, mais le degré de maturité varie énormément selon les cas d’usage ; si on les mélange, on risque de surévaluer.
Déjà en production : ce sont les stablecoins en dollars USDXP émis sur Sovereign par XP. L’officiel a également une formulation qu’on peut citer : les clients institutionnels brésiliens traitent chaque mois des dizaines de milliers d’actifs tokenisés sur les Privacy Nodes déjà mis en ligne ; la plateforme sous-jacente est entrée en production à partir de juin 2024, et plus de 30 institutions financières l’ont déjà déployée.
En phase pilote : Drex de la Banque centrale du Brésil. Seize grandes banques brésiliennes déploient chacune sa propre instance afin d’effectuer le règlement d’obligations d’État et d’autres actifs avec la monnaie numérique de la banque centrale. Le terme employé ici est « pilot ».
Ce qui a déjà été testé : Kinexys de JPMorgan a testé Sovereign comme couche de confidentialité et d’identité dans le cadre de Project EPIC. Un test n’est pas une mise en production.
Ce qui est promis mais pas encore livré : le plan AmFi apporte 1 milliard de dollars de crédit privé, et Nimofast promet jusqu’à 100 milliards de dollars d’actifs liés à l’énergie et aux matières premières. Ces deux chiffres correspondent à des volumes « engagés », pas à des actifs déjà émis via Sovereign.
Après avoir séparé ces quatre catégories, la pertinence de cette liste tient au fait que le panel des types d’institutions est complet : on y trouve aussi bien des banques commerciales que des émetteurs d’actifs, y compris des banques centrales. Ce n’est pas la somme des engagements qui fait la démonstration.
En une phrase
Chacun gère ses propres livres comptables, et le fait de faire des affaires ensemble n’est pas contradictoire. L’essentiel est de placer le règlement dans une couche intermédiaire : ce qui s’en sort des livres respectifs, ce ne sont que des preuves, et non des données.
Pour voir la description complète officielle de Sovereign, rendez-vous sur la page produit du site Rayls : rayls.com/products/sovereign
Source de référence : blog officiel Rayls (Introducing Rayls Sovereign: the onchain gateway for institutions) (Peter Bidewell, 25 août 2026) ; documentation de la blockchain publique Rayls : https://www.rayls.com/blog/introducing-rayls-sovereign-the-onchain-gateway-for-institutions