diff --git a/FURPS/application/status_go.md b/FURPS/application/status_go.md
index 8b83969..5e5caa8 100644
--- a/FURPS/application/status_go.md
+++ b/FURPS/application/status_go.md
@@ -24,4 +24,4 @@
 
 ## + (Privacy, Anonymity, Deployments)
 
-1. Status Desktop CI builds binaries with nwaku, alongside go-waku-based binaries.
\ No newline at end of file
+1. Status Desktop CI builds binaries with nwsaku, alongside go-waku-based binaries.
\ No newline at end of file
diff --git a/FURPS/core/incentivization.md b/FURPS/core/incentivization.md
new file mode 100644
index 0000000..79cd9e6
--- /dev/null
+++ b/FURPS/core/incentivization.md
@@ -0,0 +1,36 @@
+# Incentivization FURPS
+
+## Functionality
+
+1. RLNaaS clients proceed to pay RLNaaS providers for attaching RLN proof to published messages.
+2. RLNaaS clients can assess of the quality of a provisioned RLNaaS and use it to build local reputation.
+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.
+
+## 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.
+
+## Reliability
+ 
+1. A consumer prefers new providers to known unreliable providers.
+2. 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)**
+3. A client can assess whether an RLNaaS provider has relayed their message (**Vac-QA**)
+   in 90% of cases **(Vac-DST)**.
+
+## Performance
+
+1. Assuming a block time of 5 seconds,
+   a user can execute an RLNaaS payment and send a message within 30 seconds (Vac-DST)
+
+## Supportability
+
+1. A nwaku-based CLI on a testnet, interaction with a custodial wallet is out-of-scope.
+
+## + (Privacy, Anonymity, Deployments)
+
+1. Wallet address and IP address are un-linkable (privacy-preserving payment streaming).
\ No newline at end of file
diff --git a/draft-roadmap/README.md b/draft-roadmap/README.md
index 33f97f7..2e7826b 100644
--- a/draft-roadmap/README.md
+++ b/draft-roadmap/README.md
@@ -12,7 +12,8 @@ Testing out new format, once approved:
 - [Introduce E2E Reliability in Status Communities](./introduce_e2e_reliability_in_status.md)
 - Rendezvous TODO? (may be done)
 - [Deploy RLN onchain tree on L2 testnet](TODO)
-- [Integrate nwaku in Status Desktop, relay mode only](TODO)
+- [Integrate nwaku in Status Desktop, relay mode only](/draft-roadmap/integrate_nwaku_in_status_desktop_relay_mode_only.md)
+- [Define incentivization for RLNaaS](TODO)
 
 #### P2P Reliability Implementation in the Browser
 
diff --git a/draft-roadmap/TEMPLATE.md b/draft-roadmap/TEMPLATE.md
new file mode 100644
index 0000000..0e68b1e
--- /dev/null
+++ b/draft-roadmap/TEMPLATE.md
@@ -0,0 +1,24 @@
+# <Milestone Title - use verb>
+
+<Milestone Description - what do we get once done>
+
+**FURPS**:
+
+- [<Feature Name>](<path/to/furps/file>): <list of furps: F1, etc>
+
+**deliverables**: 
+
+## <Name of deliverable 1 - eg "improve feature X for the browser">
+
+**Owner**: <one waku subteam>
+
+**Feature**: [<Feature Name (only 1)>](<path/to/furps/file>)
+
+**FURPS**:
+- <F1. copy-paste full furp statement>
+
+**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)
\ No newline at end of file
diff --git a/draft-roadmap/integrate_nwaku_in_status_desktop_relay_mode_only.md b/draft-roadmap/integrate_nwaku_in_status_desktop_relay_mode_only.md
new file mode 100644
index 0000000..46ec1ce
--- /dev/null
+++ b/draft-roadmap/integrate_nwaku_in_status_desktop_relay_mode_only.md
@@ -0,0 +1,23 @@
+# Integrate nwaku in Status Desktop, relay mode only
+
+With this milestone, Status Desktop builds can use nwaku instead of go-waku.
+However, it should be seen as a MVP as further hardening and implementation of light client mode will be missing.
+Go-waku will still be used for Status Mobile.
+
+This strategy enables concrete steps toward sunsetting go-waku in a short period of time,
+avoiding a perpetual prototyping phase where many high risk problems (e.g. mobile bundle size, etc) have to be solved before the switch can be made.
+
+The next milestone will then focus on hardening the nwaku Desktop build
+and implement missing features such as Reliability Protocol for resource-restricted.
+Once done, it will reduce the scope of go-waku maintenance to light clients only and
+drastically reduce the duplicate work done between nwaku and go-waku.
+
+Note that we want to draw the line to RLN in terms of go-waku maintenance,
+meaning that if Status were to use RLN (see Scale 1:1 chat messages PoC), then it should happen with nwaku.
+
+**FURPS**:
+
+- [nwaku](/FURPS/application/nwaku.md): F1-2, S1-2, +1
+- [status-go](/FURPS/application/status_go.md): F1, U1, R1, P1, S1-2, +1
+
+**GitHub Milestone and deliverables**: https://github.com/waku-org/pm/milestone/33