Cerberus

Cerberus is an Testnet demo for Singapore: replace smart contracts, escrow, and off-ledger KYC “verified” flags with on-ledger Credentials + RequireAuth gating and DEX OfferCreate settlement, access.

Comment

Inspiration

Singapore is a global hub for wealth management and regulated finance, but real asset access (REIT-like exposure, private funds, restricted offerings) is still slowed down by fragmented workflows:

Eligibility lives off-ledger (KYC/AML, suitability, jurisdiction checks trapped in a single institution’s database). Restrictions are hard to enforce end-to-end (a “verified” badge doesn’t prevent unauthorized holding/transfer without heavy middleware or smart contracts). Settlement is messy (multiple systems, reconciliations, and operational delays). Cerberus started as a simple question: can XRPL express compliance gating and trustless settlement using only native primitives,no smart contracts, no escrow flows, no private “verified” boolean?

What it does

Cerberus is an XRPL Testnet demo that composes three ledger-native building blocks into a realistic regulated flow:

Eligibility: a “Verified” state is represented as an on-ledger Credential. Enforcement: the issuer enables RequireAuth and authorizes trustlines so only eligible wallets can hold the asset unit token. Settlement: swaps execute via the XRPL DEX using OfferCreate, giving an atomic, on-ledger settlement primitive (DvP-style behavior). For live demo reliability, the UI labels the quote asset as “RLUSD (Simulated with XRP)” so we demonstrate the exact same settlement primitive (OfferCreate) without depending on sourcing Testnet RLUSD.

How we built it

Frontend: Next.js (App Router) + TypeScript + Tailwind UI XRPL integration: xrpl.js over WebSocket for submitting transactions and verifying ledger state Issuer operations: server-side API routes (/api/admin/*) sign issuer-only transactions using a server-only ISSUER_SEED stored in .env.local Ledger primitives used: Credentials: CredentialCreate, CredentialAccept Issuer enforcement: AccountSet to enable RequireAuth, plus issuer-side trustline authorization (TrustSet authorization) DEX settlement: OfferCreate (maker liquidity + taker crossing)

Challenges we ran into

Credentials semantics & UX: making “Verified” reflect real ledger state required correct credential discovery/acceptance handling. Trustline enforcement gotchas: issuer authorization can’t happen until the user has created the trustline (TrustSet),we had to make this explicit in the flow. Live network reliability: we fixed “stuck checking ledger” issues by enforcing websocket connectivity before reads/writes. Currency encoding edge cases: non-standard currency codes (e.g., CERB) require proper 160-bit representation; otherwise you get confusing “unsupported currency” failures. Reserves & demo economics: trustlines and offers consume XRP reserve; underfunded wallets produce failures that look random unless you account for reserves. Operational dependency risk (RLUSD on Testnet): sourcing RLUSD during a live demo is brittle; we preserved OfferCreate settlement but simulated the quote asset with XRP. Two-user simulation in one browser: localStorage caused cross-tab interference; we moved active wallets per-tab using sessionStorage so User #1 and User #2 can run concurrently.

Accomplishments that we're proud of

Built a compliance-gated holding flow where restriction is enforced by the ledger, not just UI logic. Kept the demo smart-contract-free while still showing a realistic regulated pattern. Achieved atomic on-ledger settlement via the XRPL DEX (OfferCreate) and verified outcomes only after validated: true. Made the demo presentable and repeatable: two-user parallel simulation, issuer-only server signing, and clear operational steps. What we learned The hardest part of “RWA” is its eligibility, enforcement, and settlement correctness. Demos fail when you assume success; the right pattern is submit → wait for validation → query state. XRPL primitives can express real-world workflows, but you must respect practical constraints like trustline setup order and reserve requirements.

What's next for Cerberus

Replace “RLUSD (Simulated with XRP)” with real on-ledger stablecoin flows when sourcing is reliable, while keeping the same DEX settlement primitive. Add richer policy checks (credential issuer allowlists, expiry handling, revocation patterns) and clearer admin policy tooling. production-shaped reference: observability, rate limiting, replay-safe flows, and environment preflight checks. Singapore-relevant use cases: tokenized funds, restricted distributions, and trade finance instruments.

Built With

  • account-objects
  • ledger-queries)-xrpl-testnet-public-endpoints-(websocket-+-json-rpc)-platform-/-runtime-node.js-(via-next.js-dev-server-and-api-routes)-apis-next.js-api-routes-(/api/admin/*)-for-issuer-signed-actions-(server-side)-xrpl-rpc-methods-such-as-account-info
  • next.js
  • node.js
  • react
  • tailwind-css
  • transaction-building/submission
  • typescript
  • xrpl
Share this project:

Updates

Submission history