Decentralized protocols require incentivization to be economically sustainable.
While some aspects of a P2P network can successfully operate in a tit-for-tat model,
we believe that nodes that run the protocol in good faith need to be tangibly rewarded.
Motivating servers to expand resources on handling clients' requests allows us to scale the network beyond its initial altruism-based phase.
Incentivization is not necessarily limited to monetary rewards.
Reputation may also play a role.
For Waku request-response (i.e., client-server) protocols, we envision a combination of monetary and reputation-based incentivization.
See a [write-up on incentivization](https://github.com/waku-org/research/blob/1e3ed6a5cc47e6d1e7cb99271ddef9bf38429518/docs/incentivization.md) for our high-level reasoning on the topic.
The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “NOT RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in[RFC 2119](https://www.ietf.org/rfc/rfc2119.txt).
- Proof of payment: for paid non-authenticated requests. A proof of payment, in turn, may also take different forms, such as a transaction hash or a ZK-proof. In order to interpret a proof of payment, the server needs information about its type.
- Proof of membership: for services for a predefined group of users. An example use case: an application developer pays in bulk for their users' requests. A client then prove that they belong to the user set of that application. Rate limiting in Waku RLN Relay is based on a similar concept.
- Service credential: a proof of membership in a set of clients who have prepaid for the service (which may be considered a special case of proof of membership).
- if the proof is valid, the server SHOULD send back the response that the client has requested.
Note that the protocol does not ensure atomicity.
It is technically possible for a server to fail to respond to an eligible request (in violation of the protocol).
Addressing this issue is left for future work.
## Wire Format Specification / Syntax
A client includes an `EligibilityProof` in its request.
A server includes an `EligibilityStatus` in its response.
```protobuf
syntax = "proto3";
message EligibilityProof {
optional bytes proof_of_payment = 1; // e.g., a txid
// may be extended with other eligibility proof types, such as:
//optional bytes proof_of_membership = 2; // e.g., an RLN proof
}
message EligibilityStatus {
optional uint32 status_code = 1;
optional string status_desc = 2;
}
```
We include the `other_eligibility_proof` field in `EligibilityProof` to reflect other types of eligibility proofs that could be added to the protocol later.
Lightpush is one of Waku's request-response protocols.
A Lightpush client sends a request to the server containing the message to be published to the Waku network on the client's behalf.
A Lightpush server responds to indicate whether the client's message was successfully published.
See [19/WAKU2-LIGHTPUSH](https://github.com/vacp2p/rfc-index/blob/main/waku/standards/core/19/lightpush.md) for the definitions of `PushRequest` and `PushResponse`.
