Waku as a Decentralized Service Marketplace


The current core Waku protocols can roughly be divided into two groups:

  • Routing/discovery: RLN and Waku Relay, which are generally considered a unified protocol known as RLN Relay, are focused on privacy-preserving message propagation within a peer-to-peer network with built-in spam protection. Since a network mesh must be established as prerequisite for Relay, the suite of Waku discovery protocols can be seen as a necessary part of this group.
  • Service protocols: This is the set of protocols adding some value on top of the network to allow access to services generally considered useful within the decentralized communication domain. Currently, Waku service protocols are Store for message history and Lightpush/Filter for resource-restricted publishing/receiving. Peer-exchange allows for resource-restricted randomized peer discovery in the network. Service protocols may also be reliant on a discovery protocol for service discovery, but assumes the existence of an established Relay network as prerequisite for service provisioning.

What do we have?

All Waku services can be provided by individual node operators aimed at specific applications and statically configured (out of band) as the service provider by these applications.

Note that these operators may be incentivized out of band in contract with the service clients/application. It’s also a common model for applications to operate and configure their own service nodes for their own clients.

In addition, Waku and Status also provide service nodes as an altruistic service for third parties. These service nodes are publicly discoverable and available as a best-effort service to all applications, especially to help new adopters.

Where do we want to go?

We envision each Waku service protocol to become a general distributed capability in the network,
with any node operator in the network able to provide a Waku service publicly and permissionlessly.
These service providers should either actively advertise the set of services enabled
or participate in discovery such that service clients can find the services for their specific needs.

The qualitative difference with how services are currently provisioned, is that a service client should no longer need out-of-band trust and application-level configuration to “know” which specific operators/nodes provide a trusted service for its use case.
Instead, such a client could simply ask “the network” for services matching a specific description, using a variety of decentralized discovery techniques, and be returned with a set of suitable service providers matching its needs. The client application can then locally configure the trust, redundancy and reputation aspects to match its use case.

If this public service provisioning is coupled with service differentiation (such as different service pricing or global reputation for the service operators), this will facilitate creation of a decentralized service marketplace.

How are we building a decentralized service marketplace?

For such a decentralized service network to be practical, we need at least three high level capabilities in the network:

1. Decentralized service discovery

Discovering a Waku service provider for a very specific use case is like trying to find a needle in a haystack. The number of parameters/capabilities that node operators have to advertise may have a higher cardinality than current randomized decentralized discovery methods, such as discv5, can gracefully handle. The Waku Research team is investigating alternative approaches to service capability discovery that will allow for highly specialized service provisioning within a large p2p network. See this issue for detail on the work being done here. Some possible approaches include topic discovery in discv5, sub-DHTs and other methods of converging on suitable service nodes faster.

2. Distributed reputation mechanism

In order for service nodes to participate in a marketplace mechanism in a permissionless, trustless p2p environment, clients should be able to avoid nodes providing subpar service or behaving maliciously. This may require a global reputation mechanism to encourage better service provisioning and weed out bad actors.

3. Incentivization

While there is a clear incentivization vector for nodes commissioned out-of-band to provide specific services for specific applications, a general marketplace requires incentivization. Any node operator should be able to run a service node and be rewarded for doing so. For service incentivization to be practical, in the narrowest sense at least two elements are required, namely:

a) a mechanism to advertise/negotiate service prices
b) a (privacy-preserving) mechanism for trustless payments

In a wider sense, incentivization should also be integrated with decentralized discovery (see (1) above) and a distributed reputation mechanism (see (2) above) to function as a coherent marketplace: service clients should be able to discover a variety of service providers, compare pricing and reputation and select the nodes with the best price/reputation combination for the specific use case. Service nodes in turn should be incentivized by the market mechanism to provide quality services and refrain from malicious behavior (which would lower their reputation scores and therefore the price they can charge for their services).

Store Incentivization as starting point

The Waku Research team is currently building all three these elements for the use case of Store Protocol incentivization. A far more detailed breakdown of the incentivization problem for Store appears in this post. We consider Store a good starting point, as we have the clearest understanding of its use cases (thanks to close collaboration with Status and other flagship projects) and the cost of service provisioning (mainly storage costs) is already well-studied. A POC implementation is already well underway. Once we have a workable mechanism for service discovery, reputation and incentivization within Store, these elements will be generalized for other Waku service protocols, such as Lightpush and Filter.

Future work

1. Tokenomics Strategy and Sustainability

The service marketplace presents an opportunity to accrue value to the Waku ecosystem. However, how this can be captured in a Tokenomic strategy that ensure the future sustainability of Waku is yet to be defined.

2. Generalization of the Service Marketplace

The mechanisms and infrastructure described above are developed with Waku service protocols in mind. However, this can serve as a blueprint to enable any distributed or Web3 service to seamlessly integrate into the Waku network and offer generalized services to users. This would make the Waku network a universal platform for a wide range of decentralized services.


Thanks for the write up! Service Marketplaces are pretty powerful, so it sounds like something worth exploring heavily.

One thought I had while reading it si that the “How are we building…” is missing one part - what is written there seems to assume all communication happens over Waku and the actual protocol is request-response - i.e. I send a query and get a response from service provider. That is definitely the case Store, but might not fit other cases where “streaming” of some data or events is necessary to fulfill the “order”, or where there is a continuous presence/action/execution needed from the provider (think hosting my webapp or running my serverless code).

We cannot obviously boil the ocean at once, but just wanted to mention this here

1 Like

Good point! I agree.
I think for an integrated service marketplace in Waku, the service discovery and negotiation (whether req-resp, or more intricate) will in some way have to be “over Waku”, whether the actual service is req-resp, streaming or even backed by Waku at all. In this case, the “service negotiation” can be req-resp (or negotiation) via Waku, but should not necessarily imply that the service itself is.

Hello, I’m quite new to Logos and am trying to find my way here. I have worked in IT for over 20 years, but I am not a technician. My area of interest is a decentralized global marketplace and I have developed some concepts for that in the past that might be interesting for Logos. One of the questions I have is what kind of services are offered? If desired, I would be happy to contribute to this topic.

1 Like

Hey Hubert and welcome to Logos! Indeed, any insights you have will be very helpful and appreciated. :slight_smile:

First thing to note is that this idea is not very fleshed out, but a proposal to start thinking about the possible implications of viewing Waku as a decentralized service marketplace.

Our first services will just be the type of decentralized services that Waku is already providing as “value adds” on top of decentralized message routing, based on typical use case. These are:

  • historical message storage (for offline devices to resume sessions)
  • light client message publishing (i.e. publish to the network without fully participating, which requires some bandwidth/resources)
  • light client message retrieving (i.e. a service node filters and forwards only a small subset of messages matching your interest, also to save resources)

There are also some other messaging-related services that we can envision being provided by Waku. However, the point is that in order to provide the services listed above, we’re developing mechanisms and concepts that can be useful in an even more general sense for any decentralized service provider to advertise their services, establish communication with potential clients and receive payment for their services by just plugging into the Waku services framework.