From cb7179e56e69632f73f8316d29f707f030589697 Mon Sep 17 00:00:00 2001
From: driemworks <driemworks@idealabs.network>
Date: Wed, 16 Oct 2024 09:36:40 -0500
Subject: [PATCH] feat: update docs

---
 docs/murmur/README.md                        |  4 ++-
 docs/murmur/docs/intro.md                    | 10 +++---
 docs/murmur/docs/learn/protocol.md           | 36 +++++++++++++-------
 docs/murmur/docs/quick_start/_category_.json |  2 +-
 docs/murmur/docs/quick_start/browser.md      | 21 ++++++------
 docs/murmur/docs/quick_start/discord.md      |  4 +--
 docs/murmur/docs/quick_start/local.md        |  6 ++--
 docs/murmur/docs/quick_start/overview.md     | 33 +++++++++++-------
 8 files changed, 68 insertions(+), 48 deletions(-)

diff --git a/docs/murmur/README.md b/docs/murmur/README.md
index 0c6c2c2..8ada79f 100644
--- a/docs/murmur/README.md
+++ b/docs/murmur/README.md
@@ -1,4 +1,6 @@
-# Website
+# Murmur Docs
+
+This is the official documentation for the murmur protocol.
 
 This website is built using [Docusaurus](https://docusaurus.io/), a modern static website generator.
 
diff --git a/docs/murmur/docs/intro.md b/docs/murmur/docs/intro.md
index d987f23..3923790 100644
--- a/docs/murmur/docs/intro.md
+++ b/docs/murmur/docs/intro.md
@@ -13,7 +13,7 @@ Noun. *a low indistinct but often continuous sound*
 
 Murmur is a **keyless crypto wallet protocol** powered by the [Ideal Network](https://docs.idealabs.network) (IDN). Using **timelock encryption** and secure time-based [one-time password](https://www.techtarget.com/searchsecurity/definition/one-time-password-OTP) (OTP) generation, **murmur** allows users to create and execute secure crypto wallets with no mnemonic or secret key. Murmur allows users to access crypto wallets without needing a secret key or mnemonic - it is a truly keyless wallet solution.
 
-Murmur wallets can be accessed seamlessly across web-enabled devices, providing a plug-and-play solution for app developers to easily integrate web3 capabilities into applications and services with no additional infrastructure or overhead. Murmur wallets can be used by installing a standalone wallet client or by using our GDPR-compliant "MMR-as-a-Service" API, which allows you to easily create in-app wallets with seamless cross-browser interoperability. 
+Murmur wallets can be accessed seamlessly across web-enabled devices, providing a plug-and-play solution for app developers to easily integrate web3 capabilities into applications and services with no additional infrastructure or overhead. Murmur wallets can be used by installing a **standalone wallet client** or by using our GDPR-compliant "MMR-as-a-Service" **HTTP API**, which allows you to easily create in-app wallets with seamless interoperability across browsers and other HTTP clients. 
 
 ## Why Murmur?
 
@@ -30,7 +30,7 @@ Murmur sidesteps these disadvantages by relying on the Ideal Network's [randomne
 - **Truly Keyless Wallet**: No mnemonic or key management required.
 - **No Wallet Provider**: No reliance on a third-party provider for wallet access.
 - **Infinitely Scalable**: The Murmur protocol is designed to scale without increased computational or financial overhead, limited only by the underlying blockchain.
-- **Non-Custodial**: While Murmur offers API-based access for convenience, users maintain full control of their wallets at all times.
+- **Non-Custodial**: Users retain complete control of their wallets at all times. Even when opting for the convenience of HTTP-API-based access, only the heavy computational tasks are outsourced, ensuring full ownership remains with the user.
 - **Secure Against Key Extraction Attacks**: Unlike some threshold ECDSA approaches, Murmur uses threshold BLS signatures and is resistant to key extraction vulnerabilities (e.g. [research by zengo-x](https://eprint.iacr.org/2021/1621.pdf)).
 
 <!-- 
@@ -43,10 +43,10 @@ Murmur sidesteps these disadvantages by relying on the Ideal Network's [randomne
 
 The murmur protocol is very flexible and can be used in various contexts, each with different trust models. Start [here](./learn/protocol.md) to learn more about the inner workings of the murmur protocol, or just jump into the code on [github](https://github.com/ideal-lab5/murmur).
 
-**From a Browser**
-Murmur can be used from the browser by relying on the murmur.js library to communicate with an API, allowing for the creation and execution of in-app wallets. The [murmur-api](https://github.com/ideal-lab5/murmur-api) is a stateless API that simply outsources the computation required to compute and encrypt OTP codes and merkle proofs. [Murmur.js](https://github.com/ideal-lab5/murmur.js) is a javascript library that lets developers easily integrate keyless crypto wallets into their applications. In conjunction with [polkadot.js](https://polkadot.js.org/docs/api), it allows developers to easily add a 'wallet-as-a-service' mechanism to their applications. 
+**From a Browser or JS app**
+Murmur can be used from any web-enabled javascript context by relying on the **murmur.js** library to communicate with the **murmur-api**, allowing for the creation and execution of in-app wallets. The [murmur-api](https://github.com/ideal-lab5/murmur-api) is a permissionless HTTP API that simply outsources the computation required to compute and encrypt OTP codes and merkle proofs. [Murmur.js](https://github.com/ideal-lab5/murmur.js) is a javascript library that lets developers easily integrate keyless crypto wallets into their applications. In conjunction with [polkadot.js](https://polkadot.js.org/docs/api), it developers can add a 'wallet-as-a-service' mechanism to their applications with minimal effort. 
 
-Check out the [browser integration guide](./quick_start/browser.md) to learn how to integrate murmur into your applications by communicating with the api. See out the library in action by exploring the [murmur-dapp](https://github.com/ideal-lab5/murmur-dapp/) and [murmur discord bot](https://github.com/ideal-lab5/murmur-api).
+Check out the [browser integration guide](./quick_start/browser.md) to learn how to integrate murmur into your applications by communicating with the api. See out the library in action by exploring the [murmur-dapp](https://github.com/ideal-lab5/murmur-dapp/) and [murmur discord bot](https://github.com/ideal-lab5/murmur-discord-bot).
 
 **Standalone Client**
 You can also run the murmur wallet using a standalone client. Try the [cli](./quick_start/local.md) for a terminal based client that allows you to create a wallet and execute basic balance transfers.
diff --git a/docs/murmur/docs/learn/protocol.md b/docs/murmur/docs/learn/protocol.md
index 05c2ae7..8ba3278 100644
--- a/docs/murmur/docs/learn/protocol.md
+++ b/docs/murmur/docs/learn/protocol.md
@@ -9,7 +9,7 @@ A detailed mathetmatical description of the Murmur protocol. For getting started
 ## Background
 
 ### MMR
-A [Merkle mountain range](https://docs.grin.mw/wiki/chain-state/merkle-mountain-range) (MMR) is an alternative to a Merkle tree. Merkle mountain ranges are append-only data structures where leaves are added from left to right, adding a parent as soon as two leaves exist. Unlike Merkle trees, an MMR does not need to be perfectly balanced yet still allows for efficient Merkle proofs of membership. In this document, we will refer use the following notation to represent an MMR with a given set of leaves $M \leftarrow MMR(leaves = \{l_1, ..., l_k\})$ and we will refer to the MMR root as $r \leftarrow M.root$.
+A [Merkle mountain range](https://docs.grin.mw/wiki/chain-state/merkle-mountain-range) (MMR) is an alternative to a Merkle tree. Merkle mountain ranges are append-only data structures where leaves are added from left to right, adding a parent as soon as two leaves exist. Unlike Merkle trees, an MMR does not need to be perfectly balanced yet still allows for efficient Merkle proofs of membership. In this document, we will use the following notation to represent an MMR with a given set of leaves $M \leftarrow MMR(leaves = \{l_1, ..., l_k\})$ and we will refer to the MMR root as $r \leftarrow M.root$.
 
 In the same way as Merkle trees, an MMR allows for Merkle proofs to be constructed and verified. For an MMR $M \leftarrow MMR.New(leaves = \{l_1, ..., l_k\})$, a Merkle proof that $l_j$ is a leaf in the MMR is $\pi \leftarrow MMR.Prove(M.Leaves, l_j, j)$
 
@@ -52,9 +52,9 @@ Where the setup function takes some security parameter and produces a seed and $
 
 ## Protocol
 
-This solution is inspired by the [Hours of Horus](https://eprint.iacr.org/2021/715) concept by Zindros It is a new kind of keyless crypto wallet that allows the user to authenticate by providing knowledge of correct OTP codes. This wallet exists as a new type of keyless onchain account called a complete proxy. We make several improvements on the original protocol as outlined by Zindros. Specifically, rather than leveraging Witness Encryption, which is as of yet impractical, we use timelock encryption as defined above. Further, we use a Merkle mountain range over a Merkle tree, allowing for us to specify an arbitrary number of OTP codes.
+This solution is inspired by the [Hours of Horus](https://eprint.iacr.org/2021/715) concept by Zindros. It is a new kind of keyless crypto wallet that allows the user to authenticate by providing knowledge of correct OTP codes. This wallet exists as a new type of keyless onchain account called a complete proxy. We make several improvements on the original protocol as outlined by Zindros. Specifically, rather than leveraging Witness Encryption, which is as of yet impractical, we use timelock encryption as defined above. Further, we use a Merkle mountain range over a Merkle tree, allowing us to specify an arbitrary number of OTP codes.
 
-The protocol functions within a Prover-Verifier framework, where the prover convinces the verifier it has future knowledge of timelock encrypted OTP codes. In practice, the 'prover' is an end user and the 'verifier' is the blockchain runtime runtime. We assume there is an eventually consistent gossip protocol that ensures messages are relayed to all participants by some upper bounded interval. The Murmur protocol consists of four functions, the prover functions: **Create**, **PrepareExecute** and verifier functions: **VerifyCreate**, **VerifyExecute**. In the future we will expand this to include **Update** and **Recovery** capabilities. Assume we are working over an elliptic curve $\mathbb{E}(\mathbb{F}_p)$ for a finite field $\mathbb{F}_p$ of prime order. Also assume we are using type III pairings. Let $G \in \mathbb{G}_1$ be a generator and $seed \in \{0, 1\}^*$. 
+The protocol functions within a Prover-Verifier framework, where the prover convinces the verifier it has future knowledge of timelock encrypted OTP codes. In practice, the 'prover' is an end user and the 'verifier' is the blockchain runtime. We assume there is an eventually consistent gossip protocol that ensures messages are relayed to all participants by some upper bounded interval. The Murmur protocol consists of four functions, the prover functions: **Create**, **PrepareExecute** and verifier functions: **VerifyCreate**, **VerifyExecute**. In the future we will expand this to include **Update** and **Recovery** capabilities. Assume we are working over an elliptic curve $\mathbb{E}(\mathbb{F}_p)$ for a finite field $\mathbb{F}_p$ of prime order. Also assume we are using type III pairings. Let $G \in \mathbb{G}_1$ be a generator and $seed \in \{0, 1\}^*$. 
 
 For a future block $b$, we define:
 
@@ -91,7 +91,7 @@ sequenceDiagram
 1. **Create**
 $(root, \{(b, ct_b)\}_{b \in B}) \xleftarrow{R} Create(seed, B)$ where $B = \{b_1, ..., b_k\}$ is a limited block schedule
 
-    The client-side begins by producing an input 'seed', an any length string (e.g. a password), and a 'block schedule' $B$. The block schedule determines the *session* for the murmur wallet - the future block numbers when the wallet is usable. To be precise, an otp code is generated for each of the input block numbers' identities. In a Murmur wallet, an OTP code can be 'consumed' on a 'just-in-time' basis, where proof of knowledge of otp codes are submitted just before the expected block is finalized (for which it is encrypted). After this point, point the otp code should be considered expired (as it is essentially public information at this point). A wallet owner can consume this code exactly once before its expiration by proving knowledge of the code to the runtime. Thus, the size of the mmr describes the initial number of total transactions that the user can submit with this wallet before a wallet update is required.
+    The client-side begins by producing an input 'seed', an any length string (e.g. a password), along with a 'block schedule' $B$. The block schedule determines the *session* for the murmur wallet - the future block numbers when the wallet is usable. To be precise, an OTP code is generated for each of the input block numbers' identities. In a Murmur wallet, an OTP code can be 'consumed' on a 'just-in-time' basis, where a proof of knowledge of a future OTP code is submitted just before the expected block is finalized (for which it is encrypted). After this point, the OTP code should be considered expired (as it is essentially public information at this point). A wallet owner can consume this code exactly once before its expiration by proving knowledge of the code to the runtime. Thus, the size of the MMR describes the initial number of total transactions that the user can submit with this wallet before a wallet update is required.
 
     $$
         \{OTP_i\}_{i \in [n]} \leftarrow \{\mathcal{G}(seed, b_i)\}_{i \in [n]} \\
@@ -103,12 +103,12 @@ $(root, \{(b, ct_b)\}_{b \in B}) \xleftarrow{R} Create(seed, B)$ where $B = \{b_
 
     The user then gossips the data to the *verifier* (aka the Runtime). The prover also stores a map $\{(b_i, pos_i)\}_{i \in [n]}$ mapping block numbers to positions in the MMR. The secret keys should be destroyed immediately.
     
-    The MMR data can be added to some offchain storage, such as IPFS or simply on the user’s device. In particular, we will assume we have a mapping of block number to leaf position for which the wallet is valid. This will useful later on when accessing the MMR data to generate a Merkle proof. 
+    The MMR data can be added to some offchain storage, such as IPFS or simply on the user’s device. In particular, we will assume we have a mapping of block number to leaf position for which the wallet is valid. This will be useful later on when accessing the MMR data to generate a Merkle proof. 
     
 2. **VerifyCreate**:
     The prover stores a mapping between a well-known `name` and MMR roots, called the `Registry`. The verify create function:
     1. checks if the `name` is unique by querying the registry. If not, then abort.
-    2. add the name and proxy details to the Registry, mapping name to self-reported MMR root and MMR size.
+    2. adds the name and proxy details to the Registry, mapping name to self-reported MMR root and MMR size.
 
     $$
         r \leftarrow Registry.Get(name) \\
@@ -154,16 +154,26 @@ To investigate:
 In which ways is a wallet vulnerable?
 
 - if the IDN stops producing randomness then the wallet is unusable
-- if the IDN's security is compromised then wallet security is comrpomised as well
+- if the IDN's security is compromised then wallet security is compromised as well
     - so some centralization due to reliance on IDN
     - however, the IDN is a decentralized network itself, reducing the risks posed by centralization
 
 
 ## Future Work
-This type of wallet requires that murmur wallet user transactions are signed on behalf of an origin with enough funding to cover any resultant transaction fees. While we do not address it in this work, we leave it as an open task to address a potential paymaster scheme. This also allows for KYC or other such mechanisms to easily be established (e.g. if there is a semi-centralized API required to sign transction).
 
-- Performance Improvements
-    - batch verification for execution and updates 
-        - what if we used a Verkle Mountain range instead? 
-        - This could let us represent many murmur wallets with a single data structure
-        - also a VMR allows for more efficient 'multiproofs', so I suppose you could efficiently prove a set of murmur wallets, connected within a VMR, can efficiently be proved in a batch verification scenario 
+his type of wallet requires that Murmur wallet user transactions be signed by an origin with sufficient funds to cover any transaction fees incurred during the execution of Murmur extrinsics. 
+
+However, the protocol is designed to be flexible, allowing any valid signed origin and even enabling the option to set these transaction fees to zero. This flexibility supports a range of solutions depending on the specific use case. For example:
+
+- **A paymaster model** could be implemented, where a third party sponsors the transaction fees. This approach could facilitate KYC or similar mechanisms, particularly when a semi-centralized API is needed to sign transactions.
+
+- **An ephemeral origin** could be created specifically for individual transactions, allowing zero-fee Murmur transactions while enhancing anonymity. These temporary origins could be generated and destroyed for each transaction, adding an extra layer of privacy.
+In this work, we have opted for a straightforward paymaster scheme, where Alice acts as the sponsor. However, expanding this solution to support additional models remains an open area for further development.
+
+- We will investigate usage of **unsigned origins** rather than requiring users to rely on a third party or light client to obtain a signature. In this approach, murmur wallets simply send a transaction to the chain and verification of the sender is handled completely by the verification logic in the Murmur pallet.
+
+- **Performance Improvements**
+    - Implementing batch verification for execution and updates 
+        - Consider the potential of using a Verkle Mountain Range (VMR) instead. 
+        - This approach could allow the representation of multiple Murmur wallets within a single data structure.
+        - Additionally, VMR enables more efficient 'multiproofs,' which could significantly optimize batch verification by proving a set of Murmur wallets, all interconnected within the VMR, in a more streamlined and efficient manner.
\ No newline at end of file
diff --git a/docs/murmur/docs/quick_start/_category_.json b/docs/murmur/docs/quick_start/_category_.json
index 8d2565c..6c60d73 100644
--- a/docs/murmur/docs/quick_start/_category_.json
+++ b/docs/murmur/docs/quick_start/_category_.json
@@ -3,6 +3,6 @@
   "position": 2,
   "link": {
     "type": "generated-index",
-    "description": "Learn the most important murmur concepts."
+    "description": "Learn the most important Murmur concepts."
   }
 }
diff --git a/docs/murmur/docs/quick_start/browser.md b/docs/murmur/docs/quick_start/browser.md
index c258215..8d36ace 100644
--- a/docs/murmur/docs/quick_start/browser.md
+++ b/docs/murmur/docs/quick_start/browser.md
@@ -4,7 +4,7 @@ sidebar_position: 2
 
 # Browser Integration
 
-Murmur can be easily integrated into web applications with [murmur.js](https://github.com/ideal-lab5/murmur.js), a javascript wrapper that allows you to communicate with the `murmur-api`. Take a look at the [sequence diagram](#sequence-diagram) to see the end-to-end user flow.
+Murmur can be easily integrated into web applications with [murmur.js](https://github.com/ideal-lab5/murmur.js), a javascript wrapper that simplifies communication with the `murmur-api`. Take a look at the [sequence diagram](#sequence-diagram) to see the end-to-end user flow.
 
 ## Setup
 To get started, create a new javascript-based project (e.g. `npx init`). Then install the following dependencies
@@ -15,18 +15,17 @@ npm i @ideallabs/murmur.js axios @polkadot/api
 
 (Optional) Run a local IDN Node
 
-If you want to develop locally, you can run a local Ideal network node with Docker
+If you want to develop locally, you can run a local Ideal Network node with Docker
 
 ``` shell
 docker pull ideallabs/etf@latest
 docker run -p 9944:9944 ideallabs/etf --tmp --dev --alice --unsafe-rpc-external
 ```
 
-We will update this guide when we have finalized the DNS and such for a hosted node.
-
+*This guide will be updated once the DNS and related configurations for a hosted node have been finalized.*
 ---
 
-Configure setup axios and polkadotjs instances. We present a useful default here but there are many different ways an application may want to do this.
+Configure setup axios and polkadot.js instances. We present a useful default here but there are many different ways an application may want to do this.
 
 ``` js
 /* Polkadot API initialization */
@@ -52,7 +51,9 @@ const murmurClient = new MurmurClient(httpClient, api, alice)
 console.log('MurmurClient initialized')
 ```
 
-Then initialize the murmur.js library, a signer **must** be specified. Murmur wallet holders cannot sign messages by themselves currently. In the future, we will modify this to use an embedded *light client*, allowing users to construct ephemeral signing keys on-demand rather than relying on externally owned accounts to sign on their behalf.
+Then initialize the murmur.js library, a signer can be specified else it falls back to `Alice`. Murmur wallets cannot sign messages by themselves and must rely on a signer. It should be noted that Murmur wallets can also be used with the Ideal Network's [timelocked transactions](https://docs.idealabs.network) mechanism to ensure privacy of the transaction when signed by another origin.
+
+In [future work](../learn/protocol#future-work), we will investigate usage of an embedded *light client* instead, to construct ephemeral signing keys on-demand to sign on their behalf.
 
 ```js
 import { MurmurClient } from "@ideallabs/murmur.js";
@@ -63,7 +64,7 @@ const client = new MurmurClient(httpClient, this.api, alice)
 
 ## Authenticate (get a seed)
 
-The `authenticate` function enhances a user's password with greater entropy and returns a sufficient seed to create or execute a murmur wallet as a secure session cookie.
+The `authenticate` function enhances a user's password with greater entropy and returns a sufficient seed to create or execute a Murmur wallet as a secure session cookie.
 
 ``` js
 await murmur.authenticate(username, password)
@@ -85,7 +86,7 @@ murmur.new(validity, (result) => {
 
 ## Execute a Murmur Wallet
 
-To execute a call, first you must construct a valid runtime call with polkadotjs and pass it as a parameter to the execute function. For example, a balance transfer looks like
+To execute a call, first you must construct a valid runtime call with polkadot.js and pass it as a parameter to the execute function. For example, a balance transfer looks like
 
 ``` js
 // use polkadotjs to construct some call
@@ -106,7 +107,7 @@ murmurService.executeTransaction(tx, (result) => {
 
 ## Inspect Murmur wallets
 
-Murmur wallets can easily be queried using the polkadot.js ApiPromise, not explicitly through the murmur.js library. Given a potential `name` of a murmur wallet, it's address and balance can be found with:
+Murmur wallets can easily be queried using the polkadot.js ApiPromise, not explicitly through the murmur.js library. Given a potential `name` of a Murmur wallet, it's address and balance can be found with:
 
 ``` js
 const username = 'some_name';
@@ -132,6 +133,6 @@ You can also check out the [murmur discord bot](./discord.md), a bot enabling Di
 
 ## Sequence Diagram
 
-The diagram below depicts the sequence of events and communication between each component of the system when authenticating with the API, creating a wallet, and executing calls. The reader should note that the murmur API does **not** sign calls and know anything about the chain, it is stateless and permisionless and its database has open read access.
+The diagram below depicts the sequence of events and communication between each component of the system when authenticating with the API, creating a wallet, and executing calls. The reader should note that the Murmur API does **not** sign calls or know anything about the chain, it is permisionless and its database has open read access.
 
 ![sequence_diagram](../../assets/murmur_seq_diagram.drawio.png)
diff --git a/docs/murmur/docs/quick_start/discord.md b/docs/murmur/docs/quick_start/discord.md
index 5918148..c3a032a 100644
--- a/docs/murmur/docs/quick_start/discord.md
+++ b/docs/murmur/docs/quick_start/discord.md
@@ -32,10 +32,10 @@ If you configured the bot correctly in step 1 then you will see the bot come onl
 
 Any users in the server can interact with the Murmur Wallet Bot at any time by tagging the bot and invoking various commands. The bot uses murmur.js to call the murmur-api, so usage if very similar. Specifically, users first authenticate with the API, after which they can create wallets, execute balance transfers, and view their own public key and balance. Below, we detail the bot commands:
 
-- **!auth**: Authenticate with the murmur API to receive a seed.
+- **!auth**: Authenticate with the Murmur API to receive a seed.
 Example: `@murmur-discord-bot !auth`
 
-- **!create**: Create a new murmur wallet for the Discord user for a given validity period (number of blocks from now until the wallet expires). The wallet will be named the same as the discord username. 
+- **!create**: Create a new Murmur wallet for the Discord user for a given validity period (number of blocks from now until the wallet expires). The wallet will be named the same as the discord username. 
 Example: `@murmur-discord-bot !create 1000`
 
 - **!execute**: Execute a balance transfer by specifying an account address and amount
diff --git a/docs/murmur/docs/quick_start/local.md b/docs/murmur/docs/quick_start/local.md
index d697c02..f986087 100644
--- a/docs/murmur/docs/quick_start/local.md
+++ b/docs/murmur/docs/quick_start/local.md
@@ -4,13 +4,13 @@ sidebar_position: 3
 
 # Murmur CLI
 
-Create and execute a murmur wallet from a terminal.
+Create and execute a Murmur wallet from a terminal.
 
-The murmur-cli is a standalone client that creates and manages Merkle mountain range data for murmur wallets. It can be used to create new murmur wallets and to execute balance transfers from them against the Ideal Network's testnet.
+The murmur-cli is a standalone client that creates and manages Merkle mountain range data for Murmur wallets. It can be used to create new Murmur wallets and to execute balance transfers from them on the Ideal Network.
 
 ## Installation
 
-The easiest way to install the murmur client is with [cargo](https://doc.rust-lang.org/cargo/) install. By default it will try to connect to a Substrate node running on `localhost:9944`. This can be configured by specifying the environment variable `WS_URL` (e.g. `WS_URL=ws://localhost:9945`).
+The easiest way to install the Murmur client is with [cargo](https://doc.rust-lang.org/cargo/) install. By default it will try to connect to a Substrate node running on `localhost:9944`. This can be configured by specifying the environment variable `WS_URL` (e.g. `WS_URL=ws://localhost:9945`).
 
 ``` shell
 cargo install --git https://github.com/ideal-lab5/murmur
diff --git a/docs/murmur/docs/quick_start/overview.md b/docs/murmur/docs/quick_start/overview.md
index 7192e05..4c53056 100644
--- a/docs/murmur/docs/quick_start/overview.md
+++ b/docs/murmur/docs/quick_start/overview.md
@@ -4,7 +4,7 @@ sidebar_position: 1
 
 # Murmur (At a Glance)
 
-This is a comprehensive overview of the Murmur protocol and architecture. Murmur is inspired by [hours of horus](https://eprint.iacr.org/2021/715), though with several improvements to enhance practicality. Our implementation relies on the [Ideal network](https://docs.idealabs.network), a substrate-based verifiable randomness beacon we developed in conjunction with the web3 foundation. Beyond outputting verifiable randomness, the IDN also enables efficient [timelock encryption](https://docs.idealabs.network/docs/learn/crypto/timelock_encryption), a cryptographic primitives where messages can be encrypted *for a future block* in such a way that the beacon randomness produced in that block acts as a decryption key for the data. 
+This is a comprehensive overview of the Murmur protocol and architecture. Murmur is inspired by [hours of horus](https://eprint.iacr.org/2021/715), though with several improvements to enhance practicality. Our implementation relies on the [Ideal Network](https://docs.idealabs.network) (IDN), a Substrate-based verifiable randomness beacon we developed in conjunction with the [Web3 Foundation](https://web3.foundation/). Beyond outputting verifiable randomness, the IDN also enables efficient [timelock encryption](https://docs.idealabs.network/docs/learn/crypto/timelock_encryption), a cryptographic primitive where messages can be encrypted *for a future block* in such a way that the beacon randomness produced in that block acts as a decryption key for the data. 
 
 ## How it Works
 
@@ -25,7 +25,7 @@ The diagram below depicts the creation of a Murmur wallet, where:
 - $ct \leftarrow TLE(OTP, ID(j))$ represents timelock encryption 
 - the OTP code $OTP$ is encrypted "for" block number $j$. 
 
-The general idea is that we create OTP codes for future blocks and lock them with timelock encryption for each respective block. They are then organized into a Merkle mountain range which can be publicly stored. The user then submits an extrinsic to create a new wallet, specifying a *unique* name, root, and mmr size. The call can be sent from *any* origin (e.g. an ephemeral keypair built with a light client such as Substrate-connect). For formal proofs, we invite the reader to investigate the Hours of Horus paper mentioned above.
+The general idea is that OTP codes are generated for future blocks and lock them with timelock encryption for each respective block. They are then organized into a Merkle mountain range which can be publicly stored. The user then submits an extrinsic to create a new wallet, specifying a *unique* name, root, and MMR size. The call can be sent from *any* origin (e.g. an ephemeral keypair built with a light client such as Substrate-connect). For formal proofs, we invite the reader to investigate the Hours of Horus paper mentioned above.
 
 <div style={{ textAlign: 'center' }}>
 ![create](../../assets/murmur_create.drawio.png)
@@ -33,7 +33,7 @@ The general idea is that we create OTP codes for future blocks and lock them wit
 
 **Using a Wallet**
 
-Execution of calls from a murmur wallet requires that a user constructs a valid merkle proof and commitment and provides the data to the chain 'just in time'. The IDN, which acquires fresh randomness with each finalized block, will attempt to use the latest known signature to decrypt the provided ciphertext. If it cannot be decrypted, then the protocol is aborted. Otherwise, we use the plaintext to verify the commitment, which should be the hash of the OTP code concatenated with the call to be proxied. If valid, we then verify the Merkle proof. If both are valid, then the runtime is convinced that the caller knew the OTP code before it could have been decrypted and that it is a leaf within the MMR. When convinced of the validity, the runtime allows the proxy to execute the call.
+Execution of calls from a Murmur wallet requires that a user constructs a valid Merkle proof and commitment and provides the data to the chain 'just in time'. The IDN, which acquires fresh randomness with each finalized block, will attempt to use the latest known signature to decrypt the provided ciphertext. If it cannot be decrypted, then the protocol is aborted. Otherwise, the plaintext is used to verify the commitment, which should be the hash of the OTP code concatenated with the call to be proxied. If the Merkle proof is also valid, then the runtime is convinced that the caller knew the OTP code before it could have been decrypted and that it is a leaf within the MMR. When convinced of the validity, the runtime allows the proxy to execute the call.
 
 <div style={{ textAlign: 'center' }}>
 ![execute](../../assets/murmur_execute.drawio.png)
@@ -41,11 +41,11 @@ Execution of calls from a murmur wallet requires that a user constructs a valid
 
 **Updating a Wallet**
 
-You may have noticed that since we only generated OTP codes for a limited block schedule the wallet is inaccessible after block $k$ is finalized. This is indeed the case, that each murmur wallet can be considered as ephemeral. We have not yet implemented the update logic, but it will be coming soon. Once implemented, murmur wallets can be considered as 'session-based', operating in limited authorized sessions defined by the user.
+You may have noticed that since OTP codes are only generated for a limited block schedule the wallet is inaccessible after block $k$ is finalized. This is indeed the case, that each Murmur wallet can be considered as ephemeral. We have not yet implemented the update logic, but it will be coming soon. Once implemented, Murmur wallets can be considered as 'session-based', operating in limited authorized sessions defined by the user.
 
 ## Components and Architecture
 
-The murmur protocol is intended to be flexible and can be implemented in a variety of ways to fit the context. In this section we detail the various components and how discuss how they connect to one another.
+The Murmur protocol is intended to be flexible and can be implemented in a variety of ways to fit the context. In this section we detail the various components and discuss how they connect to one another.
 
 <div style={{ textAlign: 'center' }}>
 ![murmur_components](../../assets/murmur_stack.drawio.png)
@@ -53,11 +53,11 @@ The murmur protocol is intended to be flexible and can be implemented in a varie
 
 **Rust Compatibility**
 
-The `murmur-core` library, and it's corresponding `murmur-lib` implementation, allows for the solution to easily be used in **rust**. The release build of this library is able to handle the generation and encryption of 1000 OTPs in under 4 seconds.
+The `murmur-core` library, and it's corresponding `murmur-lib` implementation (using BLS377 with type III pairings), allow for the solution to easily be used in **rust**. The release build of this library is able to handle the generation and encryption of 1000 OTPs in under 4 seconds.
 
 **Javascript Compatibility**
 
-The `murmur.js` library allows for murmur to be used in **javascript**. Presently, this functions as an HTTP connector to the `murmur-api`, though in the future we will investigate javascript binding rather than relying on the api.
+The `murmur.js` library allows for Murmur to be used in **javascript**. Presently, this functions as an HTTP connector to the `murmur-api`, though in the future we will investigate javascript binding rather than relying on the API.
 
 The visualization below depicts dependencies and flow of data of each component of Murmur's architecture. 
 
@@ -75,11 +75,11 @@ This is an *implementation* of the murmur protocol over BLS377 using type III pa
 
 **[murmur-api](https://github.com/ideal-lab5/murmur-api)**
 
-The `murmur-api` is a rust-based web service that allows for easy usage of `murmur-lib`. It is a stateless API with an open-read database, allowing users to easily export MMR data (and granting them full autonomy over their murmur wallets). This API essentially exists as a convenience to externalize OTP code generation and ensure sufficient entropy is used when constructing seeds for OTP codes. In the future we strive to deprecate this component.
+The `murmur-api` is a Rust-based web service designed to facilitate the use of `murmur-lib`. It is an HTTP API with an open-read database, allowing users to export MMR data and maintain full control over their Murmur wallets. This API primarily serves as a convenience to externalize OTP code generation and ensure adequate entropy when constructing seeds for OTP codes. In the future, we aim to deprecate this component.
 
 **[murmur.js](https://github.com/ideal-lab5/murmur.js)**
 
-This is an HTTP connector for the `murmur-api`, allowing javascript-based applications to easily communicate with the `murmur-api` and with the Ideal Network to create and execute murmur wallets. It does this via axios and polkadotjs, respectively. 
+This is an HTTP connector to the `murmur-api`. It encapsulates communication with the API as a javascript-based wrapper, facilitating creation, inspection, and execution of Murmur wallets. It relies on `axios` and `polkadot.js` to communicate the the `murmur-api` and the IDN, respectively.
 
 **Examples** 
 - The [murmur-cli](https://github.com/ideal-lab5/murmur/tree/main/lib/src/bin/murmur) is a terminal-based way to use murmur. 
@@ -87,16 +87,23 @@ This is an HTTP connector for the `murmur-api`, allowing javascript-based applic
 
 
 ### Pallets
-> For the Polkadot 2024 Hackathon, we specifically deliver ONLY the murmur and modified proxy pallets. All other pallets should not be considered for judging and have been developed outside the scope of the hackathon.
 
-The [murmur pallet](https://github.com/ideal-lab5/pallets/tree/main/pallets/murmur) is the core pallet that enables murmur wallets. Specifically, it takes the role of a 'prover' in the [murmur protocol](../learn/protocol.md), where it is responsible for registering uniquely named Murmur proxies and acting as an extension to the proxy pallet, where it verifies execution parameters prior to dispatching them. Specifically, this works with our modified [proxy pallet](https://github.com/ideal-lab5/pallets/tree/main/pallets/proxy), which allows virtually uncallable proxies to be defined with *no delegate*. This proxy type can only be used via the murmur pallet's proxy extrinsic, which requires valid proof of future OTP codes.
+> IMPORTANT: Pertaining to participation in [Polkadot 2024 Hackathon | Bangkok](https://dorahacks.io/hackathon/polkadot-2024-bangkok/detail), the core consensus modules of the Ideal Network and the Randomness Beacon pallet should not be considered for evaluation, as it was developed outside the scope of this hackathon.
+
+The [Murmur pallet](https://github.com/ideal-lab5/pallets/tree/main/pallets/murmur) is the core pallet that enables Murmur wallets. Specifically, it takes the role of a 'prover' in the [Murmur protocol](../learn/protocol.md), where it is responsible for registering uniquely named Murmur proxies and acting as an extension to the proxy pallet, where it verifies execution parameters prior to dispatching them. Specifically, this works with our modified [Proxy pallet](https://github.com/ideal-lab5/pallets/tree/main/pallets/proxy), which allows virtually uncallable proxies to be defined with *no delegate*. This proxy type can only be used via the Murmur pallet's proxy extrinsic, which requires valid proof of future OTP codes.
 
 
 <div style={{ textAlign: 'center' }}>
 ![idn_pallets](../../assets/murmur_pallets.drawio.png)
 </div>
 
-Explore the repo [here](https://github.com/ideal-lab5/pallets/tree/main) to learn more about the core runtime modules that power Murmur and the Ideal Network.
+Explore the [pallets repo](https://github.com/ideal-lab5/pallets/tree/main) to learn more about the core runtime modules that power Murmur and the Ideal Network.
+
+## Vulnerabilities, Limitations, Assumption
+
+- Murmur wallets are inherently ephemeral. We currently have not implemented any update functionality, meaning that in its current state all Murmur wallets expire at some point. We will address this in the future.
+- Murmur wallets are not recoverable currently. If the user loses their username/seed then they have effectively lost access to their wallet. 
+- There has been no formal security audit of the IDN or Murmur.
+- Murmur wallets **only** work on the IDN solochain for the time being. In the near future we will deploy the network as a parachain and explore ways to make Murmur wallets easily usable in a cross-chain capacity.
 
-## Vulnerabilities, Limitations, and Future Work