chore: remove repetitive words (#19908)

client/tx/factory.go

@@ -449,7 +449,7 @@ func (f Factory) BuildSimTx(msgs ...sdk.Msg) ([]byte, error) {
 // getSimPK gets the public key to use for building a simulation tx.
 // Note, we should only check for keys in the keybase if we are in simulate and execute mode,
 // e.g. when using --gas=auto.
-// When using --dry-run, we are is simulation mode only and should not check the keybase.
+// When using --dry-run, we are in simulation mode only and should not check the keybase.
 // Ref: https://github.com/cosmos/cosmos-sdk/issues/11283
 func (f Factory) getSimPK() (cryptotypes.PubKey, error) {
 	var (

docs/architecture/adr-050-sign-mode-textual-annex1.md

@@ -272,7 +272,7 @@ Examples:
 
 The number 35 was chosen because it is the longest length where the hashed-and-prefixed representation is longer than the original data directly formatted, using the 3 rules above. More specifically:
 - a 35-byte array will have 70 hex characters, plus 17 space characters, resulting in 87 characters.
-- byte arrays starting from length 36 will be be hashed to 32 bytes, which is 64 hex characters plus 15 spaces, and with the `SHA-256=` prefix, it takes 87 characters.
+- byte arrays starting from length 36 will be hashed to 32 bytes, which is 64 hex characters plus 15 spaces, and with the `SHA-256=` prefix, it takes 87 characters.
 Also, secp256k1 public keys have length 33, so their Textual representation is not their hashed value, which we would like to avoid.
 
 Note: Data longer than 35 bytes are not rendered in a way that can be inverted. See ADR-050's [section about invertability](./adr-050-sign-mode-textual.md#invertible-rendering) for a discussion.

docs/spec/SPEC_STANDARD.md

@@ -31,7 +31,7 @@ This section should include a motivation sub-section and a definitions sub-secti
 
 ### System model and properties
 
-This section should include an assumptions sub-section if any, the mandatory properties sub-section, and a dependencies sub-section. Note that the first two sub-section are are tightly coupled: how to enforce a property will depend directly on the assumptions made. This sub-section is important to capture the interactions of the specified feature with the "rest-of-the-world", i.e., with other features of the ecosystem.
+This section should include an assumptions sub-section if any, the mandatory properties sub-section, and a dependencies sub-section. Note that the first two sub-section are tightly coupled: how to enforce a property will depend directly on the assumptions made. This sub-section is important to capture the interactions of the specified feature with the "rest-of-the-world", i.e., with other features of the ecosystem.
 
 * *Assumptions* - A list of any assumptions made by the feature designer. It should capture which features are used by the feature under specification, and what do we expect from them.
 * *Properties* - A list of the desired properties or characteristics of the feature specified, and expected effects or failures when the properties are violated. In case it is relevant, it can also include a list of properties that the feature does not guarantee.

store/storage/README.md

@@ -100,7 +100,7 @@ with only the necessary methods. The `StorageStore` interface is meant to wrap o
 accept this `Database` type, e.g. RocksDB.
 
 The `StorageStore` interface is an abstraction or wrapper around the backing SS
-engine can be seen as the the main entry point to using SS.
+engine can be seen as the main entry point to using SS.
 
 Higher up the stack, there should exist a `root.Store` implementation. The `root.Store`
 is meant to encapsulate both an SS backend and an SC backend. The SS backend is