Policy, Privacy, Security & User Protection

1 · Scope and hierarchy

Purpose, coverage and controlling authority

This Policy applies to official XRBitcoinCash domains, repositories, xApps, wallet and transaction interfaces, public-ledger readers, analysis tools, support workflows, evidence exports, local browser storage, AI/provenance records, related XRBitcoin pages maintained with the project, documentation, public communications and persons acting on behalf of the project.

1. Mandatory law and valid orders control.
2. Third-party terms control the use of independent wallets, hosts, data services, markets and providers.
3. XRBitcoinCash Terms of Use govern user obligations, disclaimers, liability and disputes.
4. This Policy governs project operating, privacy, security, evidence, accessibility, communications and change-management standards.
5. White Paper and interface text are subordinate technical explanations.

2 · On-ledger identity

Verifiable XRBC identifiers

• Issuer, currency, network, amount, destination, destination tag, flags, paths, fees and memos must be visible when relevant.
• A ticker, logo, wallet label or directory listing is not sufficient token identification.
• Material differences between interface claims and validated-ledger data are security/disclosure defects and should be corrected.

3 · Core operating principles

Project-wide user-protection rules

4 · Current ecosystem controls

Every major surface and its policy boundary

5 · Reusable XRBC access gates

Current threshold map and authorization boundary

• XRBC remains in the user's wallet merely to satisfy a gate; the threshold is not a payment, burn, subscription, escrow, deposit or staking arrangement.
• Access may relock if the balance falls below the threshold.
• Browser-visible gating is an interface control, not a security boundary for protected backend services. Privileged server functions must independently reverify authorization and current ledger state.
• Below threshold, pages should minimize unrelated wallet enumeration and show only information needed to explain gate status.

6 · Security architecture

Non-custodial, secure-by-design and validated-result controls

7 · Privacy and data minimization

What data is used and how exposure is limited

The operating preference is: take stock → scale down → protect what remains → dispose when no longer needed → plan for incidents. The project should not collect sensitive data merely because it may be convenient later.

• Do not intentionally sell personal information or use it for targeted advertising.
• Do not request Social Security numbers, card data, bank credentials, medical records, biometrics, government IDs, classified material or other unnecessary sensitive information.
• Apply least privilege to operator/provider access.
• Retention should be tied to actual support, security, dispute or legal needs; complete deletion from third-party backups cannot be promised.
• Public ledger data cannot be made private by deleting browser state.

8 · Support and private communications

Email and encrypted-support boundaries

• Official support must never ask for a seed phrase, private key, recovery words, wallet passcode or remote desktop credentials.
• An informational support NFT or transaction hash can correlate public ledger facts; it does not prove identity, truth of a complaint, legal notice, entitlement to relief or receipt/read status.
• If an encrypted recovery package contains both ciphertext and its recovery key, anyone who obtains the complete package may be able to decrypt it. Do not market the system as provider-blind or zero-knowledge unless the implementation truly provides that property.
• Support is not an emergency, regulator, court, bank, law-enforcement or wallet-provider complaint channel.
• Users should submit only the minimum information necessary to describe the issue.

9 · Analytics, scoring and forensic evidence

Signals are not accusations or guaranteed predictions

• Observed evidence must remain distinct from derived indicators, confidence estimates, missing evidence and allegations.
• Risk, liquidity, continuity, integrity, readiness and bridge caution scores summarize disclosed models; they are not credit ratings, sanctions determinations, law-enforcement findings, audit opinions or guarantees.
• High risk does not prove fraud; low risk does not prove safety, solvency, legality or future performance.
• Holder counts, concentration, HHI, Gini, maker concentration, repeated amounts, bursts and AMM cycling can have multiple legitimate or illegitimate explanations.
• Pagination, capped samples, custodial accounts, common control, stale servers and incomplete metadata can distort results.
• JSON exports and SHA-256 fingerprints help preserve digital integrity under the stated scope but do not prove truth, authorship, legal chain of custody or admissibility.

10 · Trading, orders and market conduct

Quotes and routes remain estimates until validation

• AMM reserves, funded books, pathfinding, spread, slippage, reserve settings and routes can change between preview, wallet review, submission and validation.
• A displayed price, balance, implied market value or route is not guaranteed realizable value or exit capacity.
• Market swaps may use protective bounds, but those bounds do not guarantee fill, price, liquidity or profit.
• Limit orders may remain open, partially fill or interact with later market state. Offer cancellation is effective only if the validated ledger reflects the intended result.
• No fake urgency, deceptive countdown, manipulative reward loop, hidden mandatory term, misleading scarcity message or other dark-pattern behavior should be used to push a trade.
• Users remain responsible for fees, taxes, slippage, wallet security and the transaction they approve.

11 · Bridge Integrity

Read-only caution intelligence; no bridge execution

• The page may rank or compare observed exploit history, architecture, admin controls, validators/guardians, proof systems, audits, TVL/exposure and source freshness.
• Sources must be attributed and freshness/confidence exposed where practical.
• A caution score is not a guarantee that a bridge will fail or remain safe.
• The XRBitcoinCash site must not provide a bridge deposit address, bridge quote, bridge route, approval, signing request, relayer action or transaction submission.
• If a future feature can move user value across chains, it requires separate legal/security review and must not inherit the read-only policy by implication.

12 · Tokenization, Local Asset Vault and evidence NFTs

Local-first evidence does not automatically create legal rights

• The free Tokenization Auditor may define represented rights, parties, controls and evidence; hash selected files locally; calculate planning metrics; create Evidence Pack v2.2; and save browser-local project state without a wallet.
• The Advanced page may restore the same project after its disclosed XRBC gate. Raw file inputs cannot be silently transferred between pages unless stored in the Local Asset Vault or reselected.
• Source bytes should be reverified against the saved SHA-256 before a derived package or evidence-NFT workflow proceeds.
• Local Asset Vault and browser storage are user-device conveniences, not durable custody or cloud backup. Clearing site data can destroy them.
• An NFT, memo, URI, metadata record, hash or timestamp does not by itself create or prove legal title, ownership, authority, authenticity, custody, valuation, regulatory approval, intellectual-property rights, court admissibility or recognition by an external registry.
• Outside registries, custodians, issuers, courts, governments and counterparties remain independent.

13 · Readiness Evaluator

Institutional evidence requires scope and human review

• Public XRPL telemetry, XRBC settlement conditions, RLUSD reference rails, Ripple corporate products, private XRPL-derived systems, sidechains, SWIFT/BIS context, pilots, announcements and production deployments must not be conflated.
• Automated source checks may record HTTP status, redirects, timestamps, content fingerprints and monitored terms.
• A changed source or keyword match creates a review candidate, not a verified institutional adoption claim.
• Verified claims require source, organization, date, ledger/product scope, maturity, supported finding, limitation, confidence and review state.
• Readiness scores are evidence summaries, not probabilities of adoption, endorsements, price forecasts or legal/regulatory conclusions.

14 · Settlement Desk

Invoice and receipt evidence boundaries

• Invoices may include deterministic identifiers, public destination accounts, optional Destination Tags, amounts, timestamps and six-digit request bindings.
• Destination Tags are user/merchant data and must be verified; an incorrect tag can misroute the accounting attribution even if the destination account is correct.
• A wallet signature or Xaman signed status is not settlement. The page should verify validated XRPL result and compare available fields with the invoice/request.
• A validated receipt records specified ledger evidence; it is not escrow, chargeback protection, merchant-performance assurance, contract performance, accounting certification or proof that goods/services were delivered.

15 · XRBitcoin / XRB separation

Related interface, separate asset identity

• XRBitcoin (XRB) is a separate XRPL-issued asset with its own issuer, currency code, trading pairs and history. XRBC policies do not merge the two assets.
• The XRB interface may support XRB/XRP and XRB/RLUSD trading, limit orders, Watchtower-style public analysis, Trade Compass, Route Truth Lens, exposure warnings and Quote Passport exports.
• Browser-local exposure warnings are informational guardrails and do not block the user from authorizing a valid transaction.
• Quote Passports and route diagnostics preserve pre-sign evidence but do not guarantee execution or future liquidity.
• XRB transaction safety should preserve the same one-active-request, exact-field and validated-result discipline.

16 · Accessibility and human-centered design

Usability is part of user protection

• Interfaces should target WCAG 2.2 principles where reasonably achievable: keyboard operation, visible focus, sufficient contrast, meaningful labels, scalable text, reduced-motion respect and touch targets appropriate to mobile use.
• Critical warnings and transaction fields must not be communicated by color alone.
• Complex features should use progressive disclosure so advanced controls do not bury the safe/default workflow.
• Mobile layouts must prevent horizontal drift that makes legal, wallet or transaction controls inaccessible.
• Security and legal text should use plain-language explanations alongside technical detail where practical.
• Accessibility conformance is a continuing engineering goal, not a claim that every page satisfies every success criterion for every assistive technology.

17 · AI-assisted development and provenance

Automated assistance is supplemental, not independent assurance

• AI systems may assist with coding, refactoring, testing, research, documentation and review.
• AI assistance is not an independent security audit, penetration test, legal opinion, regulator examination, accounting audit, code warranty or certification.
• Material outputs should be checked against source files, official documentation, validated XRPL data and reproducible tests.
• Model names, subscription levels or benchmark claims must not be used as proof that code or legal conclusions are correct.
• AI-discovery/provenance files should distinguish project-authored claims, model assistance, dates and current canonical sources.

18 · Communications, marketing and affiliations

Truthful claims and no deceptive endorsement

• Security, privacy, adoption, integration, audit, legal-status, institutional-readiness and uniqueness claims must be supportable and materially qualified.
• Do not claim “unhackable,” “zero risk,” “guaranteed,” “world first,” “institutional grade” or similar superiority unless a documented basis supports the exact claim.
• Do not imply endorsement, hosting, partnership, review or certification by Ripple, Xaman, SWIFT, regulators, banks, exchanges, marketplaces or other third parties merely because of compatibility, linking, tagging, sandbox use or wallet visibility.
• Disclose material operator, affiliate, sponsorship, compensation or promotional relationships where relevant.
• No fake reviews, fabricated users, AI-generated fake testimonials or review suppression.

19 · Vulnerability disclosure and incident response

Receive, contain, recover and learn

1. Prepare. Maintain asset/dependency inventory, contacts, backups, rollback paths and security ownership.
2. Receive and triage. Accept good-faith reports via the official security contact; determine affected domains, code, users, wallets, providers, data and transaction paths.
3. Contain. Disable affected functionality, keys, endpoints, integrations or deployments when necessary.
4. Eradicate and remediate. Fix the cause, rotate exposed credentials, verify code/deployment integrity and test the repair.
5. Recover. Restore only after reasonable validation; monitor for recurrence and document recovery decisions.
6. Notify and improve. Give accurate user/legal notice when required and perform post-incident review.

• Good-faith research does not authorize secret theft, wallet access, social engineering, malware, extortion, denial of service or avoidable harm.
• No bug bounty, immunity or payment is promised unless separately documented.
• Security reports should include reproducible steps, affected URLs/commits and impact when safe.

20 · Validation and release records

HTML, validation TXT and reproducible evidence

Material page upgrades should preserve a human-readable validation record alongside the production artifact where practical.

• Commit the production HTML and its corresponding validation TXT when the validation accurately describes that exact artifact.
• Validation records should identify file/release, hash when available, static checks, runtime/browser coverage, known limitations and whether real Mainnet signing was performed.
• Do not reuse a validation file after the HTML changes unless the affected checks are rerun.
• Mocked Xaman/XRPL tests must be labeled as mocked and must not be represented as a real Mainnet transaction.
• Retain material change logs and hashes sufficient to trace what version was tested and deployed.

21 · Third-party independence

Interoperability without control

XRBitcoinCash is independent of Ripple, XRPL validators/Foundation, XRPL Labs/Xaman, Sologenic, XPMarket, XRPScan, GitLab, GitHub, Render, Resend, Google/Gmail, IPFS gateways, Coinbase, Kraken, SWIFT, BIS, Apple and other referenced providers unless a separately documented relationship states otherwise.

• Third-party names, marks, software, APIs, data, privacy practices, fees and availability remain under their owners' control.
• External links can change; users must verify domain and transaction details.
• XRBitcoinCash cannot reverse, restore, compel or guarantee an independent service.

22 · Legal and regulatory operating boundaries

No custody, redemption, stable-value or unreviewed regulated expansion

• No promise of appreciation, yield, dividend, revenue share, buyback, floor price, guaranteed liquidity or managerial profit effort merely for holding XRBC.
• No fixed-value redemption, reserve-backed dollar promise, deposit status, insured-product claim or stablecoin label for XRBC absent a separately authorized program.
• No custody, acceptance-and-transmission of customer value, managed trading, lending, leverage, derivatives, brokerage, payment processing, tokenized equity/debt/real-property rights, KYC profiling or automated sanctions decisioning without dedicated legal/security review and required controls.
• Digital-asset sanctions, tax, money-transmission, securities, commodities, consumer-protection, privacy and intellectual-property rules remain fact- and jurisdiction-specific.
• Pending legislation and agency guidance must not be represented as enacted law or binding classification beyond their actual status.

23 · User responsibilities and non-waivable rights

Risk allocation and mandatory protections

• Users are responsible for wallet/device security, addresses, tags, transaction fields, backups, taxes, legal eligibility and independent research.
• Public blockchains involve irreversible transactions, volatility, illiquidity, slippage, front-running, market manipulation, issuer controls, freezes/clawback where applicable, software bugs, protocol changes, phishing, malware, outages and third-party failures.
• Nothing in this Policy eliminates consumer, privacy or other rights that applicable law does not permit to be waived.
• The Terms govern enforceable warranty/liability language; this Policy does not create a broader waiver by itself.

24 · Source register

Security, privacy, accessibility and legal literature used in this revision

25 · Governance and change management

Review cadence and production discipline

• Maintain a dated inventory of public pages/xApps, transaction types, data flows, external services, public API keys, gates, metadata endpoints and responsible maintainers.
• Maintain legal/source records distinguishing enacted law, effective rules, interpretations, pending bills, court decisions and provider terms.
• Review material changes for misleading wording, hidden risk, inaccessible controls, mobile overflow, stale data, missing validation and affiliation overclaims.
• Re-review this Policy at least quarterly and promptly after material legal, security, privacy, feature or third-party changes.
• When a control cannot be verified, disclose the limitation rather than representing it as complete.

26 · Official channels

Support, security and authenticity

• Project operator and policy owner: Scott Patrick Anderton
• Support: https://xrbitcoincash.com/support.html
• Email: xrbitcoincash@gmail.com
• Official X: @XRbitcoincash
• Security: /.well-known/security.txt
• Canonical policy: https://xrbitcoincash.com/policy.html

27 · Revision and conflict rules

Version control and legal hierarchy

• Policy v5.0.0 posted at the canonical URL supersedes earlier policy versions from August 31, 2026.
• Material legal, privacy, security, support, encryption, transaction, bridge, tokenization, settlement, evidence, accessibility or gate changes require a dated review and corresponding documentation.
• If this Policy conflicts with the Terms, the Terms control legal rights and remedies unless this Policy imposes a stricter internal security/prohibited-use rule.
• If interface language conflicts with validated XRPL data, validated data controls ledger facts and the interface must be corrected.
• Qualified counsel should review material regulated expansion and final contractual/privacy language for the operator's actual jurisdictions and data flows.