fix: spelling/grammar across docs and tooling (#25677)

viktorking7 · aljo242 · web-flow · commit 46a7f918d6d6 · 2025-12-12T00:01:30.000Z
Co-authored-by: Alex | Cosmos Labs &lt;alex@cosmoslabs.io&gt;
diff --git a/README.md b/README.md
@@ -28,7 +28,7 @@ The Cosmos SDK is a modular, open-source blockchain SDK for building secure, hig
 
 The Cosmos SDK is tailored for building secure, sovereign application-specific blockchains. Developers building with the Cosmos SDK can use predefined modules that cover standard blockchain functionality or create custom modules for their specific use case. This composable architecture enables robust customization. The SDK provides abstractions for permissioning, governance, state management, account abstraction, tokenization processes, application logic, and more.
 
-Cosmos SDK blockchains get interoperability out-of-the-box via a native integration with the [Inter-Blockchain Communication Protocol (IBC)](https://github.com/cosmos/ibc-go). Ibc-go is implemented as a Go module in the Cosmos SDK. 
+Cosmos SDK blockchains get interoperability out-of-the-box via a native integration with the [Inter-Blockchain Communication Protocol (IBC)](https://github.com/cosmos/ibc-go). ibc-go is implemented as a Go module in the Cosmos SDK. 
 
 While the Cosmos SDK is plug-and-play with any consensus engine, we recommend using [CometBFT](https://github.com/cometbft/cometbft) for a fast, battle-tested, high-throughput, configurable BFT state machine. CometBFT is developed as part of the Cosmos Stack and its releases are updated alongside the SDK.
 
diff --git a/client/debug/main.go b/client/debug/main.go
@@ -104,7 +104,7 @@ func PubkeyCmd() *cobra.Command {
 	return &cobra.Command{
 		Use:   "pubkey [pubkey]",
 		Short: "Decode a pubkey from proto JSON",
-		Long: fmt.Sprintf(`Decode a pubkey from proto JSON and display it's address.
+		Long: fmt.Sprintf(`Decode a pubkey from proto JSON and display its address.
 
 Example:
 $ %s debug pubkey '{"@type":"/cosmos.crypto.secp256k1.PubKey","key":"AurroA7jvfPd1AadmmOvWM2rJSwipXfRf8yD6pLbA2DJ"}'
diff --git a/collections/README.md b/collections/README.md
@@ -122,7 +122,7 @@ var (
 
 #### Rules
 
-``collections.NewPrefix`` accepts either `uint8`, `string` or `[]bytes` it's good practice to use an always increasing `uint8`for disk space efficiency.
+``collections.NewPrefix`` accepts either `uint8`, `string` or `[]bytes` it's good practice to use an always increasing `uint8` for disk space efficiency.
 
 A collection **MUST NOT** share the same prefix as another collection in the same module, and a collection prefix **MUST NEVER** start with the same prefix as another, examples:
 
@@ -397,7 +397,7 @@ func (k Keeper) RemoveValidator(ctx sdk.Context, validator sdk.ValAddress) error
 }
 ```
 
-The first difference we notice is that `KeySet` needs use to specify only one type parameter: the key (`sdk.ValAddress` in this case).
+The first difference we notice is that `KeySet` needs us to specify only one type parameter: the key (`sdk.ValAddress` in this case).
 The second difference we notice is that `KeySet` in its `NewKeySet` function does not require
 us to specify a `ValueCodec` but only a `KeyCodec`. This is because a `KeySet` only saves keys and not values.
 
@@ -605,7 +605,7 @@ we specified in the range.
 Then we use again the `Values` method of the `Iterator` to collect all the results.
 
 `collections.Range` also offers a `Prefix` API which is not applicable to all keys types,
-for example uint64 cannot be prefix because it is of constant size, but a `string` key
+for example uint64 cannot be prefixed because it is of constant size, but a `string` key
 can be prefixed.
 
 #### IterateAccounts
@@ -648,7 +648,7 @@ Let's see now how we can work with composite keys using collections.
 
 ### Example
 
-In our example we will show-case how we can use collections when we are dealing with balances, similar to bank,
+In our example we will showcase how we can use collections when we are dealing with balances, similar to bank,
 a balance is a mapping between `(address, denom) => math.Int` the composite key in our case is `(address, denom)`.
 
 ## Instantiation of a composite key collection
diff --git a/contrib/x/group/internal/orm/README.md b/contrib/x/group/internal/orm/README.md
@@ -24,7 +24,7 @@ A table can be built given a `codec.ProtoMarshaler` model type, a prefix to acce
 https://github.com/cosmos/cosmos-sdk/tree/release/v0.50.x/x/group/internal/orm/table.go#L30-L36
 ```
 
-In the prefix store, entities should be stored by an unique identifier called `RowID` which can be based either on an `uint64` auto-increment counter, string or dynamic size bytes.
+In the prefix store, entities should be stored by a unique identifier called `RowID` which can be based either on a `uint64` auto-increment counter, string or dynamic size bytes.
 Regular CRUD operations can be performed on a table, these methods take a `sdk.KVStore` as parameter to get the table prefix store.
 
 The `table` struct does not:
diff --git a/contrib/x/group/internal/orm/table.go b/contrib/x/group/internal/orm/table.go
@@ -21,7 +21,7 @@ var (
 )
 
 // table is the high level object to storage mapper functionality. Persistent
-// entities are stored by an unique identifier called `RowID`. The table struct
+// entities are stored by a unique identifier called `RowID`. The table struct
 // does not:
 // - enforce uniqueness of the `RowID`
 // - enforce prefix uniqueness of keys, i.e. not allowing one key to be a prefix
diff --git a/docs/architecture/adr-040-storage-and-smt-state-commitments.md b/docs/architecture/adr-040-storage-and-smt-state-commitments.md
@@ -192,7 +192,7 @@ The presented workaround can be used until the IBC module is fully upgraded to s
 
 We consider a compression of prefix keys by creating a mapping from module key to an integer, and serializing the integer using varint coding. Varint coding assures that different values don't have common byte prefix. For Merkle Proofs we can't use prefix compression - so it should only apply for the `SS` keys. Moreover, the prefix compression should be only applied for the module namespace. More precisely:
 
-* each module has it's own namespace;
+* each module has its own namespace;
 * when accessing a module namespace we create a KVStore with embedded prefix;
 * that prefix will be compressed only when accessing and managing `SS`.
 
@@ -279,7 +279,7 @@ We were discussing use case where modules can use a support database, which is n
 ## References
 
 * [IAVL What's Next?](https://github.com/cosmos/cosmos-sdk/issues/7100)
-* [IAVL overview](https://docs.google.com/document/d/16Z_hW2rSAmoyMENO-RlAhQjAG3mSNKsQueMnKpmcBv0/edit#heading=h.yd2th7x3o1iv) of it's state v0.15
+* [IAVL overview](https://docs.google.com/document/d/16Z_hW2rSAmoyMENO-RlAhQjAG3mSNKsQueMnKpmcBv0/edit#heading=h.yd2th7x3o1iv) of its state v0.15
 * [State commitments and storage report](https://paper.dropbox.com/published/State-commitments-and-storage-review--BDvA1MLwRtOx55KRihJ5xxLbBw-KeEB7eOd11pNrZvVtqUgL3h)
 * [Celestia (LazyLedger) SMT](https://github.com/lazyledger/smt)
 * Facebook Diem (Libra) SMT [design](https://developers.diem.com/papers/jellyfish-merkle-tree/2021-01-14.pdf)
diff --git a/docs/architecture/adr-048-consensus-fees.md b/docs/architecture/adr-048-consensus-fees.md
@@ -14,7 +14,7 @@ This ADR describes a flexible mechanism to maintain a consensus level gas prices
 
 ## Context
 
-Currently, each validator configures it's own `minimal-gas-prices` in `app.yaml`. But setting a proper minimal gas price is critical to protect network from dos attack, and it's hard for all the validators to pick a sensible value, so we propose to maintain a gas price in consensus level.
+Currently, each validator configures its own `minimal-gas-prices` in `app.yaml`. But setting a proper minimal gas price is critical to protect network from DoS attack, and it's hard for all the validators to pick a sensible value, so we propose to maintain a gas price in consensus level.
 
 Since tendermint 0.34.20 has supported mempool prioritization, we can take advantage of that to implement more sophisticated gas fee system.
 
diff --git a/docs/architecture/adr-049-state-sync-hooks.md b/docs/architecture/adr-049-state-sync-hooks.md
@@ -116,7 +116,7 @@ type ExtensionPayloadReader = func() ([]byte, error)
 type ExtensionPayloadWriter = func([]byte) error
 
 // ExtensionSnapshotter is an extension Snapshotter that is appended to the snapshot stream.
-// ExtensionSnapshotter has an unique name and manages it's own internal formats.
+// ExtensionSnapshotter has a unique name and manages its own internal formats.
 type ExtensionSnapshotter interface {
 	// SnapshotName returns the name of snapshotter, it should be unique in the manager.
 	SnapshotName() string
diff --git a/docs/architecture/adr-060-abci-1.0.md b/docs/architecture/adr-060-abci-1.0.md
@@ -137,7 +137,7 @@ transactions entirely with other transactions.
 
 When evaluating transactions from `RequestPrepareProposal`, the application will
 ignore *ALL* transactions sent to it in the request and instead reap up to
-`RequestPrepareProposal.max_tx_bytes` from it's own mempool.
+`RequestPrepareProposal.max_tx_bytes` from its own mempool.
 
 Since an application can technically insert or inject transactions on `Insert`
 during `CheckTx` execution, it is recommended that applications ensure transaction
diff --git a/docs/architecture/adr-064-abci-2.0.md b/docs/architecture/adr-064-abci-2.0.md
@@ -286,7 +286,7 @@ decision based on the vote extensions.
 > nor the vote extension verification mechanism described above is required for
 > applications to implement. In other words, a proposer is not required to verify
 > and propagate vote extensions along with their signatures nor are proposers
-> required to verify those signatures. An application can implement it's own
+> required to verify those signatures. An application can implement its own
 > PKI mechanism and use that to sign and verify vote extensions.
 
 #### Vote Extension Persistence
diff --git a/docs/docs/user/run-node/06-run-production.md b/docs/docs/user/run-node/06-run-production.md
@@ -40,10 +40,10 @@ Now when logging into the server, the non `root` user can be used.
 
 ### Go
 
-1. Install the [Go](https://go.dev/doc/install) version preconized by the application.
+1. Install the [Go](https://go.dev/doc/install) version recommended by the application.
 
 :::warning
-In the past, validators [have had issues](https://github.com/cosmos/cosmos-sdk/issues/13976) when using different versions of Go. It is recommended that the whole validator set uses the version of Go that is preconized by the application.
+In the past, validators [have had issues](https://github.com/cosmos/cosmos-sdk/issues/13976) when using different versions of Go. It is recommended that the whole validator set uses the version of Go that is recommended by the application.
 :::
 
 ### Firewall
diff --git a/docs/rfc/rfc-001-tx-validation.md b/docs/rfc/rfc-001-tx-validation.md
@@ -22,4 +22,4 @@ We can and will still support the `ValidateBasic` function for users and provide
 
 ### Consequences
 
-The consequence of updating the transaction flow is that transaction that may have failed before with the `ValidateBasic` flow will now be included in a block and the fees charged. 
+The consequence of updating the transaction flow is that transactions that may have failed before with the `ValidateBasic` flow will now be included in a block and the fees charged. 
diff --git a/docs/spec/_ics/ics-030-signed-messages.md b/docs/spec/_ics/ics-030-signed-messages.md
@@ -152,7 +152,7 @@ more complex structures, apart from just string messages, and still be able to
 know exactly what they are signing (opposed to signing a bunch of arbitrary bytes).
 
 Thus, in the future, the Cosmos signing message specification will be expected
-to expand upon it's canonical JSON structure to include such functionality.
+to expand upon its canonical JSON structure to include such functionality.
 
 ## API
 
diff --git a/docs/spec/store/README.md b/docs/spec/store/README.md
@@ -29,9 +29,9 @@ with, which also provides the basis of most state storage and commitment operati
 is the `KVStore`. The `KVStore` interface provides basic CRUD abilities and
 prefix-based iteration, including reverse iteration.
 
-Typically, each module has it's own dedicated `KVStore` instance, which it can
+Typically, each module has its own dedicated `KVStore` instance, which it can
 get access to via the `sdk.Context` and the use of a pointer-based named key --
-`KVStoreKey`. The `KVStoreKey` provides pseudo-OCAP. How a exactly a `KVStoreKey`
+`KVStoreKey`. The `KVStoreKey` provides pseudo-OCAP. How exactly a `KVStoreKey`
 maps to a `KVStore` will be illustrated below through the `CommitMultiStore`.
 
 Note, a `KVStore` cannot directly commit state. Instead, a `KVStore` can be wrapped
@@ -194,7 +194,7 @@ a `BaseApp` instance which internally has a reference to a `CommitMultiStore`
 that is implemented by a `rootmulti.Store`. The application then registers one or
 more `KVStoreKey` that pertain to a unique module and thus a `KVStore`. Through
 the use of an `sdk.Context` and a `KVStoreKey`, each module can get direct access
-to it's respective `KVStore` instance.
+to its respective `KVStore` instance.
 
 Example:
 
@@ -227,7 +227,7 @@ func NewApp(...) Application {
 The `rootmulti.Store` itself can be cache-wrapped which returns an instance of a
 `cachemulti.Store`. For each block, `BaseApp` ensures that the proper abstractions
 are created on the `CommitMultiStore`, i.e. ensuring that the `rootmulti.Store`
-is cached-wrapped and uses the resulting `cachemulti.Store` to be set on the
+is cache-wrapped and uses the resulting `cachemulti.Store` to be set on the
 `sdk.Context` which is then used for block and transaction execution. As a result,
 all state mutations due to block and transaction execution are actually held
 ephemerally until `Commit()` is called by the ABCI client. This concept is further
diff --git a/store/snapshots/manager.go b/store/snapshots/manager.go
@@ -102,7 +102,7 @@ func (m *Manager) RegisterExtensions(extensions ...types.ExtensionSnapshotter) e
 			return fmt.Errorf("duplicated snapshotter name: %s", name)
 		}
 		if !IsFormatSupported(extension, extension.SnapshotFormat()) {
-			return fmt.Errorf("snapshotter don't support it's own snapshot format: %s %d", name, extension.SnapshotFormat())
+			return fmt.Errorf("snapshotter doesn't support its own snapshot format: %s %d", name, extension.SnapshotFormat())
 		}
 		m.extensions[name] = extension
 	}
diff --git a/store/snapshots/types/snapshotter.go b/store/snapshots/types/snapshotter.go
@@ -40,7 +40,7 @@ type ExtensionPayloadReader = func() ([]byte, error)
 type ExtensionPayloadWriter = func([]byte) error
 
 // ExtensionSnapshotter is an extension Snapshotter that is appended to the snapshot stream.
-// ExtensionSnapshotter has an unique name and manages its own internal formats.
+// ExtensionSnapshotter has a unique name and manages its own internal formats.
 type ExtensionSnapshotter interface {
 	// SnapshotName returns the name of snapshotter, it should be unique in the manager.
 	SnapshotName() string
diff --git a/telemetry/README.md b/telemetry/README.md
@@ -79,7 +79,7 @@ For a full list of configurable options see: https://github.com/open-telemetry/o
 The node's `init` command will generate an empty otel file in the `~/.<node_home>/config` directory. Place your otel configuration
 here. 
 
-When the node's `start` command is ran, the OpenTelemetry SDK will be initialized using this file. 
+When the node's `start` command is run, the OpenTelemetry SDK will be initialized using this file. 
 If left empty, all meters and tracers will be noop.
 
 ## OpenTelemetry Initialization
@@ -107,4 +107,3 @@ NOTE: it is important to thread context.Context properly for spans and metrics t
 correlated correctly.
 When using the SDK's context type, spans must be started with Context.StartSpan to
 get an SDK context which has the span set correctly.
-
diff --git a/x/auth/README.md b/x/auth/README.md
@@ -249,7 +249,7 @@ simd query auth --help
 
 #### account
 
-The `account` command allow users to query for an account by it's address.
+The `account` command allows users to query for an account by its address.
 
 ```bash
 simd query auth account [address] [flags]
@@ -504,7 +504,7 @@ A user can query the `auth` module using gRPC endpoints.
 
 #### Account
 
-The `account` endpoint allow users to query for an account by it's address.
+The `account` endpoint allows users to query for an account by its address.
 
 ```bash
 cosmos.auth.v1beta1.Query/Account
@@ -687,23 +687,23 @@ A user can query the `auth` module using REST endpoints.
 
 #### Account
 
-The `account` endpoint allow users to query for an account by it's address.
+The `account` endpoint allows users to query for an account by its address.
 
 ```bash
 /cosmos/auth/v1beta1/account?address={address}
 ```
 
 #### Accounts
 
-The `accounts` endpoint allow users to query all the available accounts.
+The `accounts` endpoint allows users to query all the available accounts.
 
 ```bash
 /cosmos/auth/v1beta1/accounts
 ```
 
 #### Params
 
-The `params` endpoint allow users to query the current auth parameters.
+The `params` endpoint allows users to query the current auth parameters.
 
 ```bash
 /cosmos/auth/v1beta1/params
diff --git a/x/bank/README.md b/x/bank/README.md
@@ -125,7 +125,7 @@ aforementioned state:
 
 ## Params
 
-The bank module stores it's params in state with the prefix of `0x05`,
+The bank module stores its params in state with the prefix of `0x05`,
 it can be updated with governance or the address with authority.
 
 * Params: `0x05 | ProtocolBuffer(Params)`
diff --git a/x/distribution/README.md b/x/distribution/README.md
@@ -198,7 +198,7 @@ type ValidatorDistInfo struct {
 ### Delegation Distribution
 
 Each delegation distribution only needs to record the height at which it last
-withdrew fees. Because a delegation must withdraw fees each time it's
+withdrew fees. Because a delegation must withdraw fees each time its
 properties change (aka bonded tokens etc.) its properties will remain constant
 and the delegator's _accumulation_ factor can be calculated passively knowing
 only the height of the last withdrawal and its current properties.
@@ -213,7 +213,7 @@ type DelegationDistInfo struct {
 
 ### Params
 
-The distribution module stores it's params in state with the prefix of `0x09`,
+The distribution module stores its params in state with the prefix of `0x09`,
 it can be updated with governance or the address with authority.
 
 * Params: `0x09 | ProtocolBuffer(Params)`
diff --git a/x/slashing/README.md b/x/slashing/README.md
@@ -148,7 +148,7 @@ https://github.com/cosmos/cosmos-sdk/blob/v0.47.0-rc1/proto/cosmos/slashing/v1be
 
 ### Params
 
-The slashing module stores it's params in state with the prefix of `0x00`,
+The slashing module stores its params in state with the prefix of `0x00`,
 it can be updated with governance or the address with authority.
 
 * Params: `0x00 | ProtocolBuffer(Params)`

Original file line number	Diff line number	Diff line change
`@@ -21,7 +21,7 @@ var (`
`21`	`21`	`)`
`22`	`22`
`23`	`23`	`// table is the high level object to storage mapper functionality. Persistent`
`24`		-// entities are stored by an unique identifier called `RowID`. The table struct
	`24`	+// entities are stored by a unique identifier called `RowID`. The table struct
`25`	`25`	`// does not:`
`26`	`26`	// - enforce uniqueness of the `RowID`
`27`	`27`	`// - enforce prefix uniqueness of keys, i.e. not allowing one key to be a prefix`