This post is part of a series focusing on Waku's features. The goal is to help developers understand how they can leverage Waku for their own applications and projects.

Waku incentivisation and marketplace protocols are a work in progress, this article aims to lay out a vision, potential future, and solution; however, research may lead us to a different path. The content of this post should not be interpreted as promises or guarantees.

Waku’s goal is to provide protocols and software to enable private censorship-communication, first and foremost for chat applications, but generalised enough to be useful for other use cases. The integration of Waku in the Status chat application, RAILGUN private DeFi system, TheGraph indexer network, and Portrait micro-websites demonstrates that Waku is on track to become a generalised p2p communications network.

However, each project currently still needs to run a set of service nodes to support its users. There is a missing piece to making Waku decentralised for censorship-resistance: The Waku Service Marketplace.

End game: no infra, no devops

From a developer’s perspective, one can view Waku’s end game in the form of an SDK with a three-step developer experience:

1. Integrate Waku SDK
2. Set up Waku services funding, directly or via tokenomics
3. Release a true private, censorship-resistant, dapp

(1) is already possible today, and we are planning work in 2025 to make it even easier for developers to use Waku by implementing a simpler Messaging API for Golang, Rust, and JS (Browser), as well as providing out-of-the-box end-to-end reliability features.

(2) is driven by the need for decentralisation, removing the necessity for projects and developers to run nodes or any kind of infrastructure for Waku-based apps to work.

Such a model aligns with our principles. If projects or the Waku team have to run infrastructure to ensure the network works, then it is clearly not decentralised, and hence not censorship-resistant .

Beyond censorship-resistance, there is the matter of inclusivity and the challenges brought by running infrastructure in the web2 world: contract agreements and availability bound to a project’s jurisdiction, need for physical data centres for true sovereignty, and unfair pricing models by top players, as demonstrated by the rise of decentralised alternatives.

However, there is no such thing as a free lunch. Someone has to pay for Waku infrastructure. The question is, who and how?

Waku infrastructure

Let’s take a step back and understand exactly what Waku infrastructure needs to be funded to operate sustainably.

The tit-for-tat model applies to the backbone of the network, Waku Relay. Relay nodes are equal, and no additional incentivisation is necessary.

This is similar to Bitcoin’s and Ethereum’s p2p networks. Nodes that behave in a selfish manner by not uploading blocks and transactions are disconnected in favour of generous nodes. This means selfish nodes lose access to the network and, hence, are unable to use it. One cannot access the network to receive or send messages without fairly participating in Waku Relay, meaning forwarding and uploading messages they receive.

Unless they use Waku light protocols.

Relying solely on Waku Relay, and hence libp2p-gossipsub, is only possible when a node can be online most of the time and with adequate bandwidth access. We designed Waku so that this is feasible on desktop computers with household Internet access.

Such a model does not apply to browsers and mobile. A web app is often short-lived (running until the tab is closed), and mobile phones are limited by their data plan and battery usage. This means these edge nodes are inherently selfish: they only take without giving back. This is why light protocols have been developed, enabling an edge node to connect to service nodes and:

• Push messages to the relay network
• Filter messages from the relay network
• Retrieve historical messages that were previously transmitted on the relay network
• Find peers, sourced from the discv5 network

Pushing and filtering messages do consume bandwidth but are overall light services. We are performing benchmarks to better measure bandwidth usage in general.

Currently, Status Desktop runs by default in relay mode and provides filter and light push services to Status Mobile apps, making the live message routing part of the network decentralised.

However, the hungriest service to provide is Waku store. This service caches messages seen on the relay network to provide them to previously offline devices (both edge and relay nodes), meaning it needs to run a database. It is also useful for peer-to-peer reliability, allowing publishers to check if their messages propagated on the network.

While we are working towards decentralising store services, our expectation is that incentivisation will be required to ensure the secure scalability of applications using Waku and especially to ensure the appropriate availability of store services for all devices.

The case for an altruist model

To better illustrate the need for incentivisation, let’s review a model where we do not deploy it. After all, BitTorrent can be hailed as the first and most successful peer-to-peer protocol, and it does not have financial incentivisation.

BitTorrent as an example

In the BitTorrent protocol, the tit-for-tat model is embodied by the seed-leech ratio and choke algorithm.

However, this cannot be applied across all peers, as each file on the network will come with a set of peers, likely distinct from peers for other files. This makes it hard to have local reputation mechanism across the protocol because each peer may be only encountered once, when handling a specific file. This is why social reputation is used on private trackers for performance and reliability purposes.

The question is, can such an altruist model be applied to Waku?

In such a model, the concept of a BitTorrent file would translate to a Waku application, where nodes in the Waku network would focus their interest on a given application (this is not the exact topology we expect for Waku, but it simplifies the argument).

In this case, who would provide store services? Let’s assume that native applications (e.g. Status Desktop) do provide those services, encouraging users to share 50GB 'to the network'.

In this model, there needs to be a balance between consumers and providers, i.e., mobile and desktop users. If the footprint of mobile users grows too much, then there will not be enough desktop instances, a.k.a. store nodes, to reliably support those users.

One could apply a model similar to BitTorrent private trackers by tracking and reporting how much each individual user is contributing. However, this would introduce a centralised, or at best federated, element to the Waku network. Additionally, as Waku services are a consumer-provider relation (no global consensus), it would add further complexity to ensure those reports are not falsifiable.

Applications using Waku that have any browser or mobile users want to ensure the network has enough capacity to serve those users. Financial incentivisation becomes the only option.

It is worth studying RAILGUN’s usage of Waku, as they use relay in the browser rather than store. Read this post to learn more.

In summary, assuming a waku-network-per-application model, there will always be a need to ensure that the service node/edge node ratio remains adequate to ensure reliability. Financial incentivisation aims to fulfil this need in a way that allows for shared, and hence more private, Waku networks.

The Waku service marketplace

Incentivisation is enabled via the creation of a marketplace, The Waku Service Marketplace, where the actors are:

• Customers: Waku edge nodes, mobile and browser app users, as well as relay nodes such as desktop app users who experience connectivity interruptions (laptop turned off, etc.).
• Providers: Waku service nodes, especially store nodes, run by node operators, but also potentially desktop users sharing extra resources.

The Waku service marketplace would build on existing Waku protocols. It needs to be decentralised to provide the promised privacy and censorship-resistance properties. We do not want it to become another Infura or Pinata.

This means having peer capability discovery to enable finding service nodes with specific capabilities (e.g. store on a given shard) in a decentralised manner.

Once service nodes are discovered, we then need price discovery or negotiation so that customers and providers can agree on a price. This is then followed by a payment and proof of payment mechanism. Waku is not a consensus protocol, hence the service agreement and payment are kept between the consumer and the provider.

Finally, a local reputation system is needed to ensure a consumer does not get fooled twice. In the future, global reputation systems may be needed to ensure a provider is not able to fool every consumer once.

These are the building blocks to the Waku marketplace and our next goal post for incentivisation.

Let’s review potential user flows.

The sovereign user

A user paying directly for their usage of a dapp is a standard scenario in blockchain. While a project pays fees to deploy a smart contract, the users are the ones to further pay for the infrastructure (blockchain miners or validators) by paying for transactions with gas or transaction fees in the native blockchain token. This then goes to the miner and validators for securing and running the blockchain infrastructure.

In this scenario, we want to apply a similar model where a user pays service providers. While RNaaS may suggest a pay-per-message model, we are aware this does not scale and expect bulk payments to be the next step. The unit of service may also be different for protocols such as Waku store.

In this model, the user can bulk pay one or several providers, via on chain payments, to use an app that integrates Waku. This is an ideal model to deploy censorship-resistant, self-sustainable dapps.

The main drawback of this approach is the friction created for onboarding users. Users are accustomed to paying for onchain financial services, and this works well because it is related to finance and is similar in the user’s conscious to a card network payment fee.

However, in the social and chat messenger domain, everything is free because on web2 platforms, the user's data is the product. How do we reconcile those user expectations?

The subsidised user

The goal is to move away from the user-is-the-product model, due to its adverse effect on privacy (a euphemism). An alternative model to strive for is one where users generate revenue for applications via other means, such as onchain actions.

In this instance, applications may want to reduce onboarding friction so that the users can chat and play before committing to a financial transaction — similar to a “free-tier” model, where there is an option to upgrade to a “premium-tier”, however it might be presented.

Research is still in progress for this model. By enabling the sovereign user model first, we can deliver the initial building blocks for incentivisation that can then be expanded to enable subsidies.

Yet, we can envision a potential user flow for the subsidised user model:

1. The project reserves a budget for Waku by pushing funds to a marketplace smart contract
2. These funds can be allocated to new users via a service credentials system
3. Users then use those credentials to pay service providers to use Waku.

There are of course challenges to ensure that users do not run away with the money, as well as ensuring that the fund allocation does not get DoS’d by attackers exhausting all credentials.

While we do expect fragmentation of Waku networks, this should not lead to fragmentation of the marketplace. A unique Waku Service Marketplace is possible, and it can lead to higher competition by bringing all providers and consumers to the same market. This is a question of ensuring that signalling for resource needs (e.g. specific Waku network parameters) is done within an easily discoverable place (e.g. a smart contract).

Fully integrated model

Those two user models can be extended to an integrated tokenomics model. For example, in a card game where a user must first buy an NFT deck, Waku usage could be subsidised by the user acquiring an RLN membership and some service credentials as they perform the transaction to buy the deck of cards. This would allow them to play over Waku without performing further onchain transactions or even being aware that they paid for Waku in their initial transaction.

With such a model, the infrastructure costs can be embedded in the app’s tokenomics, enabling economical scalability and avoiding AWS or Vercel surprise bills.

RLNaaS as a guinea pig

RLN-as-a-Service (RLNaaS) enables users to publish on the Waku network without acquiring an RLN membership. Instead, they pay per message (or bulk thereof) to a service node, which itself owns an RLN membership to publish on Waku.

We are not convinced this is a sustainable model, as it weakens the DoS protection brought by RLN Relay, but we understand that the upfront requirements of an onchain payment for a RLN membership creates friction.

However, the current version of the RLN smart contract, which states that a membership must be acquired by locking assets, is a first step. Just as RLN memberships emerged from a desire to mitigate the collection of personally identifiable information (PII) like mobile numbers or email addresses, we expect new ways of attaining RLN memberships to emerge that mitigate the onboarding friction of locking assets, such as requiring proof of onchain activity or providing the ability to pay to onboard a friend.

RLNaaS is the simplest service to have, as it allows for an easy local reputation mechanism, especially when using peer-to-peer reliability. The intent is to develop and harden incentivisation protocols in this simpler context, and then to move to a more complex service such as the Waku store protocol.

Conclusion

While the tit-for-tat model in a peer-to-peer network has been proven by mature systems (BitTorrent, Bitcoin, and Ethereum), one needs to recognise that such a model has limitations and has led to centralisation points, especially when considering consumer devices.

By catering for mobile phones and browsers, Waku exacerbates the need for an incentivisation mechanism to ensure those devices can reliably use Waku. An adequate ratio of edge nodes and service nodes is necessary for reliability.

Research and development is a work in progress. While building a reliable and scalable network remains our highest priority, doing so without sustainability in mind would be a wasted effort.