Wavlake primary sources — 2026-05-02

Project status in this pass

• No canonical standalone whitepaper or litepaper surfaced.
• The clearest current sources of truth were Wavlake’s official site, docs, developer API spec, and public GitHub repos.
• The combined materials show a broader creator-monetization and distribution stack than the consumer-facing music app alone suggests.

Primary-source snapshots

1) Homepage

• URL: https://wavlake.com/
• Key excerpt:
  • The homepage says “Stream Anywhere, Earn Everywhere” and describes a world where creators and listeners can freely transact in an open ecosystem.
  • It says Wavlake handles hosting and feed syndication, uses open standards for universal distribution, and provides a built-in wallet so creators can receive bitcoin directly from fans and withdraw it whenever they like.
  • This is the first signal that Wavlake is packaging creator operations and monetization infrastructure, not just music playback.

2) Wavlake docs / FAQ

• URL: https://docs.wavlake.com/
• Key excerpt:
  • The docs say Studio lets artists upload and share audio through Wavlake Player or other Podcasting 2.0 compatible applications.
  • They say Wavlake publishes a public RSS feed for every release and that those feeds adhere to the Podcasting 2.0 spec.
  • They also say boosts are bitcoin payments to creators, messages require a minimum boost, and Wavlake takes 10% from every track boost and message boost.

3) Developer API docs repo README

• URL: https://github.com/wavlake/developer-docs/blob/main/README.md
• Key excerpt:
  • The README describes the repo as “Wavlake Developer API Docs” and points to the hosted developer documentation.
  • This matters because it confirms Wavlake maintains a distinct developer-facing API surface beyond its consumer app.

4) Developer API spec

• URL: https://github.com/wavlake/developer-docs/blob/main/swagger.yaml
• Key excerpt:
  • The spec documents content search, rankings, and metadata endpoints for tracks, albums, artists, and playlists under /api/v1.
  • It also exposes an /lnurl endpoint that returns an LNURL pay request string for a piece of Wavlake content and says a required appId parameter credits the developer with fee splits.
  • That fee-split language is one of the clearest signals that Wavlake is offering reusable monetization rails to integrators, not just keeping payments inside its own app.

5) Monorepo README

• URL: https://github.com/wavlake/monorepo/blob/main/README.md
• Key excerpt:
  • The monorepo says Wavlake follows a “Nostr-first architecture” where user content and metadata are stored as Nostr events rather than centralized databases.
  • It specifies artist profiles as kind 30442 events and track/album metadata as kind 30440/30441 events.
  • It further says backend APIs should be limited to file uploads, analytics aggregation, and relay management, with centralized storage reserved mainly for large files and temporary data.

6) Web client debug harness

• URL: https://github.com/wavlake/web-client/blob/main/README.md
• Key excerpt:
  • The README describes a “Wavlake Paywall Debug Client” built to expose every step of the payment flow.
  • It explicitly lists Cashu wallet operations, content API requests, 402 → token → access, and playback from signed URLs.
  • This is useful evidence that Wavlake is experimenting with or operating machine-readable paid-content access flows in addition to open RSS distribution.

Working conclusion

Wavlake is best cataloged as creator-monetization and open-content infrastructure rather than as only a Lightning music player. The decisive evidence in this pass was the combination of creator hosting plus syndication, Podcasting 2.0 RSS distribution, public content metadata APIs, LNURL fee-split support for integrators, Nostr-first metadata architecture, and Cashu/402 paywall experiments. The main follow-up question for a later pass is how far the newer Nostr-first monorepo has replaced or supplemented the older hosted API and player surfaces in production.