diff --git a/standards/application/messaging-api.md b/standards/application/messaging-api.md
index 6531821..5601271 100644
--- a/standards/application/messaging-api.md
+++ b/standards/application/messaging-api.md
@@ -344,6 +344,15 @@ If the `mode` set is `core`, the initialised `WakuNode` SHOULD use:
 `edge` mode SHOULD be used if node functions in resource restricted environment,
 whereas `core` SHOULD be used if node has no strong hardware or bandwidth restrictions.
 
+**Fetching missed messages on startup**:
+
+The node MUST persist the timestamp of the last message it successfully received or sent before going offline.
+
+After the node is started and subscriptions are set up, the node SHOULD query the
+[STORE](https://lip.logos.co/messaging/standards/core/13/store.html) protocol to retrieve messages
+missed while offline, scoped to the subscribed content topics and using the persisted timestamp as the
+lower bound of the query.
+
 ### Messaging
 
 #### Messaging type definitions
diff --git a/standards/application/reliable-channel-api.md b/standards/application/reliable-channel-api.md
index 67d1a4e..0864dce 100644
--- a/standards/application/reliable-channel-api.md
+++ b/standards/application/reliable-channel-api.md
@@ -18,6 +18,7 @@ editor: Logos Messaging Team
     * [Architectural position](#architectural-position)
     * [IDL](#idl)
   * [Procedures](#procedures)
+    * [Node initialization](#node-initialization)
     * [Outgoing message processing](#outgoing-message-processing)
     * [Incoming message processing](#incoming-message-processing)
     * [Rate limiting](#rate-limiting)
@@ -95,6 +96,20 @@ A custom Interface Definition Language (IDL) in YAML is used, consistent with [M
 
 ## Procedures
 
+### Node initialization
+
+When a node is created via `createNode` (defined in [MESSAGING-API](/standards/application/messaging-api.md)),
+the implementation MUST perform the following setup before the node is used:
+
+1. **Configure SDS persistence**: Supply the `Persistence` backend from `SdsConfig` to the SDS module so that
+   causal history and outgoing buffers survive restarts.
+2. **Configure SDS hint provider**: Register a hint provider with the SDS module.
+   The hint provider converts an SDS `MessageId` into its corresponding `MessageHash`.
+3. **Configure Segmentation persistence**: Supply the `Persistence` backend from `SegmentationConfig` to the
+   [Segmentation](./segmentation.md) module so that partially reassembled messages survive restarts.
+4. **Fetch missed messages**: Retrieve messages missed while offline as described in
+   [MESSAGING-API — Fetching missed messages on startup](/standards/application/messaging-api.md#init-node-extended-definitions).
+
 ### Outgoing message processing
 
 When `send` is called, the implementation MUST process `message` in the following order:
@@ -310,12 +325,16 @@ types:
         type: bool
         default: false
         description: When enabled, the message sender adds parity (redundant) segments to allow recovery in case of data segment loss. See [SEGMENTATION](./segmentation.md).
-
       segmentSizeBytes:
         type: uint
         default: 102400  # 100 KiB
         description: "Maximum segment size in bytes.
         Messages larger than this value are split before SDS processing."
+      persistence:
+        type: Persistence
+        description: "Backend for persisting partial reassembly state across restarts.
+        Implementations MUST use this backend to store received segments until all segments of a message have arrived and can be reassembled.
+        Refer to [SEGMENTATION](./segmentation.md) for the full definition of what state must be persisted."
 
   SdsConfig:
     type: object