Policy, Security & Compliance Framework

1 · Scope and document hierarchy

Purpose, coverage, and controlling authority

This Policy applies to official XRBitcoinCash webpages, code, widgets, transaction-template flows, public-ledger analysis, locally generated evidence, documentation, project communications, and persons acting on behalf of the project.

2 · On-ledger identity and disclosure

Verifiable XRBC identifiers

Official pages must display sufficient information to distinguish XRBC from similarly named assets. A ticker or logo alone is not acceptable identification.

• Official interfaces must identify the full issuer and currency value near trust-line and transaction actions.
• Project pages must not describe explorer, wallet, or directory labels as proof of identity or regulatory approval.
• Material issuer controls, transfer fees, freezes, clawback authority, authorization requirements, domain information, and trust-line conditions must be surfaced when relevant and technically available.
• Any discrepancy between webpage text and validated-ledger data must be treated as a security and disclosure issue.

3 · Operating principles

Long-term compliance principles

4 · Securities-law posture

SEC-aligned asset and transaction review

The project adopts the SEC–CFTC 2026 distinction between the characteristics of a crypto asset and the legal treatment of a transaction involving that asset.

• No promise of profit, appreciation, yield, passive income, dividends, revenue share, buyback, price support, floor price, guaranteed liquidity, or managerial return.
• No statement that purchasing XRBC finances development that is expected to increase token value.
• No direct institutional, negotiated, discounted, restricted, or fundraising sale of XRBC by or for the project without written securities counsel analysis and any required registration or exemption.
• No sale agreement granting equity, debt, governance, repayment, revenue, liquidation, or ownership rights unless separately structured and lawfully offered as the appropriate regulated instrument.
• No use of “SEC approved,” “SEC compliant,” “registered,” “exempt,” “not a security,” or similar legal conclusion without a current written legal basis that authorizes that exact statement.
• No reliance on a project label—such as collectible, utility, membership, credential, or digital commodity—as a substitute for transaction analysis.
• Material public statements by founders, operators, developers, affiliates, compensated promoters, and authorized channels must be reviewed because promises can arise through multiple communication media.

Ripple litigation lesson

The Ripple matter is not treated as a blanket ruling for every XRP-related or token-related transaction. The surviving final judgment illustrates that institutional sales and secondary or programmatic transactions can be analyzed differently. District-court findings are case-specific and do not provide XRBC with automatic nationwide immunity or regulatory approval.

5 · Commodity and market-integrity posture

CFTC-aligned anti-fraud and anti-manipulation controls

This Policy does not declare XRBC to be a commodity. It adopts conduct controls consistent with the CFTC's anti-fraud, anti-manipulation, customer-protection, and market-integrity concerns.

• No pump-and-dump campaign, coordinated price promotion, deceptive countdown, false urgency, or “guaranteed return” claim.
• No wash trading, self-dealing designed to create false activity, spoofing, layering, fabricated order-book depth, or knowingly misleading liquidity.
• No undisclosed project or affiliate trading intended to influence price, volume, ranking, trend indicators, or user perception.
• No selective publication of favorable metrics while knowingly omitting material liquidity, issuer, trust-line, route, or concentration risks.
• No managed trading, commodity pool, futures, options, swaps, leverage, margin, copy trading, automated profit strategy, or derivatives product without separate licensing and legal review.
• Tools must describe scores, slippage, paths, liquidity, and market data as observations or estimates, not predictions or recommendations.
• Watchtower and Value Path must preserve transparent assumptions, identify missing data, and avoid treating a locally calculated score as a regulatory or investment rating.

6 · Stablecoin boundary

GENIUS Act policy

XRBC is not intended or represented as a payment stablecoin. The following representations and operations are prohibited unless a separately licensed and legally reviewed program is established:

• No promise to redeem, repurchase, or exchange XRBC for a fixed monetary amount.
• No representation that XRBC maintains a stable value relative to the U.S. dollar, another currency, or a reference asset.
• No reserve, collateral, segregation, attestation, or one-to-one backing claim unless factually true, independently supportable, and legally authorized.
• No use of “stablecoin,” “payment stablecoin,” “digital dollar,” “cash equivalent,” “insured,” “deposit,” or “legal tender” to describe XRBC.
• No interest, yield, reward, or return represented as arising from reserves or stable-value backing.
• No direct issuance, redemption, custodial reserve management, or payment-stablecoin service without satisfying applicable federal and state requirements.

GENIUS Act implementation rules and effective dates must be monitored. A feature that changes XRBC's redemption, payment, reserve, or stability characteristics must be disabled until counsel confirms its treatment under the enacted statute and final regulations.

7 · Provisional market-structure safeguards

CLARITY Act readiness without treating the bill as law

Because the CLARITY Act remains pending, this Policy does not claim an exemption, registration status, maturity certification, digital-commodity status, or statutory safe harbor under the bill.

The following concepts are adopted voluntarily where relevant:

• Recordkeeping: retain material policy revisions, public disclosures, source references, security decisions, and transaction-template changes.
• Monitoring: identify and prohibit manipulative conduct, deceptive liquidity, insider misuse, and material conflicts.
• Customer-asset separation: maintain the present no-custody model. If custody ever exists, customer property must not be commingled or used without lawful authority.
• Intermediary separation: do not operate as an exchange, broker, dealer, custodian, or clearing function by implication; pause any feature that crosses into those activities.
• Issuer and network disclosure: publish verifiable identifiers, functionality, supply design, material controls, dependencies, risks, and project affiliations.
• Systems safeguards: maintain change control, access control, incident response, service monitoring, and business-continuity planning appropriate to the feature.
• AML readiness: if a future regulated intermediary function is added, implement the required Bank Secrecy Act program before launch.

8 · Illicit-finance controls

FinCEN, sanctions, anti-bribery, and criminal misuse

FinCEN and money-transmission boundary

• The website must not accept value from one person and transmit it to another person or location.
• The website must not buy or sell XRBC as a business, intermediate customer trades, maintain customer balances, or redeem XRBC.
• Users authorize transactions directly from their own wallets through independent software.
• Any business-model change involving acceptance and transmission, exchange, administration, redemption, or customer accounts requires a written FinCEN and state money-transmission analysis before launch.

OFAC and sanctions

• Digital-asset activity is subject to applicable sanctions to the same extent as other property or transactions.
• Official tools may block, geofence, restrict, preserve evidence, or decline support when required by sanctions, a valid order, or a documented risk-based compliance decision.
• No feature may be designed to conceal ownership, destination, transaction purpose, or sanctioned-party involvement.
• Sanctions screening, if implemented, must be risk-based, documented, tested, and must not be represented as infallible.

Anti-bribery and anti-corruption

• No bribe, kickback, improper payment, undisclosed referral payment, or thing of value may be offered to obtain listings, regulatory treatment, government action, business, or favorable publicity.
• Material compensation and conflicts involving promoters, reviewers, influencers, market makers, contractors, or public officials must be disclosed and reviewed.
• Records must not be falsified to conceal compensation, trading, ownership, or business relationships.

9 · Consumer protection and communications

FTC-aligned truthfulness, endorsements, and fee clarity

• Advertising and interface claims must be truthful, not misleading, not unfair, and supported by evidence appropriate to the claim.
• Risk disclosures must be clear, proximate, readable, and not contradicted by larger headlines, buttons, social posts, videos, or influencer statements.
• No fake reviews, fake users, fabricated testimonials, manipulated rankings, suppressed legitimate criticism, or misleading success stories.
• Material relationships—including payments, free XRBC, affiliate links, employee status, project roles, market-making relationships, or other incentives—must be clearly and conspicuously disclosed.
• No claim of “safe,” “risk free,” “guaranteed,” “approved,” “insured,” “audited,” “certified,” or “compliant” unless the exact claim is objectively true and documented.
• Displayed transaction costs must distinguish estimated XRP network fees, spread, slippage, issuer transfer fees, Xaman or third-party fees, and other costs when known.
• Warnings must be applied consistently. A project must not be singled out for a warning based on undisclosed commercial preference while comparable risks are ignored elsewhere.
• Educational materials must distinguish project statements from third-party data, regulator guidance, pending legislation, and legal conclusions.

10 · Security architecture

Non-custodial and no-secret policy

11 · Privacy and evidence handling

Data minimization and public-ledger transparency

• XRPL addresses, transactions, trust lines, balances, offers, AMMs, issuer settings, NFTs, and related ledger records are public.
• Official tools should use local browser processing and local storage when practical rather than collecting user data on a server.
• Below a tool's XRBC threshold, the interface should avoid enumerating unrelated wallet tokens and should display only the information necessary to explain gate status.
• Local watchlists, settings, challenge references, trend history, and evidence drafts may be removed when browser data is cleared.
• Users must be warned before placing personal, confidential, regulated, proprietary, or legally protected data into permanent public ledger fields or NFT metadata.
• Exported JSON and SHA-256 hashes document selected inputs and file integrity; they do not prove truth, ownership, authorization, legal effect, completeness, or current status.
• If personal information is collected in the future, a specific privacy notice, retention schedule, lawful basis, access controls, deletion process, and jurisdictional review are required before collection.

12 · Automated review boundary

AI-Assisted Review and Auditing

• XRBitcoinCash may use AI-assisted and automated systems to review code, documentation, transaction flows, disclosures, and public-ledger observations.
• Automated review is supplemental and does not constitute a formal audit, legal opinion, regulator approval, certification, warranty, or guarantee of compliance.
• AI output may be incomplete, inaccurate, inconsistent, or outdated and must be checked against source documents, validated XRPL data, tested code, and qualified professional advice.
• Material legal, security, transaction-template, custody, stablecoin, market-conduct, or consumer-protection decisions may not rely solely on automated output.

13 · Analytical and tokenization tools

Tool-output and legal-effect limitations

• Advanced Auditor, Risk Lens, Value Path, Watchtower, Advanced Tokenization, and Evidence Pack outputs are informational and experimental.
• No score, label, risk flag, evidence pack, route, hash, or architecture choice is a legal opinion, audit opinion, valuation, recommendation, certification, reserve attestation, title report, compliance determination, or guarantee.
• Watchtower automatically assigning 0/100 where no usable XRP/token AMM exists is a transparent local liquidity rule, not an allegation of fraud, insolvency, illegality, or worthlessness.
• Tokenization planning does not create title, ownership, custody, a lien, a security interest, registration, insurance, valuation, authenticity, contractual enforceability, or government recognition.
• A token or NFT representing a security, debt, equity, fractional ownership, revenue interest, investment contract, payment stablecoin, deposit, real-property interest, regulated commodity interest, or other regulated right requires specialized legal review before support.
• Public token directories and metadata sources are discovery aids. The full issuer and direct XRPL evidence control technical identity.

14 · Ripple and third-party alignment

Benchmarking without affiliation

Ripple Labs is not a regulator and does not govern XRBitcoinCash. Ripple policies are reviewed only as a benchmark for responsible conduct, including sanctions, AML, anti-terrorist financing, anti-proliferation financing, anti-bribery, truthful affiliation, intellectual property, privacy, complaint handling, and security reporting.

• XRBitcoinCash is independent of Ripple Labs, Ripple subsidiaries, XRP, XRPL validators, the XRPL Foundation, and Ripple-operated services.
• “Ripple,” “Ripple Labs,” Ripple logos, XRP, XRPL-related marks, Xaman, SWIFT, Sologenic, XPMarket, and other third-party marks remain the property of their owners.
• Descriptive references do not imply endorsement, partnership, certification, agency, licensing, sponsorship, or integration.
• Third-party terms, fees, privacy practices, eligibility rules, acceptable-use rules, sanctions controls, and technical requirements apply separately.
• The project must not copy restricted third-party content, scrape prohibited data, bypass rate limits, or present third-party metadata as proprietary project verification.

15 · Widgets, code, and integrations

Limited license, integrator duties, and revocation

• Official widgets include XRBitcoinCash-branded components, scripts, libraries, embeds, or copied code that displays data, performs analysis, or prepares transaction templates.
• A limited, revocable, non-exclusive, non-transferable license is granted only where the code or page expressly permits reuse and subject to applicable open-source licenses.
• Integrators must preserve token identifiers, transaction review, risk disclosures, third-party attribution, no-secret controls, and non-custodial boundaries.
• Integrators may not capture secrets, alter transaction fields after user review, hide issuer addresses, misstate routes, suppress warnings, fabricate scores, or imply official operation.
• Integrators are responsible for their own privacy, accessibility, consumer protection, licensing, sanctions, tax, intellectual-property, security, and jurisdictional obligations.
• Access to hosted widgets, endpoints, keys, or services may be limited or revoked for abuse, legal risk, security incidents, excessive use, misleading implementation, or policy violations.

16 · Security operations

Vulnerability disclosure and incident response

1. Receive. Accept good-faith security reports through the official security contact and preserve relevant evidence.
2. Triage. Determine affected code, domains, transactions, wallets, data, dependencies, and user impact.
3. Contain. Disable or restrict the affected feature, endpoint, key, transaction flow, or deployment when necessary.
4. Remediate. Correct the issue, rotate exposed credentials, validate the repair, and document the change.
5. Notify. Provide accurate user notice when material risk exists and make legally required reports.
6. Review. Perform a post-incident analysis and add controls to prevent recurrence.

• Security reporters must not access unnecessary data, disrupt services, exploit users, demand payment through threats, or disclose secrets.
• No bug-bounty payment is promised unless a separate written program expressly offers one.
• Security monitoring reduces risk but cannot guarantee a vulnerability-free system.

17 · Mandatory pause and review

Features that require legal and security approval before launch

18 · Governance and records

Compliance register and change management

• Maintain a dated inventory of official pages, tools, domains, third-party services, API keys, transaction types, data flows, and responsible maintainers.
• Maintain a legal-source register identifying enacted laws, effective rules, pending bills, court judgments, regulator guidance, third-party terms, review date, and operational effect.
• Record material claims about classification, custody, stablecoin status, transaction boundaries, issuer controls, and access gates.
• Review significant user-interface changes for misleading wording, missing risks, inconsistent warnings, hidden fees, and unsupported affiliations.
• Require code review and validation for transaction-template, wallet, gate, pathfinding, memo, NFT, evidence, and security changes.
• Retain enough documentation to explain why a feature was launched, paused, restricted, or removed.
• Review this Policy at least quarterly and promptly after a material legal, technical, security, or third-party change.

19 · Complaints and remediation

Fair and transparent issue handling

• Users may report security, misleading content, transaction-template, accessibility, intellectual-property, privacy, market-conduct, or other concerns through official channels.
• Complaints should be acknowledged, categorized, investigated proportionately, and documented.
• Affected content or functionality may be temporarily restricted during investigation.
• Material corrections should identify what changed without concealing the prior error.
• The project must not retaliate against good-faith complainants or suppress honest reviews.
• Complaints about Xaman, Ripple, Sologenic, XPMarket, SWIFT, or another independent service must be directed to that service when the issue is outside XRBitcoinCash control.

20 · Official channels

Contact and authenticity

• Email: xrbitcoincash@gmail.com
• Official X account: @XRbitcoincash
• Security: /.well-known/security.txt
• Canonical policy: https://xrbitcoincash.com/policy.html

Any channel, domain, account, direct message, group, wallet request, or support contact not listed through the official website is unverified. Official channels will never request a seed phrase or private key and do not provide individualized legal, tax, or investment advice.

21 · Legal and policy reference register

Primary sources used for this framework

22 · Revision and enforcement

Policy changes and enforcement

• The current version posted at https://xrbitcoincash.com/policy.html supersedes prior versions.
• The effective date must be updated when a material legal, operational, security, or communications rule changes.
• Continued use is governed by the Terms of Use and mandatory law.
• Violations may result in removal of content, revocation of widget or endpoint access, account or service restriction where applicable, legal action, or referral to a third party or authority.
• If this Policy conflicts with the Terms, the Terms control unless this Policy imposes a stricter security or prohibited-use control.