Minor review comments

docusaurus/docs/protocol/upgrades/_category_.json

@@ -3,6 +3,6 @@
   "position": 7,
   "link": {
     "type": "generated-index",
-    "description": "Documentation related to the Pocket Network protocol upgrades."
+    "description": "Documentation related to Pocket Network protocol upgrades."
   }
-}
+}

docusaurus/docs/protocol/upgrades/module_params.md

@@ -19,7 +19,6 @@ Pocket Network utilizes an off-chain governance mechanism that enables the commu
 
 Similar to how internal parameters can be adjusted using [Adding params](../../develop/developer_guide/adding_params.md), the DAO can submit changes to other modules. For example, here's a transaction that will increase the block size (a parameter in the `consensus` module):
 
-
 ```json
 {
   "body": {
@@ -38,9 +37,7 @@ Similar to how internal parameters can be adjusted using [Adding params](../../d
           "max_bytes": "1048576"
         },
         "validator": {
-          "pub_key_types": [
-            "ed25519"
-          ]
+          "pub_key_types": ["ed25519"]
         }
       }
     ]
@@ -59,22 +56,25 @@ poktrolld query consensus params
 ```
 
 Before the upgrade:
+
 ```yaml
 params:
   block:
     max_bytes: "22020096"
-  # ... the rest of the response  
+  # ... the rest of the response
 ```
 
 To submit the transaction that increases the block size:
+
 ```bash
 poktrolld tx authz exec tools/scripts/params/consensus_increase_block_size.json --from pnf --yes
 ```
 
 After the upgrade:
+
 ```yaml
 params:
   block:
     max_bytes: "66060288"
-  # ... the rest of the response  
-```
+  # ... the rest of the response
+```

docusaurus/docs/protocol/upgrades/protocol_upgrades.md

@@ -3,10 +3,9 @@ title: Protocol Upgrades
 sidebar_position: 1
 ---
 
-
 # Protocol Upgrades <!-- omit in toc -->
 
-The Pocket Network is continuously evolving through regular protocol upgrades. We implement software upgrades via a DAO process, allowing validator nodes to incorporate consensus-breaking changes. These upgrades can be automatically applied when using [Cosmovisor](../../operate/run_a_node/full_node_cosmovisor.md), or manually if not using `cosmovisor`.
+Pocket Network is continuously evolving through regular protocol upgrades. We implement software upgrades via a DAO process, allowing validator nodes to incorporate consensus-breaking changes. These upgrades can be automatically applied when using [Cosmovisor](../../operate/run_a_node/full_node_cosmovisor.md), or manually if not using `cosmovisor`.
 
 - [What is a Protocol Upgrade?](#what-is-a-protocol-upgrade)
 - [List of Upgrades](#list-of-upgrades)
@@ -17,7 +16,13 @@ The Pocket Network is continuously evolving through regular protocol upgrades. W
 
 ## What is a Protocol Upgrade?
 
-A protocol upgrade is a process of updating the Pocket Network software to introduce new features, improve existing functionalities, or address critical issues. These upgrades ensure the network remains secure, efficient, and up-to-date with the latest technological advancements. Not every GitHub release will become a protocol upgrade.
+A protocol upgrade is a process of updating Pocket Network software to introduce new features, improve existing functionalities, or address critical issues. These upgrades ensure the network remains secure, efficient, and up-to-date with the latest technological advancements.
+
+:::info
+
+Not every GitHub release will become a protocol upgrade.
+
+:::
 
 ## List of Upgrades
 
@@ -29,7 +34,7 @@ While you can find a comprehensive list of [poktroll releases](https://github.co
 
 **Planned upgrades** are those that our team has been developing for some time and have been announced in advance. These typically include new features, improvements to existing functionalities, or optimizations.
 
-**Unplanned upgrades** may occur at any time without prior notice. These are often necessary due to unforeseen circumstances such as bugs, security issues, or network congestion when no other mitigation is possible. Such upgrades may require manual intervention from users and/or validators, potentially resulting in a hard fork.
+**Unplanned upgrades** may occur at any time without prior notice. These are often necessary due to unforeseen circumstances such as bugs, security issues, chain halts, or network congestion when no other mitigation is possible. Such upgrades may require manual intervention from users and/or validators, potentially resulting in a hard fork.
 
 ### Breaking vs. Non-breaking Upgrades
 
@@ -40,4 +45,3 @@ While you can find a comprehensive list of [poktroll releases](https://github.co
 ### Manual Interventions
 
 While the risk is low, it's possible that the blockchain may encounter unexpected issues. In situations where forking the network becomes necessary (such as in cases of non-deterministic chain state), we will issue an upgrade notice requiring manual intervention from users and/or validators to ensure the network's health and integrity.
-

docusaurus/docs/protocol/upgrades/upgrade_list.md

@@ -7,12 +7,10 @@ sidebar_position: 1
 
 The tables below provide a list of past and upcoming protocol upgrades. For more detailed information about what upgrades are, how they work, and what changes they bring to the protocol, please refer to our [upgrade overview page](./index.md).
 
-
 - [Legend](#legend)
 - [TestNet](#testnet)
 - [MainNet](#mainnet)
 
-
 ## Legend
 
 ✅ - Yes
@@ -22,14 +20,13 @@ The tables below provide a list of past and upcoming protocol upgrades. For more
 
 ## TestNet
 
-
 :::warning
 This table is currently incomplete and does not include all protocol upgrades. Our recent TestNet upgrades, which were performed via a regenesis, are not listed here.
 :::
 
 | Version                                                                  | Planned | Breaking | Requires Manual Intervention | Upgrade Height |
 | ------------------------------------------------------------------------ | :-----: | :------: | :--------------------------: | -------------- |
-| [`v0.0.4`](https://github.com/pokt-network/poktroll/releases/tag/v0.0.4) |    ❓    |    ❓     |              ❌               | ❓              |
+| [`v0.0.4`](https://github.com/pokt-network/poktroll/releases/tag/v0.0.4) |   ❓    |    ❓    |              ❌              | ❓             |
 
 ## MainNet
 

docusaurus/docs/protocol/upgrades/upgrade_procedure.md

@@ -19,7 +19,6 @@ This page describes the protocol upgrade process, which is internal to the proto
   - [TestNet](#testnet)
   - [Mainnet](#mainnet)
 
-
 ## Overview <!-- omit in toc -->
 
 When a consensus-breaking change is made to the protocol, we must carefully evaluate and implement an upgrade path that allows existing nodes to transition safely from one software version to another without disruption. This process involves several key steps:
@@ -58,17 +57,17 @@ An upgrade transaction includes a [Plan](https://github.com/cosmos/cosmos-sdk/bl
         "plan": {
           "name": "v0.0.4",
           "height": "30",
-          "info": "{\"binaries\":{\"linux\/amd64\":\"https:\/\/github.com\/pokt-network\/poktroll\/releases\/download\/v0.0.4\/poktroll_linux_amd64.tar.gz?checksum=sha256:49d2bcea02702f3dcb082054dc4e7fdd93c89fcd6ff04f2bf50227dacc455638\",\"linux\/arm64\":\"https:\/\/github.com\/pokt-network\/poktroll\/releases\/download\/v0.0.4\/poktroll_linux_arm64.tar.gz?checksum=sha256:698f3fa8fa577795e330763f1dbb89a8081b552724aa154f5029d16a34baa7d8\",\"darwin\/amd64\":\"https:\/\/github.com\/pokt-network\/poktroll\/releases\/download\/v0.0.4\/poktroll_darwin_amd64.tar.gz?checksum=sha256:5ecb351fb2f1fc06013e328e5c0f245ac5e815c0b82fb6ceed61bc71b18bf8e9\",\"darwin\/arm64\":\"https:\/\/github.com\/pokt-network\/poktroll\/releases\/download\/v0.0.4\/poktroll_darwin_arm64.tar.gz?checksum=sha256:a935ab83cd770880b62d6aded3fc8dd37a30bfd15b30022e473e8387304e1c70\"}}"
+          "info": "{\"binaries\":{\"linux/amd64\":\"https://github.com/pokt-network/poktroll/releases/download/v0.0.4/poktroll_linux_amd64.tar.gz?checksum=sha256:49d2bcea02702f3dcb082054dc4e7fdd93c89fcd6ff04f2bf50227dacc455638\",\"linux/arm64\":\"https://github.com/pokt-network/poktroll/releases/download/v0.0.4/poktroll_linux_arm64.tar.gz?checksum=sha256:698f3fa8fa577795e330763f1dbb89a8081b552724aa154f5029d16a34baa7d8\",\"darwin/amd64\":\"https://github.com/pokt-network/poktroll/releases/download/v0.0.4/poktroll_darwin_amd64.tar.gz?checksum=sha256:5ecb351fb2f1fc06013e328e5c0f245ac5e815c0b82fb6ceed61bc71b18bf8e9\",\"darwin/arm64\":\"https://github.com/pokt-network/poktroll/releases/download/v0.0.4/poktroll_darwin_arm64.tar.gz?checksum=sha256:a935ab83cd770880b62d6aded3fc8dd37a30bfd15b30022e473e8387304e1c70\"}}"
         }
       }
     ]
   }
 }
 ```
 
-**name**: Name of the upgrade. It should match the `VersionName` of `upgrades.Upgrade`.
-**height**: The height at which an upgrade should be executed and the node will be restarted.
-**info**: While this field can theoretically contain any information about the upgrade, in practice, `cosmovisor` uses it to obtain information about the binaries. When `cosmovisor` is configured to automatically download binaries, it will pull the binary from the link provided in this field and perform a hash verification (which is optional).
+- `name`: Name of the upgrade. It should match the `VersionName` of `upgrades.Upgrade`.
+- `height`: The height at which an upgrade should be executed and the node will be restarted.
+- `info`: While this field can theoretically contain any information about the upgrade, in practice, `cosmovisor`uses it to obtain information about the binaries. When`cosmovisor` is configured to automatically download binaries, it will pull the binary from the link provided in this field and perform a hash verification (which is optional).
 
 ## Submitting the upgrade on-chain
 
@@ -86,19 +85,24 @@ poktrolld query upgrade plan
 
 ## Testing the Upgrade
 
+:::warning
+Note that for local testing, `cosmovisor` won't pull the binary from the info field.
+:::
+
 ### LocalNet
 
 LocalNet currently does not support `cosmovisor` and automatic upgrades. However, we have provided scripts to facilitate local testing in the `tools/scripts/upgrades` directory:
 
-1. Modify `tools/scripts/upgrades/authz_upgrade_tx_example_v0.0.4_height_30.json` to reflect the name of the upgrade and the height at which it should be scheduled. Note that for local testing, `cosmovisor` won't pull the binary from the `info` field.
+1. Modify `tools/scripts/upgrades/authz_upgrade_tx_example_v0.0.4_height_30.json` to reflect the name of the upgrade and the height at which it should be scheduled.
 
 2. Check and update the `tools/scripts/upgrades/cosmovisor-start-node.sh` to point to the correct binaries:
+
    - The old binary should be compiled to work before the upgrade.
    - The new binary should contain the upgrade logic to be executed immediately after the node is started using the new binary.
 
 3. Run `bash tools/scripts/upgrades/cosmovisor-start-node.sh` to wipe the `~/.poktroll` directory and place binaries in the correct locations.
 
-4. Execute the transaction as shown in [Submitting the upgrade on-chain](#submitting-the-upgrade-on-chain).
+4. Execute the transaction as shown in [Submitting the upgrade on-chain](#submitting-the-upgrade-on-chain) section above.
 
 ### DevNet
 
@@ -116,6 +120,10 @@ Until we transition to [cosmos-operator](https://github.com/strangelove-ventures
 2. When validator node(s) stop due to an upgrade, manually perform an ArgoCD apply and clean up old resources.
 3. Monitor validator node(s) as they start and begin producing blocks.
 
+:::tip
+If you are a member of Grove, you can find the instructions to access the infrastructure [here](https://www.notion.so/buildwithgrove/How-to-re-genesis-a-Shannon-TestNet-a6230dd8869149c3a4c21613e3cfad15?pvs=4).
+:::
+
 ### Mainnet
 
-The Mainnet upgrade process is to be determined. We aim to develop and implement improved tooling for this environment.
+The Mainnet upgrade process is to be determined. We aim to develop and implement improved tooling for this environment.