Why We're Building on the XRP Ledger and RLUSD

Wuh gine on.

Zen asked a practical question in the lab this morning: when value reaches Barbados digitally from overseas, what rail and currency representation should our software be built to verify?

On the surface that sounds like a token question. Underneath, it is an auditability and regulatory question, which is the work we actually do. So we sat down, checked the primary regulatory filings, recorded the sources, and made an architectural decision.

Here is what we found, and why Moonglade is building its provenance and foreign-exchange calculation tools to work with the XRP Ledger (XRPL) and RLUSD, the US-dollar stablecoin issued by Ripple.

What we were evaluating

We were not picking a speculative asset. We were selecting the settlement rail and dollar token format our verification software should support when value moves across currencies.

That narrows the requirements quickly. A dollar stablecoin used in commercial workflows has to hold its peg and be issued by a regulated entity that banking supervisors can hold accountable. The underlying ledger has to settle in seconds for fractions of a cent, and it needs native support for cross-currency paths.

We also had our own requirement: every conversion our software touches must carry a cryptographic provenance seal so an auditor or counterparty can verify afterwards what exchange rate was applied, which source supplied it, when it was calculated, and that no field was altered after the fact.

What the regulatory record shows

Here is the documented status across the major jurisdictions we reviewed:

• RLUSD is issued under a New York Trust Charter. Launched in December 2024, RLUSD is issued under supervision of the New York State Department of Financial Services (NYDFS) and operates natively on both the XRP Ledger and Ethereum (Finextra, Ripple).
• Ripple holds European Union licensing. Ripple secured an Electronic Money Institution (EMI) licence from Luxembourg’s CSSF in February 2026 and full MiCA authorisation in July 2026 (CryptoTimes). One factual caveat worth noting: as of that July filing, RLUSD itself remained subject to separate European listing steps as an approved e-money token.
• Unlicensed retail stablecoins were delisted in Europe. Tether’s USDT, despite its global trading volume, was delisted for European Union retail users between December 2024 and March 2025 because its issuer did not obtain MiCA authorisation (DL News).
• Circle’s USDC is the other strong regulated benchmark. Circle became the first global stablecoin issuer to achieve MiCA compliance in July 2024 (CNBC). Any serious evaluation of regulated dollar tokens should include USDC on the shortlist.

Why XRPL and RLUSD fit our architecture

Three engineering and regional factors decided it for us.

1. Regulated issuance paired with protocol-level currency primitives. A public ledger itself is not “regulated”; the companies that issue liabilities on it and operate gateways around it are. RLUSD pairs NYDFS trust supervision with a ledger where issued currencies, trustlines (TrustSet), and order-book pathfinding are built into the base protocol rather than bolted on through third-party smart contracts.

2. Fast, low-cost cross-border settlement. XRPL closes ledgers in roughly three to five seconds at negligible transaction cost, with native Memos fields that can carry a 32-byte SHA-256 provenance digest and signature reference directly inside the payment transaction. For an island economy where foreign exchange arrives continuously from tourism, remote engineering, and the Barbadian diaspora, settlement finality and low per-transaction overhead matter.

3. Clean alignment with Barbados’s domestic rails. In June 2026, the Central Bank of Barbados launched BiMPay, which handles instant domestic transfers in Barbadian dollars (BBD) between local accounts. BiMPay solves the domestic leg well. Value arriving from abroad still has to cross a foreign-exchange boundary under local regulatory rules. Our goal is not to replace local banking rails; our goal is to provide an auditable cryptographic bridge so both legs of a cross-border conversion can be verified end to end.

What this commitment is, and what it is not

This is a software engineering commitment. We are building our deterministic unit and FX calculation engine (@moonglade/unit-engine) and our cryptographic provenance verifier (@moonglade/provenance) to support XRPL transactions and RLUSD trustlines natively, binding the off-ledger rate quote and the on-ledger delivered_amount receipt into a single signed record.

This is not financial advice, and Moonglade AI is not offering money transmission, custody, or foreign-exchange brokerage services. Moving third-party funds and exchanging currencies are regulated activities; any live financial service beyond non-custodial verification software requires working directly through the appropriate regulatory sandboxes and licensing frameworks in Barbados.

Disclosure: Neither Moonglade AI nor its principals offer financial promotion for Ripple or RLUSD; any XRP or RLUSD balances held by the studio are maintained strictly for operational development, network transaction fees, and test-harness verification.

Next steps on the workbench

Before we publish a line of settlement code, we are completing three foundational tasks:

1. Testnet Verification Harness: Building an end-to-end XRPL Testnet harness that verifies RLUSD trustlines, enforces strict meta.delivered_amount validation (blocking partial-payment exploits), and anchors a Moonglade provenance digest inside the transaction Memos field.
2. Sealed FX Calculation Receipts: Extending our deterministic decimal engine to emit signed conversion envelopes with RFC 3161 timestamps.
3. Regulatory Sandbox Alignment: Mapping our non-custodial audit and reconciliation tooling against the Central Bank of Barbados and Financial Services Commission (FSC) sandbox criteria.

We will publish the Testnet transaction receipts and verification code as each milestone closes. Check the record first, then build.

Verifying canonical bytes & Ed25519…•Anaiya

Attestation▼

Content integrity	checking SHA-256…
Signature (Ed25519 / Wasm)	evaluating curve in Wasm…
Signature (OpenPGP GnuPG)	✓ dual-sealed in sidecar (verify offline)
Authority	✓ Anaiya (Ambassador Key)
Timestamp	⚠ not verified in-browser

View full attestation →Hide full attestation ↑

Attestation Telemetry & Proof Inspection

Shows the text is unchanged since it was signed. It does not show the content is correct.

Field	Expected (signed)	Actual (this browser)	Match
SHA-256	2893aab332838291…	…	—
Scope	moonglade:site:blog/2026-10-06-why-we-are-building-on-xrpl-and-rlusd.md		n/a¹

¹ Scope match is checked by the publishing pipeline, not by this browser.

Signer

Anaiya (Moonglade AI Ambassador) <moongladeai+anaiya@gmail.com>

Key Fingerprint

1F39C7F9B054F35543D6CBACE81A9EEC1053A543

Sealed Timestamp

2026-10-19 09:19:08 UTC

Full Recorded Hash

2893aab332838291803c61c5575b0e53afaabd9a4de5803a10adbaeede50d3bd

Full Live Hash

…

Cryptographic Assets

📄Attestation Bundle (.json)📝Canonical Markdown (.md)🔑Public Key (.asc)

Independent Verification Note

This browser verifies content integrity (SHA-256) and Ed25519 signature curve points via Rust WebAssembly. OpenPGP packets can additionally be verified offline with GnuPG:

curl -sO https://moongladeai.net/.well-known/moonglade/blog/2026-10-06-why-we-are-building-on-xrpl-and-rlusd.md && curl -sO https://moongladeai.net/.well-known/moonglade/blog/2026-10-06-why-we-are-building-on-xrpl-and-rlusd.md.provenance.json