fix: Documentation: Improve governance docs with new proposal types and messages [DEV-5394]

SUMMARY.md

@@ -15,6 +15,7 @@
   * [Manage accounts](docs/cheqd-cli/cheqd-cli-accounts.md)
   * [Manage a node](docs/cheqd-cli/cheqd-cli-node-management.md)
   * [Make transactions](docs/cheqd-cli/cheqd-cli-token-transactions.md)
+  * [Draft governance proposals](docs/cheqd-cli/cheqd-cli-gov-proposals-types.md)
   * [Use fee abstraction](docs/cheqd-cli/cheqd-cli-fee-abstraction.md)
 
 ## 🏦 Validator Guides

docs/cheqd-cli/cheqd-cli-gov-proposals-types.md

@@ -0,0 +1,157 @@
+# Using cheqd Cosmos CLI for submitting governance proposals
+
+From Cosmos SDk v0.50+ versions the `gov` module provides a draft json file for all types of proposals. These json files can be generated using the `draft-proposal` subcommand present within the `gov` module.
+
+```bash
+cheqd-noded tx gov draft-proposal
+Use the arrow keys to navigate: ↓ ↑ → ← 
+? Select proposal type: 
+  ▸ text
+    community-pool-spend
+    software-upgrade
+    cancel-software-upgrade
+    other
+```
+
+It provides an interactive interface and provides a json output using user submitted information. The json file can be submitted on chain for voting using the following command:
+
+```bash
+cheqd-noded tx gov submit-proposal [path/to/proposal.json]
+  --from <key-name> \
+  --chain-id cheqd-mainnet-1 \
+  --gas auto \
+  --gas-adjustment 1.4 \
+  --gas-prices 5000ncheq
+```
+
+## Examples of `proposal.json` for a few commonly submitted proposal types
+
+### 1) Text proposals
+
+```bash
+{
+ "metadata": "ipfs://CID",
+ "deposit": "8000000000000ncheq",
+ "title": "<proposal_title>",
+ "summary": "<proposal_description>",
+ "expedited": false
+}
+```
+
+The main parameters here are:
+
+- `proposal_title` - name of the proposal.
+- `proposal_description` - proposal description; limited to 255 characters; you can use json markdown to provide links.
+
+### 2) Community Pool Spend
+
+```bash
+{
+  "messages": [
+    {
+      "@type": "/cosmos.distribution.v1beta1.MsgCommunityPoolSpend",
+      "authority": "cheqd10d07y265gmmuvt4z0w9aw880jnsr700j5ql9az",
+      "recipient": "<recipient_address>",
+      "amount": [
+        {
+          "denom": "ncheq",
+          "amount": "<amount>"
+        }
+      ]
+    }
+  ],
+  "metadata": "ipfs://CID",
+  "deposit": "8000000000000ncheq",
+  "title": "<proposal_title>",
+  "summary": "<proposal_description>",
+  "expedited": false
+}
+```
+
+The main parameters here are:
+
+- `proposal_title` - name of the proposal.
+- `proposal_description` - proposal description; limited to 255 characters; you can use json markdown to provide links.
+- `recipient_address`- cheqd address to which the community pool tokens should be sent.
+- `amount` - amount of tokens to be sent to the recipient address.
+
+### 3) Software upgrade
+
+```json
+{
+ "messages": [
+  {
+   "@type": "/cosmos.upgrade.v1beta1.MsgSoftwareUpgrade",
+   "authority": "cheqd10d07y265gmmuvt4z0w9aw880jnsr700j5ql9az",
+   "plan": {
+    "name": "<proposal_name>",
+    "time": "0001-01-01T00:00:00Z",
+    "height": "<upgrade_height>",
+    "info": "<upgrade_info>",
+    "upgraded_client_state": null
+   }
+  }
+ ],
+ "metadata": "ipfs://CID",
+ "deposit": "8000000000000ncheq",
+ "title": "<proposal_title>",
+ "summary": "<proposal_description>",
+ "expedited": false
+}
+```
+
+The main parameters here are:
+
+- `proposal_title` - name of the proposal.
+- `proposal_name` - name of proposal which will be used in `UpgradeHandler` in the new application,
+- `proposal_description` - proposal description; limited to 255 characters; you can use json markdown to provide links.
+- `upgrade_height` - height when upgrade process will be triggered. Keep in mind that this needs to be after voting period has ended.
+- `upgrade_info` - link to the upgrade info file, containing new binaries. Needs to contain sha256 checksum. See example - `https://raw.githubusercontent.com/cheqd/cheqd-node/refs/heads/main/networks/mainnet/upgrades/upgrade-v3.json?checksum=sha256:5989f7d5bca686598c315eb74e8eb507d7f9f417d71008a31a6b828c48ce45eb`
+- `operator_alias` - alias of a key which will be used for signing proposal.
+- `<chain_id>` - identifier of chain which will be used while creating the blockchain.
+
+### 4) IBC Recover Client
+
+```bash
+{
+ "messages": [
+  {
+   "@type": "/ibc.core.client.v1.MsgRecoverClient",
+   "subject_client_id": "<expired_client-id>",
+   "substitute_client_id": "<new_client-id>",
+   "signer": "prop_submitter_address>"
+  }
+ ],
+ "metadata": "ipfs://CID",
+ "deposit": "8000000000000ncheq",
+ "title": "<proposal_title>",
+ "summary": "<proposal_description>",
+ "expedited": false
+}
+```
+
+The main parameters here are:
+
+- `proposal_title` - name of the proposal.
+- `proposal_description` - proposal description; limited to 255 characters; you can use json markdown to provide links.
+- `expired_client_id` - IBC client id of the expired connection.
+- `new_client_id` - IBC client id of the replacement connection.
+- `prop_submitter_address` - Cheqd address of the user who will submit the proposal.
+
+## Expedited Proposals
+
+Cosmos SDK v0.50+ also added support for **expedited proposals**. Expedited proposals have shorter a voting period and a higher tally threshold by default. If an expedited proposal fails to meet the threshold within the shorter voting period, it is then automatically converted to a regular proposal and restarts voting under regular voting conditions.
+
+### Submitting expedited proposals
+
+Any and all proposals can be submitted as expedited proposals by switching the `expedited` field to `true` in proposal.json file.  Eg;-
+
+```bash
+{
+ "metadata": "ipfs://CID",
+ "deposit": "8000000000000ncheq",
+ "title": "<proposal_title>",
+ "summary": "<proposal_description>",
+ "expedited": true
+}
+```

docs/upgrades/propose-software-upgrade.md

@@ -16,7 +16,7 @@ The next steps are describing the general flow for making a proposal:
 
 - Send proposal command to the pool;
 - After getting it, ledger will be in the `PROPOSAL_STATUS_DEPOSIT_PERIOD`;
-- After sending the first deposit from one of other operators, proposal status will be moved to `PROPOSAL_STATUS_VOTING_PERIOD` and voting period (2 weeks for now) will be started;
+- After sending the first deposit from one of other operators, proposal status will be moved to `PROPOSAL_STATUS_VOTING_PERIOD` and voting period (5 days for now) will be started;
 - Due to the voting period operators should send their votes to the pool, get new binary downloaded and got to be installed;
 - After voting period passing (for now it's 2 weeks) in case of success voting process proposal should be passed to `PROPOSAL_STATUS_PASSED`;
 - The next step is waiting for `height` which was suggested for upgrade.
@@ -25,28 +25,51 @@ The next steps are describing the general flow for making a proposal:
 #### Command for sending proposal
 
 ```bash
-cheqd-noded tx gov submit-legacy-proposal software-upgrade <proposal_name> \
-  --title "<proposal_title>" \
-  --description "<proposal_description>" \
-  --upgrade-height <upgrade_height> \
-  --upgrade-info <upgrade_info> \
-  --deposit 8000000000000ncheq \
+cheqd-noded tx gov submit-proposal [path/to/proposal.json]
   --from <operator_alias> \
   --chain-id cheqd-mainnet-1 \
   --gas auto \
   --gas-adjustment 1.4 \
   --gas-prices 5000ncheq
 ```
 
+Where the contents of `proposal.json` are in the following format:
+
+```json
+{
+ "messages": [
+  {
+   "@type": "/cosmos.upgrade.v1beta1.MsgSoftwareUpgrade",
+   "authority": "cheqd10d07y265gmmuvt4z0w9aw880jnsr700j5ql9az",
+   "plan": {
+    "name": "<proposal_name>",
+    "time": "0001-01-01T00:00:00Z",
+    "height": "<upgrade_height>",
+    "info": "<upgrade_info>",
+    "upgraded_client_state": null
+   }
+  }
+ ],
+ "metadata": "ipfs://CID",
+ "deposit": "8000000000000ncheq",
+ "title": "<proposal-title>",
+ "summary": "<proposal_description>",
+ "expedited": false
+}
+```
+
 The main parameters here are:
 
+- `proposal-title` - name of the proposal.
 - `proposal_name` - name of proposal which will be used in `UpgradeHandler` in the new application,
 - `proposal_description` - proposal description; limited to 255 characters; you can use json markdown to provide links,
 - `upgrade_height` - height when upgrade process will be occurred. Keep in mind that this needs to be after voting period has ended.
 - `upgrade_info` - link to the upgrade info file, containing new binaries. Needs to contain sha256 checksum. See example - `https://raw.githubusercontent.com/cheqd/cheqd-node/refs/heads/main/networks/mainnet/upgrades/upgrade-v3.json?checksum=sha256:5989f7d5bca686598c315eb74e8eb507d7f9f417d71008a31a6b828c48ce45eb`
 - `operator_alias` - alias of a key which will be used for signing proposal,
 - `<chain_id>` - identifier of chain which will be used while creating the blockchain.
 
+Follow our [guide for drafting governance proposal](../cheqd-cli/cheqd-cli-gov-proposals-types.md) if you need help with creating the proposal file.
+
 In case of successful submitting  the next command can be used for getting `proposal_id`:
 
 ```bash