How XRPL.Sale Aims to Create Network Effects in Token Launches

SALE ID gives a human‑readable profile that binds to your XRPL account without giving us custody of your keys.

• Account binding: We verify ownership by asking your wallet to sign a message. No seed phrases. You can re‑bind if you rotate wallets.
• Data model: Public bits (handle, avatar) are visible; private preferences stay server‑side and are removable by you.
• Recovery: You recover by proving control of the bound XRPL account. We don’t offer custodial recovery.
• Anti‑sybil: Rate limits and abuse checks are live. Optional verification (e.g., project‑level attestations) is on the roadmap.
• Privacy: We minimize personal data, log access, and honor deletion requests. Storage details are documented in the docs.
• Wallets and seeds: Creating SALE ID requires a wallet signature. We recommend signer wallets (e.g., Xaman). A seed‑entry path exists for advanced users; we discourage it and never store seeds. See the Security Policy for guidance.

The AI guide explains XRPL concepts, suggests defaults, and helps checklists. It’s designed to be helpful without being pushy. Analysis is not financial advice.

GDPR/CCPA: data export and deletion requests are supported; retention windows and subprocessors are documented. Read more in the AI Assistant docs.

Tiers exist to make early launches practical and later allocations orderly. We avoid manipulative patterns.

• Goal: fair access for early buyers and predictable allocation for larger tickets
• Transparency: min/max per tier and schedules are explicit in the UI and on‑chain where applicable
• Measurement: we look at completion rates and drop‑off by step, not “conversion hacks”
• We’ll publish cohort deltas (e.g., D30 retention before/after a change) instead of making universal claims

If a buyback and burn program is active, it must be specific and auditable. Here’s the model we work toward, with on‑chain proof.

• Two‑sided network: value scales with active issuers × active buyers, not n².
• K‑factor: invites × acceptance rate. When K > 1 and D30 holds, organic growth compounds.
• Cohorts: we track D1/D7/D30 per release and report deltas when features ship behind flags.
• Quality of supply: we monitor project completion rate, dispute rate, and time‑to‑launch.

Monthly snapshots include numerators/denominators and dates.

• Non‑custodial: wallets sign; funds settle on XRPL.
• Centralization points: API, rate limits, spam/abuse filters, and off‑chain metadata. We document uptime targets and incident response.
• Abuse controls: per‑account limits, anomaly detection, and manual review paths for edge cases.
• Compliance: phishing education, issuer checks, and a clear process for takedown/legal requests. KYC/AML requirements depend on jurisdiction and project category.

XRPL.Sale is non‑custodial. You sign with your wallet; funds settle on XRPL. We recommend signer wallets (e.g., Xaman). We do not recommend entering seed phrases anywhere. See our security guidance.

• Market risk and low‑liquidity events
• Smart routing or integration failures
• Issuer defaults or delivery failures
• Social engineering and phishing risk
• Regulatory limits on promotions and token flows

We won’t custody user keys, won’t promise returns, and won’t design “casino” mechanics. Feature rollouts are measured and reversible.