fix: correct typos and improve wording in ADRs and release checklist

.github/ISSUE_TEMPLATE/qa.md

@@ -15,7 +15,7 @@ v                     without deliberation
 
 ## Gotchas
 
-<!-- Gotchas is an area which changes could of been made that the auditors should be aware of -->
+<!-- Gotchas is an area which changes could have been made that the auditors should be aware of -->
 
 ## QA Breakdown
 
@@ -54,7 +54,7 @@ v                     without deliberation
 * [ ] Upgrade a chain with data from vX
 * Release documentation
     * [ ] Audit UPGRADING.md
-    * [ ] Update all codeblock to the appropriate version number
+    * [ ] Update all code block to the appropriate version number
 
 
 ### Audit checklist

SECURITY.md

@@ -39,7 +39,7 @@ We require that all researchers:
 
 * Abide by this policy to disclose vulnerabilities, and avoid posting
   vulnerability information in public places, including GitHub, Discord,
-  Telegram, and Twitter.
+  Telegram, and X.
 * Make every effort to avoid privacy violations, degradation of user experience,
   disruption to production systems (including but not limited to the Cosmos
   Hub), and destruction of data.

crypto/bcrypt_readme.md

@@ -1,10 +1,10 @@
 # Security parameter choice
 
-The present Bcrypt security parameter used is 12, which should take about a quarter of a second on midrange consumer hardware (see [Benchmarking](#benchmarking) section below).
+The present Bcrypt security parameter used is 12, which should take about a quarter of a second on mid-range consumer hardware (see [Benchmarking](#benchmarking) section below).
 
 For some background into security parameter considerations, see [here](https://auth0.com/blog/hashing-in-action-understanding-bcrypt/) and [here](https://security.stackexchange.com/questions/3959/recommended-of-iterations-when-using-pkbdf2-sha256/3993#3993).
 
-Given our security model, where an attacker would need to already have access to a victim's computer and copy the `~/.gaiacli` directory (as opposed to e.g. web authentication), this parameter choice seems sufficient for the time being. Bcrypt always generates a 448-bit key, so the security in practice is determined by the length & complexity of a user's password and the time taken to generate a Bcrypt key from their password (which we can choose with the security parameter). Users would be well-advised to use difficult-to-guess passwords.
+Given our security model, where an attacker would need to already have access to a victim's computer and copy the `~/.gaiacli` directory (as opposed to e.g. web authentication), this parameter choice seems sufficient for the time being. Bcrypt always generates a 448-bit key, so the security in practice is determined by the length & complexity of a user's password and the time taken to generate a Bcrypt key from their password (which we can choose with the security parameter). Users should be well-advised to use difficult-to-guess passwords.
 
 ## Benchmarking
 

docs/architecture/adr-003-dynamic-capability-store.md

@@ -8,8 +8,8 @@
 ## Context
 
 Full implementation of the [IBC specification](https://github.com/cosmos/ibc) requires the ability to create and authenticate object-capability keys at runtime (i.e., during transaction execution),
-as described in [ICS 5](https://github.com/cosmos/ibc/tree/master/spec/core/ics-005-port-allocation#technical-specification). In the IBC specification, capability keys are created for each newly initialised
-port & channel, and are used to authenticate future usage of the port or channel. Since channels and potentially ports can be initialised during transaction execution, the state machine must be able to create
+as described in [ICS 5](https://github.com/cosmos/ibc/tree/master/spec/core/ics-005-port-allocation#technical-specification). In the IBC specification, capability keys are created for each newly initialized
+port & channel, and are used to authenticate future usage of the port or channel. Since channels and potentially ports can be initialized during transaction execution, the state machine must be able to create
 object-capability keys at this time.
 
 At present, the Cosmos SDK does not have the ability to do this. Object-capability keys are currently pointers (memory addresses) of `StoreKey` structs created at application initialisation in `app.go` ([example](https://github.com/cosmos/gaia/blob/dcbddd9f04b3086c0ad07ee65de16e7adedc7da4/app/app.go#L132))
@@ -27,7 +27,7 @@ the `CapabilityKeeper` will be hooked up to modules through unique function refe
 (by calling `ScopeToModule`, defined below) so that it can identify the calling module when later
 invoked.
 
-When the initial state is loaded from disk, the `CapabilityKeeper`'s `Initialise` function will create
+When the initial state is loaded from disk, the `CapabilityKeeper`'s `Initialize` function will create
 new capability keys for all previously allocated capability identifiers (allocated during execution of
 past transactions and assigned to particular modes), and keep them in a memory-only store while the
 chain is running.
@@ -81,7 +81,7 @@ type ScopedCapabilityKeeper struct {
 ```
 
 `ScopeToModule` is used to create a scoped sub-keeper with a particular name, which must be unique.
-It MUST be called before `InitialiseAndSeal`.
+It MUST be called before `InitializeAndSeal`.
 
 ```go
 func (ck CapabilityKeeper) ScopeToModule(moduleName string) ScopedCapabilityKeeper {
@@ -272,7 +272,7 @@ mod2Keeper := NewMod2Keeper(ck.ScopeToModule("mod2"), ....)
 
 // load initial state...
 
-ck.InitialiseAndSeal(initialContext)
+ck.InitializeAndSeal(initialContext)
 ```
 
 #### Creating, passing, claiming and using capabilities

docs/architecture/adr-006-secret-store-replacement.md

@@ -15,11 +15,11 @@ This is not desirable for a number of reasons. Perhaps the biggest reason is ins
 
 All modern desktop computers OS (Ubuntu, Debian, MacOS, Windows) provide a built-in secret store that is designed to allow applications to store information that is isolated from all other applications and requires passphrase entry to access the data.
 
-We are seeking solution that provides a common abstraction layer to the many different backends and reasonable fallback for minimal platforms that don’t provide a native secret store.
+We are seeking a solution that provides a common abstraction layer to the many different backends and reasonable fallback for minimal platforms that don’t provide a native secret store.
 
 ## Decision
 
-We recommend replacing the current Keybase backend based on LevelDB with [Keyring](https://github.com/99designs/keyring) by 99 designs. This application is designed to provide a common abstraction and uniform interface between many secret stores and is used by AWS Vault application by 99-designs application.
+We recommend replacing the current Keybase backend based on LevelDB with [Keyring](https://github.com/99designs/keyring) by 99 designs. This application is designed to provide a common abstraction and uniform interface between many secret stores and is used by AWS Vault application by 99designs.
 
 This appears to fulfill the requirement of protecting both key material and metadata from rogue software on a user’s machine.
 
@@ -48,7 +48,7 @@ Running tests locally on a Mac require numerous repetitive password entries.
 ## References
 
 * #4754 Switch secret store to the keyring secret store (original PR by @poldsam) [__CLOSED__]
-* #5029 Add support for github.com/99designs/keyring-backed keybases [__MERGED__]
+* #5029 Add support for github.com/99designs/keyring-backed Keybases [__MERGED__]
 * #5097 Add keys migrate command [__MERGED__]
 * #5180 Drop on-disk keybase in favor of keyring [_PENDING_REVIEW_]
 * cosmos/gaia#164 Drop on-disk keybase in favor of keyring (gaia's changes) [_PENDING_REVIEW_]

docs/architecture/adr-012-state-accessors.md

@@ -67,7 +67,7 @@ func (Value) Set(ctx Context, o interface{}) {}
 // Check if a raw value exists
 func (Value) Exists(ctx Context) bool {}
 
-// Delete a raw value value
+// Delete a raw  value
 func (Value) Delete(ctx Context) {}
 ```
 

docs/architecture/adr-017-historical-header-module.md

@@ -12,14 +12,14 @@ In order for the Cosmos SDK to implement the [IBC specification](https://github.
 
 ## Decision
 
-The application MUST store the most recent `n` headers in a persistent store. At first, this store MAY be the current Merklised store. A non-Merklised store MAY be used later as no proofs are necessary.
+The application MUST store the most recent `n` headers in a persistent store. At first, this store MAY be the current Merkelized store. A non-Merkelized store MAY be used later as no proofs are necessary.
 
 The application MUST store this information by storing new headers immediately when handling `abci.RequestBeginBlock`:
 
 ```go
 func BeginBlock(ctx sdk.Context, keeper HistoricalHeaderKeeper) error {
   info := HistoricalInfo{
-    apphash: ctx.HeaderInfo().AppHash,
+    AppHash: ctx.HeaderInfo().AppHash,
     Time: ctx.HeaderInfo().Time,
     NextValidatorsHash: ctx.CometInfo().NextValidatorsHash,
   }

docs/architecture/adr-034-account-rekeying.md

@@ -10,7 +10,7 @@ PROPOSED
 
 ## Abstract
 
-Account rekeying is a process hat allows an account to replace its authentication pubkey with a new one.
+Account rekeying is a process that allows an account to replace its authentication pubkey with a new one.
 
 ## Context
 

server/README.md

@@ -85,6 +85,6 @@ func newApp(logger log.Logger, db corestore.KVStoreWithBatch, traceStore io.Writ
 ```
 
 Note, some of the options provided are exposed via CLI flags in the start command
-and some are also allowed to be set in the application's `app.toml`. It is recommend
+and some are also allowed to be set in the application's `app.toml`. It is recommended
 to use the `cast` package for type safety guarantees and due to the limitations of
 CLI flag types.

store/streaming/README.md

@@ -4,7 +4,7 @@ This package contains an extensible plugin system for the Cosmos-SDK. The plugin
 
 Although the `go-plugin` is built to work over RPC, it is currently only designed to work over a local network.
 
-## Pre requisites
+## Prerequisites
 
 For an overview of supported features by the `go-plugin` system, please see https://github.com/hashicorp/go-plugin. The `go-plugin` documentation is located [here](https://github.com/hashicorp/go-plugin/tree/master/docs). You can also directly visit any of the links below:
 

x/authz/README.md

@@ -34,7 +34,7 @@ granting arbitrary privileges from one account (the granter) to another account
 
 ### Authorization and Grant
 
-The `x/authz` module defines interfaces and messages grant authorizations to perform actions
+The x/authz module defines interfaces and messages that grant authorizations to perform actions
 on behalf of one account to other accounts. The design is defined in the [ADR 030](https://github.com/cosmos/cosmos-sdk/blob/main/docs/architecture/adr-030-authz-module.md).
 
 A *grant* is an allowance to execute a Msg by the grantee on behalf of the granter.
@@ -48,7 +48,7 @@ https://github.com/cosmos/cosmos-sdk/blob/v0.52.0-beta.1/x/authz/authorizations.
 
 ### Built-in Authorizations
 
-The Cosmos SDK `x/authz` module comes with following authorization types:
+The Cosmos SDK x/authz module comes with the following authorization types:
 
 #### GenericAuthorization