diff --git a/content/docs/rfcs/10/README.md b/content/docs/rfcs/10/README.md
index 77b1a240..36ce5d92 100644
--- a/content/docs/rfcs/10/README.md
+++ b/content/docs/rfcs/10/README.md
@@ -109,6 +109,30 @@ See [13/WAKU2-STORE](/spec/13) spec for more details.
See [14/WAKU2-FILTER](/spec/14) spec for more details.
+## Overview
+
+See the sequence diagram below for an overview of how the different protocols interact.
+
+
+
+
+ Figure 1: Overview of how protocols interact in Waku v2.
+
+
+0. We have six nodes, A-F. The protocols initially mounted are indicated as such. The PubSub topics `pubtopic1` and `pubtopic2` is used for routing and indicates that it is subscribed to messages on that topic for relay, see [11/WAKU2-RELAY](/spec/11) for details. Ditto for [13/WAKU2-STORE](/spec/13) where it indicates that these messages are persisted on that node.
+
+1. Node A creates a WakuMessage `msg1` with a ContentTopic `contentTopic1`. See [14/WAKU2-MESSAGE](/spec/14) for more details. If WakuMessage version is set to 1, we use the [6/WAKU1](/spec6) compatible `data` field with encryption. See [7/WAKU-DATA](/spec/7) for more details.
+
+2. Node F requests to get messages filtered by PubSub topic `pubtopic1` and ContentTopic `contentTopic1`. Node D subscribes F to this filter and will in the future forward messages that match that filter. See [12/WAKU2-FILTER](/spec/12) for more details.
+
+3. Node A publishes `msg1` on `pubtopic1` and subscribes to that relay topic pick it up. It then gets relayed further from B to D, but not C since it doesn't subscribe to that topic. See [11/WAKU2-RELAY](/spec/11).
+
+4. Node D saves `msg1` for possible later retrieval by other nodes. See [13/WAKU2-STORE](/spec/13).
+
+5. Node D also pushes `msg1` to F, as it has previously subscribed F to this filter. See [12/WAKU2-FILTER](/spec/12).
+
+6. At a later time, Node E comes online. It then requests messages matching `pubtopic1` and `contentTopic1` from Node D. Node D responds with messages meeting this (and possibly other) criteria. See [13/WAKU2-STORE](/spec/13).
+
# Upgradability and Compatibility
## Compatibility with Waku v1
diff --git a/static/rfcs/10/overview.msc b/static/rfcs/10/overview.msc
new file mode 100644
index 00000000..0119c954
--- /dev/null
+++ b/static/rfcs/10/overview.msc
@@ -0,0 +1,33 @@
+# Sequence diagram for Waku v2 (WakuMessage, WakuData, Relay, Store, Filter)
+# PNG generated with https://mscgen.js.org
+msc {
+ hscale="1",
+ wordwraparcs=true;
+
+ a [label="A\nrelay\n(0)"],
+ b [label="B relay(pubtopic1)\n(0)"],
+ c [label="C relay(pubtopic2)\n(0)"],
+ d [label="D relay(pubtopic1), store(pubtopic1), filter\n(0)"],
+ e [label="E\nrelay, store\n(0)"],
+ f [label="F\nrelay, filter\n(0)"];
+
+ a rbox a [label="msg1=WakuMessage(contentTopic1, data) [14/WAKU2-MESSAGE] (1)"];
+ a note a [label="If version=1, encrypt data per [7/WAKU-DATA] (1)"];
+
+ f => d [label="FilterRequest(pubtopic1, contentTopic1) [12/WAKU2-FILTER] (2)"];
+ d rbox d [label="Subscribe F to filter [12/WAKU2-FILTER] (2)"];
+
+ a => b [label="Publish msg1 on pubtopic1 [11/WAKU2-RELAY] (3)"];
+ b => d [label="relay msg1 on pubtopic1 [11/WAKU2-RELAY] (3)"];
+
+ d rbox d [label="store: saves msg1 [13/WAKU2-STORE] (4)"];
+
+ d => f [label="MessagePush(msg1)[12/WAKU2-FILTER] (5)"];
+
+ ---;
+
+ e note e [label="E comes online (6)"];
+ e => d [label="HistoryQuery(pubtopic1, contentTopic1) [13/WAKU2-STORE] (6)"];
+ d => e [label="HistoryResponse(msg1, ...) [13/WAKU2-STORE] (6)"];
+
+}
diff --git a/static/rfcs/10/overview.png b/static/rfcs/10/overview.png
new file mode 100644
index 00000000..bcf37474
Binary files /dev/null and b/static/rfcs/10/overview.png differ