enter incentivization milestone

FURPS/core/incentivization.md

@@ -7,12 +7,14 @@
 3. RLNaaS clients can use local reputation of RLNaaS providers to select what provider to use.
 4. Payments can be done by batch.
 5. Service node cannot take whole batch payment without providing the expected service.
+   (TODO: may be dropped, see [deliverable](/draft-roadmap/define_incentivization_for_rlnaas.md#-privacy-preserving-payment-streaming-f5-u3-s1-research) )
 
 ## Usability
 
 1. A consumer node can pay a service node for RLNaaS.
 2. A consumer node can select an RLNaaS provider based on their price and local reputation.
 3. A user can pay a service provider without revealing their wallet address.
+   (TODO: may be dropped, see [deliverable](/draft-roadmap/define_incentivization_for_rlnaas.md#-privacy-preserving-payment-streaming-f5-u3-s1-research) )
 
 ## Reliability
  

draft-roadmap/TEMPLATE.md

@@ -1,5 +1,7 @@
 # <Milestone Title - use verb>
 
+**Estimated date of completion**: <Enter date>
+
 <Milestone Description - what do we get once done>
 
 **FURPS**:

draft-roadmap/define_incentivization_for_rlnaas.md

@@ -0,0 +1,53 @@
+# [Define Incentivization for RLNaaS](https://github.com/waku-org/pm/milestone/35)
+
+By the end of this milestone, we will have defined a roadmap and implemented a working proof of concept to incentivise node operators running Waku infrastructure for shared shards.
+
+In general, Waku infrastructure consists of RLN Relay nodes both forming the decentralised routing backbone for Waku messages and providing a set of services on top of Waku that might be useful for applications.
+A sustainable Waku infrastructure is necessary within Status to achieve scalability for 1:1 chats and permissionless communities.
+These Status features use RLN rate-limiting on shared shards as supported by the RLN relay nodes
+and require a set of decentralised services for Status Mobile and resource-restricted clients,
+including RLN proofs as a service, Store, Filter and Lightpush.
+This milestone encapsulates the efforts to distribute rewards for running RLN Relay nodes and getting paid for providing Waku services.
+This is the first step to providing a sustainable way to scale the Status application.
+
+**FURPS**: TODO
+
+**deliverables**:
+
+## [Pay for RLN provision PoC](https://github.com/waku-org/pm/issues/245)
+
+**Owner**: core research
+
+**Feature**: [Incentivization](/FURPS/core/incentivization.md)
+
+**FURPS**:
+- F1. RLNaaS clients proceed to pay RLNaaS providers for attaching RLN proof to published messages.
+- F2. RLNaaS clients can assess of the quality of a provisioned RLNaaS and use it to build local reputation.
+- F3. RLNaaS clients can use local reputation of RLNaaS providers to select what provider to use.
+- U1. A consumer node can pay a service node for RLNaaS.
+- U2. A consumer node can select an RLNaaS provider based on their price and local reputation.
+- R1. A consumer prefers new providers to known unreliable providers.
+- R2. In a stable network, a client can find, pay and send a message via a RLNaaS provider (**Vac-QA**)
+   in 90% of cases **(Vac-DST)**
+- R3. A client can assess whether an RLNaaS provider has relayed their message (**Vac-QA**)
+   in 90% of cases **(Vac-DST)**.
+- P1. Assuming a block time of 5 seconds,
+  a user can execute an RLNaaS payment and send a message within 30 seconds (Vac-DST)
+
+For S1. A nwaku-based CLI on a testnet, interaction with a custodial wallet is out-of-scope.
+
+**Checklist**:
+- [ ] Specs: link to specs
+- [ ] Code: link to GitHub issues/PRs/Epic
+- [ ] Dogfood: link to dogfooding session/artefact
+- [ ] Docs: links to README.md or docs.waku.org (TBD)
+
+## [Service incentivisation roadmap & spec](https://github.com/waku-org/pm/issues/246)
+
+**Owner**: research
+
+**Output**: a roadmap document.
+
+##  🏗️ Privacy-preserving payment streaming: F5, U3, S1 (research)
+
+**Probably need to drop due to core research team member's departure earlier this year.**