Privacy Policy
Updated October 16, 2026 · Questions: admin@xrpfrontend.com
Workspace organization and published destinations
Workspace names, types, grouped public wallet addresses, internal labels and optional destination tags are stored in the service database for their verified owner wallets. Workspace membership is private to authorized wallet sessions by default. Choosing a public payment destination explicitly publishes its label, address and optional tag under the workspace username. Publishing requires wallet ownership verification. Private listing visibility does not hide addresses, transactions or relationships already visible on the public XRP Ledger. Reading balances contacts public ledger providers. Removing a workspace deletes its organization records and published destination listings, not wallet funds, registered usernames or blockchain history. Workspaces do not store customer signing keys or confer transaction authority. Team access and shared permissions are not implemented.
ChangeNOW Bridge exchanges
When you request a Bridge quote or create an exchange, XRPFrontend sends the selected currency, network, amount and verified receiving wallet address to ChangeNOW through its server API. It stores quote IDs, amounts, receiving addresses, creation state, provider exchange IDs and deposit instructions to associate exchanges with your verified wallet and avoid duplicate creation. ChangeNOW handles its own verification, exchange data and KYC documents under its privacy policy. XRPFrontend does not collect ChangeNOW identity documents or customer private keys. API credentials remain server-side. Exchange deposits and payouts are public blockchain activity.
Accounting records and exports
Accounting history is requested from public XRP Ledger nodes for the address you select. XRPFrontend accounting classifications, custom attributes, references, valuations, notes and review timestamps are stored privately in the service database for the verified wallet and selected network. History retrieval itself does not submit a transaction. Downloaded work files include fetched transaction evidence and current payment proofs; they may contain customer information. Files are not encrypted by the app. Restoring a work file merges annotations only; ledger evidence must be retrieved again. Do not enter SSNs, tax identification numbers, W-9 forms, recovery phrases or private keys. The same verified wallet can load saved annotations on another device. Automated tax filing is not implemented. Cookie expiry and clearing browser data end local access but do not erase server records. Keep secure backups and manage exported copies independently.
Contact and date
Updated October 16, 2026. XRPFrontend is operated from Texas, United States. For privacy questions or requests, email admin@xrpfrontend.com. This notice describes the data handled by the site and the services it uses. Third-party providers have their own policies and retention practices.
What the application does
XRPFrontend is an interface for public XRP Ledger information and wallet-approved transactions. It does not hold your Mainnet signing keys. It is not an anonymous browsing service. Public addresses, IP addresses, and transaction information may be linkable to individuals.
Browser storage
XRPFrontend wallet invoice records are stored on the service database for access from a verified receiving-wallet session, rather than in browser localStorage. Network preference is stored in sessionStorage. User-selected interface language and display currency are remembered in browser localStorage; these settings contain no wallet keys or transaction amounts. Interface translations are bundled with the site, and wallet or account data is not sent to a translation service. The Xaman SDK can retain authorization/session information in browser storage; this is not a wallet seed. Signing out ends the website session but does not delete saved invoice records. Older browser-only annotations can be imported explicitly; their local originals are retained. Username and tip payment hashes may be retained locally to recover interrupted purchases. Short-lived abuse controls store hashed request identifiers and counts, rather than raw client IP addresses, with periodic cleanup of expired counters. Connected public wallet addresses and wallet types can be remembered locally for the account dropdown; these records are not signing keys. Token watchlists and saved NFT identifiers can remain in this browser. Persistent market-data snapshots and recorded asset-value history are no longer retained; old versions of those storage keys are removed when market features load.
Directory names, wallet sessions and referrals
Xaman sign-in is checked server-side by verifying its signed OAuth identity against Xaman’s public signing certificates, along with the application, wallet and expiry. Public certificates may be refreshed from Xaman when signing keys rotate. The access token is used transiently for verification and is not stored by our backend. Account-specific Xaman signing clients retain their access tokens in this tab’s memory while connected; Xaman’s SDK may also remember its authorization in browser storage. Account switching reuses valid protected wallet sessions, and signing reconnection may be needed after authorization expires or a page reload. Other signing wallets use a short-lived ownership challenge. The server stores a hashed session token associated with the public wallet address, with a 30-day expiry; protected HttpOnly cookies preserve active and previously verified wallet sessions. Explicit sign-out revokes the selected wallet’s remembered sessions. It stores a pending username reservation for up to 24 hours, and after a successful registration stores the public username, wallet address, payment transaction hash and optional referral attribution. Public username lookup reveals the username and address. Saved invoices, payment references, verified payment hashes, private annotations, watchlists and labels are stored for access from your verified wallet session. Public profile fields, enabled PayString addresses and tags, and the tip button are public. Tip activation orders, payment hashes and disabled dates are retained to verify purchases and prevent receipt reuse. Referral links set a 30-day browser cookie only after you allow optional referral storage. Reject optional storage declines this cookie and removes any existing referral cookie. Your choice is remembered locally and in a preference cookie for up to one year. Change it from Privacy settings in the footer. Withdrawing permission stops new cookie attribution; it does not erase existing paid orders, legally retained purchase records or recorded sponsor attribution. The server captures eligible affiliate attribution at username reservation or trade review, then records the paying wallet and sponsor only after validated settlement. Trade reviews store the unsigned operation, fee amount, referral candidate, creation time and expiry. Tip orders no longer capture new referrals or earn commissions. Current username registrations create commission records at the recorded rate. The affiliate program covers usernames, XRP-related swaps and XRP NFT purchases. Trade receipts include a public reference to the saved review. Pending trade hashes may be retained in this browser for recovery. Historical commission and Check records are retained for reconciliation. Validated fee-event receipts, affiliate liabilities, locked payout IDs, beneficiaries, signed company XRP payment blobs and transaction hashes are retained to prevent duplication and reconcile uncertain settlement. Affiliates access their own records through a verified session. Customer signing remains in the customer’s own wallet. Automated company payouts use a revocable regular signing key stored as a secret in a separate payout Worker; the company master key is not supplied to the website. Private receipts include activity details, collected fees, recorded commission amounts, recipients, payment attempts and settlement times. Public payout memos include the activity type, source transaction hash, collected fee, commission amount and receipt ID. The company owner can view the complete payout reconciliation; affiliates can view only their own private receipts. A signed transaction is an authorization for that exact transaction, not a private key. A registration payment, memo and issued Check are public XRPL data and cannot be removed by the site. Contact support about removing service-held account data or a disputed registration.
Temporary username coupons
Coupon claims require a verified wallet. The service stores the campaign, claimed username, wallet, claim time and a keyed fingerprint of the public IP (IPv6 addresses are grouped by their /64 network) to enforce one claim per connection and wallet. Raw IP addresses are not stored in coupon claim records; hosting providers may keep their own access logs. Shared networks share a claim limit. Turning off a campaign stops new claims while preserving registered usernames and the redemption record needed to prevent reuse. Coupon registration is off-ledger, carries no username payment or network fee, and generates no affiliate commission.
Public transactions and invoices
The affiliate Paid Out leaderboard publishes aggregate confirmed payout totals alongside registered usernames or shortened affiliate wallet addresses. It excludes pending commissions, private referral records and the company payout queue. CheckCash receipt hashes are stored to verify collection without counting the same Check twice. Submitted transactions, including memos, amounts, accounts and tags, become public ledger data. Other parties can copy and analyze that data; XRPFrontend cannot erase or reverse it. Creating an invoice alone does not write it to the blockchain. Its share URL contains an identifier that can retrieve the invoice details, so anyone with the link can read them. The URL may appear in browser history, hosting access logs or messaging/link-preview services. Never put sensitive customer information into a title, note or share link.
Tokens, NFTs and third-party media
Token and NFT pages request public ledger records, indexed marketplace data, prices, and metadata from external providers. Issuer websites, artwork URLs and IPFS gateways may receive your IP address and browser request when media loads. Names, images, attributes and prices can be inaccurate or unavailable. Creating an NFT stores its URI and properties on the public ledger; artwork and JSON metadata must be hosted separately by their publisher. XRPFrontend does not host or guarantee the availability of those files. Uploaded profile and collection images are cropped in the browser, stored as JPEGs in the service database, and served publicly. Profile images are tied to the verified wallet address; collection images are tied to the verified issuer and collection taxon. The authorized wallet can replace or delete them from the relevant editor; cached copies may persist briefly. A public collection or account view does not require wallet verification.
Connections and recipients
The browser queries public ledger services at xrplcluster.com and s.altnet.rippletest.net; those operators receive requested accounts and network connection information. Xaman receives authorization and signing-request data, including proposed transaction fields, to provide its service. CROSSMARK and Ledger integrations communicate with the selected extension or device and follow those products’ security boundaries. The Testnet faucet receives the address being funded and request connection information. Explorer links take you to another service. These services apply their own privacy terms.
Workspace portfolio charts
Historical portfolio charts send the public wallet addresses currently grouped in the selected view, requested times and ledger indexes to XRPL.to through the existing server-side market connection. They do not send private workspace names, labels, session cookies or signing keys. Charts retrieve past ledger holdings and historical exchange rates; no portfolio-history dataset is stored permanently by XRPFrontend. Short-lived browser memory coalesces repeated reads, and request-rate counters are kept as described above. Each grouped wallet is counted once.
Ledger search and history
Submitted transaction hashes, ledger numbers, NFT and ledger-object IDs, and public account-history queries are sent through XRPFrontend’s server to XRPL public nodes. XRPL public nodes receives those public identifiers and the server connection information. Wallet session cookies, signing keys and private workspace records are not forwarded. Validated transaction and ledger responses may be reused in bounded server memory for up to 24 hours; current object and history pages for up to 15 seconds. Search rate-limit counters and provider cooldown timestamps are stored in the service database. Per-client counters use a hash derived from the connecting IP, scope and time window and expire automatically. These counters are not a saved search-history dataset. Token and collection names use the market provider described below. Public name lookup returns existing public directory records and only public workspace discovery metadata.
Market-data providers and cooldowns
Market screens request XRPL.to data through XRPFrontend’s server. The provider receives the requested asset identifiers, collection identifiers or search queries and the server connection information. The hosting provider receives your browser request. Artwork, issuer websites and other externally loaded media may still contact their hosts from your browser. Market responses are reused only in bounded temporary memory, including up to one minute of server memory for submitted name searches; they are not saved as an XRPFrontend market-data dataset or offered as a standalone public market-data API. Cooldown timing may be retained in tab session storage so a reload does not immediately repeat a rate-limited request; this is a timestamp, not a market-data snapshot. Collection-issuer verification can also send a collection identifier to XRPL.to. The site’s existing server credential is not sent to browsers or exposed in downloads. Other market, logo, ledger, wallet and media providers handle requests under their own policies.
Hosting, logs and support
The hosting provider receives network requests, IP addresses, browser metadata and requested URLs to deliver and secure the website. The xrpfrontend.com deployment uses Cloudflare infrastructure. Hosting logs and security controls are managed by the hosting provider; their retention may differ from records in the application database. Email sent to admin@xrpfrontend.com includes your email address and anything you send; Google processes it as the email provider. Do not email recovery phrases, private keys or sensitive financial documents.
Purpose and tracking
Application data is used to display accounts, save verified-wallet invoices and remember local preferences, prepare transactions, request wallet approval, and troubleshoot support requests. No advertising pixels, behavioral-advertising SDK, data-sale workflow or customer-profiling system is intentionally implemented in this application. That is not a claim that infrastructure providers collect nothing. Cookies or session mechanisms required by wallet authorization or restricted hosting may still be used.
Retention and deletion
Saved invoices and annotations remain in the service database after browser data is cleared. Older unimported browser-only records may be discarded when site data is cleared. Clearing browsing history alone does not necessarily clear localStorage. Clearing cookies and site data usually does. Exported PDFs and shared links are separate copies, not restorable invoice-history backups. Ledger records cannot be deleted by this site. Provider logs and support correspondence have separate retention. Contact us to request deletion of service-held data where applicable; transaction and purchase evidence may need to be retained for security, dispute handling or legal obligations.
Requests and rights
Email admin@xrpfrontend.com to request information, correction, access or deletion of data the operator holds, or to appeal a response. Applicable privacy rights depend on your location and the law’s scope. Identity verification should be proportionate and never require a wallet seed. The operator cannot retrieve local-only records from your browser or remove public ledger records. Where applicable law requires response deadlines, appeals or regulator complaint information, those requirements apply; this notice does not narrow those rights.
Security and international processing
Locally bundled scripts and wallet-controlled signing reduce some risks but do not guarantee security. Browser malware, compromised extensions, malicious site code, phishing, dependency vulnerabilities and invoice alteration remain possible. Local storage is readable by scripts running on this origin. Providers may process data outside Texas or outside your country. This release has not received an independent security audit.
Children and changes
The service is intended for adults with authority to use their wallet. Do not submit children’s information. Contact the support address about information submitted in error. Changes to actual data handling require corresponding notice updates; the revision date will identify updates. We will update this page when material data practices change.