Last month, I wrote about how to verify BRL1.p’s “1:1 backing” yourself. That was just a snapshot from October 17. Later, I deposited some money in the vault myself, and I kept wondering: who’s keeping an eye on things every day after the snapshot? This week, I set up the checks to run automatically every six hours. While I was at it, I went back and reconciled every cross-chain transfer since launch—and found two more things than I expected.

The short answer: no. A single snapshot can only prove that the numbers on both sides matched at that moment. To have ongoing confidence, you need to do at least three things: match every cross-chain transfer on both chains using its message ID; put every balance change on both chains into a timeline and check whether the supply ever exceeded the vault’s holdings; and periodically check who is actually signing off on transfers.

I’ve checked all three of these things for BRL1.p. Since launch, all 18 cross-chain transactions have reconciled, and across 36 balance changes, the supply has never exceeded the vault. But there were two things the previous snapshot couldn’t show: one of the three required verifiers changed its signing key on the first day BRL1.p was live, and its name in LayerZero’s registry later changed from Nethermind to Twinstake; additionally, all 54 verifications by the three verifiers were submitted on-chain by the same account.

What one snapshot missed

BRL1.p is the version of the Brazilian real stablecoin BRL1 bridged to the Rayls public blockchain. Users deposit BRL1 on Polygon into a vault contract; LayerZero relays the message to Rayls, where the same amount of BRL1.p is minted. In the reverse direction, tokens are first burned, then unlocked.

In the October 17 snapshot, the vault balance and BRL1.p supply were both 250,013.482911, exactly matching. But the snapshot itself couldn’t tell us what happened between the two snapshots. I matched lock and mint transactions by amount, address, and order, without using LayerZero message IDs. If I’d matched them incorrectly, I wouldn’t have noticed. As for the “three verifiers,” the snapshot only showed the three addresses in the configuration; it didn’t show who was behind them or which keys they used to sign.

The code, transaction-by-transaction records, and logs from every run are in the 2026-11-brl1p-monitor folder of the public hansonhan0520-lang/rayls-verify repository. GitHub Actions runs the checks automatically every 6 hours and commits the results back to the repository. The figures in this article come from several runs between 03:25 and 03:56 UTC on November 6, 2026.

First: Reconcile each transaction using its message ID

LayerZero assigns a unique ID, a GUID, to each cross-chain message. It is recorded in the OFTSent event on the source chain when the message is sent, and in the OFTReceived event on the destination chain when it arrives. Matching IDs mean it’s the same transaction.

The result: 18 transactions—16 from Polygon to Rayls and 2 from Rayls to Polygon. The GUIDs matched on both sides for every transaction, the amounts locked equaled the amounts minted, and the transaction hashes on both ends listed by LayerZero’s own message explorer, LayerZero Scan, matched the on-chain records. LayerZero numbers messages on each channel sequentially: the 16 transactions were numbered 1 to 16, and the transactions in the reverse direction were numbered 1 and 2, with no gaps. So the table contains every message. I also checked the reverse: every change in the vault balance and BRL1.p supply had a corresponding cross-chain message, with no tokens minted or transferred out “out of nowhere.”

Arrival times: Polygon to Rayls took 248–293 seconds, with a median of 267 seconds; the reverse direction took 57 and 63 seconds. The previous 13 transactions ranged from 248 to 274 seconds. One transaction added on October 28 took 293 seconds, extending the upper bound.

Second: Put both chains on one timeline

A healthy lock-and-mint bridge has an invariant: the BRL1 in the vault must never be less than the BRL1.p supply. Because funds are locked before tokens are minted, and tokens are burned before funds are unlocked, during the four or five minutes a transfer is in flight, the vault holds more than the supply by the amount currently in transit.

I lined up the 36 balance changes across both chains by block timestamp and calculated the difference after each change. The difference was never below 0; its minimum was exactly 0, meaning the supply never exceeded the vault at any point. On Polygon, I didn’t rely only on event-based calculations: at the blocks for all 18 balance changes, I directly read the vault’s balanceOf using two independent archive nodes, drpc and Tenderly. Every reading matched the calculated result.

I also reread the administrative permissions. From October 14 to November 6, I read the Polygon vault’s owner, peer contract, LayerZero delegate, and verifier configuration once each day at 00:00 UTC. All 24 readings were identical. All 18 administrative and configuration events found on the two chains occurred during deployment, between 18:05 and 18:10 on October 13; there have been no changes since. The situation noted last time also remains unchanged: minting and burning rights are held only by the cross-chain adapter, while the administrator, pause, upgrade permissions, and ownership of both contracts remain with the same regular wallet address.

Third: Who is actually signing off?

There was a major incident in this area this year. In April, KelpDAO’s cross-chain bridge was exploited for about $292 million. In its May incident report, LayerZero attributed the cause to manipulated RPC nodes combined with an application configuration that relied on just one verifier. LayerZero calls its verifiers DVNs. They observe messages on the source chain and, once enough confirmations have accumulated, sign off on them for release on the destination chain. BRL1.p requires all three DVNs to sign in both directions: LayerZero Labs, Canary, and a DVN with the ID nethermind.

First, did they actually sign? Before each message arrives, the destination chain records one PayloadVerified event for each DVN. Each of the 16 Polygon-to-Rayls messages has three such events on Rayls, for 48 in total; each of the 2 messages in the reverse direction has three on Polygon, for 6 in total. Every event reports exactly the required number of confirmations: 120 blocks on Polygon and 10 on Rayls. On Rayls, verification arrived 232–253 seconds after the lock on Polygon. Most of the four-plus minutes the transfer took was spent waiting for Polygon’s 120 blocks.

Next, who signed? The DVN contracts require each verification to include signatures from a minimum number of signers. Those signatures are in the verification transaction’s input data, so the signing addresses can be recovered. I recovered the signers for all 54 verifications. LayerZero Labs requires 2 signatures from a set of 3 signers; the same two keys signed all 16 transactions. Canary requires 1 signature from 1 signer; the same key signed all 16 transactions.

The change was with the third DVN. The first 4 transactions (October 14) were signed by key 0xbbd4; from the fifth transaction (October 15) onward, the key changed to 0x86f0, with one transaction signed by 0x598c. On-chain records show that between 19:55 on October 14 and 00:30 on October 15 UTC, this DVN simultaneously added two signers and removed the original one on both Polygon and Rayls—right between the fourth and fifth BRL1.p transactions.

The name changed too. In my October 17 run log, LayerZero’s public DVN registry listed this address as Nethermind; when I checked again on November 6, it was listed as Twinstake, with the ID still set to nethermind. Nethermind announced on August 19 that it had stopped operating a LayerZero DVN and was moving to Chainlink node operations. Taken together, the most likely explanation is that Nethermind handed this DVN over to Twinstake, and the signing keys changed along with it. This is my inference: on-chain, we can see that the keys changed on October 14, but not who holds them. The registry is an off-chain label maintained by LayerZero, and I only have readings from two dates, so I don’t know exactly when the name changed.

There’s another common factor. All 54 verification transactions, across all DVNs and both chains, were submitted by the same account, 0xb8ff…47cb. This account and another account, 0xb52f…f0b6, both hold administrator roles on all six DVN contracts—three on each chain. It has already sent more than 8.88 million transactions on Polygon. According to LayerZero’s contract code and documentation, administrators submit verifications, but each submission must include the required signer signatures; an administrator cannot forge a verification on its own. My interpretation is that, security-wise, the three locks still use three separate sets of keys, and forging a message would require obtaining at least four signing keys (2 + 1 + 1). But for availability, the submission channel is concentrated in one account. If it stops working, cross-chain transfers in both directions will get stuck waiting. The latter is an inference based on the code; I haven’t observed an outage.

A reproducibility snag: the official node can’t reconstruct history

For others to reproduce the results, it’s important to explain where the data comes from. The official Rayls public node isn’t much help here: reading any historical state returns “pruned,” and it can’t even read the October 17 block. Queries for logs from BRL1.p and the adapter return 0 entries across a range of 1.5 million blocks, and I can’t get a receipt for any of the 18 Rayls transactions. But the transactions themselves are searchable, and the input data for all 16 incoming transactions includes the corresponding GUID, recipient address, and amount. The 2 outgoing transactions also include the recipient address and amount.

So the event history on the Rayls side has to come from the Rayls block explorer. I cross-checked it against three things: LayerZero Scan records, transaction input returned by the official node, and the current supply of 255,291.961901 read from the official node. That supply exactly matches the figure reconstructed from the explorer events. On Polygon, I used PublicNode and Tenderly to retrieve logs; the two nodes matched entry by entry.

The reserves: still the same report

The bridge only handles a one-to-one relationship between BRL1.p and BRL1. Whether BRL1 itself is backed by reais depends on the issuer’s proof of reserves. As of November 6, the latest report I could download from brl1.io was still the one dated October 1: reserves of 19,354,372 reais against 17,381,384.54 BRL1, a ratio of 111.35%. The report says it was prepared internally and has not been audited by an independent firm. Yet the link on the website is labeled “Latest audited proof of reserves.” The link marked “Latest” on the “How it works” page leads to a report dated April 14, 2025, also prepared internally; another link requires signing in to Google to view, and the Fact Finance reserves page linked from the website returns a 404.

For the two reports I could access, I checked the token amounts against the block numbers they cited. Readings from both archive nodes matched the reports. This shows that the “liabilities” side of the reports matches the blockchain; the “assets” side is still only the issuer’s own assertion. On November 6, there were already 17,882,561.54 BRL1 on Polygon—501,177 more than on October 1—and no public report covers the reserves corresponding to those additional tokens.

For an example of what independent assurance can look like, consider the U.S. GENIUS Act: issuers publish the composition of their reserves every month, certified by the CEO and CFO, and an external accounting firm provides attestation. BRL1 is a Brazilian stablecoin and is not subject to this law; I’m using it only as a point of comparison. When BRL1 does publish an independent report, first check whether it’s signed by an independent accounting firm and whether it specifies the type of assurance performed and the standards used. You can check whether the token amounts in the report are readable at the cited block using por_check.py in the repository.

What’s still missing

The event history on the Rayls side depends on the block explorer; the official node can only provide a cross-check, not an independent reconstruction. Polygon’s daily readings are taken only once at 00:00, but every balance change was also checked separately by block. The blockchain doesn’t show who holds the signing keys or who operates the 0xb8ff account. Automated checks began on November 6 and cover only the period after that date; the earlier period was reconstructed from historical data.

My take

Transaction-by-transaction checks show the bridge itself is clean: all 18 transactions reconcile, and the supply never exceeded the vault. The signing layer is more complicated than “three verifiers” suggests: there really are three separate sets of keys, but one set changed on the first day of operation, and there’s only one submission channel. The weakest link remains the issuer: the latest proof of reserves is still an unaudited internal report.

The standard for checking is simple. Anyone can run the brl1p-monitor workflow in the rayls-verify repository, or view the results it commits every 6 hours. If there’s a new administrative or configuration event, a verifier changes signers, the supply exceeds the vault even once, or BRL1 publishes an independently attested reserve report, it will be recorded in the next run.

Sources:

Article code, transaction-by-transaction records, and run logs (submitted November 6, 2026): https://github.com/hansonhan0520-lang/rayls-verify/tree/4e37e76f7541fbea2cba1c0b8967c46afa905677/2026-11-brl1p-monitor

Run logs from the previous snapshot (October 17, 2026): https://github.com/hansonhan0520-lang/rayls-verify/tree/main/2026-10-brl1p-backing

LayerZero DVN contract documentation: https://docs.layerzero.network/v2/workers/off-chain/dvn-technical-reference

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

LayerZero KelpDAO incident report (May 18, 2026): https://layerzero.network/publications/kelpdao-incident-report.pdf

crypto.news, Nethermind exits its role as a LayerZero verifier (August 19, 2026): https://crypto.news/nethermind-leaves-layerzero-verifier-role-chainlink/

BRL1 official website and proof-of-reserves documents (accessed November 6, 2026): https://brl1.io/en

Center for Audit Quality, GENIUS Act requirements for accountants (October 27, 2025): https://www.thecaq.org/audit-in-action-what-does-the-genius-act-require-of-accountants

#Rayls $RLS #Stablecoin