XRP Friyay -

The Spaces centered on three themes: legal risk around leveraging real people’s names in tokens/NFTs, the XRPL’s technical roadmap and neutrality, and a candid look at adoption, infrastructure, and custody realities. The host (from XRP Cafe) explained why NFTs and tokens using Arthur Britto’s name were delisted at the request of his legal representatives, emphasizing it was a right-of-publicity issue, not a DMCA takedown, and that assets remain tradable on-ledger via other front ends. Speakers clarified marketplaces on XRPL act as explorers that facilitate P2P signing, so delisting is a centralized editorial choice, not censorship. Wietse Wind (XRPL Labs/Xaman) discussed proposals such as batching, token escrow, permissioned domains/DEX, and especially MPT as a cleaner, more general value representation than trust lines/XLS-20. A David Schwartz clip underscored neutrality as layer-1’s ultimate selling point. The room dissected Cloudflare’s “stablecoin-like” move for AI monetization without mentioning blockchain, predicting many corporate “dollars,” walled gardens, and a key interoperability role for XRPL. Wietse urged strong key hygiene (Tangem, hot/cold model), warned about rampant impersonation scams, and shared sober views on self-custody off-ramps, bank de-risking, full-history infra costs, and yield schemes (favoring protocol-level, overcollateralized designs like Flare over unsecured third-party programs).

XRP After Dark – Comprehensive Notes

Participants and roles

• Host (unidentified): Led the discussion, moderated segments on legal, decentralization, Cloudflare, amendments, self‑custody, yield, infra, and support.
• Wietse Wind (XRPL Labs/Xaman; appears as “Wietse”): Provided deep technical and operational insights on XRPL, wallets, amendments, infra, self‑custody, and support practices.
• XRPScan representative (appears as “XRPScan”): Commented on Cloudflare’s announcement and market perception of “blockchain” terminology.
• Shelly (co-host): Weighed in on community items and tone.
• Stephanie (community builder): Asked about XApps portability across wallets.
• “Guardian/Red Guardian/Guardy” (community member): Mentioned in relation to Reddit/community debates.
• Adam (XRP Cafe team): Referenced by the host regarding verification of a legal letter.
• Chris Thompson (community; “Big CJET”): Referenced in infra and Cloudflare discussion.
• Teku (community proposer): Referenced for recent XLS proposals.
• David Schwartz (Ripple): Referenced; his clip on neutrality played and discussed.
• Arthur Britto (XRPL co‑creator): Central to the legal-topic segment.
• Satish (XRPL Labs): Mentioned for building the in-app support system (“Monk Desk”).

Highlights and key takeaways

• Using a real person’s name/likeness for tokens/NFTs invites right-of-publicity/legal challenges as projects gain traction. Platforms can delist from their UI; assets remain on-chain.
• The issue is not decentralization or censorship; marketplaces are centralized websites making editorial/business risk decisions. XRPL assets and P2P transacting continue.
• David Schwartz’s “neutrality” framing: decentralization and neutrality of L1s are the ultimate selling points for institutions; branding shifts like “rippled” to “xrpld” aim for protocol/company separation.
• Amendments pipeline is rich but poses complexity and testing risk. Batch, token escrow, and MPT (Multipurpose Tokens) are viewed as high‑impact; MPT could unify/streamline value representation vs trustlines/XLS‑20.
• Cloudflare’s “Net Dollars” is likely a payments-ledger play (not necessarily public blockchain). Large players may cherry‑pick crypto’s narratives while skipping decentralization; interoperability remains a major opportunity for XRPL and public chains.
• Self‑custody remains vital as an option, but for most users it may become less viable over 5–10 years due to regulation, friction, and banking scrutiny. Key hygiene and hot/cold models are essential.
• Yield on XRP via third parties is not risk‑free; users should understand unsecured-loan risk and opaque strategies. Protocol‑level, overcollateralized, trust-minimized systems (e.g., Flare’s model) are preferable.
• Public infra and full-history cost is climbing; practical approaches include truncating public history and offering full history via agreements/paid access.
• Scam epidemic on social platforms necessitates “in‑app support only” policies and better platform‑level enforcement. XRPL Labs built in‑house support tooling (“Monk Desk”) and encourages projects to adopt similar practices.

Legal actions against projects using “Arthur Britto” name

What happened

• A legal representative acting on behalf of Arthur Britto asked XRP Cafe to remove collections that use Britto’s name/likeness.
• XRP Cafe verified the representative’s authenticity and the letter of authority (Adam consulted legal counsel). Collections were delisted from XRP Cafe’s UI.

Important clarifications

• The complaint was not about a South Park PFP copyright or DMCA. It was about name, likeness, persona, and “right of publicity.”
• XRPL assets are immutable; NFTs/tokens remain on-ledger and tradable peer-to-peer via other discovery interfaces. Delisting pertains to display/visualization on a centralized marketplace site.

Perspectives

• Host: Using others’ names is a latent risk; small/low-volume projects may be ignored, but success draws legal scrutiny. Marketplaces gain nothing from fighting right‑of‑publicity battles.
• Speaker 3 (co-host): Key difference vs. unrelated PFP memes—this was the person whose likeness was monetized without permission. It’s not censorship/decentralization; it’s a private business decision.
• Comparison: David Schwartz once used a Phoenix memecoin PFP, but that did not leverage his name or persona. If a “David Schwartz coin” emerged, he might act similarly to Britto.

P2P and platform mediation

• XRP Cafe clarified: transactions are P2P on XRPL; marketplaces are explorers and UIs for discovery. They facilitate listing/viewing and signing, not custodial intermediated settlement.
• After delisting, holders retain full ownership and can transact via other platforms or direct P2P flows.

Guidance for builders

• Avoid using real individuals’ names/likenesses; right‑of‑publicity claims escalate with project success.
• Free speech arguments won’t spare platforms from risk; expect businesses to delist to limit liability.

Decentralization, neutrality, and branding

David Schwartz’s “On‑chain Academy” clip

• Institutions will see the neutrality of decentralized L1s as a positive, not a trade‑off. Neutrality and decentralization are the ultimate selling points and expected to drive massive growth.
• Discussion underscored that public, permissionless blockchains (BTC, ETH, XRPL, etc.) possess neutrality in varying degrees; market share competition plays out on these dimensions.

“rippled” renaming to “xrpld”

• Aim: better protocol/company separation. Mixed community reactions—some value the “Ripple” brand legacy; others prefer clarity around XRPL’s neutrality and public nature.

XRPL amendments and developer concerns

Proposal momentum

• Community is actively shipping high‑quality XLS ideas (e.g., Teku’s DEX-focused proposals). More proposals are welcomed.

Noteworthy amendments

• Batch: Aggregate multiple actions atomically; supports complex trades involving multiple senders/receivers; brings parity with workflows common in smart‑contract ecosystems.
• Token Escrow: A long‑desired feature to simplify project operations and user experiences.
• Permissioned domains/permission delegation/permissioned DEX: Enablers for more complex enterprise or controlled environments (not consumer-facing basics).
• MPT (Multipurpose Tokens):
  • A cleaner, unified representation of value with arbitrary metadata, freeze/fee logic, and compatibility with existing transactors. Avoids rounding issues and reduces storage/bloat compared to trustlines.
  • Could subsume roles of trustlines (IOUs) and XLS‑20 NFTs for many use cases, simplifying developer experience and data models. Legacy will still exist; migration must respect history and dependent tooling.

Cautionary notes (Wietse)

• Pace vs. safety: Core changes are outpacing builders’ ability to implement, increasing complexity and risk. Last‑minute security findings have occurred; rigorous testing is essential.
• Core bloat: The larger the codebase and native feature set, the harder future additions become. Be judicious about pushing features into protocol vs. building at the edges.

Cloudflare “Net Dollars,” AI monetization, and enterprise “stablecoins”

What Cloudflare appears to be doing

• Launching “Net Dollars,” positioned as programmable money for content monetization, API‑based settlement, and brokering AI training access/payments between publishers and AI consumers.
• Minimal (or no) mention of “blockchain/web3” across their materials—likely strategic to avoid the negative connotation many mainstream devs have toward “crypto/NFTs.”

Market implications

• Terminology shift: “Stablecoin” is becoming synonymous with platform balances/payment licenses—potentially backed by traditional databases, not public chains.
• Gatekeeping vectors: Large infra players can steer model training via access toggles and monetization (e.g., Cloudflare “AI scrape” controls), influencing which data LLMs train on.
• Advertising model evolution: AI answers with profiling/paid prioritization reshapes how advertisers pay publishers and how users might be rewarded.

Crypto’s role and opportunities

• Cherry‑picking risk: Enterprises may adopt crypto’s language and regulator openness while skipping decentralization entirely.
• Interoperability opportunity: If many walled‑garden “dollars” emerge (e.g., Cloudflare, GitHub, Apple), routing value between platforms becomes a premier use case for public chains. XRPL’s IOU model and escrow are well‑suited to act as connective tissue.
• Top‑down vs grassroots: Enterprise adoption is likely to outpace pure grassroots, with MiCA/other regimes tightening individual self‑custody flows while corporate rails expand.

Self‑custody reality check and best practices

Wietse’s candid outlook

• For the majority, self‑custody may be less viable over 5–10 years due to regulatory tightening, friction, bank scrutiny, and on/off‑ramp burdens.
• Personal experience: Significant time spent on AML/KYC documentation; warnings from banks; even account closures due to perceived crypto risk.
• Practical response: Some exposure kept via a bank’s integrated crypto offering to simplify audit trails, despite being a leading self‑custody wallet builder.

The option still matters

• Decentralization is about being able to do something; self‑custody must remain feasible for those who need or prefer it.

Best practices

• Hot/cold split (Katy Perry model):
  • Hot wallet for everyday use and acceptable risk; cold wallet for longer‑term holdings.
  • Use different wallets for different apps; maintain low reserves where possible; practice key hygiene.
• Hardware choices:
  • Tangem (no seed phrase exposure; but ensure backup cards and secure storage; physical loss without backup is catastrophic).
  • Ledger and similar: Effective but remember physical-access attacks exist; physical security matters.
• Don’t store seed phrase photos in cloud drives; credential compromises plus OCR scanning are common attack vectors.
• Physical distance is a protective friction: Needing to retrieve a hardware device can interrupt scam flows.

Yield on XRP: risks and safer architectures

• Current third‑party yield schemes (e.g., Doppler, mXRP) are not risk‑free:
  • You lend XRP to an entity; it re‑deploys into diversified strategies (DeFi/VC/etc.), often vaguely described; user funds may not be segregated; this resembles unsecured loans with counterparty risk.
  • Teams may be genuine and well‑intentioned, but users must understand the risk profile.
• Protocol‑level overcollateralized designs (e.g., Flare’s architecture for trust‑minimized cross‑chain assets and overcollateralized positions) are structurally safer:
  • Recovery paths are enforced by protocol/state, not dependent on a single corporate entity’s solvency.

XApps: portability and integration

• XApps are web apps integrated inside wallets.
• To test an XApp in another wallet:
  • Contact the XApp developer; most require minimal changes (passing account context; transaction delivery/signing flows).
  • Wallets load the web app and pipe in account/session details and signing mechanisms.

XRPL infrastructure and full-history realities

• Full‑history servers at scale are extremely costly:
  • Storage expansion is not “just add drives”—latency, RAID/controller addressing limits, server generations, redundancy, and ready‑standby capacity all multiply costs.
  • Operators must provision for peak‑surge scenarios while idling; power and bandwidth consumption are continual.
• Capacity snapshot:
  • Prior stress at ~30k concurrent active users; current comfort around ~50k across platforms.
  • Scaling to ~100k could require multi‑million dollar investments over multi‑year colocation/power/bandwidth contracts.
• Practical proposal:
  • Truncate public full history to ~5–7 years (aligning with common regulatory retention), and maintain full history behind contracts/paid tiers (research allowances plus auditor-grade access). This could reduce total infra cost while improving the likelihood of sustainable full history availability.

Scam epidemic and support policies

• Impersonation scams on social platforms (X/Telegram) are rampant; reporting is insufficient.
• Recommendation: Offer “in‑app support only.” Do not serve support on socials; redirect all users to in‑app channels.
• XRPL Labs built an in‑house ticketing system (“Monk Desk”) after vendor price escalations and data portability issues; it integrates with Xaman’s push and can be shared with projects that want secure in‑app support.
• Platforms bear responsibility: Social networks need better impersonation detection/mitigation.

Community notes

• Reddit post: A 20‑year‑old proudly DCA’ing to 1,300 XRP sparked debate; onboarding excitement met with critical pushback. Mixed signals reflect bear‑market sentiment and caution culture.
• “Guardian” (Red Guardian) adopted a darker critique stance in threads; host seeks constructive dialogue.
• Sentiment: “Van Hayson” mentioned as feeling re‑energized; broader mood described as low.

Recommendations and action items

• For marketplaces:
  • Formalize editorial policies on likeness/name usage; pre‑establish takedown processes; maintain clear P2P facilitation while de‑risking display.
  • Communicate clearly when delisting is “UI only”—on‑ledger assets remain tradable.
• For builders:
  • Avoid real‑person names/likenesses; educate communities on right‑of‑publicity.
  • Prefer protocol‑level solutions (batch, escrow, MPT) where they reduce complexity. Test rigorously; be cautious about core bloat.
  • Explore XRPL as interop fabric for enterprise “platform dollars.”
  • Implement in‑app support only; adopt secure ticketing; train users to distrust social DMs.
• For infra operators:
  • Consider pragmatic full‑history truncation with contractual full-history access for auditors/research; monitor request patterns and plan capacity ahead of surges.
• For users:
  • Self‑custody with discipline: hot/cold split, hardware backups, no seed photos in clouds, physical security, time as a safeguard against scams.
  • Treat yield offers as unsecured loans unless protocol‑secured; understand recovery and collateral paths.
  • When in doubt, use in‑app support; never share keys/seed phrases with anyone.