From 30c19850e57f3373c60a64901611900b9c3f5a5b Mon Sep 17 00:00:00 2001 From: Sergei Tikhomirov Date: Wed, 30 Oct 2024 14:23:18 +0100 Subject: [PATCH] Update standards/core/incentivization.md Co-authored-by: Hanno Cornelius <68783915+jm-clius@users.noreply.github.com> --- standards/core/incentivization.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/standards/core/incentivization.md b/standards/core/incentivization.md index 96317db..55fd8dc 100644 --- a/standards/core/incentivization.md +++ b/standards/core/incentivization.md @@ -41,7 +41,7 @@ In that case, a client MUST provide a valid eligibility proof as part of its req Forms of eligibility proofs include: - 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 a similar concept. +- 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). Upon a receiving a request: