Privacy practices for XRP trades
Ripple (XRP) launched in 2012 as a payment-focused cryptocurrency. XRPL uses Federated Byzantine Agreement (FBA) consensus — validators on a Unique Node List (UNL) reach agreement on transaction ordering. The default UNL is published by the XRP Ledger Foundation (non-profit) with the for-profit Ripple Labs Inc. historically influencing validator selection. Native XRP cannot be frozen by any central authority — the freeze flag on XRPL applies only to issued tokens (IOUs), not to native XRP. The chain is transparent at the base layer — sender, recipient, amount, and destination tag (if present) are all visible on chain like Bitcoin. XRPL has no native protocol-level mixing. Users wanting transaction-level privacy rely on wallet-side address rotation (deriving a fresh address per trade from their HD seed) and off-chain coordination — the practices below cover what you can control.
Use a fresh address every trade
This chain uses transparent addresses with no native stealth. The standard practice: use a Hierarchical Deterministic (BIP-32) wallet that derives a new receive address per request. Most modern wallets do this automatically. The cost of address reuse is severe — every trade you accept at the same address builds a public record of your activity.
Universal practices
**Use a fresh receive address for every trade.** Your wallet should support this; if it doesn't, look for one that does. Address reuse is the single biggest leak.
**Practice coin control when spending.** When sending coins later, avoid combining the trade output with coins from another source — that combines their address histories permanently.
**Broadcast through Tor or your wallet's privacy mode.** Your home IP address sees the transaction first; nodes near your IP can correlate it to you. A Tor-aware wallet broadcasts through Tor by default.
**Avoid sending trade coins to or from KYC exchanges.** Once trade coins touch a KYC exchange, the trade becomes legally identifiable by combining exchange records with chain data. If you need to bridge to fiat, route through a self-custodied intermediate step.
What to avoid
- Do not paste your same receive address into multiple trades.
- Do not send the exact amount listed on the order — Morphit's amount-randomizer toggle (the "🔐 Randomize amount" checkbox in the address-share modal) breaks this; leave it ON.
- Do not combine the trade output with coins from a different source when you later spend it.
- Do not broadcast from your home IP via a non-private wallet — use Tor.
⚠ Caveats specific to this asset
XRPL is transparent at the base layer with no native mixing protocol. - **Share fresh addresses per trade.** Using the same XRPL address across multiple Morphit listings lets observers correlate your orders on a fully transparent chain. Generate a fresh receive address per trade — modern XRPL wallets (Xaman, Crossmark, Bifrost) derive these from your HD seed and let you create new accounts in seconds. - **Destination tags are not a privacy feature — they're an identifier, and Morphit cannot carry one.** A tag is visible on chain and correlates transactions. Morphit's address share has no tag field and its payment link sets none, so never share an exchange-hosted deposit address that needs a tag (the funds would be lost in the exchange's pool); share a self-custody address that needs no tag. - **Reserve requirement creates account-creation visibility.** Your first incoming XRP must be ≥1 XRP (the base reserve). The on-chain `Payment` transaction that funds a new account is publicly visible as account activation, which is a stronger correlation signal than a regular payment to an already-existing account. If reducing this signal matters, fund the receive address yourself first (from an account that's already mixed/separated) and only then share it. - **Network-layer privacy still matters.** Broadcasting through Tor or your wallet's privacy mode keeps your home IP off the chain's view of you. - **XRPL RPC providers can correlate.** Your wallet talks to an XRPL RPC endpoint (xrplcluster.com, Ripple's, or a self-hosted rippled node) — that provider sees every transaction you sign. Self-hosting a rippled node, or rotating between providers, reduces the surface area. - **Consensus-set concentration is a known property.** The default UNL (Unique Node List) is published by the XRP Ledger Foundation; running your own validator with a custom UNL is supported but uncommon. For Morphit's purposes this affects censorship-resistance considerations (a coordinated UNL could refuse to include transactions) more than transaction privacy. Document and decide based on your threat model. - **Only classic addresses are accepted.** XRPL has a newer "X-address" format (XLS-5d) that bundles a destination tag into the address. Morphit accepts only classic `r`-prefixed addresses and carries no tag, so share a self-custody classic address that needs no tag.
Morphit does NOT recommend specific wallet software. Even reputable wallets have been compromised or have had hidden flaws. The privacy techniques here are protocol standards, not endorsements — your wallet, your responsibility.