Merge branch 'main' into son/check_bank_docs

client/keys/migrate.go

@@ -18,8 +18,6 @@ Otherwise, we try to deserialize it using Amino into LegacyInfo. If this attempt
 LegacyInfo to Protobuf serialization format and overwrite the keyring entry. If any error occurred, it will be 
 outputted in CLI and migration will be continued until all keys in the keyring DB are exhausted.
 See https://github.com/cosmos/cosmos-sdk/pull/9695 for more details.
-
-It is recommended to run in 'dry-run' mode first to verify all key migration material.
 `,
 		Args: cobra.NoArgs,
 		RunE: runMigrateCmd,

client/v2/README.md

@@ -2,7 +2,9 @@
 sidebar_position: 1
 ---
 
-# AutoCLI
+# Client/v2
+
+## AutoCLI
 
 :::note Synopsis
 This document details how to build CLI and REST interfaces for a module. Examples from various Cosmos SDK modules are included.
@@ -14,9 +16,9 @@ This document details how to build CLI and REST interfaces for a module. Example
 
 :::
 
-The `autocli` (also known as `client/v2`) package is a [Go library](https://pkg.go.dev/cosmossdk.io/client/v2/autocli) for generating CLI (command line interface) interfaces for Cosmos SDK-based applications. It provides a simple way to add CLI commands to your application by generating them automatically based on your gRPC service definitions. Autocli generates CLI commands and flags directly from your protobuf messages, including options, input parameters, and output parameters. This means that you can easily add a CLI interface to your application without having to manually create and manage commands.
+The `autocli` (also known as `client/v2/autocli`) package is a [Go library](https://pkg.go.dev/cosmossdk.io/client/v2/autocli) for generating CLI (command line interface) interfaces for Cosmos SDK-based applications. It provides a simple way to add CLI commands to your application by generating them automatically based on your gRPC service definitions. Autocli generates CLI commands and flags directly from your protobuf messages, including options, input parameters, and output parameters. This means that you can easily add a CLI interface to your application without having to manually create and manage commands.
 
-## Overview
+### Overview
 
 `autocli` generates CLI commands and flags for each method defined in your gRPC service. By default, it generates commands for each gRPC services. The commands are named based on the name of the service method.
 
@@ -32,7 +34,7 @@ For instance, `autocli` would generate a command named `my-method` for the `MyMe
 
 It is possible to customize the generation of transactions and queries by defining options for each service.
 
-## Application Wiring
+### Application Wiring
 
 Here are the steps to use AutoCLI:
 
@@ -73,7 +75,7 @@ if err := rootCmd.Execute(); err != nil {
 }
 ```
 
-### Keyring
+#### Keyring
 
 `autocli` uses a keyring for key name resolving names and signing transactions.
 
@@ -100,7 +102,7 @@ keyring.NewAutoCLIKeyring(kb)
 
 :::
 
-## Signing
+### Signing
 
 `autocli` supports signing transactions with the keyring.
 The [`cosmos.msg.v1.signer` protobuf annotation](https://docs.cosmos.network/main/build/building-modules/protobuf-annotations) defines the signer field of the message.
@@ -110,7 +112,7 @@ This field is automatically filled when using the `--from` flag or defining the
 AutoCLI currently supports only one signer per transaction.
 :::
 
-## Module wiring & Customization
+### Module wiring & Customization
 
 The `AutoCLIOptions()` method on your module allows to specify custom commands, sub-commands or flags for each service, as it was a `cobra.Command` instance, within the `RpcCommandOptions` struct. Defining such options will customize the behavior of the `autocli` command generation, which by default generates a command for each method in your gRPC service.
 
@@ -131,31 +133,7 @@ AutoCLI can create a gov proposal of any tx by simply setting the `GovProposal`
 Users can however use the `--no-proposal` flag to disable the proposal creation (which is useful if the authority isn't the gov module on a chain).
 :::
 
-### Conventions for the `Use` field in Cobra
-
-According to the [Cobra documentation](https://pkg.go.dev/github.com/spf13/cobra#Command) the following conventions should be followed for the `Use` field in Cobra commands:
-
-1. **Required arguments**:
-   * Should not be enclosed in brackets. They can be enclosed in angle brackets `< >` for clarity.
-   * Example: `command <required_argument>`
-
-2. **Optional arguments**:
-   * Should be enclosed in square brackets `[ ]`.
-   * Example: `command [optional_argument]`
-
-3. **Alternative (mutually exclusive) arguments**:
-   * Should be enclosed in curly braces `{ }`.
-   * Example: `command {-a | -b}` for required alternatives.
-   * Example: `command [-a | -b]` for optional alternatives.
-
-4. **Multiple arguments**:
-   * Indicated with `...` after the argument.
-   * Example: `command argument...`
-
-5. **Combination of options**:
-   * Example: `command [-F file | -D dir]... [-f format] profile`
-
-### Specifying Subcommands
+#### Specifying Subcommands
 
 By default, `autocli` generates a command for each method in your gRPC service. However, you can specify subcommands to group related commands together. To specify subcommands, use the `autocliv1.ServiceCommandDescriptor` struct.
 
@@ -165,7 +143,7 @@ This example shows how to use the `autocliv1.ServiceCommandDescriptor` struct to
 https://github.com/cosmos/cosmos-sdk/blob/v0.50.0-beta.0/x/gov/autocli.go#L94-L97
 ```
 
-### Positional Arguments
+#### Positional Arguments
 
 By default `autocli` generates a flag for each field in your protobuf message. However, you can choose to use positional arguments instead of flags for certain fields.
 
@@ -183,7 +161,7 @@ Then the command can be used as follows, instead of having to specify the `--add
 <appd> query auth account cosmos1abcd...xyz
 ```
 
-### Customising Flag Names
+#### Customising Flag Names
 
 By default, `autocli` generates flag names based on the names of the fields in your protobuf message. However, you can customise the flag names by providing a `FlagOptions`. This parameter allows you to specify custom names for flags based on the names of the message fields.
 
@@ -200,7 +178,7 @@ autocliv1.RpcCommandOptions{
 
 `FlagsOptions` is defined like sub commands in the `AutoCLIOptions()` method on your module.
 
-### Combining AutoCLI with Other Commands Within A Module
+#### Combining AutoCLI with Other Commands Within A Module
 
 AutoCLI can be used alongside other commands within a module. For example, the `gov` module uses AutoCLI to generate commands for the `query` subcommand, but also defines custom commands for the `proposer` subcommands.
 
@@ -212,7 +190,7 @@ https://github.com/cosmos/cosmos-sdk/blob/fa4d87ef7e6d87aaccc94c337ffd2fe90fcb7a
 
 If not set to true, `AutoCLI` will not generate commands for the module if there are already commands registered for the module (when `GetTxCmd()` or `GetQueryCmd()` are defined).
 
-### Skip a command
+#### Skip a command
 
 AutoCLI automatically skips unsupported commands when [`cosmos_proto.method_added_in` protobuf annotation](https://docs.cosmos.network/main/build/building-modules/protobuf-annotations) is present.
 
@@ -225,7 +203,7 @@ Additionally, a command can be manually skipped using the `autocliv1.RpcCommandO
 }
 ```
 
-### Use AutoCLI for non module commands
+#### Use AutoCLI for non module commands
 
 It is possible to use `AutoCLI` for non module commands. The trick is still to implement the `appmodule.Module` interface and append it to the `appOptions.ModuleOptions` map.
 
@@ -235,7 +213,31 @@ For example, here is how the SDK does it for `cometbft` gRPC commands:
 https://github.com/cosmos/cosmos-sdk/blob/main/client/grpc/cmtservice/autocli.go#L52-L71
 ```
 
-## Summary
+#### Conventions for the `Use` field in Cobra
+
+According to the [Cobra documentation](https://pkg.go.dev/github.com/spf13/cobra#Command) the following conventions should be followed for the `Use` field in Cobra commands:
+
+1. **Required arguments**:
+   * Should not be enclosed in brackets. They can be enclosed in angle brackets `< >` for clarity.
+   * Example: `command <required_argument>`
+
+2. **Optional arguments**:
+   * Should be enclosed in square brackets `[ ]`.
+   * Example: `command [optional_argument]`
+
+3. **Alternative (mutually exclusive) arguments**:
+   * Should be enclosed in curly braces `{ }`.
+   * Example: `command {-a | -b}` for required alternatives.
+   * Example: `command [-a | -b]` for optional alternatives.
+
+4. **Multiple arguments**:
+   * Indicated with `...` after the argument.
+   * Example: `command argument...`
+
+5. **Combination of options**:
+   * Example: `command [-F file | -D dir]... [-f format] profile`
+
+### Summary
 
 `autocli` lets you generate CLI to your Cosmos SDK-based applications without any cobra boilerplate. It allows you to easily generate CLI commands and flags from your protobuf messages, and provides many options for customising the behavior of your CLI application.
 
@@ -245,7 +247,7 @@ For more information on `hubl`, including how to configure a new chain and query
 
 # Off-Chain
 
-Off-chain functionalities allow you to sign and verify files with two commands:
+Off-chain is a `client/v2` package providing functionalities for allowing to sign and verify files with two commands:
 
 * `sign-file` for signing a file.
 * `verify-file` for verifying a previously signed file.
@@ -275,6 +277,7 @@ The `encoding` flag lets you choose how the contents of the file should be encod
         "signer":  "cosmos1x33fy6rusfprkntvjsfregss7rvsvyy4lkwrqu",
         "data":  "Hello World!\n"
       }
+
      ```
 
 * `simd off-chain sign-file alice myFile.json --encoding base64`
@@ -286,6 +289,7 @@ The `encoding` flag lets you choose how the contents of the file should be encod
         "signer":  "cosmos1x33fy6rusfprkntvjsfregss7rvsvyy4lkwrqu",
         "data":  "SGVsbG8gV29ybGQhCg=="
       }
+
      ```
 
 * `simd off-chain sign-file alice myFile.json --encoding hex`

core/testing/go.mod

@@ -3,7 +3,7 @@ module cosmossdk.io/core/testing
 go 1.23
 
 require (
-	cosmossdk.io/core v1.0.0-alpha.3
+	cosmossdk.io/core v1.0.0-alpha.4
 	github.com/golang/mock v1.6.0
 	github.com/tidwall/btree v1.7.0
 )

core/testing/go.sum

@@ -1,5 +1,5 @@
-cosmossdk.io/core v1.0.0-alpha.3 h1:pnxaYAas7llXgVz1lM7X6De74nWrhNKnB3yMKe4OUUA=
-cosmossdk.io/core v1.0.0-alpha.3/go.mod h1:3u9cWq1FAVtiiCrDPpo4LhR+9V6k/ycSG4/Y/tREWCY=
+cosmossdk.io/core v1.0.0-alpha.4 h1:9iuroT9ejDYETCsGkzkvs/wAY/5UFl7nCIINFRxyMJY=
+cosmossdk.io/core v1.0.0-alpha.4/go.mod h1:3u9cWq1FAVtiiCrDPpo4LhR+9V6k/ycSG4/Y/tREWCY=
 cosmossdk.io/schema v0.3.0 h1:01lcaM4trhzZ1HQTfTV8z6Ma1GziOZ/YmdzBN3F720c=
 cosmossdk.io/schema v0.3.0/go.mod h1:RDAhxIeNB4bYqAlF4NBJwRrgtnciMcyyg0DOKnhNZQQ=
 github.com/golang/mock v1.6.0 h1:ErTB+efbowRARo13NNdxyJji2egdxLGQhRaY+DUumQc=

docs/architecture/PROCESS.md

@@ -1,8 +1,8 @@
 # ADR Creation Process
 
 1. Copy the `adr-template.md` file. Use the following filename pattern: `adr-next_number-title.md`
-2. Create a draft Pull Request if you want to get an early feedback.
-3. Make sure the context and solution is clear and well documented.
+2. Create a draft Pull Request if you want to get early feedback.
+3. Make sure the context and solution are clear and well documented.
 4. Add an entry to a list in the [README](./README.md) file.
 5. Create a Pull Request to propose a new ADR.
 
@@ -14,7 +14,7 @@ An ADR is a document to document an implementation and design that may or may no
 
 ADR creation is an **iterative** process. Instead of having a high amount of communication overhead, an ADR is used when there is already a decision made and implementation details need to be added. The ADR should document what the collective consensus for the specific issue is and how to solve it. 
 
-1. Every ADR should start with either an RFC or discussion where consensus has been met. 
+1. Every ADR should start with either an RFC or a discussion where consensus has been met. 
 
 2. Once consensus is met, a GitHub Pull Request (PR) is created with a new document based on the `adr-template.md`.
 
@@ -44,9 +44,9 @@ DRAFT -> PROPOSED -> LAST CALL yyyy-mm-dd -> ACCEPTED | REJECTED -> SUPERSEDED b
                      ABANDONED
 ```
 
-* `DRAFT`: [optional] an ADR which is work in progress, not being ready for a general review. This is to present an early work and get an early feedback in a Draft Pull Request form.
-* `PROPOSED`: an ADR covering a full solution architecture and still in the review - project stakeholders haven't reached an agreed yet.
-* `LAST CALL <date for the last call>`: [optional] clear notify that we are close to accept updates. Changing a status to `LAST CALL` means that social consensus (of Cosmos SDK maintainers) has been reached and we still want to give it a time to let the community react or analyze.
+* `DRAFT`: [optional] an ADR which is a work in progress, not being ready for a general review. This is to present an early work and get early feedback in a Draft Pull Request form.
+* `PROPOSED`: an ADR covering a full solution architecture and still in the review - project stakeholders haven't reached an agreement yet.
+* `LAST CALL <date for the last call>`: [optional] Notify that we are close to accepting updates. Changing a status to `LAST CALL` means that social consensus (of Cosmos SDK maintainers) has been reached and we still want to give it a time to let the community react or analyze.
 * `ACCEPTED`: ADR which will represent a currently implemented or to be implemented architecture design.
 * `REJECTED`: ADR can go from PROPOSED or ACCEPTED to rejected if the consensus among project stakeholders will decide so.
 * `SUPERSEDED by ADR-xxx`: ADR which has been superseded by a new ADR.

docs/architecture/adr-043-nft-module.md

@@ -17,9 +17,9 @@ This ADR defines the `x/nft` module which is a generic implementation of NFTs, r
 
 * `MsgNewClass` - Receive the user's request to create a class, and call the `NewClass` of the `x/nft` module.
 * `MsgUpdateClass` - Receive the user's request to update a class, and call the `UpdateClass` of the `x/nft` module.
-* `MsgMintNFT` - Receive the user's request to mint a nft, and call the `MintNFT` of the `x/nft` module.
-* `BurnNFT` - Receive the user's request to burn a nft, and call the `BurnNFT` of the `x/nft` module.
-* `UpdateNFT` - Receive the user's request to update a nft, and call the `UpdateNFT` of the `x/nft` module.
+* `MsgMintNFT` - Receive the user's request to mint an NFT, and call the `MintNFT` of the `x/nft` module.
+* `BurnNFT` - Receive the user's request to burn an NFT, and call the `BurnNFT` of the `x/nft` module.
+* `UpdateNFT` - Receive the user's request to update an NFT, and call the `UpdateNFT` of the `x/nft` module.
 
 ## Context
 
@@ -48,7 +48,7 @@ We create a `x/nft` module, which contains the following functionality:
 * Expose external `Message` interface for users to transfer ownership of their NFTs.
 * Query NFTs and their supply information.
 
-The proposed module is a base module for NFT app logic. It's goal it to provide a common layer for storage, basic transfer functionality and IBC. The module should not be used as a standalone.
+The proposed module is a base module for NFT app logic. Its goal is to provide a common layer for storage, basic transfer functionality and IBC. The module should not be used as a standalone.
 Instead an app should create a specialized module to handle app specific logic (eg: NFT ID construction, royalty), user level minting and burning. Moreover an app specialized module should handle auxiliary data to support the app logic (eg indexes, ORM, business data).
 
 All data carried over IBC must be part of the `NFT` or `Class` type described below. The app specific NFT data should be encoded in `NFT.data` for cross-chain integrity. Other objects related to NFT, which are not important for integrity can be part of the app specific module.
@@ -58,7 +58,7 @@ All data carried over IBC must be part of the `NFT` or `Class` type described be
 We propose two main types:
 
 * `Class` -- describes NFT class. We can think about it as a smart contract address.
-* `NFT` -- object representing unique, non fungible asset. Each NFT is associated with a Class.
+* `NFT` -- object representing unique, non-fungible asset. Each NFT is associated with a class.
 
 #### Class
 
@@ -81,7 +81,7 @@ message Class {
 * `symbol` is the symbol usually shown on exchanges for the NFT class; _optional_
 * `description` is a detailed description of the NFT class; _optional_
 * `uri` is a URI for the class metadata stored off chain. It should be a JSON file that contains metadata about the NFT class and NFT data schema ([OpenSea example](https://docs.opensea.io/docs/contract-level-metadata)); _optional_
-* `uri_hash` is a hash of the document pointed by uri; _optional_
+* `uri_hash` is a hash of the document pointed by URI; _optional_
 * `data` is app specific metadata of the class; _optional_
 
 #### NFT
@@ -107,7 +107,7 @@ message NFT {
 
 * `uri` is a URI for the NFT metadata stored off chain. Should point to a JSON file that contains metadata about this NFT (Ref: [ERC721 standard and OpenSea extension](https://docs.opensea.io/docs/metadata-standards)); _required_
 * `uri_hash` is a hash of the document pointed by uri; _optional_
-* `data` is an app specific data of the NFT. CAN be used by composing modules to specify additional properties of the NFT; _optional_
+* `data` is an app specific data of the NFT. Can be used by composing modules to specify additional properties of the NFT; _optional_
 
 This ADR doesn't specify values that `data` can take; however, best practices recommend upper-level NFT modules clearly specify their contents.  Although the value of this field doesn't provide the additional context required to manage NFT records, which means that the field can technically be removed from the specification, the field's existence allows basic informational/UI functionality.