Waku

• Name: Waku
• URL: https://docs.waku.org/
• Category: decentralized messaging protocol / private transport infrastructure / spam-resistant peer-to-peer coordination layer
• Summary: Waku is best understood not as a blockchain, storage network, or simple chat app, but as a modular communication stack for private, censorship-resistant peer-to-peer messaging in resource-constrained environments. Its reusable mechanism is the separation of relay, spam-resistance, filtering, store-and-retrieve, and light-push functions into composable protocols that let applications trade anonymity, bandwidth, persistence, and latency against each other.
• What it does:
  • Provides a family of protocols for sending and receiving messages over libp2p-based peer-to-peer networks without requiring a blockchain execution layer
  • Uses Relay for pub/sub dissemination, RLN Relay for spam-resistant rate limiting, Filter for bandwidth-light subscriptions, Store for historical retrieval, and Light Push for short-lived client publishing
  • Supports mostly-offline, browser, and mobile devices by letting light nodes retrieve missed messages or rely on remote peers for dissemination
  • Exposes configurable node roles through nwaku, the Nim client used to run Waku nodes and select which protocols an operator supports
  • Serves as communication infrastructure for privacy-sensitive Web3 use cases such as chat, offchain coordination, multisig signature exchange, state channels, mempool / L2 coordination, and social-style data exchange
  • Maintains protocol research, specifications, and implementation repos that make the network legible as a transport layer rather than only an end-user application
• Key claims:
  • Waku’s own docs explicitly say it is not a blockchain and not a long-term storage network; the project is more useful analytically as a transport and coordination layer sitting between apps and more durable state systems
  • The core design move is modularity: applications choose among Relay, RLN Relay, Filter, Store, and Light Push depending on privacy, bandwidth, online-time, and delivery tradeoffs rather than inheriting one monolithic messaging model
  • RLN Relay is especially important because it makes spam resistance an explicit economic / membership layer instead of leaving anti-spam power entirely to centralized gateways or rate-limit heuristics
  • The protocol docs and research materials show that practical authority can migrate into content-topic conventions, RLN set management, relay/store node topology, and the light-node peers that resource-constrained clients depend on
  • Waku is a useful comparison class for decentralized event-streaming and wallet / coordination middleware because it focuses on ephemeral communication and retrieval, not canonical application state or durable archival storage
  • The current website surface redirects Waku branding into the broader Logos stack, where messaging appears as one module among blockchain, storage, and other components; that branding migration is analytically relevant because it suggests Waku’s communication layer is being repositioned as one composable subsystem inside a larger sovereignty / privacy stack
• Whitepaper: Waku has a formal paper, Waku: A Family of Modular P2P Protocols For Secure & Censorship-Resistant Communication, alongside official docs and implementation repos. The strongest source packet for this pass is ../whitepapers/waku-primary-sources-2026-05-09.md, and the paper PDF is saved as ../whitepapers/waku-modular-p2p-protocols-2022.pdf.
• Sources:
  • https://docs.waku.org/
  • https://docs.waku.org/learn/concepts/protocols
  • https://docs.waku.org/run-node/
  • https://github.com/waku-org
  • https://raw.githubusercontent.com/waku-org/research/master/README.md
  • https://raw.githubusercontent.com/waku-org/nwaku/master/README.md
  • https://arxiv.org/abs/2207.00038
  • https://arxiv.org/pdf/2207.00038.pdf
  • https://waku.org/

Internal linkages

• Keep this note on xmtp, nym, and hopr.

Control surface

• The leverage sits in relay and store-node topology, RLN membership or anti-spam policy, content-topic conventions, and the remote peers light clients end up trusting.

• Keep the note on modular transport and spam resistance, not on broad web3 messaging haze.

• Last reviewed: 2026-06-11 UTC