This post is an extension to the idea of using Streams, which could be more suitable to the bandwidth based utility and just generally the nature of how Store queries work esp with SDS in-place. This idea was initially proposed in On‑Chain Payments for SI. I realized that the previous post majorly covers a survey of on-chain options and the idea of streams was not well-covered. This post also aims to describe how the system looks at the end of full implementation with privacy fully tackled.

Introduction

We propose to settle Waku service fees on a privacy-preserving chain (“privacy rail”) - e.g., Aztec-style zk rollup or Aleo-style L1 - using a time/bandwidth-metered Private Stream that pays providers periodically (e.g., every 30–600s), and which might be best suitable to the nature of Store queries.

• No per-request on-chain tx: requests/replies stay on Waku.
• Strong privacy: payer & provider identities and amounts are not visible on public chains; settlement happens inside the privacy rail.
• Low fees / high TPS: one settle() per epoch covers many requests; costs are amortized.
• Provider safety: bounded exposure via per_epoch_cap; cryptographic Delivery Receipts (DRs) (optional but recommended) ensure we “pay for delivered bytes,” not just elapsed time.
• No custodians / Payment Nodes: money moves user→provider directly on the privacy rail.

This is the most direct on-chain path that doesn’t compromise on privacy, fees, or scalability and fits Waku’s off-chain, message-based architecture. Concept of Streams are already used by some projects such as Superfluid and Sablier etc, but without the Privacy part.

RLN lets us fund a free tier (e.g., one small history page per epoch per RLN identity) so users need to only open a stream for larger queries which is well suitable to time or bandwidth-metered streams. RLN-powered free tier takes care of occasional missing message queries with SDS while large history pulls are handled by Streams. Free Tier abuse is curbed by (a) membership stake and (b) slashing if they exceed the per-epoch cap trying to farm free requests. This limited free tier usage concept (freemium) is similar to most cloud providers.

1) Goals & requirements

Functional

• Pay Waku Store nodes (and other services) per usage, with as low as sub-minute settlement (or higher if desired).
• No per-request on-chain requirement; must scale with message volume.

Privacy

• Hide payer identity, provider identity, and amounts from public observers.
• Avoid linkability between sessions; support stealth addresses per session.
• Keep Waku control-plane metadata minimal; no on-chain identifiers appear in Waku messages.

Cost & performance

• Fees much less than a cent per request; target one on-chain tx per epoch (e.g., 30–600s).