When a stablecoin appears on a new chain, the symbol tells almost none of the story. A balance labeled “USD” can be an issuer’s own token, a claim on coins held in a bridge contract, or a synthetic asset backed by a liquidity pool. Those are different assets with different redemption paths, operational controls, and failure modes—even if a wallet displays them the same way.
That is why Ripple’s expansion of RLUSD to Optimism, Base, Ink, and Unichain is more interesting than another chain-support announcement. Ripple began L2 testing with Wormhole’s Native Token Transfers (NTT) in December 2025, pending regulatory approval; its current product documentation lists all four networks alongside Ethereum, XRPL, and the XRPL EVM sidechain. The important distinction is not that NTT makes a bridge disappear. It is that it gives an issuer a way to move supply between chains without relying on the familiar model where a third-party bridge locks a token and issues a separately branded wrapped copy. Ripple’s launch announcement and current RLUSD documentation describe the rollout.
The answer in one 100-RLUSD transfer
Here is the concrete difference a user, wallet, or treasury team should understand. The table describes the NTT design pattern, not a claim about a particular RLUSD contract’s unpublished configuration. NTT supports both burn-and-mint and hub-and-spoke deployments; an issuer chooses the mechanism and controls its token’s minting permissions.
| Step | NTT-style native supply movement | Traditional locked-and-wrapped bridge |
|---|---|---|
| Start | A holder sends 100 RLUSD to the source-chain NTT manager. In a burn-and-mint design, 100 units are removed from circulation on the source chain. | A holder sends 100 issuer-issued RLUSD into a bridge escrow. The 100 units remain locked there. |
| Verify the transfer | The manager routes a transfer message through its configured transceiver(s). On the destination, the manager waits for its configured verification threshold. | The bridge’s validator, relayer, or multisig authorizes the destination bridge contract. |
| Finish | Once verification and inbound limits pass, 100 units are minted to the recipient on the destination chain. Global supply remains unchanged: 100 fewer on the source, 100 more on the destination. | The destination bridge mints or releases 100 bridge-issued representations. The holder has an additional contract and bridge relationship to assess. |
| If capacity is exhausted | NTT can queue completion until an inbound limit allows it; the transfer is not magically instantaneous or risk-free. | A pool can run short of destination liquidity, or an escrow / bridge control can become the critical bottleneck. |
Wormhole’s documentation calls the components that route and verify messages transceivers. The NTT manager enforces outbound and inbound rate limits, collects enough transceiver attestations to reach its configured threshold, and then mints or unlocks on the destination. A higher threshold can add redundancy but can also slow completion; rate limits can turn a large transfer into a queued one. Those details are security controls, not footnotes. Wormhole’s transfer-flow documentation and its configuration guide make that trade-off explicit.
“Native” therefore means something specific: the issuer retains the supply and policy model across the token’s supported chains. It does not mean that tokens teleport without cross-chain messaging, that a token holder no longer needs to evaluate smart-contract permissions, or that an NTT manager cannot be paused. It also does not make a stablecoin’s fiat redemption claim stronger by itself. That claim lives with the issuer and its reserves, not with the transport protocol.
A useful comparison: four ways to unify stablecoin liquidity
The phrase “not wrapped” can become marketing shorthand unless the mechanism is named. There are several legitimate designs, and the right question is which party operates each layer and which contract relationship a holder relies on.
| Model | Supply movement | Who provides the key transport assurance? | What the holder is primarily relying on |
|---|---|---|---|
| RLUSD with Wormhole NTT | NTT can burn/mint or use hub-and-spoke lock/mint; Ripple says it preserves native issuance and control | The NTT deployment’s chosen transceiver set and threshold | The RLUSD issuer’s redemption/reserve terms plus the NTT messaging and policy configuration |
| Circle CCTP for USDC | Burn native USDC on one supported chain; mint native USDC on another | Circle’s attestation service | Circle’s issuer controls and the CCTP attestation path |
| USDT0 / LayerZero OFT | Its documentation describes an Ethereum lockbox with destination-chain minting, and burn/unlock on return | LayerZero messaging plus USDT0’s dual-DVN configuration | Locked collateral, USDT0’s contracts, and the selected verification networks |
| Ordinary wrapped-token bridge | Lock an issuer token; mint a representation elsewhere | The bridge’s own validators / relayers / control keys | The issuer token and the bridge escrow and wrapper contract |
The comparison is intentionally not a ranking. CCTP is also a native burn-and-mint route: Circle says it burns USDC on the source chain, obtains a Circle-signed attestation, then mints native USDC on the destination. Its supported-chain list includes Base, Optimism, Ink, and Unichain. Circle’s CCTP overview is a useful reminder that “native supply movement” is not unique to any one interoperability provider.
USDT0 illustrates a different but still supply-accounted design. Its technical documentation says that original assets are locked in an Ethereum OFT adapter, equivalent USDT0 is minted on destination chains, and a return transfer burns the destination token before unlocking the original. USDT0’s architecture says its transfers require both LayerZero and USDT0 verification networks. That is not the same as a generic third-party wrapped token, but it does leave an Ethereum lockbox as a material part of the system.
The common invariant is simple: a system must not create more redeemable dollars globally just because the token crossed chains. The different designs decide whether that is enforced by burning and minting issuer-controlled supply, by locking collateral and minting a claim, or by rebalancing liquidity pools. None removes the need for a careful review of upgrade authority, pause rights, rate limits, message verification, and monitoring.
Why these four L2s matter—and what the rollout actually proves
Optimism, Base, Ink, and Unichain put RLUSD where Ethereum-compatible applications can use lower-cost execution and existing DeFi integration patterns. For a stablecoin issuer, deploying to several L2s can reduce the pressure to choose one venue for payments, trading collateral, or application settlement. For an integrator, though, chain availability is only the start: token address verification, market liquidity, supported exchanges, redemption access, and policy restrictions determine whether a balance is actually useful.
Ripple’s own materials are a better guide than an inferred launch narrative. The December 2025 announcement says testing would begin on the four networks ahead of an official debut, subject to approval. The present documentation lists Base, Ink, Optimism, and Unichain as supported RLUSD networks and publishes the relevant EVM token addresses. Ripple’s token-address page is the right source for an integration—not an address copied from social media or a token bearing a familiar ticker.
This is also a distribution test, not proof that a technically elegant transport layer will produce liquidity. Circle already documents CCTP routes across a broad list of chains, including the same four L2s. Tether’s USDT0 documentation describes an omnichain system around a lock-and-mint architecture. An issuer wins useful share only when on-ramps, exchanges, wallets, lending markets, and business settlement flows meet on the same supported networks. A new deployment gives those participants an option; it does not compel them to use it.
“Regulated” lives in the issuer stack, not in the bridge label
RLUSD’s institutional case depends more on its issuer and redemption structure than on whether its transfer message uses NTT. Ripple says Standard Custody & Trust Company is a New York Department of Financial Services-chartered limited-purpose trust company, that RLUSD is backed one-to-one with permitted cash equivalents, and that direct customers meet bank-level KYC and AML requirements. The company publishes monthly reserve attestations and reports that BNY is the primary reserve custodian.
Those are meaningful claims to inspect, but they should be kept separate from protocol security. Ripple’s transparency page reported $1.8665 billion of RLUSD circulating as of August 20, 2026, against $1.9813 billion of reserve funds; the page also states that the figures are subject to monthly third-party attestations. Ripple’s transparency reports and RLUSD user terms explain the reserve and redemption framework. NYDFS separately lists RLUSD among its greenlisted coins, while retaining the ability to limit or remove a listed coin. NYDFS’s virtual-currency listing page provides that regulatory context.
For an institution, the resulting diligence has two columns:
- Issuer and asset: Who has a direct redemption right? What reserve assets and attestations are available? Who can freeze, mint, or pause under the terms and contracts?
- Transport and deployment: Which contracts are canonical on each chain? Which transceivers and thresholds verify a transfer? What are the rate limits, upgrade paths, incident procedures, and monitoring signals?
Treating the first column as a substitute for the second is a category error. A fully reserved issuer can still depend on cross-chain contracts. Treating an interoperability brand as a substitute for issuer diligence makes the opposite error.
The competitive question is adoption, not a slogan
The addressable market is large but concentrated. The IMF reported that the stablecoin market grew roughly 50% during 2025 to about $300 billion by year end, with USDT and USDC together representing more than 80% of market capitalization. More recently, CoinDesk Data reported a $308 billion sector market capitalization at the end of July 2026. The IMF’s 2026 analysis and CoinDesk Data’s July report are useful scale indicators, not forecasts for RLUSD.
That concentration makes the real test measurable. Watch the verified supply and liquidity on each L2, the number of reputable on/off-ramp and exchange venues, the depth of pools rather than their promotional TVL, integration by wallets and payment applications, transfer success and queue behavior, and whether direct redemption remains clear across jurisdictions. For tokenized-fund settlement, look for disclosed production usage rather than treating a partnership announcement as volume. Ripple and Securitize announced a smart-contract mechanism allowing BUIDL and VBILL holders to exchange their shares for RLUSD; that is a concrete use case, but it is not evidence by itself that RLUSD will capture broad L2 liquidity. Securitize’s announcement describes the arrangement.
The practical takeaway: verify the asset and the path
Ripple’s L2 expansion is a meaningful example of the market moving beyond casually wrapped stablecoin copies. NTT gives a token issuer a configurable way to preserve a global supply invariant while extending a token into several ecosystems. But the useful conclusion is narrower than “native is safe.” A transfer still crosses a security boundary; it still depends on configured verification, smart-contract roles, capacity limits, and an issuer’s redemption and reserve practices.
For builders, the implementation discipline is straightforward: use the issuer’s address registry, identify the canonical contract and transfer path on both chains, read the pause and upgrade authorities, simulate a failed or rate-limited transfer, and keep issuer-redemption risk separate from bridge-message risk. That is the difference between recognizing an RLUSD balance and understanding what backs—and moves—it.



