The browser validates the support fields, reduces an optional screenshot, and creates a random case reference plus six-digit correlation code.
Official support channelBrowser-encrypted evidence option
XRBC · support · encrypted evidence receipt
Support without exposing wallet secrets.
Use ordinary email support, or create a private browser-encrypted case package bound to one Xaman-authorized XRPL NFT receipt. The encrypted route separates the readable complaint from the public ledger, verifies the receipt on a validated ledger, confirms the NFT in the submitting wallet, and then delivers a private recovery package for local decryption.
No seed or private key collectionAES-256-GCM in browserValidated-ledger confirmationPrivate recovery package requiredNot a regulated secure-messaging service
Never send a seed, recovery phrase, mnemonic, private key, family seed, Xaman passcode, device passcode, or remote-access credential.
XRBitcoinCash Support never needs them.
Encryption and evidence architecture
What is encrypted, what is public, and what is verified
The encrypted route is an evidence-separation workflow. It does not put the readable support narrative, reply address, or screenshot on the XRP Ledger.
Web Crypto generates a fresh 256-bit AES key and 96-bit IV. AES-GCM encrypts the report with authenticated additional data binding wallet, reference, code, protocol and version.
The encrypted envelope is SHA-256 hashed. An optional screenshot is separately AES-GCM encrypted with its own IV/AAD and receives a ciphertext SHA-256 fingerprint.
One Xaman NFTokenMint uses taxon 1001, flags 8, zero transfer fee, a fixed HTTPS metadata base URI constrained to the XRPL 256-byte URI limit, public reference/code memos and the envelope SHA-256. The plaintext complaint is excluded.
The mint must validate successfully and appear in account_nfts. Only then is the private recovery package sent for local decryption.
| Layer | Typical contents | Visibility | What it means |
|---|---|---|---|
| Readable case | Issue type, reply contact, page, public evidence reference, problem narrative | Local before encryption; private recovery package after encryption | The support message. It is not intentionally written to the NFT metadata or readable ledger memo fields. |
| Encrypted envelope | AES-GCM IV, authenticated data, ciphertext, protocol/version and optional compression marker | Private package; ciphertext may pass through support transport | Confidentiality plus tamper detection under the recovery key. It does not prove the truth of the underlying report. |
| Encrypted screenshot | Ciphertext attachment, filename/content-type descriptor, independent IV/AAD and ciphertext SHA-256 | Private email attachment/package | Allows integrity checking before local decryption; attachment content remains subject to device and mailbox security. |
| XRPL receipt | Submitting public wallet, mint transaction, NFTokenID, taxon, flags, immutable URI, reference/code and envelope hash memos | Public XRP Ledger | Chronology and wallet-authorized receipt evidence after validation. It is not identity, legal notice, truth, ownership of off-ledger content or acceptance of the case. |
| Recovery package | Encrypted envelope, recovery key, NFT/transaction identifiers and screenshot descriptor | Private delivery and optional local download | Possession may enable decryption. Because key and ciphertext are delivered through the support channel, this is not provider-blind or zero-knowledge messaging. |
AES-GCM is an authenticated-encryption mode: ciphertext modification or mismatched authenticated data causes decryption failure rather than silently producing trusted plaintext.
The recovery key can exist in browser state, a downloaded recovery JSON, clipboard history, or the private support email. Anyone who obtains a usable package and key may be able to decrypt it.
The current delivery route is not end-to-end encrypted against every intermediary because the recovery email contains the decryption material. Do not use it for classified, privileged, regulated-health, cardholder, banking-secret or similarly restricted data.
XRPL NFT URI and ledger transaction fields can be persistent. Never place sensitive information in the ticket reference, six-digit code, metadata URI, public wallet, transaction memos or any field intended for ledger publication.
Cross-industry interoperability pattern
Portable evidence architecture—not automatic regulatory compliance
The support protocol combines common building blocks—JSON records, SHA-256 fingerprints, authenticated browser encryption, public transaction identifiers and a private recovery package. Those primitives make the pattern adaptable to many case-management systems, but each industry must supply its own identity, retention, authorization, privacy and legal controls.
Financial operations & payment support
A case can reference public payment hashes, destination tags, invoice identifiers or settlement receipts while the human-readable complaint stays private.
Potential use: reconciliation exceptions, customer-service evidence, settlement investigations. Not a bank ledger, KYC system, money-transmission service or regulatory filing.
Cybersecurity & incident response
Teams can bind a private incident narrative and screenshot to a timestamped public receipt and portable hash without publishing the sensitive report itself.
Potential use: incident intake, remediation chronology, evidence handoff. Not suitable for secrets, exploit payloads, credentials, classified material or a substitute for a dedicated incident-response platform.
Insurance, warranty & service claims
A receipt can establish that a wallet submitted a case at a particular point in ledger history while photos or descriptions remain encrypted off-ledger.
Potential use: claim intake, warranty service, maintenance records. Does not prove coverage, damage, ownership, causation or entitlement.
Supply chain & asset service history
Reference IDs and hashes can link a private service package to a public chronology marker without treating the NFT as the physical asset itself.
Potential use: maintenance tickets, provenance-support records, exception reports. Does not establish title, authenticity, custody or regulatory provenance.
Legal, audit & e-discovery workflows
Portable JSON, cryptographic fingerprints and public chronology can supplement a conventional evidence repository or audit trail.
Potential use: evidence indexing and chain-of-events support. Not legal service, service of process, privilege, notarization, admissibility, certified chain of custody or court authentication.
SaaS, enterprise & customer support
The protocol can map naturally to ticket IDs, CRM cases, status systems and private support attachments because its recovery package is structured JSON rather than a proprietary binary-only record.
Potential use: cross-system support handoff and reproducible evidence exports. Production integration still requires API authentication, access control, retention and privacy agreements.
Healthcare & life sciences
The cryptographic pattern can inform regulated-system design, but this XRBitcoinCash support implementation is not a HIPAA, HITECH, GxP or clinical-record system.
Do not submit PHI, medical records, patient identifiers, clinical data or regulated research information through this support route.
Government & public-sector records
Public chronology plus private content separation can be conceptually useful for case tracking, but government deployment requires agency-specific identity, records, accessibility, procurement and security controls.
Not approved for classified information, CUI, law-enforcement evidence, statutory filings, official notices or government records-management obligations.
Machine-readable interoperability descriptor
Download a non-secret descriptor of the support protocol for review by developers, auditors or case-management integrators. It documents the public/private split and expected evidence fields; it contains no support ticket data or cryptographic key.
Threat model and operating limits
What can still go wrong
Encryption reduces exposure; it does not eliminate compromised devices, malicious browser extensions, mailbox compromise, provider outages, user error or false evidence.
Endpoint compromise
Malware, remote-access tools, malicious extensions, clipboard monitoring or an unlocked browser profile can expose plaintext or recovery keys before or after encryption.
Email/provider exposure
The private recovery package traverses the configured support transport. Delivery acceptance does not prove inbox placement, reading, confidentiality or a response.
Ledger permanence
The public wallet, transaction, NFTokenID, URI and memo values may be permanently observable and generally cannot be deleted by XRBitcoinCash.
Metadata dependency
The NFT URI is immutable, while an HTTPS metadata resource or image can become stale, unavailable or change if its host changes the response.
Evidence semantics
A validated receipt proves specific ledger facts, not real-world identity, authorship, accuracy, damages, intent, contractual rights or legal acceptance.
Duplicate prevention
Saved pending state is intentionally resumed before any new mint. Email retries occur only after the NFT is confirmed and cannot create another NFT.
Technical references behind the design
The page uses established browser cryptography and XRPL primitives; these sources explain the underlying standards, not an endorsement or certification of XRBitcoinCash.
Step 1 · one form
Describe the support request
The same form is used for both delivery methods. Email-only sends the readable report. The wallet method encrypts the readable fields before the support email is created.
Step 2 · Xaman and one NFT
Encrypted wallet ticket
Any ordinary XRPL wallet may submit the ticket. The private recovery email—not the public NFT—contains the AES key needed by the operator decryptor.
Connected walletNot connected
Ticket referenceCreated when workflow begins
Verification code------
1 · EncryptBrowser AES-256-GCM
2 · SignOne NFTokenMint
3 · ConfirmValidated + account_nfts
4 · Automatic emailPrivate recovery package
Connect Xaman and complete the form.
Automatic delivery: After the NFT validates and appears in account_nfts, the page emails the private recovery package automatically. The main button becomes an email-only fallback if provider confirmation is not returned.
One automatic action
Create the encrypted ticket once. The page resumes saved state, confirms the NFT, and sends the private recovery email without requiring a separate step.
Approve the NFT receipt in Xaman
Verify Mainnet, the connected account, taxon 1001, zero transfer fee, the fixed XRBitcoinCash metadata URL, and the six-digit code.
NFT receipt confirmed in the submitting wallet.
Support reference
NFTokenID
Mint transaction
Wallet
Metadata URI
Email stateNot sent
Support Operator — Decrypt Private Email Package Locally
No operator wallet connection is required for decryption.
The private recovery package delivered to the official inbox contains the AES key. Nothing entered here is uploaded or written to XRPL.
Support boundaries
What this page proves
NFT receipt
A validated mint plus account_nfts proves the submitting wallet created and owns the public informational receipt.
Private support package
The readable complaint and reply contact are encrypted in the browser. The recovery key appears only in the private email package or local download.
No custody or reversal
XRBitcoinCash cannot reverse validated XRPL transactions, recover wallet secrets, or control Xaman, XRPScan, Resend, or other independent services.