docs(messaging): defined RLN for lightpush milestone

Author: igor-sirotin

content/messaging/roadmap/index.md

@@ -41,6 +41,7 @@ We use two release stages for developer-facing APIs and libraries:
 - [Chat — Group Conversations](2025-extend-chat-sdk-with-group-conversations)
 - [Logos Core Integration — Phase 2](2026-logos-core-integration-phase-2)
 - [QUIC Transport in Logos Delivery](2025-support-discovery-research-and-libp2p-quic)
+- [RLN for lightpush](2026-rln-for-lightpush.md)
 
 ### Testnet [v0.3](v03)
 

content/messaging/roadmap/milestones/2026-rln-for-lightpush.md

@@ -0,0 +1,60 @@
+---
+title: RLN for LightPush
+tags:
+  - messaging-milestone
+date: '2026-04-06T00:00:00.000Z'
+github: 'https://github.com/logos-messaging/pm/issues/411'
+---
+**Resources Required**:
+- 1 Delivery engineer
+- AnonComms support
+
+Resolve the architectural gap where LightPush service nodes share a single RLN quota with relay traffic, making LightPush non-functional under high-volume relay conditions.
+
+Once done, Logos Messaging fleets should be able to become fully RLN-protected; edge nodes are required to get an RLN membership and send lightpush requests with RLN-proof attached; RLNaaS is discontinued.
+
+It's an open question, how edge not will get RLN membership. The initial implementation should have the same approach as Relay, later versions might introduce sponsored memberships.
+## Risks
+
+| Risk                                            | (Accept, Own, Mitigation)                     |
+| ----------------------------------------------- | --------------------------------------------- |
+| RLN membership sponsorship model is not defined | Focus on no-sponsorship implementation first. |
+## Deliverables
+
+### Add support for RLN proofs in edge mode
+
+**Owner**: Delivery Team
+
+Enable light clients with their own RLN membership to generate proofs client-side and submit messages with proofs via lightpush. The service node verifies the proof and relays without consuming its own quota.
+
+This decouples lightpush from service node quota entirely for clients that have their own membership, and is the long-term path to sustainable edge mode.
+
+**Done when**: A light client with its own RLN membership can send a pre-proven message via lighpush, and the service node relays it without consuming its own nonce.
+
+Note that this might already be possible in `logos-delivery`, in that case it needs verification.
+
+### [Improve RLN UX by reducing contract interactions](https://github.com/waku-org/pm/issues/344)
+
+**Owner**: Delivery Team
+
+**Feature**: [RLN Smart Contract](/messaging/furps/core/rln_smart_contract.md)
+
+**FURPS**:
+- U3. Application does not need to do a Web3 RPC call for every tree change to generate or validate messages.
+- U4. Application can transfer tokens and register membership with a single transaction.
+
+### Enable LightPush rate limiting in Logos Testnet
+
+**Owner**: Delivery Team
+
+Enable Logos Testnet fleet nodes to start verifying lightpush RLN proofs, and drop lightpush requests without RLN proofs.
+
+**Done when**: Fleet deployments (`logos.dev`, `logos.test`) are updated.
+
+### Enable LightPush rate limiting in `waku.sandbox`
+
+Enable `waku.sandbox` fleet nodes to start verifying lightpush RLN proofs, and drop lightpush requests without RLN proofs.
+
+This must be done carefully. Node operators and users should be notified. No disturbance should occur for network users.
+
+**Done when**: Fleet deployments (`logos.dev`, `logos.test`) are updated.