getoptimum · swarna1101 · Oct 22, 2025 · Oct 22, 2025
diff --git a/.vitepress/config.mts b/.vitepress/config.mts
@@ -192,7 +192,7 @@ function sidebarHome() {
           link: "/docs/learn/overview/intro",
         },
         {
-          text: "mumP2P Protocol",
+          text: "mump2p Protocol",
           link: "/docs/learn/overview/p2p.md",
         },
         {
@@ -250,7 +250,7 @@ function sidebarHome() {
       collapsed: false,
       items: [
         {
-          text: "mumP2P Protocol",
+          text: "mump2p Protocol",
           collapsed: true,
           items: [
             {

diff --git a/docs/guides/02-getting-started-docker.md b/docs/guides/02-getting-started-docker.md
@@ -3,17 +3,17 @@
 Running **Optimum Network** locally with Docker gives you **full control** over configuration, topology, and experiments.  
 You can run the network in two primary ways:
 
-**1. OptimumProxy + mumP2P** — Clients connect to an **Optimum Proxy**, which manages P2P connections for them.
+**1. OptimumProxy + mump2p** — Clients connect to an **Optimum Proxy**, which manages P2P connections for them.
 
-![OptimumProxy + mumP2P Architecture](../../static/img/docker_1.png)
+![OptimumProxy + mump2p Architecture](../../static/img/docker_1.png)
 
 * Simplifies client configuration — only the Proxy address is needed.
 * Proxy handles shard reassembly, threshold logic, and node selection automatically.
 * Easier scaling and centralized policy control.
 
-**2. Direct mumP2P** — Clients connect directly to **mumP2P nodes** (each node must run the gRPC API).
+**2. Direct mump2p** — Clients connect directly to **mump2p nodes** (each node must run the gRPC API).
 
-![Direct mumP2P Architecture](../../static/img/docker_2.png)
+![Direct mump2p Architecture](../../static/img/docker_2.png)
 
 * Fewer network hops = potentially lower latency.
 * Clients must know node addresses and manage failover logic.
@@ -32,7 +32,7 @@ local deployment offers:
 
 Choose the deployment mode that best fits your use case:
 
-| **Mode A: Proxy + mumP2P** | **Mode B: Direct mumP2P** |
+| **Mode A: Proxy + mump2p** | **Mode B: Direct mump2p** |
 |---|---|
 | **One endpoint** — simpler client config | **Lowest latency** — fewer network hops |
 | **Policy control** — rate limiting, auth | **Direct control** — no proxy overhead |
@@ -62,7 +62,7 @@ Choose the deployment mode that best fits your use case:
 
 | Component           | Purpose                                                                                                                                 | Docker Images               |
 | ------------------- | --------------------------------------------------------------------------------------------------------------------------------------- | --------------------------- |
-| **mumP2P Node** | RLNC-enabled mesh peer, encodes/decodes message shards, handles peer discovery and subscriptions. Optional gRPC API for direct clients. | `getoptimum/p2pnode:v0.0.1-rc2` |
+| **mump2p Node** | RLNC-enabled mesh peer, encodes/decodes message shards, handles peer discovery and subscriptions. Optional gRPC API for direct clients. | `getoptimum/p2pnode:v0.0.1-rc2` |
 | **Optimum Proxy**   | Bridges clients and the mesh, manages subscriptions, shard reassembly, threshold logic, and node selection.                             | `getoptimum/proxy:v0.0.1-rc3`   |
 
 
@@ -84,8 +84,8 @@ We’ll keep identity in `./identity` folder so you can reuse keys across restar
 
 | Recommended mode              | Why                                                                                       |
 | ----------------------------- | ----------------------------------------------------------------------------------------- |
-| **OptimumProxy + mumP2P** | One endpoint for clients, proxy handles matching, decoding thresholds, fanout, and policy |
-| **Direct mumP2P**         | Fewer hops, you control connection/retry logic and node selection                         |
+| **OptimumProxy + mump2p** | One endpoint for clients, proxy handles matching, decoding thresholds, fanout, and policy |
+| **Direct mump2p**         | Fewer hops, you control connection/retry logic and node selection                         |
 
 
 ## 3. Environment Configuration
@@ -119,7 +119,7 @@ This creates `./identity/p2p.key` with your unique Peer ID.
 
 > **Complete Guide:** [Identity generation and Makefile commands](https://github.com/getoptimum/optimum-dev-setup-guide#quick-start) - all make commands, direct binary usage
 
-## 5. Mode A — OptimumProxy + mumP2P (Recommended)
+## 5. Mode A — OptimumProxy + mump2p (Recommended)
 
 ### Docker Compose Setup
 
@@ -228,7 +228,7 @@ For gRPC bidirectional streaming (higher performance than WebSocket):
 > * [Setup and Usage Guide](https://github.com/getoptimum/optimum-dev-setup-guide/blob/main/docs/guide.md#grpc-proxy-client-implementation)
 > * REST subscription + gRPC streaming + flow control settings
 
-## 6. Mode B — Direct mumP2P (Advanced / Lower Latency)
+## 6. Mode B — Direct mump2p (Advanced / Lower Latency)
 
 In this mode, clients connect directly to node sidecar gRPC (no proxy).
 

diff --git a/docs/guides/03-parameters.md b/docs/guides/03-parameters.md
@@ -1,8 +1,8 @@
-# Understanding Key Parameters in mumP2P
+# Understanding Key Parameters in mump2p
 
 > **Complete Reference:** [Full parameter guide and defaults](https://github.com/getoptimum/optimum-dev-setup-guide/blob/main/docs/guide.md#configuration) - all variables, `.env` workflow, production configs
 
-mumP2P nodes can operate in **two distinct protocol modes**, configured via:
+mump2p nodes can operate in **two distinct protocol modes**, configured via:
 
 ```sh
 NODE_MODE=optimum    # RLNC-enhanced gossip
@@ -13,9 +13,9 @@ Each mode has its own parameter set, with some shared configurations.
 
 We support **two protocol modes** to let developers and researchers compare **performance, reliability, and bandwidth trade-offs** in real-world scenarios — without changing the rest of their infrastructure.
 
-## mumP2P (RLNC) Mode — `NODE_MODE=optimum`
+## mump2p (RLNC) Mode — `NODE_MODE=optimum`
 
-mumP2P extends the gossip protocol with **Random Linear Network Coding**:
+mump2p extends the gossip protocol with **Random Linear Network Coding**:
 
 * Messages are split into **shards**
 * Shards can be forwarded early once a threshold is reached
@@ -134,7 +134,7 @@ The following table shows the **production defaults**, which are optimized for t
 
 ### For Quick Start (Copy-Paste Ready)
 
-**mumP2P Mode (`NODE_MODE=optimum`):**
+**mump2p Mode (`NODE_MODE=optimum`):**
 
 ```yaml
 environment:
@@ -200,5 +200,5 @@ environment:
 | `GOSSIPSUB_MESH_MAX`         | 12            | gossipsub    | Max peers before pruning                       |
 | `BOOTSTRAP_PEERS`            | []            | Both         | List of peer multiaddrs for bootstrap         |
 
-> **Note:** These are the production defaults used by mumP2P nodes. For experimental tuning, see [Common Experiments](./04-experiments.md).
+> **Note:** These are the production defaults used by mump2p nodes. For experimental tuning, see [Common Experiments](./04-experiments.md).
 
diff --git a/docs/guides/04-experiments.md b/docs/guides/04-experiments.md
@@ -13,13 +13,13 @@ Each experiment below lists the **goal**, a quick **how-to**, and **what to obse
 You can run them using:
 
 * **mump2p CLI** (see [CLI Guide](./01-getting-started-cli.md))
-* **gRPC client** (with `MessageTraceGossipSub` or `MessageTraceOptimumP2P` for protocol metrics)
+* **gRPC client** (with `MessageTraceGossipSub` or `MessageTraceOptimump2p` for protocol metrics)
 
 
 
-## 1. GossipSub vs mumP2P
+## 1. GossipSub vs mump2p
 
-**Goal:** Compare standard libp2p gossip to RLNC-enhanced gossip to confirm mumP2P is faster.
+**Goal:** Compare standard libp2p gossip to RLNC-enhanced gossip to confirm mump2p is faster.
 
 **How:**
 
@@ -29,11 +29,11 @@ You can run them using:
 
 **Observe:**
 
-* **Delivery latency** (primary metric - mumP2P should be faster)
-* **Bandwidth usage** (mumP2P should use less)
+* **Delivery latency** (primary metric - mump2p should be faster)
+* **Bandwidth usage** (mump2p should use less)
 * **Success rate** (both should deliver messages successfully)
 
-**Expected Result:** mumP2P should show lower latency and bandwidth usage.
+**Expected Result:** mump2p should show lower latency and bandwidth usage.
 
 
 ## 2. Shard Factor Sweep
@@ -74,29 +74,29 @@ You can run them using:
 
 ## 4. Mesh Density Impact
 
-**Goal:** Compare mumP2P vs GossipSub with different mesh sizes.
+**Goal:** Compare mump2p vs GossipSub with different mesh sizes.
 
 **How:**
 
 * Test both `NODE_MODE=gossipsub` and `NODE_MODE=optimum`.
 * For GossipSub: try `GOSSIPSUB_MESH_TARGET` = 4, 6, 8.
-* For mumP2P: try `OPTIMUM_MESH_TARGET` = 6, 12, 18.
+* For mump2p: try `OPTIMUM_MESH_TARGET` = 6, 12, 18.
 * Run the same publish/subscribe test.
 
 **Observe:**
 
 * **Delivery latency** (primary metric)
 * **Bandwidth usage**
 
-**Expected Result:** mumP2P should perform better with higher mesh targets (around 12) while GossipSub optimal around 6.
+**Expected Result:** mump2p should perform better with higher mesh targets (around 12) while GossipSub optimal around 6.
 
 
 
 
 
 ## 5. Load Test
 
-**Goal:** Find when mumP2P vs GossipSub starts to fail under stress.
+**Goal:** Find when mump2p vs GossipSub starts to fail under stress.
 
 **How:**
 
@@ -109,13 +109,13 @@ You can run them using:
 * **When delivery starts to fail** (primary metric)
 * **Delivery rate degradation**
 
-**Expected Result:** mumP2P should handle higher stress levels before failing compared to GossipSub.
+**Expected Result:** mump2p should handle higher stress levels before failing compared to GossipSub.
 
 
 > **Tip:** Enable protocol traces in the gRPC client to get hop-by-hop delivery info:
 >
 > * `MessageTraceGossipSub` for GossipSub mode.
-> * `MessageTraceOptimumP2P` for mumP2P mode.
+> * `MessageTraceOptimump2p` for mump2p mode.
 
 ## Metrics Collection
 
@@ -128,7 +128,7 @@ For comprehensive metrics collection during experiments, use the gRPC P2P client
 The client automatically captures and displays:
 
 * **GossipSub traces**: Peer routing, message delivery status, hop counts, latency
-* **mumP2P traces**: Shard encoding/decoding, reconstruction efficiency, redundancy metrics  
+* **mump2p traces**: Shard encoding/decoding, reconstruction efficiency, redundancy metrics  
 * **Message-level data**: Delivery success rates, end-to-end latency, bandwidth usage
 
 **Key trace handlers:**
@@ -137,8 +137,8 @@ The client automatically captures and displays:
 case protobuf.ResponseType_MessageTraceGossipSub:
     fmt.Printf("[TRACE] GossipSub trace received: %s\n", string(resp.GetData()))
 
-case protobuf.ResponseType_MessageTraceOptimumP2P:
-    fmt.Printf("[TRACE] mumP2P trace received: %s\n", string(resp.GetData()))
+case protobuf.ResponseType_MessageTraceOptimump2p:
+    fmt.Printf("[TRACE] mump2p trace received: %s\n", string(resp.GetData()))
 ```
 
 Use this client instead of the CLI for detailed performance analysis during experiments.
diff --git a/docs/guides/05-faq-glossary.md b/docs/guides/05-faq-glossary.md
@@ -107,4 +107,4 @@ When something doesn't work:
 
 * **CLI Issues**: [mump2p-cli FAQ](https://github.com/getoptimum/mump2p-cli#faq---common-issues--troubleshooting)
 * **Setup Issues**: Check [`optimum-dev-setup-guide/docs/guide.md`](https://github.com/getoptimum/optimum-dev-setup-guide/blob/main/docs/guide.md)
-* **Protocol Questions**: See [mumP2P Documentation](./p2p.md)
+* **Protocol Questions**: See [mump2p Documentation](./p2p.md)
diff --git a/docs/guides/overview.md b/docs/guides/overview.md
@@ -16,7 +16,7 @@ Whether you are an application developer, systems engineer, or hackathon partici
 
 Choose your path to get started with Optimum Network:
 
-### **Try mumP2P (≤5 min)**
+### **Try mump2p (≤5 min)**
 
 **[Using mump2p-cli](01-getting-started-cli.md)** — Connect to hosted proxy, no setup required
 
@@ -30,7 +30,7 @@ Choose your path to get started with Optimum Network:
 
 * Complete local network deployment
 * Experiment with different parameters
-* Compare mumP2P vs GossipSub performance
+* Compare mump2p vs GossipSub performance
 
 ### **Understanding & Experimenting**
 
@@ -77,9 +77,9 @@ Before diving deep, familiarize yourself with these terms and how they relate to
 | **Direct P2P Mode** | Clients connect directly to P2P nodes via gRPC without going through a proxy. This can reduce latency but requires more configuration. |
 | **Mesh Parameters** | Settings such as `MESH_TARGET` that define how many peers a node tries to keep in its topic mesh. |
 | **Fanout**   | A temporary set of peers a publisher sends messages to when it is not part of the topic mesh. |
-| **Control Messages** | Special messages like GRAFT, PRUNE, IHAVE, IWANT used for GossipSub mesh management. mumP2P integrates similar control flows for RLNC. |
+| **Control Messages** | Special messages like GRAFT, PRUNE, IHAVE, IWANT used for GossipSub mesh management. mump2p integrates similar control flows for RLNC. |
 | **Node Discovery** | The process by which proxies or nodes automatically learn about other nodes to connect to. |
 | **gRPC API** | The RPC interface provided by either a P2P node or a proxy for client communication. |
 
-For more technical details, see the **[mumP2P Technical Overview](../learn/overview/p2p.md)**.
+For more technical details, see the **[mump2p Technical Overview](../learn/overview/p2p.md)**.
 
diff --git a/docs/learn/overview/intro.md b/docs/learn/overview/intro.md
@@ -12,9 +12,9 @@ Powered by [Random Linear Network Coding (RLNC)](./p2p.md#random-linear-network-
 
 ## Products
 
-Builders and operators can adopt **mumP2P** now for measurable latency gains. DeRAM and DeROM are next to unlock low-latency reads/writes.
+Builders and operators can adopt **mump2p** now for measurable latency gains. DeRAM and DeROM are next to unlock low-latency reads/writes.
 
-### mumP2P
+### mump2p
 
 RLNC-accelerated, libp2p/gossipsub-compatible pub/sub for fast, resilient propagation of blocks, blobs, and transactions.  
 **Get started:** [Overview](../../learn/overview/p2p.md) · [Quickstart](../../guides/01-getting-started-cli.md)
@@ -40,7 +40,7 @@ A **flexnode** is an operator-run node that participates in Optimum's coded goss
 
 ## Start here
 
-* **Try mumP2P (≤5 min):** [Using mump2p-cli](../../guides/01-getting-started-cli.md)
+* **Try mump2p (≤5 min):** [Using mump2p-cli](../../guides/01-getting-started-cli.md)
 * **Run locally:** [Local Setup with Docker](../../guides/02-getting-started-docker.md)
 * **Integrate:** [Publish/Subscribe via Optimum Proxy endpoints](https://github.com/getoptimum/optimum-dev-setup-guide/blob/main/docs/guide.md#proxy-api)