Le mois dernier, j’ai expliqué comment vérifier soi-même la « couverture à 1:1 » de BRL1.p. Il ne s’agissait alors que d’un instantané pris le 17 octobre. Depuis, j’ai moi-même déposé des fonds dans le coffre-fort et je me suis demandé : qui surveille la situation chaque jour après cet instantané ? Cette semaine, j’ai automatisé les vérifications pour qu’elles s’exécutent toutes les 6 heures. J’en ai aussi profité pour examiner et rapprocher toutes les transactions inter-chaînes depuis le lancement. Le résultat a révélé deux éléments de plus que prévu.

Réponse courte : non. Un instantané prouve seulement que les chiffres des deux côtés étaient égaux à cet instant précis. Pour pouvoir se fier au système dans la durée, il faut au minimum faire trois choses : rapprocher chaque transfert inter-chaînes sur les deux chaînes à l’aide de son identifiant de message ; placer sur une même chronologie chaque variation de solde des deux chaînes et vérifier que l’offre n’a jamais dépassé le contenu du coffre-fort ; et vérifier régulièrement qui signe les autorisations.

J’ai effectué ces trois vérifications pour BRL1.p. Les 18 transferts inter-chaînes depuis le lancement correspondent tous, et sur les 36 variations de solde, l’offre n’a jamais dépassé le contenu du coffre-fort. Mais deux éléments échappaient à l’instantané précédent : parmi les trois vérificateurs dont la signature est obligatoire, l’un a changé de clé de signature dès le premier jour de fonctionnement de BRL1.p. Son nom dans le registre LayerZero est ensuite passé de Nethermind à Twinstake. Par ailleurs, le même compte a soumis sur la chaîne les 54 vérifications effectuées par les trois vérificateurs.

Ce qu’un instantané ne permet pas de voir

BRL1.p est la version de BRL1, un stablecoin indexé sur le réal brésilien, transférée vers la blockchain Rayls. Sur Polygon, les utilisateurs déposent des BRL1 dans un contrat de coffre-fort ; LayerZero transmet le message à Rayls, où le même nombre de BRL1.p est ensuite émis. Dans le sens inverse, les jetons sont d’abord détruits, puis débloqués.

Lors de l’instantané du 17 octobre, le solde du coffre-fort et l’offre de BRL1.p étaient tous deux de 250,013.482911, à la décimale près. Mais l’instantané ne permet pas de savoir ce qui s’est passé entre deux relevés. À l’époque, j’avais associé les verrouillages et les émissions en fonction des montants, des adresses et de l’ordre chronologique, sans utiliser les identifiants de message LayerZero. Une erreur d’association serait donc passée inaperçue. Quant aux « trois vérificateurs », l’instantané ne montrait que les trois adresses configurées : il ne disait rien des personnes derrière ces adresses ni des clés utilisées pour signer.

Le code de l’article, le relevé de chaque transaction et les journaux de chaque exécution sont disponibles dans le dossier 2026-11-brl1p-monitor du dépôt public hansonhan0520-lang/rayls-verify. GitHub Actions exécute automatiquement les vérifications toutes les 6 heures et publie les résultats dans le dépôt. Les chiffres présentés ici proviennent de plusieurs exécutions effectuées le 6 novembre 2026, entre 03:25 et 03:56 (UTC).

Première étape : rapprocher chaque transaction à l’aide de son identifiant

LayerZero attribue un identifiant unique, le GUID, à chaque message inter-chaînes. À l’envoi, il est inscrit dans l’événement OFTSent sur la chaîne source ; à la réception, il figure dans l’événement OFTReceived sur la chaîne cible. Seuls deux identifiants identiques permettent de confirmer qu’il s’agit de la même transaction.

Résultat : 18 transactions, dont 16 de Polygon vers Rayls et 2 de Rayls vers Polygon. Pour chacune, les GUID correspondent des deux côtés, le montant verrouillé est égal au montant émis, et les hachages des transactions sur les deux chaînes indiqués par l’explorateur de messages de LayerZero, LayerZero Scan, correspondent aussi à ceux relevés sur la chaîne. LayerZero numérote séquentiellement les messages de chaque canal : les 16 transactions portent les numéros 1 à 16, et celles dans l’autre sens les numéros 1 et 2. Il n’y a donc aucun numéro manquant et aucun message ne manque dans le tableau. J’ai également vérifié dans l’autre sens : chaque variation du solde du coffre-fort et de l’offre de BRL1.p correspond à un message inter-chaînes. Il n’y a eu aucune émission ni aucun transfert « sorti de nulle part ».

Temps de réception : de Polygon vers Rayls, entre 248 et 293 secondes, avec une médiane de 267 secondes ; dans l’autre sens, 57 et 63 secondes. La fourchette des 13 transactions précédentes était de 248 à 274 secondes. Une transaction ajoutée le 28 octobre a pris 293 secondes, ce qui a repoussé la limite supérieure.

Deuxième étape : réunir les deux chaînes sur une même chronologie

Un pont de verrouillage et d’émission sain respecte un invariant : le montant de BRL1 dans le coffre-fort doit toujours être au moins égal à l’offre de BRL1.p. Comme les fonds sont d’abord verrouillés puis émis, et d’abord détruits puis débloqués, le coffre-fort contient pendant les quatre ou cinq minutes du transfert inter-chaînes le montant de la transaction en cours d’acheminement, en plus du montant correspondant à l’offre.

J’ai classé les 36 variations de solde des deux chaînes par heure de bloc, puis calculé la différence entre les deux à chaque étape. Après chaque variation, la différence est restée supérieure ou égale à 0 ; son minimum était exactement 0. Autrement dit, l’offre n’a jamais dépassé le contenu du coffre-fort. Côté Polygon, je ne me suis pas fié uniquement aux événements pour déduire les soldes : pour les blocs correspondant aux 18 variations, j’ai interrogé directement le balanceOf du coffre-fort auprès de deux nœuds d’archive indépendants, drpc et Tenderly. Les résultats concordent un à un avec les valeurs déduites ; aucun écart.

J’ai également réexaminé les privilèges administratifs. Du 14 octobre au 6 novembre, j’ai relevé chaque jour à 00:00 (UTC) le propriétaire du coffre-fort Polygon, le contrat de la chaîne partenaire, le délégué LayerZero et la configuration des vérificateurs : les 24 relevés sont identiques. Les 18 événements de gestion et de configuration repérés sur les deux chaînes ont tous eu lieu pendant le déploiement, le 13 octobre entre 18:05 et 18:10 ; rien n’a été modifié depuis. La situation que j’avais relevée précédemment n’a pas changé : les droits d’émission et de destruction sont détenus uniquement par l’adaptateur inter-chaînes, tandis que les droits d’administration, de suspension et de mise à niveau, ainsi que la propriété des contrats sur les deux chaînes, restent entre les mains de la même adresse de portefeuille ordinaire.

Troisième étape : qui signe réellement les autorisations ?

Un incident majeur a eu lieu cette année à ce niveau. En avril, le pont inter-chaînes de KelpDAO s’est fait voler environ 292 millions de dollars. Dans son rapport d’incident de mai, LayerZero a attribué la cause à la manipulation de nœuds RPC, combinée au fait que l’application ne dépendait que d’un seul vérificateur. Chez LayerZero, les vérificateurs sont appelés DVN. Ils voient le message sur la chaîne source, attendent le nombre de confirmations requis, puis signent pour autoriser son exécution sur la chaîne cible. Dans les deux sens, BRL1.p exige la signature des trois DVN : LayerZero Labs, Canary et un DVN dont l’identifiant est nethermind.

Commençons par vérifier s’ils ont effectivement signé. Avant la réception de chaque message, la chaîne cible enregistre une entrée PayloadVerified pour chaque DVN. Les 16 messages de Polygon vers Rayls ont chacun trois entrées sur Rayls, soit 48 au total ; les 2 messages dans l’autre sens ont chacun trois entrées sur Polygon, soit 6 au total. Pour chaque entrée, le nombre de confirmations indiqué correspond exactement au nombre requis : 120 blocs sur Polygon et 10 blocs sur Rayls. Sur Rayls, les vérifications sont arrivées entre 232 et 253 secondes après le verrouillage sur Polygon. Sur les un peu plus de quatre minutes du transfert inter-chaînes, la majeure partie du temps est donc consacrée à attendre les 120 blocs sur Polygon.

Voyons maintenant qui a signé. Le contrat DVN exige que chaque vérification soit accompagnée d’un nombre minimum de signatures de signataires. Ces signatures figurent dans les données d’entrée de la transaction de vérification, ce qui permet de retrouver les adresses des signataires. J’ai reconstitué les signatures des 54 vérifications : pour LayerZero Labs, le seuil est de 2 signatures parmi 3 signataires, et les 16 transactions ont toutes été signées par les mêmes deux clés ; pour Canary, le seuil est d’une signature parmi un signataire, et les 16 transactions ont toutes été signées par la même clé.

Le troisième DVN, lui, a changé. Les 4 premières transactions (14 octobre) ont été signées par la clé 0xbbd4 ; à partir de la 5e (15 octobre), c’est la clé 0x86f0 qui a été utilisée, sauf pour l’une d’elles, signée par 0x598c. Les données de la chaîne montrent qu’entre le 14 octobre à 19:55 et le 15 octobre à 00:30 (UTC), ce DVN a simultanément ajouté deux signataires et supprimé l’ancien sur Polygon et Rayls, exactement entre les 4e et 5e transactions de BRL1.p.

Le nom a également changé. Dans le journal d’exécution LayerZero du 17 octobre, le registre public des DVN de LayerZero associait cette adresse à Nethermind ; lorsque j’ai consulté le registre à nouveau le 6 novembre, le nom indiqué était Twinstake, mais l’identifiant était toujours nethermind. Le 19 août, Nethermind avait annoncé qu’elle cessait d’exploiter un DVN LayerZero pour se consacrer aux nœuds Chainlink. Pris ensemble, ces éléments suggèrent que le DVN de Nethermind a probablement été confié à Twinstake, et que les clés de signature ont été remplacées en conséquence. Il s’agit d’une déduction de ma part : la chaîne montre uniquement que la clé a changé le 14 octobre, pas qui la détenait. Le registre est une étiquette hors chaîne maintenue par LayerZero, et je n’ai consulté que les versions de deux dates ; j’ignore donc quand le changement de nom a eu lieu exactement.

Un autre point commun : les 54 transactions de vérification, quel que soit le DVN ou la chaîne, ont toutes été soumises par le même compte, 0xb8ff…47cb. Ce compte et un autre, 0xb52f…f0b6, détiennent tous deux le rôle d’administrateur sur les six contrats DVN (trois par chaîne). Le compte a déjà émis plus de 8,88 millions de transactions sur Polygon. D’après le code des contrats et la documentation de LayerZero, les administrateurs soumettent les vérifications, mais chaque soumission doit comporter les signatures requises : un administrateur ne peut pas falsifier une vérification à lui seul. Voici donc comment je comprends la situation : du point de vue de la sécurité, les trois verrous restent contrôlés par trois groupes de clés différents, et falsifier un message nécessiterait de récupérer au moins 4 clés de signature (2 + 1 + 1) ; du point de vue de la disponibilité, le canal de soumission dépend d’un seul compte. S’il s’arrête, les transferts inter-chaînes dans les deux sens resteront bloqués en cours de route. Cette dernière affirmation est une déduction fondée sur le code ; je n’ai pas observé d’interruption.

Un obstacle à la reproduction des résultats : les nœuds officiels ne permettent pas de reconstruire l’historique

Pour que d’autres puissent reproduire ces résultats, il faut préciser l’origine des données. Le nœud public officiel de Rayls n’est pas d’une grande aide : toute requête portant sur un état historique renvoie « pruned », y compris pour le bloc du 17 octobre ; les recherches de journaux de BRL1.p et de l’adaptateur sur une plage de 1,5 million de blocs ne renvoient aucune entrée ; et je n’ai obtenu le reçu d’aucune des 18 transactions Rayls. Les transactions elles-mêmes sont toutefois consultables. Les données d’entrée des 16 transactions de réception contiennent le GUID correspondant, l’adresse du destinataire et le montant ; celles des 2 transactions d’envoi contiennent aussi l’adresse du destinataire et le montant.

L’historique des événements côté Rayls ne peut donc provenir que de l’explorateur de blocs Rayls. Je l’ai recoupé à l’aide de trois sources : les enregistrements de LayerZero Scan, les données d’entrée des transactions renvoyées par le nœud officiel et l’offre actuelle de 255,291.961901 lue sur le nœud officiel. Cette dernière correspond exactement au chiffre reconstitué à partir des événements de l’explorateur. Côté Polygon, j’ai utilisé deux nœuds, PublicNode et Tenderly, pour récupérer les journaux ; leurs résultats concordent entrée par entrée.

Du côté des réserves : toujours le même rapport

Le pont inter-chaînes ne fait que garantir une parité de un pour un entre BRL1.p et BRL1. Pour savoir si BRL1 est réellement couvert par des réaux, il faut consulter les attestations de réserves de l’émetteur. Le rapport le plus récent que j’ai pu télécharger sur brl1.io le 6 novembre était toujours celui du 1er octobre : 19 354 372 réaux de réserves pour 17 381 384,54 BRL1, soit un ratio de 111,35 %. Le rapport précise qu’il a été préparé en interne et qu’il n’a pas été audité par un organisme indépendant. Pourtant, le lien sur le site est intitulé « dernière attestation de réserves auditée ». Le lien qualifié de « dernier » sur la page « Fonctionnement » renvoie à un rapport daté du 14 avril 2025, lui aussi préparé en interne ; un autre lien nécessite une connexion à Google ; et la page des réserves de Fact Finance, vers laquelle renvoie le site, affiche une erreur 404.

J’ai vérifié les quantités de jetons indiquées dans les deux rapports consultables, à partir des numéros de blocs qu’ils mentionnent. Les relevés des deux nœuds d’archive concordent avec les rapports. Cela confirme que la partie « passif » des rapports correspond aux données de la chaîne ; la partie « actif » repose toujours uniquement sur les déclarations de l’émetteur. Le 6 novembre, 17 882 561,54 BRL1 étaient en circulation sur Polygon, soit 501 177 de plus que le 1er octobre. Aucune attestation publique ne couvre encore les réserves correspondant à cette augmentation.

On peut prendre comme référence les exigences d’une assurance indépendante prévues par le GENIUS Act américain : l’émetteur publie chaque mois la composition de ses réserves, certifiée par les signatures du PDG et du directeur financier, et un cabinet comptable externe réalise une mission d’assurance. BRL1 est un stablecoin brésilien et n’est pas soumis à cette loi ; je la cite uniquement à titre de comparaison. Lorsque BRL1 publiera réellement un rapport indépendant, il faudra d’abord vérifier si celui-ci est signé par un cabinet comptable indépendant, et s’il précise le type de mission d’assurance réalisée ainsi que les normes appliquées. Le script por_check.py du dépôt permet de vérifier si les quantités de jetons du rapport peuvent être lues sur la chaîne au bloc indiqué.

Ce qui reste à faire

L’historique des événements côté Rayls dépend de l’explorateur de blocs ; le nœud officiel ne permet que des recoupements, pas une reconstruction indépendante. Les relevés quotidiens de Polygon ne sont effectués qu’une fois, à 00:00, mais chaque variation de solde a aussi été vérifiée séparément par bloc. La chaîne ne permet pas de savoir qui détient les clés de signature ni qui exploite le compte 0xb8ff. Les vérifications automatisées ont commencé le 6 novembre et ne couvrent que la période postérieure ; la période précédente a été reconstituée à partir de l’historique.

Mon avis

Le rapprochement de chaque transaction montre que le pont inter-chaînes fonctionne proprement : les 18 transactions correspondent toutes, et l’offre n’a jamais dépassé le contenu du coffre-fort. La réalité des signatures est plus complexe que ne le laisse entendre l’expression « trois vérificateurs » : il s’agit bien de trois groupes de clés distincts du point de vue de la sécurité, mais l’un d’eux a changé dès le premier jour de fonctionnement, et un seul compte soumet les vérifications. Le maillon le plus faible reste l’émetteur : l’attestation de réserves la plus récente est toujours un rapport interne non audité.

Le moyen de vérifier est simple. N’importe qui peut lancer le workflow brl1p-monitor dans le dépôt rayls-verify, ou consulter directement les résultats publiés toutes les 6 heures. Tout nouvel événement de gestion ou de configuration, tout changement de signataire chez un vérificateur, tout dépassement, même ponctuel, de l’offre par rapport au coffre-fort, ou toute publication par BRL1 d’un rapport indépendant d’assurance sera consigné lors de l’exécution suivante.

Sources de référence :

Code de l’article, relevé de chaque transaction et journaux d’exécution (soumis le 6 novembre 2026) : https://github.com/hansonhan0520-lang/rayls-verify/tree/4e37e76f7541fbea2cba1c0b8967c46afa905677/2026-11-brl1p-monitor

Journaux d’exécution du précédent instantané (17 octobre 2026) : https://github.com/hansonhan0520-lang/rayls-verify/tree/main/2026-10-brl1p-backing

Documentation du contrat LayerZero DVN : https://docs.layerzero.network/v2/workers/off-chain/dvn-technical-reference

Registre public LayerZero des DVN : https://metadata.layerzero-api.com/v1/metadata/dvns

Rapport d’incident LayerZero sur KelpDAO (18 mai 2026) : https://layerzero.network/publications/kelpdao-incident-report.pdf

crypto.news, Nethermind quitte son rôle de vérificateur LayerZero (19 août 2026) : https://crypto.news/nethermind-leaves-layerzero-verifier-role-chainlink/

Site officiel de BRL1 et documents attestant des réserves (consultés le 6 novembre 2026) : https://brl1.io/en

Centre américain pour la qualité de l’audit, exigences du GENIUS Act à l’égard des comptables (27 octobre 2025) : https://www.thecaq.org/audit-in-action-what-does-the-genius-act-require-of-accountants

#Rayls $RLS #stablecoin