On October 15, I bridged some BRL1 from Polygon to Rayls in two transactions, swapped them for BRL1.p, and put them into the launch deposit for Rayls’ first vault. The page said that every BRL1.p is backed one-to-one by BRL1, but honestly, I had no way to verify that claim myself when I clicked confirm. This article is a complete post hoc walkthrough of “how to verify it.”
The short answer
When a cross-chain bridge stablecoin claims to be “backed 1:1,” that actually involves three things. The most straightforward is whether the bridge’s vault holds enough coins. That, along with “can anyone mint extra coins without going through the vault?”, can both be checked directly on-chain. The remaining question—whether the locked stablecoins themselves have real reserves—lies beyond the blockchain, so you can only consult the issuer’s reports.
Think of a bridge as a coat check: you hand over a coat and get a claim ticket. Counting whether the coats on the rack match the tickets issued is the easiest check; more important is who holds blank tickets and whether the coat itself is genuine.
I checked BRL1.p at these three levels at 07:21 UTC on October 17, 2026. The vault balance and circulating supply matched exactly: 250,013.482911 BRL1 was locked in the Polygon vault, and the total supply of BRL1.p on Rayls was also 250,013.482911—not a single decimal place off. According to the code, minting authority was given only to the bridge contract, but privileges that can change the rules are currently concentrated in a single ordinary wallet address. As for BRL1's reserves, the issuer's October 1 report states 111.35% collateralization. I verified the on-chain half of the reserves listed in the report; the report itself states that the bank-held half has not yet been independently audited.
Each step below explains where to look and what to check, so readers can repeat the process.
What exactly does “1:1 backed” mean? Three things to check
BRL1 is a real-denominated stablecoin issued on Polygon by a consortium of Brazilian firms (Mercado Bitcoin, Bitso, Foxbit, and Cainvest). BRL1.p is its bridged version on the Rayls chain, using LayerZero's “lock-and-mint” model: you deposit BRL1 into the bridge vault on Polygon, and an equivalent amount of BRL1.p is minted on Rayls. To redeem, BRL1.p is first burned on Rayls, then the Polygon vault releases the BRL1.
Rayls documentation says that every BRL1.p is backed one-to-one by BRL1 in the vault, and that anyone can check the vault on-chain. That statement is true, but it covers only the first layer. I wanted to find out how much an ordinary user can verify for themselves at each of the three layers.
Layer one: Does the vault balance match the circulating supply?
The first layer requires no coding. Just open a block explorer and read two numbers.
On Polygon, open the BRL1 contract (0x5C067C80C00eCd2345b05E83A3e758eF799C40B5) in the explorer and go to “Read Contract.” Since it is a proxy contract, click “Read/Write proxy.” Find balanceOf, enter the bridge vault address 0x3Ea6BaC7d4138BcC126D0F17aE10122B3620abA6, and click Read. The result I got was 250013482911000000000000. BRL1 has 18 decimal places, which converts to 250,013.482911 tokens.
On Rayls, open the BRL1.p contract (0xA069d3798FEAb32994aC5D98A9F011DA6024f334) in the same page on explorer.rayls.com and read totalSupply. The result is also 250013482911000000000000.
There's a small trap worth mentioning here. When I looked directly at the vault address's “Tokens” tab in Polygon's Blockscout explorer, it showed zero tokens at 07:11 UTC, while a contract read one minute later returned more than 250,000. The balance tab is an index compiled by the explorer, so it may be delayed or incomplete; the figure in the contract is the on-chain state. So when verifying, read the contract—don't rely on the balance tab.
One more detail: a healthy state is “vault balance ≥ circulating supply,” not necessarily an exact match. Cross-chain transfers take time while messages are delivered. I counted all 13 transfers from Polygon to Rayls to date: from the vault receiving BRL1 to BRL1.p being minted on Rayls took between 248 and 274 seconds, with a median of 265 seconds. The two redemptions in the other direction took 57 and 63 seconds, respectively. This matches the documentation's “about 5 minutes” and “about 2 minutes.” During that time, the vault will hold more than the circulating supply by the amount still in transit. Conversely, if the circulating supply ever exceeds the vault balance, that is the warning sign to watch for.
I checked four times between 07:04 and 07:21 UTC, and both sides showed 250,013.482911 each time.
Is checking the balance enough? Check the transaction history too
A matching balance only shows that things match at this moment. A more thorough check is to go through every deposit and withdrawal the bridge has handled since deployment.
On Polygon, the vault has received 13 BRL1 deposits since its deployment on October 13, totaling 259,589.937257 tokens. On Rayls, BRL1.p has been minted 13 times, also totaling 259,589.937257 tokens. The vault has released tokens twice, totaling 9,576.454346; BRL1.p has also been burned twice on Rayls, totaling 9,576.454346. I matched them one by one by “same amount, same address, chronological order.” All 13 deposit-mint pairs and both withdrawal-burn pairs matched, and the sender and recipient addresses in each pair were the same wallet. To be clear, I matched these by amount and address; I did not decode the LayerZero message IDs one by one.
Two of those transfers were mine: they took about 260 seconds and 250 seconds, respectively, to arrive.
Layer two: Who can mint extra tokens, and who can change the rules?
Having the same number of coats and claim tickets doesn't mean nobody can secretly print more tickets. This layer requires checking the contract code and permissions.
The BRL1.p contract source code has been publicly verified on the Rayls explorer. According to the code, only an address holding MINTER_ROLE can mint, and only an address holding BURNER_ROLE can burn; ordinary holders cannot burn tokens directly. The design goal stated in the code comments is that “BRL1 locked on Polygon equals the total supply of BRL1.p.” On-chain events show that since deployment, both roles have been granted to only one address: the bridge contract on Rayls, 0xE56dDf65E311CddB71f69c0aC4D27E58B239D69a. There have been no revocations and neither role has been granted to any other address.
The bridge contracts on the two sides also point to each other: the Polygon vault lists this Rayls contract as its peer, and the Rayls contract lists this Polygon vault as its peer. Cross-chain messages must be signed by all three “verification networks” (called DVNs by LayerZero) to be accepted: LayerZero Labs, Nethermind, and Canary. All three are required; none is optional. Messages sent from Polygon require 120 block confirmations, while messages sent from Rayls require 10. This aligns with the guidance in LayerZero's own integration checklist to use “more than one DVN” and have “at least one not operated by LayerZero Labs.”
The other set of permissions is what really deserves attention. BRL1.p is an upgradeable contract. An address holding DEFAULT_ADMIN_ROLE can grant minting privileges to any address, while an address holding UPGRADER_ROLE can replace the contract code. As of my check, these two roles, along with the pause authority, the owners of both bridge contracts, and the delegate for configuration at the LayerZero endpoint, were all held by the same address: 0x633Ac5e2315b973417e8caa6B3Ad2162e0461ce1. This address has no contract code on either chain, meaning it is an ordinary wallet, not a multisig.
This doesn't mean anyone will act maliciously. It means that, at this layer, “1:1” depends on the safekeeping of this key, not on mathematics. LayerZero's integration checklist recommends setting both the contract owner and endpoint delegate to a multisig or governance contract. Deposits are still in the pilot phase, so whether these privileges will later be moved to a multisig or timelock is something worth monitoring—and anyone can check again using the script below.
As an aside, the source code verified for the Polygon vault is named WDATAAdapter, and its comments also refer to a different token. That might be surprising. The contract file itself contains only a constructor; the rest of the logic comes from LayerZero's OFTAdapter library, and the constructor arguments used at deployment point to BRL1. The on-chain token() call also returns the BRL1 address. It looks like a template was reused without renaming, and I found no evidence that this affects functionality.
Layer three: Can BRL1's own reserves be checked on-chain?
The first two layers are on-chain. The third asks: Is there really any Brazilian real behind the BRL1 locked in the vault?
The reserve report I could access on BRL1's official website is dated October 1, 2026. It states that at 16:07:25 UTC that day, at Polygon block 94777137, the circulating supply of BRL1 was 17,381,384.54 tokens, with total reserves of R$19,354,372 and a collateralization ratio of 111.35%. The reserves consisted of bank deposits (3.25%), Brazilian government LFT bonds (32.31%), and repurchase agreements (64.44%), held in a segregated account at Banco XP opened in the consortium's name.
For the on-chain half of the report, I used an archive node to read totalSupply at the same block. The result was exactly 17,381,384.54 tokens, and the block timestamp was 16:07:26 UTC—one second later than the report's timestamp. The bank-held half cannot be checked on-chain. The report itself says it was prepared internally by the BRL1 team and approved by the consortium's board, and that it “has not yet been audited by an independent entity.” Meanwhile, the BRL1.p documentation on Rayls says that “the consortium publishes audited proof-of-reserves reports.”
Additionally, the BRL1 contract itself is connected to an access-control contract called DenyList: denied addresses cannot transfer tokens, and an address holding recovery privileges (RECOVERY_ROLE) can also transfer tokens out of denied addresses. Many regulated stablecoins have similar designs, which means that BRL1 in the vault is also subject to rules set at the issuer level. When I checked, the bridge vault was not denied, and BRL1 had not been paused. The 250,013 BRL1 in the vault amounts to about 1.51% of the 16,575,367.54 BRL1 in total on Polygon.
A checklist you can use to reproduce the checks
I turned the steps above into a read-only script. It needs neither a wallet nor an API key: you can paste it into your browser console by pressing F12, or run it with Node 18 or later. The script, run logs, and screenshots are all on GitHub, at the commit for this run (commit 9d09d0c): https://github.com/hansonhan0520-lang/rayls-verify/tree/9d09d0cdca2c5446d22777db57513a46e0bace86/2026-10-brl1p-backing. It outputs six items in sequence: the vault balance and circulating supply; all deposits and withdrawals; whether the two sides point to each other; who holds which privileges; the DVN configuration; and BRL1's status at the issuer level.
It's important to distinguish that the balances, transaction histories, privileges, and configurations in this article were read directly from the chain; “reused a template” and “whether privileges will be migrated later” are my inferences or things to watch, not matters that can be proven on-chain.
During testing, I also ran into an issue: the official Rayls public RPC does not return event logs or transaction receipts for the blocks around deployment (near block 12437224), but the Rayls explorer has those records. So the script reads historical events on the Rayls side from the explorer's API, while still reading the current state from the RPC.
When looking at any “1:1 bridged” stablecoin in the future, you can start by asking these questions: Is the vault balance greater than or equal to the circulating supply? Is minting authority held only by the bridge contract? Are the privileges that can change the rules controlled by a multisig? How many independent verifiers must sign cross-chain messages? When was the underlying stablecoin's latest reserve report, and was it independently audited?
The balance, transaction history, privilege, and configuration figures in this article come from readings taken between 07:04 and 07:21 UTC on October 17, 2026. The historical block for the reserve report was checked later that same day, and figures may have changed since then as deposits and withdrawals occur. These are new measurements from my first investigation; I have not carried over conclusions from my earlier articles.
Risk notice: The initial deposit period is locked until November 19 at the latest, and the vault terms have not yet been finalized. Risks listed by Rayls include the possibility that BRL1.p may lose value or become irredeemable, as well as smart-contract failures. Participation requires KYC, and residents of some regions are not eligible. This article is not investment advice.
Sources:
Rayls documentation, Get BRL1.p (accessed 2026-10-17):https://docs.rayls.com/docs/get-brl1p
Rayls blog, First vault on Rayls: launch deposits open (2026-10-15):https://www.rayls.com/blog/first-vault-on-rayls-launch-deposits-open
BRL1 reserve report, Proof of Reserves, as of 2026-10-01:https://drive.google.com/file/d/1BuRUC6u3UTzf17kOChhKby_L9hE5IU73/view
BRL1.p contract source code (Rayls explorer, verified 2026-10-16): https://explorer.rayls.com/address/0xCAcBa996CA4c2AC37144BA30BFEBC5f7cDBD36D7?tab=contract
Polygon bridge vault contract (Blockscout, verified 2026-10-15): https://polygon.blockscout.com/address/0x3Ea6BaC7d4138BcC126D0F17aE10122B3620abA6?tab=contract
LayerZero Integration Checklist (accessed 2026-10-17): https://docs.layerzero.network/v2/tools/integration-checklist
LayerZero public DVN directory (accessed 2026-10-17): https://metadata.layerzero-api.com/v1/metadata/dvns
This article's verification script and evidence (commit 9d09d0c): https://github.com/hansonhan0520-lang/rayls-verify/tree/9d09d0cdca2c5446d22777db57513a46e0bace86/2026-10-brl1p-backing
#Rayls $RLS #BRL1 #Stablecoin #CrossChainBridge