docs: add auth tx commands documentation (#13682)

docs/architecture/adr-060-abci-1.0.md

@@ -233,8 +233,6 @@ know them today will still exist and function as they currently do.
   block execution. Albeit, the overhead should be negligible.
 * Not backwards compatible with previous versions of Tendermint and the Cosmos SDK.
 
-### Neutral
-
 ## Further Discussions
 
 It is possible to design the app-side implementation of the `Mempool[T MempoolTx]`

docs/architecture/adr-061-liquid-staking.md

@@ -10,7 +10,7 @@ PROPOSED
 
 ## Abstract
 
-Add a semi-fungible liquid staking primitive to the default cosmos SDK staking module. This upgrades proof of stake to enable safe designs with lower overall monetary issuance and integration with numerous liquid staking protocols like Stride, Persistence, Quicksilver, Lido etc.
+Add a semi-fungible liquid staking primitive to the default Cosmos SDK staking module. This upgrades proof of stake to enable safe designs with lower overall monetary issuance and integration with numerous liquid staking protocols like Stride, Persistence, Quicksilver, Lido etc.
 
 ## Context
 
@@ -22,7 +22,7 @@ The most important deficiency of the legacy staking design is that it composes p
 
 The Osmosis team has adopted the idea of Superfluid and Interfluid staking where assets that are participating in DeFi appliactions can also be used in proof of stake. This requires tight integration with an enshrined set of DeFi applications and thus is unsuitable for the Cosmos SDK.
 
-It's also important to note that Interchain Accounts are available in the default IBC implementation and can be used to (rehypothecate)[https://www.investopedia.com/terms/h/hypothecation.asp#toc-what-is-rehypothecation] delegations. Thus liquid staking is already possible and these changes merely improve the UX of liquid staking. Centralized exchanges also rehypothecate staked assets, posing challenges for decentralization. This ADR takes the position that adoption of in-protocol liquid staking is the preferable outcome and provides new levers to incentivize decentralization of stake. 
+It's also important to note that Interchain Accounts are available in the default IBC implementation and can be used to [rehypothecate](https://www.investopedia.com/terms/h/hypothecation.asp#toc-what-is-rehypothecation) delegations. Thus liquid staking is already possible and these changes merely improve the UX of liquid staking. Centralized exchanges also rehypothecate staked assets, posing challenges for decentralization. This ADR takes the position that adoption of in-protocol liquid staking is the preferable outcome and provides new levers to incentivize decentralization of stake. 
 
 These changes to the staking module have been in development for more than a year and have seen substantial industry adoption who plan to build staking UX. The internal economics at Informal team has also done a review of the impacts of these changes and this review led to the development of the exempt delegation system. This system provides governance with a tuneable parameter for modulating the risks of principal agent problem called the exemption factor. 
 
@@ -71,18 +71,12 @@ The MsgExemptDelegation message is used to exempt a delegation to a validator. I
 
 This design allows the chain to force an amount of self-delegation by validators participating in liquid staking schemes.
 
-
 ## Consequences
 
-
 ### Backwards Compatibility
 
 By setting the exemption factor to zero, this module works like legacy staking. The only substantial change is the removal of min-self-bond and without any tokenized shares, there is no incentive to exempt delegation. 
 
 ### Positive
 
-This approach should enable integration with liquid staking providers and improved user experience. It provides a pathway to security under non-exponential issuance policies in the baseline staking module.
-
-
-## References
-
+This approach should enable integration with liquid staking providers and improved user experience. It provides a pathway to security under non-exponential issuance policies in the baseline staking module.

x/auth/README.md

@@ -396,6 +396,127 @@ tx_sig_limit: "7"
 tx_size_cost_per_byte: "10"
 ```
 
+#### Transactions
+
+The `auth` module supports transactions commands to help you with signing and more. Compared to other modules you can access directly the `auth` module transactions commands using the only `tx` command.
+
+Use directly the `--help` flag to get more information about the `tx` command.
+
+```bash
+simd tx --help
+```
+
+##### `sign`
+
+The `sign` command allows users to sign transactions that was generated offline.
+
+```bash
+simd tx sign tx.json --from $ALICE > tx.signed.json
+```
+
+The result is a signed transaction that can be broadcasted to the network thanks to the broadcast command.
+
+More information about the `sign` command can be found running `simd tx sign --help`.
+
+##### `sign-batch`
+
+The `sign-batch` command allows users to sign multiples offline generated transactions.
+The transactions can be in one file, with one tx per line, or in multiple files.
+
+```bash
+simd tx sign txs.json --from $ALICE > tx.signed.json
+```
+
+or
+
+```bash 
+simd tx sign tx1.json tx2.json tx3.json --from $ALICE > tx.signed.json
+```
+
+The result is multiples signed transactions. For combining the signed transactions into one transactions, use the `--append` flag.
+
+More information about the `sign-batch` command can be found running `simd tx sign-batch --help`.
+
+##### `multi-sign`
+
+The `multi-sign` command allows users to sign transactions that was generated offline by a multisig account.
+
+```bash
+simd tx multisign transaction.json k1k2k3 k1sig.json k2sig.json k3sig.json
+```
+
+Where `k1k2k3` is the multisig account address, `k1sig.json` is the signature of the first signer, `k2sig.json` is the signature of the second signer, and `k3sig.json` is the signature of the third signer.
+
+More information about the `multi-sign` command can be found running `simd tx multi-sign --help`.
+
+##### `multisign-batch`
+
+The `multisign-batch` works the same way as `sign-batch`, but for multisig accounts.
+With the difference that the `multisign-batch` command requires all transactions to be in one file, and the `--append` flag does not exist.
+
+More information about the `multisign-batch` command can be found running `simd tx multisign-batch --help`.
+
+##### `validate-signatures`
+
+The `validate-signatures` command allows users to validate the signatures of a signed transaction.
+
+```bash
+$ simd tx validate-signatures tx.signed.json
+Signers:
+  0: cosmos1l6vsqhh7rnwsyr2kyz3jjg3qduaz8gwgyl8275
+
+Signatures:
+  0: cosmos1l6vsqhh7rnwsyr2kyz3jjg3qduaz8gwgyl8275                      [OK]
+```
+
+More information about the `validate-signatures` command can be found running `simd tx validate-signatures --help`.
+
+##### `broadcast`
+
+The `broadcast` command allows users to broadcast a signed transaction to the network.
+
+```bash
+simd tx broadcast tx.signed.json
+```
+
+More information about the `broadcast` command can be found running `simd tx broadcast --help`.
+
+##### `encode`
+
+The `encode` command encodes a transaction created with the `--generate-only` flag or signed with the sign command.
+The transaction is seralized it to Protobuf and returned as base64.
+
+```bash
+$ simd tx encode tx.json
+Co8BCowBChwvY29zbW9zLmJhbmsudjFiZXRhMS5Nc2dTZW5kEmwKLWNvc21vczFsNnZzcWhoN3Jud3N5cjJreXozampnM3FkdWF6OGd3Z3lsODI3NRItY29zbW9zMTU4c2FsZHlnOHBteHU3Znd2dDBkNng3amVzd3A0Z3d5a2xrNnkzGgwKBXN0YWtlEgMxMDASBhIEEMCaDA==
+$ simd tx encode tx.signed.json
+```
+
+More information about the `encode` command can be found running `simd tx encode --help`.
+
+##### `decode`
+
+The `decode` commands decodes a transaction encoded with the `encode` command.
+
+
+```bash
+simd tx decode Co8BCowBChwvY29zbW9zLmJhbmsudjFiZXRhMS5Nc2dTZW5kEmwKLWNvc21vczFsNnZzcWhoN3Jud3N5cjJreXozampnM3FkdWF6OGd3Z3lsODI3NRItY29zbW9zMTU4c2FsZHlnOHBteHU3Znd2dDBkNng3amVzd3A0Z3d5a2xrNnkzGgwKBXN0YWtlEgMxMDASBhIEEMCaDA==
+```
+
+More information about the `decode` command can be found running `simd tx decode --help`.
+
+##### `aux-to-fee`
+
+The `aux-to-fee` comamnds includes the aux signer data in the tx, broadcast the tx, and sends the tip amount to the broadcaster.
+[Learn more about tip transaction](https://docs.cosmos.network/main/core/tips).
+
+```bash
+# simd tx bank send <from> <to> <amount> --aux (optional: --tip <tipAmt> --tipper <tipper>)
+simd tx aux-to-fee tx.aux.signed.json
+```
+
+More information about the `aux-to-fee` command can be found running `simd tx aux-to-fee --help`.
+
 ### gRPC
 
 A user can query the `auth` module using gRPC endpoints.

x/auth/client/cli/encode.go

@@ -16,7 +16,7 @@ func GetEncodeCommand() *cobra.Command {
 	cmd := &cobra.Command{
 		Use:   "encode [file]",
 		Short: "Encode transactions generated offline",
-		Long: `Encode transactions created with the --generate-only flag and signed with the sign command.
+		Long: `Encode transactions created with the --generate-only flag or signed with the sign command.
 Read a transaction from <file>, serialize it to the Protobuf wire protocol, and output it as base64.
 If you supply a dash (-) argument in place of an input filename, the command reads from standard input.`,
 		Args: cobra.ExactArgs(1),

x/auth/client/cli/tips.go

@@ -17,7 +17,7 @@ import (
 func GetAuxToFeeCommand() *cobra.Command {
 	cmd := &cobra.Command{
 		Use:   "aux-to-fee <aux_signed_tx.json>",
-		Short: "includes the aux signer data in the tx, broadcast the tx, and sends the tip amount to the broadcaster",
+		Short: "Includes the aux signer data in the tx, broadcast the tx, and sends the tip amount to the broadcaster",
 		Args:  cobra.ExactArgs(1),
 		RunE: func(cmd *cobra.Command, args []string) error {
 			clientCtx, err := client.GetClientTxContext(cmd)

x/auth/client/cli/tx_multisign.go

@@ -211,8 +211,9 @@ func makeMultiSignCmd() func(cmd *cobra.Command, args []string) (err error) {
 
 func GetMultiSignBatchCmd() *cobra.Command {
 	cmd := &cobra.Command{
-		Use:   "multisign-batch [file] [name] [[signature-file]...]",
-		Short: "Assemble multisig transactions in batch from batch signatures",
+		Use:     "multisign-batch [file] [name] [[signature-file]...]",
+		Aliases: []string{"multi-sign-batch"},
+		Short:   "Assemble multisig transactions in batch from batch signatures",
 		Long: strings.TrimSpace(
 			fmt.Sprintf(`Assemble a batch of multisig transactions generated by batch sign command.
 

x/bank/README.md

@@ -504,15 +504,15 @@ parameters.
 
 A user can query and interact with the `bank` module using the CLI.
 
-### Query
+#### Query
 
 The `query` commands allow users to query `bank` state.
 
 ```shell
 simd query bank --help
 ```
 
-#### balances
+##### balances
 
 The `balances` command allows users to query account balances by address.
 
@@ -537,7 +537,7 @@ pagination:
   total: "0"
 ```
 
-#### denom-metadata
+##### denom-metadata
 
 The `denom-metadata` command allows users to query metadata for coin denominations. A user can query metadata for a single denomination using the `--denom` flag or all denominations without it.
 
@@ -566,7 +566,7 @@ metadata:
   symbol: STK
 ```
 
-#### total
+##### total
 
 The `total` command allows users to query the total supply of coins. A user can query the total supply for a single coin using the `--denom` flag or all coins without it.
 
@@ -587,7 +587,7 @@ amount: "10000000000"
 denom: stake
 ```
 
-#### send-enabled
+##### send-enabled
 
 The `send-enabled` command allows users to query for all or some SendEnabled entries.
 
@@ -613,15 +613,15 @@ pagination:
   total: 2 
 ```
 
-### Transactions
+#### Transactions
 
 The `tx` commands allow users to interact with the `bank` module.
 
 ```shell
 simd tx bank --help
 ```
 
-#### send
+##### send
 
 The `send` command allows users to send funds from one account to another.