Service Incentivisation MVP

Waku
, ,
1

Background

Service incentivisation over Waku is a topic that has been discussed and investigated more or less since the founding of Waku. Most recently we’ve published a speculative roadmap towards incentivisation focusing on Lightpush protocol. This resulted in a working proof of concept that shows basic payment for RLNaaS using Lightpush.

The MVP described here builds upon this PoC. It introduces a minimal but practically feasible system for incentivising service provision, managing payments, and tracking on-chain reputation. The goal is to demonstrate a working, end-to-end flow for incentivised services on Waku, that is usable in a testnet setting. This should be a significant step towards a robust service incentivisation layer in Waku.

MVP Scope

I suggest that we develop a protocol consisting of (only) three discrete, but integrated subprotocols:

  1. Payment protocol: a privacy-preserving payment protocol for clients to pay for Waku services without requiring an on-chain transaction per service request.
  2. On-chain reputation protocol: a transparent, minimal on-chain footprint to help clients identify reputable service providers based on observable behaviour (e.g., deposits, uptime, longevity)
  3. Progressive trust protocol: protocol by which a client-service relationship can bootstrap from little (or zero) trust to a trusted relationship based on repeated good service provision and on-chain reputation.

What is out of scope?

  • Service discovery is assumed to happen out of band. Clients “know” which service providers nominally provide a service interesting to them.
  • Price negotiation for specific services is also assumed to happen out of band. In other words, we assume a client “knows” how much a service costs before the first payment.

MVP Components

1. Payment protocol

Purpose

The payment protocol defines how clients pay service providers in a way that is at least moderately scalable, unlinkable, and resistant to abuse. It ensures that service requests are paid for without requiring an on-chain transaction per request or linking the client’s identity to their wallet.

Requirements

  1. No need for an on-chain transaction per service request
  2. No direct link between Waku client identity and a specific wallet
  3. Mechanism to prevent, detect or discourage double-spending

Possible implementation notes

  • Service Credential-based Payments: Clients deposit funds on-chain and receive a batch of unlinkable, single-use service tokens (similar to other note-redeemable payment systems).
    • Each token has a nullifier associated with leaf in on-chain Merkle tree, preventing double-spending (at least of redeemed tokens).
    • Tokens are redeemed off-chain by submitting them to the service provider, who can redeem in batch
    • Tokens can be of equal denominations to simplify anonymity and validation.
    • In order to prevent abuse or frontrunning, we may have to make the token/notes redeemable only by a target wallet, which makes this (somewhat?) similar to a payment channel.
    • Double spending remains an issue before batch redemption, so mechanism to discourage this will still be required.
  • Alternatives: Probabilistic micropayments, but these are possibly too complex or under-researched for this MVP phase.

2. On-Chain reputation protocol

Purpose

The on-chain reputation protocol provides a public, verifiable signal about a service provider’s trustworthiness. It is not a reputation score in the traditional sense (e.g., attestations or reviews), but rather a set of observable economic behaviors that clients can use to infer a basic trust level.

Requirements

  • Clients must be able to query public, on-chain data to form a basic trust metric for service providers
  • Reputation must be derived from behaviors that are costly to fake or incentivise honest participation

Possible implementation notes

  • Provider Deposit: Service providers must publicly commit funds (collateral deposit or stake) in a smart contract as a signal of intent. This deposit is visible and timestamped on-chain.
    • Opportunity cost of keeping funds locked should be meaningful.
    • Stake is not slashed in MVP, but not withdrawing the funds is an implicit cost.
  • Clients must be able to verify that a provider has deposited funds and not recently withdrawn.
  • Trust/Reputation score can initially just be a combination of:
    • length of time provider’s stake has remained untouched
    • total number of service tokens redeemed
  • This informs the initial trust metric a client assigns to a service provider before using it for the first time. It can also be used to continuously revise the trust metric for a specific service provider, augmenting the local reputation (see next protocol).

3. Progressive trust protocol

Purpose

This protocol governs the initial interaction and trust evolution between a client and an unknown service provider. It assumes a hostile environment where trust must be earned incrementally, using the signals provided by the on-chain reputation protocol and service quality assessments after each interaction.

Requirements

  • Clients should start with minimal trust in a service provider and only increase that trust based on successful interactions.
  • Initial interactions should have limited financial exposure to the client (e.g., low-value payments).
  • Service providers must be able to advertise their staking/payment address and credentials.
  • Clients must be able to verify the provider’s public address, match it against on-chain reputation signals, and decide on risk thresholds (see “On-chain reputation protocol”).
  • Clients must evaluate service quality locally after each interaction and adjust local reputation scores accordingly. Bad service providers should not be used again.

Possible implementation notes

  • I imagine we can use Metadata protocol for the service provider to provide some proof-of-delegation and its staking/payment address to potential clients. It’s possible that pricing and other service-related information be included in the Metadata exchange.
  • The first payment from a client to an untrusted service provider should be small enough that it’s an acceptable risk to lose this payment.

Next steps

I propose that we treat the three components and their associated requirements outlined above as the definition of our MVP. The immediate action is to add or remove from this definition to gain consensus on an MVP definition.

The first concrete step after MVP agreement is to design a minimal protocol and specification that:

  • Meets the stated requirements, even if imperfectly;
  • Clearly documents assumptions, tradeoffs, and known limitations;
  • Is practically implementable within the MVP scope.

The desired output is a single specification document that defines the overall incentivisation protocol.

4 Likes
2

Note that, although, I have jotted down some thoughts on implementation, the important thing is to agree on the requirements first. We likely need more research to design an implementation for each subprotocol.

1 Like
3

I will argue that 2 and 3 are unnecessary.

We can keep reputation informal by just talking to users and service providers then make recommendations ourselves.

Nascent tech. attracts nerds, moderation, reputation or abuse prevention is not needed at first. Once we start scaling it will be important then.

With micropayment in place, risk is so small that trying new providers is not a big deal even if some could be scammers.

Building decentralized and private payment system is plenty complicated already.

The least usage of blockchains the better, we’re trying to be decentralized, private and with good UX.

P.S.
Also incrementalism = :skull_and_crossbones:

4

Thanks for detailing out the requirments.

I kind of agree with @SionoiS on 2 things

  1. The least usage of blockchains the better, blockchains come with their own overhead and complexity that may not be needed.
  2. Items 2 and 3 are not necessary for an MVP, we could just start with local reputation that was already built as part of POC.

We could start with a fixed price per service-quantity at network level (e.g store query for X msgs has Y cost or store for duration T has Y1 cost) to make it simple and not have out of band negotiation. Price negotiation can be taken up at a later stage.

5

Thanks for the post! :raised_hands:

  1. I like the idea of requiring service providers to hold a deposit. It can act as a guarantee for consumers, covering potential damages.

  2. How is trust measured?

  3. Off-topic: The “Metadata” protocol feels too general-purpose. At some point, we may need to narrow its scope to ensure clear responsibilities and prevent it from growing unchecked.

6

I assume you see the proposal as offering too little of an increment on current PoC? Can you expand on your thoughts?

Especially as at the same time, you suggest that the MVP can be reduced in scope (and hence a smaller increment :upside_down_face: )

Good stuff. Are we still thinking Light Push service? Or do we want to start expanding to store?

Is that the right direction building on the PoC? I haven’t yet played with the PoC, I guess my question is whether we should furthering the integration of the PoC (js-waku, store, etc) to continue dogfooding.

What did we learn from the PoC so far?

1 Like
7

Are we still thinking Light Push service? Or do we want to start expanding to store?

Undecided for now, but I think the MVP will be easier to demonstrate with Store than Lightpush. This also matches long-term roadmap a bit better, I’d say. I don’t necessarily see RLNaaS as a major part of Waku in the future.

whether we should furthering the integration of the PoC (js-waku, store, etc) to continue dogfooding.

I don’t think there’s much point. The PoC demonstrates the different moving parts, but what is proposed here is substantially different enough that trying to maintain the PoC or expand it will not have much long-term benefit.

What did we learn from the PoC so far?

I think the PoC mostly allowed some things that we expected to be confirmed and demonstrated (e.g. the cost of frequent chain interactions, different functions involved with incentivisation, etc.). I think most of its benefit however is not so much in protocol exploration as in familiarising ourselves with the different technologies involved, web3 library, the nwaku codebase, etc.

8

Thanks for the detailed proposal.

I’d like to suggest that we shift focus slightly before diving deeper into protocol design.

An MVP, unlike a PoC, needs to prove not just technical viability but also market viability. Technical feasibility seems relatively clear and was partially demonstrated by the PoC. The missing piece, in my view, is economic viability—who are we building this for, what value does it deliver?

Right now, the plan reads as too abstract. Shall we start with identifying potential consumers of such a marketplace? Let’s talk to teams like Status, Railgun, or The Graph. What infrastructure are they running themselves today that they’d rather outsource through a decentralized marketplace? What pain points do they have?

The way I see the value prop is two-sided (as one would expect for a marketplace):

  • For app developers: “no-infra,” simple integration, focus on building.
  • For service providers: a revenue stream.

Both aspects involve trade-offs, and we should have a clear vision on what we’re willing to sacrifice.

Take reputation as an example. I’m skeptical we can build a robust, permissionless, ungameable reputation system in the MVP phase. If reputation can be reset cheaply by creating a new identity, then capital lock-up must be meaningful—but not so high that it prices out most participants. Either we tolerate some fraud (low stakes), or we require high deposits (limiting us to high-value use cases, which often lean centralized). The choice depends on what use cases we’re aiming for.

Or, consider the financial aspect. If we require deposit lock-ups, then services must be valuable enough to justify locked capital. If a service provider can get 5–10% APY passively (in TradFi or DeFi), what kind of services justify forgoing that? I suspect the use cases that justify such capital costs will be financial or security-critical. Could we convince a DeFi protocol that avoiding centralized dependencies (e.g. WalletConnect) is worth it in terms of capital costs and switching costs to a decentralized marketplace instead?

This is a multi-dimensional design space. To navigate it, we need:

  • A clearer picture of our target users and their needs.
  • A sense of what trade-offs are acceptable and how strict our security model is.
  • And ideally, some research on similar efforts—what’s been tried, what worked, what didn’t.

Let’s validate user demand before finalizing the technical path.

2 Likes
9

I’m not saying we are guilty, it’s just a general warning to not fall into this trap.

Building things incrementally is not bad per say BUT increment for increment sake is wrong.

10

Answering

The missing piece, in my view, is economic viability—who are we building this for, what value does it deliver?

We are building this for Status, to remove the risk of running own infrastructure.
It deliver the ability for a project like Status to only be a software provider, not an infrastructure one.

Shall we start with identifying potential consumers of such a marketplace?

Currently, Status is.

If a service provider can get 5–10% APY passively (in TradFi or DeFi), what kind of services justify forgoing that?

Running some modelling sounds good to understand what kind of numbers we are looking for a service provider, based on usage, numbers of users, etc.

Could we convince a DeFi protocol that avoiding centralized dependencies (e.g. WalletConnect) is worth it in terms of capital costs and switching costs to a decentralized marketplace instead?

We are not at a stage to try to convince projects that are contented with central infra to move.
The USP is no-infra. Logos/Status is not satisfied with centralized infra. It is our mandate to move them away from it.

A clearer picture of our target users and their needs.

Status app, application built with Waku Chat SDK need to be able to run without hosting any infra.

A sense of what trade-offs are acceptable and how strict our security model is.

do you have a A/B choice you can offer? you cannot expect users to tell you what trade-off they can accept if you don’t know the trade-offs yourselfs.
What are trade-offs are you explicitly referring to?

And ideally, some research on similar efforts—what’s been tried, what worked, what didn’t.

I thought @SionoiS did that ?

2 Likes
11

Yes, I have a optimist vision that we can build a SDK that rivals with Web2 competitors thanks to the no-infra part.

However, this is not the core objective.

A world where freedom of expression and privacy are guaranteed for anybody, anywhere.

Build decentralised protocols that enable private communication and interactions.

This cannot be achieved if developer have to run their own centralized infra.

This the aim, remove the need of centralized infra. This is our assumption and what Status needs.

Have a MVP that demonstrate that.

Then we can iterate towards production by working on trade-offs and economic costs etc.

1 Like
12

I’ve been thinking that to be attractive to potential service providers. We have to fulfill some criteria.

As @sergei-tikhomirov pointed out economic viability is key. This category would include, micro-payment scheme, tokenomics, gasless TXs, etc…

Another I can think of is liability. Without privacy, the provider could be identified and prosecuted for it’s users actions (As we’ve seen recently…)

The third one would be UX, how easy is it to start providing services. Good engineering is paramount here.

13

Thanks everyone for good feedback and valid points!

I think we have a rough definition of the problem we’re trying to solve. I’d propose that we shift our focus back again to Store protocol, where clients have an interest to query for (mostly recent) historical messages in order to allow Status to have a no-infra deployment. This solves incentivisation for a particular service, but hopefully in terms that can be carried over to other service protocols as well.

Good points re economic viability. It’s a bit of a chicken-egg situation though, as we have to consider the costs of a specific protocol to understand what level of demand and what price points make that protocol profitable. Note that we’re likely to see this first rolled out as a sponsored service protocol. Depending on payment mechanism (e.g. with tokens), Status will likely distribute the necessary tokens to clients to pay decentralised service providers. The question of economic viability then becomes: for this protocol to make tokenomic sense, the payment-per-request should be at least x.

For me the next step is to conceive of the smallest “complete system” that can answer to the basic requirements. I agree that the payment protocol is likely the most complex part of the system and should be prioritised. For everything else we can make simplifying assumptions. However, I would argue that the question of bootstrapping a paying relationship between a service provider and a client cannot be completely left out. We could say that somehow finding a service node, knowing if it’s trustworthy, discovering its payment address, etc. all happens “out of band”, but then the payment mechanism itself becomes rather obsolete too (just pay them out of band). I’m also mindful of falling into an incrementalism that cannot in theory conceive of the larger system that it’s part of. Nevertheless, the idea of the MVP definition is not that we start with all three subprotocols simultaneously, but that we situate each part we develop into a broader system, being clear about tradeoffs and assumptions at each stage.

I would suggest our first deliverable to be a raw spec that defines a viable payment protocol.

1 Like
14

Speaking of Store, would there be any benefit to separating the search part to the message retrieval WRT incentivisation?

15

Not quite sure I understand - do you mean separately incentivising the DB querying part from the message provisioning to the client?

The way I would see this is that we’re abstracting the problem to:
→ request paid service
← respond to paid service

Based on how this develops, it may indeed be that the DB indexing becomes a separate paid service with its own market, but I would see Store in its simplest form as query-in-request, results-in-response for now.

16

We had a meeting. I’ll summarize the discussion here.

Economic viability

While a good thing, we already know that Status will be using it, either by subsidy to providers or users. We also acknowledge that intrinsic motivation also play a role. Members of a community will be motivated to provide services. Last point is that it’s difficult to estimate.

Payment system

@shash256 will write his proposal for a system on this forum. :rocket:

Trust

We could start with unofficial providers selected by us.

Roadmap

We agree that we need a good overview of the whole system to not incrementally step in the wrong direction. We have to design a system that can be upgraded later so that we don’t have to scrap parts of the system.

We will start with Store protocol i13N.
We will start with a payment system.

Did I miss anything?

2 Likes
17

No-infra as a USP sounds great and I agree with it. Still, “no-infra” (like “the cloud”) is someone else’s computer. The risk I see is if the marketplace struggles to attract service providers, we will end up with a de-facto centralized setup, just with extra complexity. This is why economic viability feels important to me.

At least two examples come to mind. Assume Status users sync messages via Store using the marketplace:

  • Reliability. Is it acceptable if 10% of queries to the marketplace fail? 1%? 0.1%? Should there be a centralized backup in case of failure? Should users be refunded for failed requests?
  • Privacy. Is it acceptable if a serice provider can reliably link a user’s request to their Status ID? To their on-chain address? Same questions regarding message content vs metadata-only. Same questions assuming X% of service providers collude.

My meta-question is how we as developers understand which trade-offs (ones listed above and likely others) are acceptable. I agree we cannot ask users directly - shall we ask Status as the main and, for now, only customer?

18

You are listing technical solutions, which would fit in the “technical viability” section. Which is what a PoC/MVP should answer.

“economic viability” is going down

the path of doing the maths:

E.g for a node operator

  • price of VPS
  • model usage per DAU
  • model payment per DAU
  • do some maths

Or for a project that subsidise users:

  • cost per DAU
  • comparable of cost of self-hosting
  • delta = cost of decentralization and censorship resistance.

Yes, I agree, we should do those. can be interesting to quickly do even with current solution. a quick ddoc sheet should help.

We can start compile of form of questions we need to answer from node operator point of view, and get preliminary answer from our own infra lead.

Totally agree. IMO this can be gradual. The UX can be rough as we dogfood internally, then we need to iron it out before external dogfooding.

I agree these are important questions. But they cannot be answered in a vacuum. You have to have a picture of the whole system to answer those. What does “10%” mean? are we talking about queries to store node? If so, the UX impact may vary depending on various factor, such as usage of SDS.

Should users be refunded for failed requests?

My understanding was that it was simply not possible to enforce refunding due to the nature of Waku and the fact that we cannot prove to a global consensus that a provider “failed to provide”. Can you please clarify what you mean because this is at odd with the assumptions we’ve operating with in the domain of incentivization.

No

Maybe, ideally no but we could review do user validation to confirm. AFAIK, the proposed system will not allow linkability so that’s ideal.

I think that’s my point here, You are asking those questions in a vacuum, and hence they cannot be answered.

You have to come up with a technical solution that goes in the right direction, and then as you iterate on it, do you put those trade-off in front of the user: how much privacy is enough privacy so we can now focus on performance, etc.

Are there 2 different designs proposed and one of them links store requests with wallet address but the other not? if so, what area those designs and what are the other tradeoffs.

It is unrealistic to go ask a user and say “do you want a faster car?”. Faster than what? what are the compromises? are the cars exactly the same in every single other aspect?

Again, you need to start somewhere, and clarify the side-effect.
I can tell you right now: I want 100% anonymity and service reliability, even if 100% of the service providers collude. Can you do it? Most likely no. Which is why it’s best to start with a design and explore the limitations (technical validation), then review the costs from various PoV (economical validation), and present that to target user (user validation).

1 Like