cosmos · robert-zaremba · Sep 28, 2021 · Sep 27, 2021 · Sep 27, 2021 · Sep 27, 2021
diff --git a/CHANGELOG.md b/CHANGELOG.md
@@ -120,7 +120,7 @@ Ref: https://keepachangelog.com/en/1.0.0/
 * [\#9699](https://github.com/cosmos/cosmos-sdk/pull/9699) Add `:`, `.`, `-`, and `_` as allowed characters in the default denom regular expression.
 
 ### Bug Fixes
-
+* [#10180](https://github.com/cosmos/cosmos-sdk/issues/10180) Documentation: make references to Cosmos SDK consistent
 * (store) [#10218](https://github.com/cosmos/cosmos-sdk/pull/10218) Charge gas even when there are no entries while seeking.
 * (x/genutil) [#10104](https://github.com/cosmos/cosmos-sdk/pull/10104) Ensure the `init` command reads the `--home` flag value correctly.
 * [\#9651](https://github.com/cosmos/cosmos-sdk/pull/9651) Change inconsistent limit of `0` to `MaxUint64` on InfiniteGasMeter and add GasRemaining func to GasMeter.

diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md
@@ -19,7 +19,7 @@
         - [Point Release Procedure](#point-release-procedure)
     - [Code Owner Membership](#code-owner-membership)
 
-Thank you for considering making contributions to Cosmos-SDK and related
+Thank you for considering making contributions to the Cosmos SDK and related
 repositories!
 
 Contributing to this repo can mean many things such as participating in
@@ -65,7 +65,7 @@ Other notes:
 
 ## Architecture Decision Records (ADR)
 
-When proposing an architecture decision for the SDK, please start by opening an [issue](https://github.com/cosmos/cosmos-sdk/issues/new/choose) or a [discussion](https://github.com/cosmos/cosmos-sdk/discussions/new) with a summary of the proposal. Once the proposal has been discussed and there is rough alignment on a high-level approach to the design, the [ADR creation process](https://github.com/cosmos/cosmos-sdk/blob/master/docs/architecture/PROCESS.md) can begin. We are following this process to ensure all involved parties are in agreement before any party begins coding the proposed implementation. If you would like to see examples of how these are written, please refer to the current [ADRs](https://github.com/cosmos/cosmos-sdk/tree/master/docs/architecture).
+When proposing an architecture decision for the Cosmos SDK, please start by opening an [issue](https://github.com/cosmos/cosmos-sdk/issues/new/choose) or a [discussion](https://github.com/cosmos/cosmos-sdk/discussions/new) with a summary of the proposal. Once the proposal has been discussed and there is rough alignment on a high-level approach to the design, the [ADR creation process](https://github.com/cosmos/cosmos-sdk/blob/master/docs/architecture/PROCESS.md) can begin. We are following this process to ensure all involved parties are in agreement before any party begins coding the proposed implementation. If you would like to see examples of how these are written, please refer to the current [ADRs](https://github.com/cosmos/cosmos-sdk/tree/master/docs/architecture).
 
 ## Pull Requests
 

diff --git a/LICENSE b/LICENSE
@@ -1,4 +1,4 @@
-Cosmos-SDK
+Cosmos SDK
 License: Apache2.0
 
                                  Apache License

diff --git a/docs/README.md b/docs/README.md
@@ -64,7 +64,7 @@ aside: false
 
 - **[Module Directory](../x/)**: Cosmos SDK module implementations and their respective documentation.
 - **[Specifications](./spec/)**: Specifications of modules and other parts of the Cosmos SDK.
-- **[SDK API Reference](https://godoc.org/github.com/cosmos/cosmos-sdk)**: Godocs of the Cosmos SDK.
+- **[Cosmos SDK API Reference](https://godoc.org/github.com/cosmos/cosmos-sdk)**: Godocs of the Cosmos SDK.
 - **[REST and RPC Endpoints](https://cosmos.network/rpc/)**: List of endpoints to interact with a `gaia` full-node.
 - **[Rosetta API](./run-node/rosetta.md)**: Rosetta API integration.
 

diff --git a/docs/architecture/adr-002-docs-structure.md b/docs/architecture/adr-002-docs-structure.md
@@ -2,7 +2,7 @@
 
 ## Context
 
-There is a need for a scalable structure of the SDK documentation. Current documentation includes a lot of non-related SDK material, is difficult to maintain and hard to follow as a user.
+There is a need for a scalable structure of the Cosmos SDK documentation. Current documentation includes a lot of non-related Cosmos SDK material, is difficult to maintain and hard to follow as a user.
 
 Ideally, we would have:
 
@@ -11,7 +11,7 @@ Ideally, we would have:
 
 ## Decision
 
-Re-structure the `/docs` folder of the SDK github repo as follows:
+Re-structure the `/docs` folder of the Cosmos SDK github repo as follows:
 
 ```
 docs/
@@ -40,9 +40,9 @@ docs/
 The files in each sub-folders do not matter and will likely change. What matters is the sectioning:
 
 - `README`: Landing page of the docs.
-- `intro`: Introductory material. Goal is to have a short explainer of the SDK and then channel people to the resource they need. The [sdk-tutorial](https://github.com/cosmos/sdk-application-tutorial/) will be highlighted, as well as the `godocs`.
-- `concepts`: Contains high-level explanations of the abstractions of the SDK. It does not contain specific code implementation and does not need to be updated often. **It is not an API specification of the interfaces**. API spec is the `godoc`.
-- `clients`: Contains specs and info about the various SDK clients.
+- `intro`: Introductory material. Goal is to have a short explainer of the Cosmos SDK and then channel people to the resource they need. The [Cosmos SDK tutorial](https://github.com/cosmos/sdk-application-tutorial/) will be highlighted, as well as the `godocs`.
+- `concepts`: Contains high-level explanations of the abstractions of the Cosmos SDK. It does not contain specific code implementation and does not need to be updated often. **It is not an API specification of the interfaces**. API spec is the `godoc`.
+- `clients`: Contains specs and info about the various Cosmos SDK clients.
 - `spec`: Contains specs of modules, and others.
 - `modules`: Contains links to `godocs` and the spec of the modules.
 - `architecture`: Contains architecture-related docs like the present one.
@@ -65,8 +65,8 @@ Accepted
 
 ### Positive
 
-- Much clearer organisation of the SDK docs.
-- The `/docs` folder now only contains SDK and gaia related material. Later, it will only contain SDK related material.
+- Much clearer organisation of the Cosmos SDK docs.
+- The `/docs` folder now only contains Cosmos SDK and gaia related material. Later, it will only contain Cosmos SDK related material.
 - Developers only have to update `/docs` folder when they open a PR (and not `/examples` for example).
 - Easier for developers to find what they need to update in the docs thanks to reworked architecture.
 - Cleaner vuepress build for website docs.

diff --git a/docs/architecture/adr-003-dynamic-capability-store.md b/docs/architecture/adr-003-dynamic-capability-store.md
@@ -21,7 +21,7 @@ This ADR proposes such an interface & mechanism.
 
 ## Decision
 
-The SDK will include a new `CapabilityKeeper` abstraction, which is responsible for provisioning,
+The Cosmos SDK will include a new `CapabilityKeeper` abstraction, which is responsible for provisioning,
 tracking, and authenticating capabilities at runtime. During application initialisation in `app.go`,
 the `CapabilityKeeper` will be hooked up to modules through unique function references
 (by calling `ScopeToModule`, defined below) so that it can identify the calling module when later

diff --git a/docs/architecture/adr-006-secret-store-replacement.md b/docs/architecture/adr-006-secret-store-replacement.md
@@ -4,12 +4,12 @@
 
 - July 29th, 2019: Initial draft
 - September 11th, 2019: Work has started
-- November 4th: SDK changes merged in
+- November 4th: Cosmos SDK changes merged in
 - November 18th: Gaia changes merged in
 
 ## Context
 
-Currently, an SDK application's CLI directory stores key material and metadata in a plain text database in the user’s home directory.  Key material is encrypted by a passphrase, protected by bcrypt hashing algorithm. Metadata (e.g. addresses, public keys, key storage details) is available in plain text.
+Currently, a Cosmos SDK application's CLI directory stores key material and metadata in a plain text database in the user’s home directory.  Key material is encrypted by a passphrase, protected by bcrypt hashing algorithm. Metadata (e.g. addresses, public keys, key storage details) is available in plain text.
 
 This is not desirable for a number of reasons. Perhaps the biggest reason is insufficient security protection of key material and metadata. Leaking the plain text allows an attacker to surveil what keys a given computer controls via a number of techniques, like compromised dependencies without any privilege execution. This could be followed by a more targeted attack on a particular user/computer.
 

diff --git a/docs/architecture/adr-010-modular-antehandler.md b/docs/architecture/adr-010-modular-antehandler.md
@@ -44,7 +44,7 @@ type Decorator interface {
 }
 ```
 
-Each decorator works like a modularized SDK antehandler function, but it can take in a `next` argument that may be another decorator or a Handler (which does not take in a next argument). These decorators can be chained together, one decorator being passed in as the `next` argument of the previous decorator in the chain. The chain ends in a Router which can take a tx and route to the appropriate msg handler.
+Each decorator works like a modularized Cosmos SDK antehandler function, but it can take in a `next` argument that may be another decorator or a Handler (which does not take in a next argument). These decorators can be chained together, one decorator being passed in as the `next` argument of the previous decorator in the chain. The chain ends in a Router which can take a tx and route to the appropriate msg handler.
 
 A key benefit of this approach is that one Decorator can wrap its internal logic around the next Checker/Deliverer. A weave Decorator may do the following:
 
@@ -84,7 +84,7 @@ If however, users wish to change the order or add, modify, or delete ante micro-
 
 This is an example of a user's AnteHandler if they choose not to make any custom micro-functions.
 
-##### SDK code
+##### Cosmos SDK code
 
 ```go
 // Chains together a list of AnteHandler micro-functions that get run one after the other.
@@ -186,13 +186,13 @@ Cons:
 
 ### Simple Decorators
 
-This approach takes inspiration from Weave's decorator design while trying to minimize the number of breaking changes to the SDK and maximizing simplicity. Like Weave decorators, this approach allows one `AnteDecorator` to wrap the next AnteHandler to do pre- and post-processing on the result. This is useful since decorators can do defer/cleanups after an AnteHandler returns as well as perform some setup beforehand. Unlike Weave decorators, these `AnteDecorator` functions can only wrap over the AnteHandler rather than the entire handler execution path. This is deliberate as we want decorators from different modules to perform authentication/validation on a `tx`. However, we do not want decorators being capable of wrapping and modifying the results of a `MsgHandler`.
+This approach takes inspiration from Weave's decorator design while trying to minimize the number of breaking changes to the Cosmos SDK and maximizing simplicity. Like Weave decorators, this approach allows one `AnteDecorator` to wrap the next AnteHandler to do pre- and post-processing on the result. This is useful since decorators can do defer/cleanups after an AnteHandler returns as well as perform some setup beforehand. Unlike Weave decorators, these `AnteDecorator` functions can only wrap over the AnteHandler rather than the entire handler execution path. This is deliberate as we want decorators from different modules to perform authentication/validation on a `tx`. However, we do not want decorators being capable of wrapping and modifying the results of a `MsgHandler`.
 
-In addition, this approach will not break any core SDK API's. Since we preserve the notion of an AnteHandler and still set a single AnteHandler in baseapp, the decorator is simply an additional approach available for users that desire more customization. The API of modules (namely `x/auth`) may break with this approach, but the core API remains untouched.
+In addition, this approach will not break any core Cosmos SDK API's. Since we preserve the notion of an AnteHandler and still set a single AnteHandler in baseapp, the decorator is simply an additional approach available for users that desire more customization. The API of modules (namely `x/auth`) may break with this approach, but the core API remains untouched.
 
-Allow Decorator interface that can be chained together to create an SDK AnteHandler.
+Allow Decorator interface that can be chained together to create a Cosmos SDK AnteHandler.
 
-This allows users to choose between implementing an AnteHandler by themselves and setting it in the baseapp, or use the decorator pattern to chain their custom decorators with SDK provided decorators in the order they wish.
+This allows users to choose between implementing an AnteHandler by themselves and setting it in the baseapp, or use the decorator pattern to chain their custom decorators with the Cosmos SDK provided decorators in the order they wish.
 
 ```go
 // An AnteDecorator wraps an AnteHandler, and can do pre- and post-processing on the next AnteHandler

diff --git a/docs/architecture/adr-011-generalize-genesis-accounts.md b/docs/architecture/adr-011-generalize-genesis-accounts.md
@@ -6,7 +6,7 @@
 
 ## Context
 
-Currently, the SDK allows for custom account types; the `auth` keeper stores any type fulfilling its `Account` interface. However `auth` does not handle exporting or loading accounts to/from a genesis file, this is done by `genaccounts`, which only handles one of 4 concrete account types (`BaseAccount`, `ContinuousVestingAccount`, `DelayedVestingAccount` and `ModuleAccount`).
+Currently, the Cosmos SDK allows for custom account types; the `auth` keeper stores any type fulfilling its `Account` interface. However `auth` does not handle exporting or loading accounts to/from a genesis file, this is done by `genaccounts`, which only handles one of 4 concrete account types (`BaseAccount`, `ContinuousVestingAccount`, `DelayedVestingAccount` and `ModuleAccount`).
 
 Projects desiring to use custom accounts (say custom vesting accounts) need to fork and modify `genaccounts`.
 

diff --git a/docs/architecture/adr-012-state-accessors.md b/docs/architecture/adr-012-state-accessors.md
@@ -6,7 +6,7 @@
 
 ## Context
 
-SDK modules currently use the `KVStore` interface and `Codec` to access their respective state. While
+Cosmos SDK modules currently use the `KVStore` interface and `Codec` to access their respective state. While
 this provides a large degree of freedom to module developers, it is hard to modularize and the UX is
 mediocre.
 

diff --git a/docs/architecture/adr-016-validator-consensus-key-rotation.md b/docs/architecture/adr-016-validator-consensus-key-rotation.md
@@ -7,11 +7,11 @@
 
 ## Context
 
-Validator consensus key rotation feature has been discussed and requested for a long time, for the sake of safer validator key management policy (e.g. https://github.com/tendermint/tendermint/issues/1136). So, we suggest one of the simplest form of validator consensus key rotation implementation mostly onto Cosmos-SDK.
+Validator consensus key rotation feature has been discussed and requested for a long time, for the sake of safer validator key management policy (e.g. https://github.com/tendermint/tendermint/issues/1136). So, we suggest one of the simplest form of validator consensus key rotation implementation mostly onto Cosmos SDK.
 
 We don't need to make any update on consensus logic in Tendermint because Tendermint does not have any mapping information of consensus key and validator operator key, meaning that from Tendermint point of view, a consensus key rotation of a validator is simply a replacement of a consensus key to another.
 
-Also, it should be noted that this ADR includes only the simplest form of consensus key rotation without considering multiple consensus keys concept. Such multiple consensus keys concept shall remain a long term goal of Tendermint and Cosmos-SDK.
+Also, it should be noted that this ADR includes only the simplest form of consensus key rotation without considering multiple consensus keys concept. Such multiple consensus keys concept shall remain a long term goal of Tendermint and Cosmos SDK.
 
 ## Decision
 

diff --git a/docs/architecture/adr-017-historical-header-module.md b/docs/architecture/adr-017-historical-header-module.md
@@ -7,7 +7,7 @@
 
 ## Context
 
-In order for the Cosmos SDK to implement the [IBC specification](https://github.com/cosmos/ics), modules within the SDK must have the ability to introspect recent consensus states (validator sets & commitment roots) as proofs of these values on other chains must be checked during the handshakes.
+In order for the Cosmos SDK to implement the [IBC specification](https://github.com/cosmos/ics), modules within the Cosmos SDK must have the ability to introspect recent consensus states (validator sets & commitment roots) as proofs of these values on other chains must be checked during the handshakes.
 
 ## Decision
 
@@ -30,7 +30,7 @@ func BeginBlock(ctx sdk.Context, keeper HistoricalHeaderKeeper, req abci.Request
 
 Alternatively, the application MAY store only the hash of the validator set.
 
-The application MUST make these past `n` committed headers available for querying by SDK modules through the `Keeper`'s `GetHistoricalInfo` function. This MAY be implemented in a new module, or it MAY also be integrated into an existing one (likely `x/staking` or `x/ibc`).
+The application MUST make these past `n` committed headers available for querying by Cosmos SDK modules through the `Keeper`'s `GetHistoricalInfo` function. This MAY be implemented in a new module, or it MAY also be integrated into an existing one (likely `x/staking` or `x/ibc`).
 
 `n` MAY be configured as a parameter store parameter, in which case it could be changed by `ParameterChangeProposal`s, although it will take some blocks for the stored information to catch up if `n` is increased.
 
@@ -44,7 +44,7 @@ Implementation of this ADR will require changes to the Cosmos SDK. It will not r
 
 ### Positive
 
-- Easy retrieval of headers & state roots for recent past heights by modules anywhere in the SDK.
+- Easy retrieval of headers & state roots for recent past heights by modules anywhere in the Cosmos SDK.
 - No RPC calls to Tendermint required.
 - No ABCI alterations required.
 

diff --git a/docs/architecture/adr-019-protobuf-state-encoding.md b/docs/architecture/adr-019-protobuf-state-encoding.md
@@ -65,13 +65,13 @@ will provide two concrete implementations of the `Marshaler` interface: `AminoCo
 - `AminoCodec`: Uses Amino for both binary and JSON encoding.
 - `ProtoCodec`: Uses Protobuf for both binary and JSON encoding.
 
-Modules will use whichever codec that is instantiated in the app. By default, the SDK's `simapp`
+Modules will use whichever codec that is instantiated in the app. By default, the Cosmos SDK's `simapp`
 instantiates a `ProtoCodec` as the concrete implementation of `Marshaler`, inside the `MakeTestEncodingConfig`
 function. This can be easily overwritten by app developers if they so desire.
 
 The ultimate goal will be to replace Amino JSON encoding with Protobuf encoding and thus have
 modules accept and/or extend `ProtoCodec`. Until then, Amino JSON is still provided for legacy use-cases.
-A handful of places in the SDK still have Amino JSON hardcoded, such as the Legacy API REST endpoints
+A handful of places in the Cosmos SDK still have Amino JSON hardcoded, such as the Legacy API REST endpoints
 and the `x/params` store. They are planned to be converted to Protobuf in a gradual manner.
 
 ### Module Codecs
@@ -139,7 +139,7 @@ compression at the persistence layer in the future and the performance impact
 is likely to be small. Thus, not using `Any` is seem as a pre-mature optimization,
 with user experience as the higher order concern.
 
-Note, that given the SDK's decision to adopt the `Codec` interfaces described
+Note, that given the Cosmos SDK's decision to adopt the `Codec` interfaces described
 above, apps can still choose to use `oneof` to encode state and transactions
 but it is not the recommended approach. If apps do choose to use `oneof`s
 instead of `Any` they will likely lose compatibility with client apps that
@@ -226,7 +226,7 @@ every module that implements it in order to populate the `InterfaceRegistry`.
 
 ### Using `Any` to encode state
 
-The SDK will provide support methods `MarshalInterface` and `UnmarshalInterface` to hide a complexity of wrapping interface types into `Any` and allow easy serialization.
+The Cosmos SDK will provide support methods `MarshalInterface` and `UnmarshalInterface` to hide a complexity of wrapping interface types into `Any` and allow easy serialization.
 
 ```go
 import "github.com/cosmos/cosmos-sdk/codec"