XRBitcoinCash (XRBC) Technical, Security & Ecosystem White Paper

1 · Executive summary

XRBC as a user-protection and evidence ecosystem

XRBitcoinCash is an issued currency on XRP Ledger Mainnet and a collection of interfaces built around a common principle: evidence before action. The ecosystem does not change XRPL consensus. It organizes standard XRPL primitives—trust lines, offers, AMMs, pathfinding, payments, memos, NFTs, account objects and validated transaction history—into interfaces intended to make risk, liquidity, authority, evidence, uncertainty and transaction intent easier to inspect before a user acts.

XRBC also functions as a reusable access credential for selected advanced interfaces. Where a balance gate applies, the page reads the connected wallet's XRBC balance. The XRBC stays in that wallet; it is not a website fee, deposit, burn, lock, escrow, subscription payment, transfer to the operator, or promise of financial return.

The project separates four distinct classes of behavior: public read-only information, deliberately connected wallet reads, local browser evidence/analysis, and ledger-changing actions that require explicit wallet review. A page should not blur one class into another.

2 · Verifiable network identity

XRBC identifiers and independent verification

A display name, ticker, icon, directory listing, social account or wallet label is not sufficient identity proof. Users should verify the complete issuer, currency value and network before adding a trust line or approving a transaction.

Issuer address

Currency HEX

3 · Project-wide safety architecture

Design principles carried across the ecosystem

4 · Unified user experience

One ecosystem shell, consistent safety language and mobile behavior

The current project standard uses the same two-tier XRBitcoinCash header across upgraded pages. It keeps the XRBitcoinCash identity, related-project links, Xaman entry point, theme control, Terms, Policy & Security, Support and AI Provenance visible above a consistent 20-destination navigation row.

• Canonical navigation: Home, Trade, Wallet, Orders, Live Metrics, Sentinel, Liquidity Scanner, Forensics, Ecosystem, Order Manager, Audit, Risk Lens, Value Path, Watchtower, Bridge Integrity, Tokenization, Advanced, Readiness, Settlement and White Paper.
• Responsive behavior: desktop uses the full two-tier shell; smaller screens collapse to a deliberate menu with keyboard Escape handling, full-width touch targets and no horizontal drift.
• Accessibility: skip links, semantic landmarks, ARIA current-page markers, status regions, keyboard focus and reduced-motion handling are used where applicable.
• Plain-language modes: complex tools increasingly distinguish fast/guided paths from professional/advanced paths rather than forcing every user through the full technical model.
• Visual consistency: dark/light theme state, risk colors and safety labels are shared so a user does not need to relearn the ecosystem on every page.

5 · Complete ecosystem inventory

Every current user-facing surface and its primary boundary

The table below includes the canonical navigation destinations and the support/legal/provenance surfaces that govern or support them. In-page Home modules such as Trade, Wallet, Orders, Live Metrics and Sentinel are listed separately because they have different user risks even though they share the main portal.

6 · Main portal and core market controls

Home, Trade, Wallet, Orders, Live Metrics and Sentinel

The main portal brings XRBC identity, wallet connection, trust-line management, trading, open-order management and live XRPL observations into one interface. Its core safety model is to make the intended transaction understandable before the wallet request appears.

• Quick buys, sales, trust lines, offers and cancellations are transaction-preparation functions, not automatic execution.
• Open orders remain market instructions and may never fill. Offer cancellation only becomes final after validation.
• Displayed AMM or order-book values are snapshots, not guaranteed prices or exit values.
• Wallet authorization selects a public account; it does not prove a person's real-world identity and does not transfer custody to the site.

7 · Liquidity Sentinel

Validated-ledger AMM scanning and exit-capacity visibility

Liquidity Sentinel scans wallet trust lines and public issued assets, examines direct XRP/token AMMs, exposes reserves and fees, estimates execution impact, tracks scan-to-scan changes and can export local JSON evidence. Optional XRBC trust-line or trade requests remain Xaman-authorized.

• Direct XRP-to-issued-token AMM discovery and reserve/fee display.
• Estimated execution impact for fixed XRP sizes and/or selected position sizes.
• Health/caution/risk/frozen/no-direct-pool/data-unavailable classifications.
• Local watchlist and change tracking.
• One-payload handoff and validated transaction-field checks where a transaction is prepared.

8 · Sentinel Forensics

Structured evidence rather than accusation

Sentinel Forensics turns raw XRPL state into a structured evidence trail. Its current forensic model separates observed risk, evidence confidence and market continuity instead of producing one unexplained verdict.

• AMM reserves, fee, price impact, vote and auction-slot evidence.
• Funded order-book depth, maker diversity, concentration, imbalance, spread and ladder gaps.
• Holder sampling with concentration, HHI, Gini and coverage disclosure.
• Validated transaction activity, bursts, repeated amounts, interval regularity, reciprocal payments, AMM cycling, actor concentration, failed ratio and recency.
• Issuer authority/policy controls and recent issuer changes.
• Wallet exit scenarios at 25%, 50% and 100% of a selected position.
• Evidence matrix that separates observed, derived and unavailable facts; local snapshots and SHA-256-capable exports.

9 · Extended Audit

Public method, gated wallet-token workbench

The Extended XRPL Token Auditor makes its method and limitations public while reserving deeper wallet-token analysis for a reusable 50 XRBC gate. The workbench combines market, account and issuer evidence rather than relying on ticker-level reputation.

• AMM reserves and estimated price impact.
• Funded order-book depth, spread and maker analysis.
• On-ledger participation sampling.
• Issuer posture, control settings and blackhole-pattern analysis.
• Connected-wallet token discovery only after the disclosed gate is satisfied.

10 · Risk Lens

Observed risk, exit capacity and confidence

Risk Lens uses a reusable 150 XRBC gate to expose advanced analysis of liquidity, exit capacity, order-book quality, concentration, trust-line controls, issuer authority, transaction activity and data confidence.

• AMM reserves, fees and wallet-exit impact.
• Funded spread, depth, maker diversity and concentration.
• Issuer key/blackhole, freeze, clawback, transfer-fee and authorization review.
• Holder trust-line freeze, authorization, No Ripple and quality settings.
• Transparent observed-risk score plus a separate confidence score.

11 · Value Path

Route and execution-quality comparison before action

Value Path uses a reusable 400 XRBC gate to compare direct AMM behavior, funded order books, XRP-bridge routes and XRPL pathfinding. The objective is to expose tradeoffs between apparently similar routes before a user prepares a transaction.

• Direct AMM and order-book simulation.
• XRP-bridge and pathfinding comparison across configured data sources.
• Slippage, spread, depth, partial-fill, maker concentration and confidence.
• Wallet-position scenarios at 10%, 25%, 50%, 75% and 100%.
• Local JSON evidence snapshot.

12 · Watchtower

Ongoing liquidity, issuer and trust-line monitoring

Watchtower is a 1,000 XRBC-gated monitoring station for users who need more than a point-in-time token check. It keeps local watchlists, local trend history and alert settings while repeatedly analyzing market and issuer conditions.

• AMM reserves, fees, LP-token data and simulated slippage.
• Funded order-book spread, depth, maker counts and concentration.
• Issuer freeze, clawback permission, authorization, Default Ripple, transfer rate, tick size, domain and related controls.
• Connected-holder trust-line freeze, authorization, No Ripple, limits and quality settings.
• Pinned validated-ledger snapshots, freshness/server-health checks and evidence coverage.
• Local trends, configurable alerts and SHA-256 JSON evidence export.

13 · Bridge Integrity Watchtower

A deliberately non-executing cross-chain caution system

Bridge Integrity is intentionally different from the trading tools: it is a defensive observation page and contains no bridge quote, deposit workflow, contract approval, route execution, wallet signature or transaction payload. The public safety screen is designed to interrupt a risky assumption before funds leave a wallet.

• Fail-closed “Stop Before You Send” bridge safety screen.
• Ranked caution board with a published bounded formula.
• Sourced cross-chain incident history with evidence tier and timestamps.
• Separate operational state, caution, evidence coverage and freshness.
• Advanced local route/endpoint structure review, XRPL payment invariants, bridge-vault deltas, deposit/mint reconciliation, reserve/liability review and heuristic public-source screening.
• Local persistence and canonical SHA-256 evidence-pack generation.

14 · Asset Tokenization Auditor

Free local-first evidence and architecture planning

The free Asset Tokenization Auditor can be used without connecting a wallet. It is designed to force the user to define what a token or record actually represents before moving to any ledger action.

• Searchable asset taxonomy and custom asset descriptions.
• Explicit represented-right modeling: what the holder receives and what the holder does not receive.
• Owner, issuer, custodian, registry, attestor, servicer, recovery authority and recognizing-party roles.
• Jurisdiction, registry dependency, custody, transfer restrictions, issuer controls and metadata continuity.
• Local evidence-file selection and SHA-256 hashing; selected file bytes are not intentionally uploaded by the local audit workflow.
• Architecture recommendation, risk findings, evidence completeness and Evidence Pack v2.2 generation.
• Browser-local saved project with user-controlled download/export.

15 · Advanced Asset Tokenization

Shared project, Local Asset Vault and optional evidence NFT

The Advanced Asset Tokenization Auditor is the gated continuation of the same browser-local project, not a separate record. The 2,500 XRBC gate unlocks professional editing and optional ledger actions while the XRBC remains in the connected wallet.

• Restores the same project schema and Evidence Pack created on the free page.
• Uses an on-device Local Asset Vault keyed by the Evidence Pack SHA-256.
• Requires the exact source file or backup to reproduce the saved SHA-256 before minting when file bytes are not already available locally.
• Generates image/file hashes, metadata-manifest integrity values and a compact XRPL URI binding the evidence record.
• Prepares an exact NFTokenMint request for explicit Xaman review and records a validated mint receipt when successful.
• Separates six-digit verification used by trade/gate transactions from the memo-free compatibility mint path where applicable; the user must review the actual mint fields.
• Detects stale shared-project state so one tab does not silently overwrite a newer local record.

16 · XRBC Readiness Evaluator

Live XRPL observatory plus reviewed institutional evidence

The Readiness Evaluator is a public, read-only observatory. It deliberately separates live XRPL/market telemetry from reviewed evidence about institutional, tokenization and financial-system integration.

• Validated-ledger WebSocket pulse with a separate 15-second proxy polling cross-check.
• Live server_info, validated ledger and feature amendment/capability inspection.
• XRBC/XRP AMM and funded order-book rail plus an independently labeled XRP/RLUSD reference rail.
• Rolling session trends for ledger age and market spread.
• Versioned evidence JSON, monitored-source registry, source fingerprints and candidate-change queue.
• Browser evidence refresh and scheduled source-monitor architecture; changed source content cannot automatically promote itself into verified evidence.
• Explicit scope labels for public XRPL, private XRPL-derived systems, XRPL-adjacent sidechains, Ripple corporate products and context-only systems.

17 · XRBC Settlement Desk

Request, sign, verify and document an XRBC payment

The Settlement Desk creates a reproducible payment request and then checks the actual validated XRPL transaction against that request.

• SHA-256 invoice identifier generated from the invoice record.
• Destination XRBC trust-line inspection.
• Optional XRPL Destination Tag validation and binding.
• Six-digit Xaman verification memo for the payment request.
• Explicit review of payer, destination, tag, XRBC amount and Invoice ID.
• Post-signing transaction lookup and validated tesSUCCESS verification.
• Comparison of transaction type, destination, tag, Invoice ID, issuer, currency, amount, payer and memo binding where available.
• Local browser invoice history plus downloadable/printable settlement evidence receipt.

18 · Ecosystem directory and Order Manager

Discovery, open-offer control and wallet-neutral access

The Ecosystem page is a public tools hub for XRBC market metrics, wallet liquidity/trust-line analysis, route/order previews and links into the specialized tools. It has no XRBC holding gate; each advanced destination applies its own disclosed threshold.

The Order Manager likewise has no XRBC holding gate. It separates public workflow information, deliberately connected account reads and ledger-changing actions. It can review validated open offers, prepare OfferCancel, add the exact XRBC trust line and prepare XRBC purchases for independent wallet approval.

19 · Support, policy and provenance

Support evidence without asking for wallet secrets

The support architecture is intended to give users a consistent path for reporting problems across every ecosystem page. Depending on the deployed support path, it can use direct HTTPS email delivery, optional Xaman wallet attachment, locally encrypted XRPL memo evidence and/or a support-evidence NFT/receipt.

• Users may identify the relevant page/xApp, issue type and public transaction/wallet evidence.
• Public XRPL address or transaction-hash attachment is opt-in/out and never requires a seed phrase or private key.
• Optional screenshots should be redacted before submission; users should not send recovery phrases, private keys, passwords or unrelated personal data.
• Encryption, email delivery, NFT display and provider availability can fail. A support receipt does not prove the truth of the complaint, successful delivery, confidentiality, ownership, legal notice or resolution.
• The Policy page documents public-ledger permanence, browser storage, support-provider exposure, encrypted-support limitations, forensic/risk-score boundaries, AI-assisted development, tokenization/NFT limitations, gates, third parties and incident response.
• AI provenance, /.well-known/ai.json, /ai/provenance.json, /llms.txt, metadata and security.txt provide machine/human-readable orientation and contact paths; they do not make AI-assisted development an independent audit.

20 · Reusable XRBC access gates

Access logic without website custody

A reusable XRBC gate reads the connected wallet's XRBC balance and enables a page-defined interface state when the threshold is met. The balance stays in the user's wallet. The site does not receive, burn, consume, transfer, escrow or lock the XRBC. Access may relock when the balance falls below the threshold or when the page requires a fresh verification.

21 · Wallet authorization and transaction verification

Xaman is the user-authorization boundary for XRBC actions

For XRBC purchases, sales, trust lines and other supported Xaman workflows, the webpage may read public data and prepare a transaction request, but the user reviews and authorizes the request in Xaman. The page never needs the user's seed phrase or private key.

• Force or clearly identify the intended XRPL network.
• Use expiring payloads and one active transaction intent at a time where practical.
• Display a six-digit challenge/purpose reference when the transaction type supports that verification pattern.
• Show exact spend/receive amounts or bounds, destination, issuer/currency, paths, flags, Invoice ID and Destination Tag where relevant.
• Use maximum-spend or minimum-delivery protection where appropriate to the transaction type.
• Handle rejection, cancellation, expiry and failure visibly.
• Retrieve the transaction hash and independently inspect the validated ledger result.
• Compare the validated transaction type, account, destination, asset, amount, flags and request-specific fields against what the webpage expected.

22 · Evidence, local data and privacy

What a hash, snapshot, receipt or export can—and cannot—prove

• XRPL account, transaction, trust-line, AMM, order-book, NFT and issuer information is public ledger data.
• A SHA-256 digest can show whether the bytes being checked match the bytes that were originally hashed. It does not prove truth, completeness, authorship, authority, legality, consent, value or current real-world condition.
• Browser-local history, watchlists, project drafts, alerts, Evidence Packs and Local Asset Vault data can be deleted by the user, browser, storage policy, reset or device failure.
• Exported JSON is an evidence aid, not an official registry, accounting ledger, legal record or regulator filing unless a competent external system separately recognizes it.
• Public-ledger records may be effectively permanent. Users should not put secrets or unnecessary sensitive personal data into public transaction fields or immutable metadata.
• Third-party metadata, logos, names, project categories, holder counts, explorer labels and market pages can be stale or wrong. Issuer/currency and direct ledger evidence take precedence for XRPL identity.

23 · Security posture and threat model

Defense in depth without claiming perfect security

No CSP, wallet, encryption scheme, browser check, AI review, static validator, source-code audit or transaction comparison can guarantee that software is vulnerability-free or that a user's device, wallet, network, browser extension, DNS, hosting provider or third-party service is uncompromised.

24 · Consolidated limitations and liability disclosures

Page-specific boundaries that protect users from overreliance

This matrix consolidates the recurring limitations built into the ecosystem. It summarizes user-facing warnings; it does not replace the Terms of Use. Where the Terms and this white paper differ, the current Terms control legal rights and remedies to the extent enforceable by law.

25 · Material risks

Risks no interface can eliminate

26 · Project governance, source and reuse

Public visibility is not the same as unlimited permission

The project uses public web pages, a public XRPL, machine-readable metadata and source repositories to make behavior inspectable. Public availability of code or documentation does not automatically place project-owned material into the public domain or under an open-source license. The current repository LICENSE, Terms and applicable law control reuse, attribution, platform rights, permitted watchdog use and other rights.

Third-party libraries, public-domain material, XRPL data, wallet software, service marks and external content remain subject to their own owners, licenses and terms.

27 · Official references

Project surfaces and verification resources

On-ledger state is the final technical reference for XRP Ledger facts. Website descriptions, explorers, wallet labels, market pages and metadata can become stale or inaccurate.

28 · Document control

Revision history