Sign in Subscribe

First Steps Toward Incentivising Waku

Sergei Tikhomirov

• 4 min read
First Steps Toward Incentivising Waku

Waku, at its core, provides P2P routing infrastructure. Additional services can be provided on top of Waku, for example, to help resource-constrained devices use the network. Currently, services are provided voluntarily on a best-effort basis. To ensure sustainability of a service-enhanced routing network, it is crucial to incentivise service nodes.

This post explains why incentivisation is essential and outlines a new proof of concept (PoC) that demonstrates an incentivised Lightpush service. We also share early thoughts on how this work could evolve into a decentralised Waku Service Marketplace.

Waku and Its Light Protocols

Waku is a suite of peer-to-peer routing protocols for privacy-preserving communication. Built upon its core Relay protocol for pub-sub communication, Waku offers "value-added" service protocols related to messaging, such as Lightpush, Store, and Filter. These services are particularly beneficial for edge nodes with resource constraints, enabling them to participate in the network without acting as full Relay participants.

These light protocols are designed for resource-constrained environments: mobile devices, browsers, or other clients that cannot maintain persistent connections or semi-permanent bandwidth usage. Instead of directly participating in the Relay mesh, edge nodes rely on service nodes to act on their behalf.

Lightpush, for example, allows an edge node to publish a message via a service node. Store lets an edge node retrieve past messages. Filter enables receiving a subset of messages transmitted within a shard. In all cases, the heavy lifting is done by the service node.

While this design increases accessibility, it also has significant drawbacks. First, it is unsustainable: service nodes provide resources without compensation. Second, risks of centralisation and censorship grow. Finally, Waku-based apps are burdened with self-hosting infrastructure, diverting developers from core tasks.

Why Incentivise Lightpush First?

In Lightpush, an edge node wants to publish a message; the service node does so using its own connectivity and RLN credentials. RLN (Rate-Limiting Nullifier) is a zero-knowledge-based rate-limiting mechanism that prevents spam. It allows publishers to anonymously prove they are allowed to emit messages at a given rate. Membership is scarce and requires registration with a smart contract. In this model, we enable edge nodes to publish without RLN membership—instead, they use service nodes that have one.

This makes Lightpush a natural starting point for incentivisation. A client can pay a service node for the act of publishing a message, and the service node spends one unit of its RLN allowance to fulfil the request. The economic relationship is direct and easily testable. What makes Lightpush especially well suited for a PoC is the fact that a message is either published immediately or fails to publish, which is easy to verify. In contrast, Store and Filter are more akin to subscription models, where an edge node expects a service to be continuously provided throughout a given time period.

What the PoC Implements

Our proof of concept introduces two key mechanisms: eligibility and reputation.

Eligibility checks are performed by the service node. When it receives a Lightpush request, it verifies whether the request includes a valid proof of payment. This proof is a transaction hash pointing to a payment on the Linea Sepolia testnet. The service node considers a request eligible only if the payment:

  • is in native ETH;
  • transfers the exact expected amount;
  • is sent to the correct service address;
  • has not been used before.

The PoC assumes that the edge node learns the service node’s on-chain address and expected payment amount off-band.

In the PoC, each request requires its own payment. This model is simple and easy to reason about, but not scalable. In future iterations, we plan to support bulk pre-payments or credit-based systems, allowing edge nodes to pay once and send many requests over time.

Reputation is tracked by the edge node. It records whether past requests to a given service node were fulfilled successfully. If a service node fails to respond or errors out, it is marked as having a bad reputation. Future requests avoid that node. If a previously neutral or unknown node successfully handles a request, its reputation is upgraded to good. This creates a lightweight feedback loop to favour reliable providers.

All of this is implemented in a local test setup involving four nwaku nodes: Alice (edge), Bob and Charlie (service), and Dave (Relay). The PoC includes full configuration files, build instructions, and test cases for eligible and ineligible requests. You can try it yourself by following the PoC setup guide.

Toward a Waku Service Marketplace

This PoC is an early but concrete step toward a decentralised Waku Service Marketplace. It shows that edge nodes can attach proof of payment in their requests and keep track of service quality differences. From here, many directions open up:

  • Support for dynamic pricing by service nodes;
  • Discovery mechanisms for edge nodes to compare available providers;
  • Expanded payment models: subscriptions, pre-paid balances, metered billing;
  • Shared or decentralised reputation systems;
  • Integration of Store and Filter into the same incentive framework.

While this is still in the research phase, we believe this model can generalise. As described in the Waku Service Marketplace proposal, the longer-term vision is for Waku protocols to operate as part of a decentralised marketplace for privacy-preserving services. In the even broader future, this could evolve into a generalised service marketplace spanning domains beyond messaging.

Get Involved

We're at the beginning of this journey and your ideas are welcome. You may:

We’re looking forward to hearing from developers, node operators, and dApp builders interested in the future of decentralised messaging infrastructure.