stablecoin
Ripple USD RLUSD
Ripple USD (RLUSD) is a fiat-backed stablecoin with ~$1.75B circulating supply, natively issued on XRP Ledger and Ethereum, with recent expansion to L2s (Base, Optimism) via Wormhole NTT. The token is a standard ERC-20 / XRPL issued currency with no custom cryptographic primitives — it inherits the classical ECC-based security of all its host chains. Ripple has published a substantive 4-phase PQ roadmap for the XRP Ledger (targeting 2028) with Phase 2 ML-DSA testing on AlphaNet underway in H1 2026, but this covers only the base ledger, not RLUSD specifically. On Ethereum, admin control relies on classical ECDSA multisigs (7-of-7 for critical roles, 2-of-32 for operational roles). The Wormhole NTT bridge dependency introduces another classical-signature vulnerability surface. RLUSD's centralized freeze and clawback capabilities provide a meaningful quantum-recoverability path — the issuer could freeze compromised accounts and claw back tokens in a Q-Day scenario — but this is recoverability, not resistance. With 0% of value-at-risk protected by PQC or hybrid-PQC and no token-specific quantum mitigation, RLUSD scores 7/100 (Stage 1: Quantum Risk Assessed). Users should monitor Ripple's XRPL PQ roadmap and any future token-specific migration announcements.
Roadmap OnlyToken Inherits Host-Chain RiskPQ-RecoverablePartial Protection
Category breakdown
QRI Factors
Algorithm & Implementation Assurance
2.5 / 20
Migration Mechanism, Governance & Ecosystem Coordination
1.75 / 15
Migration Status & Value-at-Risk
1.5 / 25
Production Cryptographic Protection
0 / 35
Security Assessment & Evidence Preparedness
1.25 / 5
Critical Quantum Blockers
- All production spend authorization remains entirely classical (ECDSA on Ethereum, Ed25519/secp256k1 on XRPL) with no production PQC or hybrid-PQC protection.
- RLUSD Ethereum admin multisigs (UPGRADER, DEFAULT_ADMIN roles use 7-of-7 thresholds; MINTER, PAUSER, CLAWBACKER use 2-of-32) use classical ECDSA; compromise via quantum key recovery could allow unlimited minting, contract upgrades, and fund clawback.
- ~82% of RLUSD supply sits on Ethereum, which has no published PQC migration roadmap or production PQC support.
- Wormhole NTT bridge uses classical Guardian signatures (ECDSA); cross-chain transfers to L2s and XRPL EVM Sidechain are quantum-vulnerable at the bridge verification layer.
- No RLUSD-specific quantum migration plan exists for Ethereum deployment or Wormhole bridge dependency.
Key Risks
- Host-chain dependency risk: RLUSD's quantum security is entirely dependent on XRPL and Ethereum base-layer migration timelines. Neither chain has production PQC today.
- Admin key compromise risk: The 7-of-7 multisig controlling Ethereum contract upgrades and 2-of-32 multisigs for minting/burning/clawback use classical ECDSA. If threshold signer keys are compromised by a quantum attacker, the entire token contract can be upgraded maliciously or unlimited tokens minted.
- Bridge risk: Wormhole NTT Guardian signatures (13-of-19 classical ECDSA) secure cross-chain RLUSD transfers to L2s. A quantum break of the Guardian set could enable theft of bridged RLUSD value.
- Long-exposure risk: ERC-2612 permit signatures, transacted EOAs, and XRPL accounts with visible public keys create 'harvest now, decrypt later' exposure for long-held RLUSD positions.
- Value concentration risk: ~82% of RLUSD supply is on Ethereum where no protocol-native key rotation exists, making large-value migration operationally harder than on XRPL.
- No token-specific migration plan: Even if XRPL achieves PQ readiness by 2028, the Ethereum deployment (~$1.4B) and Wormhole-dependent L2 deployments have no published quantum migration path from Ripple.
Assurance Notes
- OpenZeppelin audit (2024) covers RLUSD Ethereum smart contract and MultiSign contract for classical security, not quantum-critical properties.
- Two confidential audits shared under NDA with Aave governance; none cover quantum-specific properties.
- XRPL PQC roadmap (Phase 2) includes ML-DSA testing on AlphaNet in H1 2026, but no production PQC deployment exists on any host chain.
- RLUSD Ethereum admin multisigs (7-of-7, 2-of-32) use custom MultiSign contract with classical ECDSA; no PQC migration plan documented.
- Wormhole Guardian Network uses classical ECDSA signatures (13-of-19 threshold); optional Boundless ZK verifier adds Ethereum consensus proofs but does not replace Guardian signatures.
- Freeze/clawback capability provides centralized recoverability mechanism but does not prevent quantum-enabled theft at the cryptographic layer.
- No quantum-specific audit or threat model published for RLUSD's multi-chain deployment.
- RLUSD supply is ~82% on Ethereum, ~18% on XRPL (as of May 2026).
Non-Scoring Caveats
- XRPL has a credible 4-phase PQC roadmap targeting 2028, with Phase 2 ML-DSA testing on AlphaNet in H1 2026, but this covers only the XRPL deployment (~18% of RLUSD supply).
- Centralized freeze/clawback provides recoverability mechanism if quantum attack is detected, but does not prevent the underlying cryptographic break.
- RLUSD is a standard ERC-20 and XRPL issued token with no custom cryptographic primitives; inherits all host-chain quantum vulnerabilities.
- No evidence of RLUSD-specific quantum threat assessment covering multi-chain deployment and bridge dependencies.
- OpenZeppelin audit is scope-mismatched for quantum readiness but provides general smart contract security assurance.
- No formal quantum-specific incident-response playbook exists for RLUSD.
Evidence record
Claims and Caveats
Security Assessment & Evidence Preparedness
Public cryptographic inventory of critical public-key mechanisms and public quantum threat model
Claim: RLUSD is a standard ERC-20 and XRPL issued token inheriting host-chain cryptography. No standalone quantum cryptographic inventory or threat model has been published for the token itself. Ripple's XRPL PQ roadmap (April 2026) provides a quantum threat model for the XRP Ledger base layer, which indirectly covers RLUSD on XRPL but does not address Ethereum-specific admin keys, Wormhole bridge dependencies, or token-level governance.
Coverage basis: Inherited host-chain risk; partial coverage from XRPL PQ roadmap only
Implementation score: 0.25 · Evidence confidence: Medium
Issue classification: quantum-critical uncertainty · Score treatment: score-reducing
Assurance: XRPL PQ blog post is a primary source with high credibility from Ripple. No equivalent Ethereum-side quantum assessment exists. The token documentation describes mechanisms but makes no quantum claims.
RLUSD is not PQ-native, so full credit under Section 7.1 does not apply. The XRPL roadmap is substantive but is a host-chain assessment, not a token-level inventory. The Ethereum and Wormhole dependency surfaces are entirely unaddressed.
Security Assessment & Evidence Preparedness
Public evidence record supporting the assessment
Claim: RLUSD has public GitHub repository, Etherscan-verified contracts, XRPL explorer entries, and official documentation. These support verification of the standard-token architecture but contain no quantum-specific evidence.
Coverage basis: Standard token evidence only; no quantum-specific artifacts
Implementation score: 0.25 · Evidence confidence: High
Issue classification: none · Score treatment: note-only
Assurance: Evidence quality is high for the classical implementation. The lack of quantum-specific evidence is expected for a standard token with no PQC features.
The GitHub repo has been stagnant since October 2025, indicating no active quantum-related development at the token level.
Production Cryptographic Protection
Spend authorization / transaction signatures are PQC or hybrid-PQC on mainnet
Claim: All RLUSD transactions rely on host-chain signatures: Ed25519/ECDSA on XRPL and ECDSA on Ethereum. No PQC or hybrid-PQC signature path exists on any production deployment.
Coverage basis: Host-chain classical signatures only; 0% PQ coverage
Implementation score: 0 · Evidence confidence: High
Issue classification: quantum-critical vulnerability · Score treatment: score-reducing
Quantum blocker: All production spend authorization remains entirely ECC/EdDSA-only across all host chains
Assurance: Verifiable from Etherscan (ECDSA), XRPL explorer (Ed25519/ECDSA), and Ripple's own PQ blog post confirming classical-only production signatures.
This is the fundamental quantum vulnerability. Both host chains (XRPL, Ethereum) and the token itself have zero PQ transaction signature protection.
Production Cryptographic Protection
Account, address, public-key exposure, and key-derivation design prevents long-exposure quantum-vulnerable ownership paths
Claim: RLUSD inherits host-chain account models. XRPL supports native key rotation (structural advantage) but uses classical key derivation. Ethereum EOAs have no key rotation; public keys are exposed on first spend. ERC-2612 permit signatures create additional long-exposure ECDSA signatures on-chain. No PQ/hybrid controls exist.
Coverage basis: Host-chain classical key models; XRPL key rotation provides migration path but not PQ protection
Implementation score: 0 · Evidence confidence: High
Issue classification: quantum-critical vulnerability · Score treatment: score-reducing
Quantum blocker: Long-exposure public keys on Ethereum (transacted EOAs, ERC-2612 permits) and XRPL create harvest-now-decrypt-later risk
Assurance: XRPL key rotation is confirmed by Ripple's PQ blog post as a structural advantage, but it does not prevent quantum attack on currently exposed keys. It only enables migration after detection.
The ERC-2612 permit function is particularly concerning — signed permits with ECDSA signatures are broadcast on-chain and persist indefinitely, creating a permanent long-exposure attack surface.
Production Cryptographic Protection
Consensus-critical authentication is PQC or hybrid-PQC where applicable
Claim: RLUSD has no independent consensus layer. It inherits consensus security from XRPL (Ed25519/ECDSA validator signatures) and Ethereum (BLS/ECDSA). Both host chains remain classical-only.
Coverage basis: Host-chain consensus; token has no independent consensus mechanism
Implementation score: 0 · Evidence confidence: High
Issue classification: quantum-critical vulnerability · Score treatment: score-reducing
Assurance: The token inherits host-chain consensus vulnerability. XRPL's PQ roadmap covers consensus migration (Phase 3-4), but no production protection exists.
Per Section 7.2, host-chain dependencies are applicable, not N/A. A quantum break of XRPL or Ethereum consensus would affect RLUSD settlement finality.
Production Cryptographic Protection
State-integrity and data-availability mechanisms are quantum-safe where applicable
Claim: RLUSD uses standard ERC-20 and XRPL issued-currency state models without custom state-binding cryptography. The token's supply integrity depends on host-chain state integrity (classical). The freeze/clawback mechanisms are enforced by classical admin signatures.
Coverage basis: Host-chain state integrity; token-level supply controls via classical multisig
Implementation score: 0 · Evidence confidence: High
Issue classification: quantum-critical vulnerability · Score treatment: score-reducing
Assurance: Supply integrity is ultimately protected by the 1:1 fiat reserve backing and monthly Deloitte attestations, providing an off-chain safeguard independent of cryptographic assumptions.
The fiat reserve backing and monthly attestations (Deloitte) provide an off-chain supply integrity guarantee that is independent of quantum attacks on the blockchain layer. However, on-chain supply manipulation via compromised admin keys could temporarily create discrepancies.
Production Cryptographic Protection
Privacy and proof layers are quantum-safe where applicable
Claim: RLUSD has no privacy layer or ZK proof system. This subfactor is not applicable.
Coverage basis: No privacy layer exists
Implementation score: 0 · Evidence confidence: High
Issue classification: none · Score treatment: not applicable
Production Cryptographic Protection
P2P transport, node identity, and peer authentication are PQC, hybrid-PQC, or satisfied by design
Claim: RLUSD is a token, not a blockchain network. It has no independent P2P layer. This subfactor is not applicable.
Coverage basis: No P2P layer exists at token level
Implementation score: 0 · Evidence confidence: High
Issue classification: none · Score treatment: not applicable
Production Cryptographic Protection
Critical wallet, custody, HSM, signer, and hardware-wallet workflows support the production PQ/hybrid path
Claim: RLUSD admin roles (MINTER, BURNER, PAUSER, CLAWBACKER, UPGRADER, DEFAULT_ADMIN) are controlled by ECDSA-based MultiSign contracts on Ethereum. No PQ/hybrid custody path exists for admin key holders. On XRPL, issuer account uses standard Ed25519/ECDSA keys.
Coverage basis: Classical ECDSA multisig for all admin functions
Implementation score: 0 · Evidence confidence: High
Issue classification: quantum-critical vulnerability · Score treatment: score-reducing
Quantum blocker: 7-of-7 ECDSA multisig for UPGRADER_ROLE and DEFAULT_ADMIN_ROLE could be compromised by quantum attacker controlling threshold of signer keys
Assurance: The Aave/Chaos Labs technical analysis (Dec 2024) provides detailed mapping of all admin roles and their multisig configurations. The multisig contracts are not verified on Etherscan.
The 7-of-7 multisig for UPGRADER_ROLE requires all signers. The 2-of-32 thresholds for operational roles (PAUSER, CLAWBACKER, MINTER, BURNER) are lower but still require classical ECDSA signatures.
Migration Status & Value-at-Risk
Percentage of economically relevant value-at-risk protected from quantum key-recovery attacks
Claim: Approximately $1.75B in RLUSD circulating supply is entirely unprotected from quantum attacks. ~$690M on XRPL, ~$1.06B on Ethereum, with a small amount on L2s via Wormhole. 0% of value is protected by PQC or hybrid-PQC.
Coverage basis: 0% PQ-protected value; all ~$1.75B is quantum-vulnerable
Implementation score: 0.05 · Evidence confidence: High
Issue classification: quantum-critical vulnerability · Score treatment: score-reducing
Quantum blocker: 0% of ~$1.75B RLUSD value-at-risk is quantum-protected; all value depends on classical ECC signatures
Assurance: Supply figures are independently verifiable from CoinMarketCap, CoinGecko, and Deloitte monthly attestations.
Coverage <25% maps to Implementation Score 0.05 (1/20 points per Section 9.3.1). The centralized freeze/clawback mechanism provides a recoverability path but does not constitute quantum protection of current value.
Migration Status & Value-at-Risk
Critical wallets migrated, protected, or inherently PQ-native
Claim: None of the RLUSD admin multisig wallets, treasury accounts, issuer accounts, or bridge contracts are quantum-protected.
Coverage basis: 0 critical wallets quantum-protected
Implementation score: 0 · Evidence confidence: Medium
Issue classification: quantum-critical vulnerability · Score treatment: score-reducing
Assurance: The Aave analysis mapped all admin multisig addresses and thresholds on Ethereum. XRPL issuer account is publicly known.
The XRPL issuer account supports native key rotation, which is a structural advantage, but no rotation to PQ keys has occurred (PQ keys not supported on XRPL mainnet).
Migration Status & Value-at-Risk
Legacy vulnerable pools/accounts/UTXOs/contracts are identified, measurable, deprecated, migrated, frozen, or proven not to exist by design
Claim: No quantum-vulnerable account inventory has been published for RLUSD. On Ethereum, all transacted EOAs holding RLUSD have exposed public keys. On XRPL, all accounts that have signed transactions have visible public keys. No deprecation, freeze, or migration has been initiated for quantum-vulnerable RLUSD holdings.
Coverage basis: No vulnerable account inventory; no deprecation or migration initiated
Implementation score: 0 · Evidence confidence: Medium
Issue classification: quantum-critical uncertainty · Score treatment: score-reducing
Assurance: The freeze/clawback capability means Ripple CAN freeze vulnerable accounts if identified, but no pre-identified inventory, policy, or procedure exists publicly for quantum scenarios.
The XRPL PQ roadmap's 'Quantum-Day' contingency plan discusses a hard shift rejecting classical signatures and using ZK proofs for migration, which would de facto deprecate all vulnerable accounts. But this is a future plan, not current implementation.
Migration Mechanism, Governance & Ecosystem Coordination
Public migration or protection roadmap with sequencing, activation criteria, and dependencies
Claim: Ripple has published a 4-phase PQ roadmap for the XRP Ledger targeting full transition by 2028. Phase 2 (testing/experimentation) is underway in H1 2026 with Project Eleven collaboration. However, no RLUSD-specific migration roadmap exists. The XRPL roadmap does not address Ethereum deployment migration or Wormhole bridge transition.
Coverage basis: XRPL host-chain roadmap only; no token-specific roadmap
Implementation score: 0.25 · Evidence confidence: High
Issue classification: quantum-critical uncertainty · Score treatment: score-reducing
Assurance: The XRPL roadmap is a detailed, primary-source document from Ripple with named team members, phases, and partnerships. Credibility is high. However, it covers only one of RLUSD's two primary host chains.
The 2028 target is for XRPL only. No equivalent roadmap exists for the Ethereum deployment (~82% of RLUSD supply) or the Wormhole NTT bridge dependency.
Migration Mechanism, Governance & Ecosystem Coordination
Migration accessibility and defaults: PQ/hybrid account creation, wallet tooling, transaction paths, custody paths, user-facing warnings, education, and migration prompts
Claim: No PQ/hybrid account creation, wallet tooling, transaction paths, or custody paths exist for RLUSD on any chain. No user-facing quantum warnings or migration prompts are provided.
Coverage basis: No migration accessibility exists
Implementation score: 0 · Evidence confidence: High
Issue classification: quantum-critical vulnerability · Score treatment: score-reducing
Assurance: This is expected given the absence of any PQ production path.
For the XRPL portion, Phase 3 (H2 2026) plans Devnet deployment of candidate PQ signatures alongside classical ones, which would be the first step toward migration accessibility for RLUSD on XRPL.
Migration Mechanism, Governance & Ecosystem Coordination
Migration enforcement and coordination: enforcement mechanisms, exchange/custody/bridge/wallet coordination
Claim: RLUSD has freeze and clawback capabilities that could serve as migration enforcement mechanisms in a quantum emergency. However, no quantum-specific enforcement policy, coordination framework with exchanges/custodians, or bridge transition plan exists.
Coverage basis: Freeze/clawback mechanism exists but not configured for quantum enforcement
Implementation score: 0.25 · Evidence confidence: High
Issue classification: assurance-only caveat · Score treatment: note-only
Assurance: The freeze/clawback mechanism is well-documented, NYDFS-compliant, and verified through Aave's technical analysis. It provides a credible enforcement path but is not currently configured or tested for quantum scenarios.
This is a significant PQ-recoverability feature. In a Q-Day scenario, Ripple could: (1) enact a global freeze, (2) identify quantum-compromised accounts, (3) claw back tokens, and (4) reissue to quantum-safe accounts. However, this relies on Ripple detecting the attack and acting before the attacker exits, and the admin keys themselves must not be compromised.
Migration Mechanism, Governance & Ecosystem Coordination
Emergency disclosure, incident-response, or governance process for quantum-related vulnerabilities
Claim: No public quantum-specific incident-response process exists for RLUSD. The XRPL roadmap mentions a 'Quantum-Day' contingency plan but provides no operational details for RLUSD specifically.
Coverage basis: No quantum-specific incident response exists
Implementation score: 0 · Evidence confidence: Medium
Issue classification: assurance-only caveat · Score treatment: note-only
Assurance: The absence of a formal quantum-specific IR playbook is an assurance gap. However, since the freeze/clawback mechanism provides a practical emergency response path, this does not create a new quantum-critical vulnerability beyond those already identified.
The 'Quantum-Day' contingency plan concept (XRPL rejecting classical signatures and using ZK proofs for migration) is described at a high level but lacks operational details, trigger criteria, governance process, and coordination framework.
Algorithm & Implementation Assurance
Uses NIST-standardized, standards-track, or broadly reviewed PQC/hybrid-PQC algorithms appropriate to the use case
Claim: RLUSD uses zero PQC algorithms in production. The XRPL roadmap references testing of NIST-recommended schemes (ML-DSA) in Phase 2, but this is experimental/testnet work, not production.
Coverage basis: No PQC algorithms in production
Implementation score: 0.25 · Evidence confidence: High
Issue classification: quantum-critical vulnerability · Score treatment: score-reducing
Assurance: The XRPL roadmap's reference to NIST-standardized ML-DSA testing is credible (Project Eleven partnership, Denis Angell's AlphaNet prototyping). But this is roadmap/experimental, not production.
Even when XRPL adopts PQC, RLUSD on Ethereum and L2s via Wormhole will remain on classical cryptography unless those systems independently migrate.
Algorithm & Implementation Assurance
Independent cryptographic and implementation audit exists for the quantum-critical scope
Claim: OpenZeppelin audited the RLUSD Ethereum smart contract and custom MultiSign contract. This audit covered standard smart-contract security but did not evaluate quantum-critical properties.
Coverage basis: General smart-contract audit only; scope-mismatched for quantum
Implementation score: 0 · Evidence confidence: Medium
Issue classification: assurance-only caveat · Score treatment: note-only
Assurance: The OpenZeppelin audit is from a reputable auditor and covers the current implementation. It is scope-mismatched for quantum (does not evaluate PQC algorithms, hybrid constructions, or quantum attack resistance) but provides general assurance of implementation quality.
Two confidential audits were referenced in the Aave analysis; only the OpenZeppelin report was shared. Neither covered quantum properties.
Algorithm & Implementation Assurance
Open-source, reproducible implementation
Claim: RLUSD smart contracts are open-source (Apache 2.0 license) on GitHub. The Ethereum proxy and implementation contracts are verified on Etherscan. The XRPL token uses the native XRPL issued-currency protocol which is fully open-source.
Coverage basis: Fully open-source implementation
Implementation score: 1 · Evidence confidence: High
Issue classification: none · Score treatment: not applicable
Assurance: The Ethereum MultiSign contracts are NOT verified on Etherscan (noted by Aave analysis), limiting reproducibility of the admin key control layer. The main StablecoinProxy and implementation are verified.
The GitHub repo has only 22 stars and 4 contributors, indicating limited community review beyond the OpenZeppelin audit.
Algorithm & Implementation Assurance
Parameter agility and future upgrade path are documented
Claim: The UUPS proxy pattern enables contract upgrades without state migration, providing a technical path to deploy quantum-safe implementations in the future. The XRPL roadmap discusses cryptographic agility as a guiding principle.
Coverage basis: UUPS upgradeability provides technical path; no quantum-specific agility documentation
Implementation score: 0.25 · Evidence confidence: Medium
Issue classification: assurance-only caveat · Score treatment: note-only
Assurance: The UUPS proxy pattern is a well-understood upgrade mechanism. However, the absence of a timelock on upgrades (noted by Aave analysis) means there is no mandatory delay before a contract upgrade takes effect.
The XRPL roadmap's commitment to 'cryptographic agility, supporting multiple NIST-standardized algorithms rather than a single scheme' is a strong design principle but applies to the base ledger, not the token level.
Algorithm & Implementation Assurance
Stateful-signature safety, side-channel, fault-injection, state-management, hardware-wallet, HSM, or custody implementation risks
Claim: RLUSD does not use stateful signatures (XMSS/LMS) or custom cryptographic implementations. The token relies on standard host-chain signature schemes.
Coverage basis: No stateful signatures or custom crypto implementations exist
Implementation score: 0 · Evidence confidence: High
Issue classification: none · Score treatment: not applicable
This subfactor would become applicable if RLUSD or its host chains adopt XMSS/LMS-based PQ signatures.
Algorithm & Implementation Assurance
Performance and resource-impact analysis exists where PQ signature/verification costs could affect safe deployment
Claim: No PQ performance analysis exists for RLUSD. The XRPL roadmap discusses benchmarking NIST PQC signature schemes against XRPL's transaction model, but this is experimental and covers the base ledger, not the token.
Coverage basis: Host-chain experimental benchmarking only; no token-level analysis
Implementation score: 0.25 · Evidence confidence: Medium
Issue classification: assurance-only caveat · Score treatment: note-only
Assurance: Ripple's PQ blog post explicitly acknowledges PQ signature size and verification cost as challenges requiring architectural assessment. The Project Eleven collaboration is performing Devnet benchmarking.
For RLUSD specifically, PQ signature sizes (ML-DSA signatures are ~2.4KB vs ~64 bytes for ECDSA) could meaningfully impact gas costs on Ethereum for token transfers if implemented at the account level. No analysis of this impact exists.
Bridges and Wrapped Assets
Bridge verification and signer sets are PQC or hybrid-PQC
Claim: Wormhole NTT uses Guardian Network with classical ECDSA signatures (13-of-19 threshold) for cross-chain RLUSD transfers. Optional Boundless ZK verifier adds Ethereum consensus proofs but does not replace Guardian signatures.
Coverage basis: Classical bridge verification; optional ZK verifier additive only
Implementation score: 0 · Evidence confidence: High
Issue classification: quantum-critical vulnerability · Score treatment: score-reducing
Quantum blocker: Wormhole Guardian signatures are classical ECDSA; bridge compromise via quantum key recovery could enable fraudulent cross-chain RLUSD transfers.
Assurance: Guardian signer whitepaper confirms ethcrypto.Sign() (ECDSA). Boundless ZK verifier is optional and additive, not a replacement.
RLUSD expanded to L2s and XRPL EVM Sidechain via Wormhole NTT. Bridge is quantum-vulnerable.
Report metadata