XRBitcoinCash (XRBC) Technical White Paper

1 · Executive summary

Abstract

XRBitcoinCash (XRBC) is an issued currency on the XRP Ledger. It uses standard XRPL trust lines, decentralized exchange order books, automated market makers, pathfinding, payment transactions, memos, and other public-ledger features without changing XRPL consensus.

XRBC functions as a transferable ecosystem building block and reusable access credential. Holding a stated balance may unlock advanced analytical tools, but the XRBC remains in the user's wallet. Access gates are not payments to the website, burns, escrow deposits, custody arrangements, transfers of ownership, or promises of financial return.

The ecosystem's central design principle is evidence before action: read public ledger state, explain limitations, prepare clearly bounded transaction templates, require independent wallet review, and preserve the user's ability to reject every transaction.

2 · Verifiable network identity

Token parameters and independent verification

These identifiers distinguish XRBC from issued currencies that may use similar names. On-ledger data is the final reference. Verify the complete issuer and currency value before establishing a trust line or approving a transaction.

Issuer address

Currency HEX

3 · Protocol architecture

XRPL integration and transaction model

• Trust lines. A wallet must establish an XRBC trust line before receiving XRBC.
• Order books. Standard XRPL offers provide public decentralized exchange liquidity and funded-order visibility.
• Automated market makers. XRPL AMMs provide pool-based liquidity where a compatible pair exists.
• Pathfinding. Public XRPL pathfinding may identify direct or multi-hop routes subject to current ledger state.
• Transaction limits. Templates may use exact destination amounts, maximum spend limits, minimum-delivery protection, and partial-payment flags when appropriate.
• Memos. Interfaces may add application, domain, evidence, and six-digit verification references.
• XRPL NFTs. Tokenization workflows may prepare standard NFT-related transactions separately from XRBC purchases and sales.

4 · Wallet authorization boundary

Xaman-only XRBC purchase and sale policy

XRBitcoinCash webpages may read XRPL liquidity, calculate a route, and prepare an XRBC transaction template. The webpage cannot sign an XRBC purchase or sale and does not submit one using a user secret.

• Every webpage-initiated XRBC purchase and sale must create a Xaman payload.
• Xaman provides the QR code or mobile deep link.
• Xaman is the exclusive signing and submission path for those XRBC transactions.
• The user must verify XRPL Mainnet, issuer, currency, destination, amounts, maximum spend, minimum received, paths, flags, and memo before approving.
• A six-digit challenge may be displayed and included in the transaction memo to match the webpage request with the wallet request.
• Closing a webpage panel does not cancel an already-created Xaman payload; it can remain valid until signed, rejected, or expired.

5 · Ecosystem specification

Evidence-oriented tools and reusable XRBC gates

The ecosystem separates public information from increasingly advanced analysis. Gated tools use reusable connected-wallet balance thresholds. XRBC remains in the wallet and may be used elsewhere, subject to the wallet continuing to meet the threshold.

6 · Continuous local monitoring

Watchtower mission and scoring limits

Watchtower is a read-only surveillance and evidence station for selected XRPL-issued tokens. Its local Watch Score compares observed data with selected thresholds. It is not a credit rating, investment rating, listing standard, or prediction.

• AMM reserves, trading fees, LP-token values, and simulated slippage.
• Funded order-book spread, depth, offer counts, unique makers, and maker concentration.
• Issuer authorization, freeze, clawback permission, Default Ripple, master-key state, transfer fee, tick size, domain, and related settings.
• Connected-holder trust-line freeze, deep freeze, authorization, No Ripple, limits, and quality settings.
• Optional issuer obligations and public metadata, which may be incomplete, unavailable, stale, or third-party supplied.
• Local trend history and alerts that can be lost if browser storage is cleared.

7 · Structured asset analysis

Advanced tokenization workflow

Advanced Tokenization is an analytical and documentation workflow. It does not by itself create legal ownership, perfect a lien, transfer a title, satisfy registration requirements, make an asset compliant, or cause an outside registry, court, custodian, government, or counterparty to recognize a tokenized claim.

• The underlying asset or program and external identifiers.
• The legal, contractual, economic, access, redemption, or informational right proposed to be represented.
• The owner, issuer, custodian, registry, attestor, servicer, recovery authority, and other parties.
• Document hashes, registry references, attestations, custody evidence, insurance evidence, appraisals, and professional review.
• Architecture alternatives, transferability, fractionalization, authorization, freeze, clawback, redemption, continuity, and metadata decisions.
• Risk findings, unresolved dependencies, exportable evidence, and standard XRPL NFT planning where appropriate.

8 · Liquidity and market structure

DEX, AMM, and routing model

1. Trust line first. A wallet must have an XRBC trust line before receiving XRBC.
2. Public liquidity. XRPL order books and compatible AMMs are public and can change without notice.
3. Project-designated interface. Sologenic is the project-designated XRBC DEX/AMM interface, but it is a third-party service and does not create guaranteed liquidity.
4. Path limits. A prepared transaction should expose maximum spend, minimum received, destination amount, path, slippage, and expiry information when applicable.
5. No execution guarantee. A quote can become stale before signing or validation. A route may fail, partially execute where permitted, or produce a different effective result within approved limits.
6. No project-controlled price. XRBitcoinCash does not guarantee or establish a floor, target, redemption price, or future market value.

These links are provided for convenience. They do not imply custody, endorsement, regulatory approval, accuracy, availability, guaranteed liquidity, an offer, or a solicitation.

9 · Security posture

Non-custodial design and implementation limits

• User-controlled keys. Interfaces do not need a seed phrase or private key to read public ledger state or prepare a Xaman request.
• Explicit wallet review. Wallet authorization remains separate from webpage calculations and interface text.
• Validated-ledger preference. Tools should prefer validated XRPL data where supported.
• Challenge and replay controls. Six-digit memos, nonces, expirations, session matching, rate limits, and replay resistance may be used as defense-in-depth measures.
• Default-deny privileged services. Public read-only data should be separated from privileged actions. Server-side authorization is required for any future privileged API.
• Local evidence. Evidence packs and trend history may remain on the user's device unless exported or transmitted.
• Third-party dependencies. Wallets, browsers, RPC providers, explorers, market interfaces, metadata directories, hosting providers, and networks may fail or provide incomplete information.
• Automation limits. Automated checks and AI-assisted review cannot guarantee correctness, completeness, legal sufficiency, or freedom from vulnerabilities.

Users should verify the official domain, use updated devices, independently confirm transaction fields, and avoid approving unfamiliar requests.

10 · Evidence and data handling

Local records, public data, and evidentiary limits

• XRPL account, transaction, AMM, order-book, trust-line, NFT, and issuer information is public ledger data.
• Wallet token enumeration should occur only after the relevant reusable XRBC gate is satisfied.
• Local browser storage may hold watchlists, settings, challenge references, and limited trend history.
• Exported JSON and SHA-256 values can help demonstrate that a particular evidence file has not changed after hashing.
• A hash proves consistency with the hashed input; it does not prove that the input was truthful, complete, authorized, legally effective, or current.
• Third-party names, logos, categories, trust levels, holder counts, and project metadata are discovery aids and not substitutes for the issuer address and direct XRPL evidence.

11 · Regulatory and classification stance

Classification, jurisdiction, and participant responsibility

• XRBC is described as a transferable XRPL-issued token used for ecosystem access, public-ledger routing, integrations, and evidence-oriented tools.
• XRBC is not marketed with a promise of profit, passive income, dividends, yield, price appreciation, managerial return, or loss protection.
• Holding XRBC alone does not grant equity, debt, dividends, governance rights, ownership of XRBitcoinCash, or a claim on project assets.
• No offering memorandum, prospectus, registration statement, broker relationship, fiduciary relationship, or advisory relationship is created or implied.
• Digital-asset classification and legal treatment can differ by transaction, facts, jurisdiction, participant, and time.
• Participants are responsible for securities, commodities, payments, money-transmission, consumer-protection, sanctions, anti-money-laundering, tax, licensing, reporting, and other obligations.
• Tool-access thresholds are functional webpage conditions, not promises that holding XRBC has economic value or that a tool will remain available.

12 · Risk disclosures

Material risks and limitations

13 · Official and third-party references

References

On-ledger data is the final technical reference for XRPL state. Website text, explorer labels, market interfaces, metadata directories, and social channels can become stale or inaccurate.

14 · Document control

Revision history