A bank that wants its tokens to reach public-chain liquidity has to answer this question clearly. The place where the compliance check sits determines what the institution can still tell a regulator about a holder after the asset is no longer only on its private books.
I have been reading the current Rayls documentation and product pages (as of early October 2026) to see how the design actually handles this. Below is what the primary sources say, what can be verified from them, and where gaps remain.
What Rayls Sovereign is (from the official product page)
Rayls Sovereign is a private, institutional-grade EVM ledger that an institution runs inside its own perimeter, next to its core banking and treasury systems. The institution keeps control of its data, keys, and governance. It can mint tokenized deposits, receivables, private credit, or other assets and settle them atomically. When the institution chooses, it can connect outward through compliant bridges.
The product page states: “Compliant bridges reach Rayls Private Networks and the Rayls Public Chain, when you choose and only then.”
How the public-chain route works (from the official docs)
According to the page “Connecting Rayls Sovereign to the Rayls Public Chain” (updated early October 2026), the path is a direct one-to-one connection. It does not go through the Private Network Hub. It uses its own RN-prefixed contracts and a dedicated public relayer.
The documented flow is:
1. The token is deployed on the Sovereign ledger and registered in RNTokenGovernanceV1. Setting the status to ACTIVE emits a TokenActivated event.
2. The public relayer deploys a mirror token on the Public Chain and records the pairing.
3. A user who is registered in RNUserGovernanceV1 can call `teleportToPublicChain`. The docs state: “The call requires the caller to be registered in RNUserGovernanceV1, enforced by an onlyRegisteredUsers modifier, which is how KYC and compliance requirements are carried into the bridge itself rather than being applied alongside it.”
4. Tokens are locked on the Sovereign ledger and the mirror is minted on the Public Chain.
5. To return, the holder calls `teleportToPrivacyNode` on the public mirror. This burns the mirror and unlocks the original on the private side. The documentation does not describe a second registration check on the return path.
The Public Chain product page describes the same lock-and-mint mechanism. The Public Chain itself is permissionless: anyone can hold USDr, deploy contracts, or transact. Compliance, when needed, is enforced at the smart-contract layer of the specific application.
Where the compliance check sits and what that means
In the standard Rayls public route, the registration check sits at the outbound call from the institution’s ledger. Once the mirror token exists on the Public Chain, further restrictions depend on custom rules the issuer adds or on vault-level attestation controls.
This differs from designs that check continuously inside a trading pool (for example, requiring a non-transferable credential and a whitelist before every trade or liquidity action). Both approaches can answer the question of who may hold the asset, but they do so at different moments and with different ongoing visibility for the issuer.
From the published documents, the practical trade-off is:
- A check at the bridge keeps the control point inside the institution’s perimeter at the moment of exit. Continuous control after that requires additional rules.
- Continuous checks inside a pool give ongoing wallet-level visibility but place key management and upgrade paths with the venue.
A September 2026 SEC order on temporary conditional relief for tokenized securities venues describes pool allow-lists and token-level transfer restrictions. It does not mention a bridge-level check.
What can be verified from primary sources and what remains open
Documented and verifiable from the current public docs:
- Registration requirement on `teleportToPublicChain` via RNUserGovernanceV1.
- Lock on the private side and mint of the mirror on the public side.
- No registration check described on the return path.
- Freeze controls exist on the Private Network route; no equivalent is described for the direct public route.
Still not independently verifiable from public sources:
- Who can add or remove users in RNUserGovernanceV1 on a live deployment.
- Whether deployed mirror contracts currently have active timelock or multisig settings on their access managers (no public list of mirror addresses is published).
- The exact implementation of the “attestation-based access controls” mentioned for public-chain vaults.
These open points matter because they affect what an institution can confidently state to a regulator once tokens are on the public chain.
Production context
The architecture is already used in production or pilot settings. Examples publicly referenced by Rayls include Núclea tokenizing corporate receivables at scale, XP’s USDXP stablecoin, and institutional issuance of private credit and other real-world assets. These show the “private first, public only when chosen” model in operation.
Bottom line
Rayls gives an institution a private ledger it owns and a documented, registration-gated path onto a permissionless public chain. The compliance control that is explicitly written into the public documentation sits at the moment the tokens leave the private ledger. Everything after that depends on custom rules or the rules of the specific public application the tokens enter.
That is what the current primary sources support. The remaining questions are practical ones that institutions and regulators would still want answered for any specific deployment.
---
Sources
Official Rayls Documentation & Product Pages
- Rayls Sovereign Product Page: https://rayls.com/products/sovereign
(Statements on compliant bridges, attestation-based access controls, and asset tokenization use cases)
- Connecting Rayls Sovereign to the Rayls Public Chain: https://docs.rayls.com/docs/connecting-rayls-sovereign-to-the-public-chain
(Teleport flow, onlyRegisteredUsers, RNUserGovernanceV1, lock-and-mint, return path)
- Rayls Public Chain Product Page: https://www.rayls.com/products/public-chain
(Lock-and-mint bridge description, permissionless nature of the Public Chain, compliance at the smart contract layer)
- RaylsErc20Handler: https://docs.rayls.com/docs/raylserc20handler
(Details on teleportToPublicChain, isCustom flag, Owner and MESSAGE_EXECUTOR roles)
- Rayls High-Level Architecture: https://docs.rayls.com/docs/rayls-high-level-architecture
- Tokenised deposits and stablecoins on Rayls Sovereign: https://docs.rayls.com/docs/rayls-node-use-cases-tokenised-deposit
Rayls Blogs & Announcements
- Introducing Rayls Sovereign for institutions: https://www.rayls.com/blog/introducing-rayls-sovereign-the-onchain-gateway-for-institutions
- The private-public settlement flow: tokenised deposits and stablecoins on Rayls: https://www.rayls.com/blog/the-private-public-settlement-flow-tokenised-deposits-and-stablecoins-on-rayls
- Bridging to the Rayls Public Chain: LayerZero integration is live: https://www.rayls.com/blog/bridging-to-the-rayls-public-chain-layerzero-integration-is-live
External Sources
- SEC Order Granting Temporary Conditional Exemptive Relief, Release No. 34-106402, 17 September 2026: https://www.sec.gov/files/rules/exorders/2026/34-106402.pdf
Note
All technical descriptions and quotations above are taken directly from the sources listed. Certain operational details (who manages live user registration, access manager settings on deployed mirror tokens, and the exact implementation of vault attestation controls) are not yet publicly available and therefore cannot be independently verified.