docs: 10180 Fix SDK (#10237)

* docs: Fix Cosmos-sdk references in md files

* Fix SDK to Cosmos SDK in all found places and adjust grammar in turn

* Add changelog entry

* Update docs/core/context.md

Co-authored-by: Barrie Byron <barrie.byron@tendermint.com>

* Update docs/architecture/adr-010-modular-antehandler.md

Co-authored-by: Barrie Byron <barrie.byron@tendermint.com>

* Update docs/basics/README.md

Co-authored-by: Barrie Byron <barrie.byron@tendermint.com>

* Update docs/architecture/adr-040-storage-and-smt-state-commitments.md

Co-authored-by: Barrie Byron <barrie.byron@tendermint.com>

* Update docs/building-modules/intro.md

Co-authored-by: Barrie Byron <barrie.byron@tendermint.com>

* Update docs/building-modules/intro.md

Co-authored-by: Barrie Byron <barrie.byron@tendermint.com>

* Update docs/core/baseapp.md

Co-authored-by: Barrie Byron <barrie.byron@tendermint.com>

* Update docs/building-modules/intro.md

Co-authored-by: Barrie Byron <barrie.byron@tendermint.com>

* Update docs/basics/accounts.md

Co-authored-by: Barrie Byron <barrie.byron@tendermint.com>

* docs 10180 fix 'an Cosmos SDK' where used

Co-authored-by: Barrie Byron <barrie.byron@tendermint.com>
Co-authored-by: Amaury <1293565+amaurym@users.noreply.github.com>
Co-authored-by: Robert Zaremba <robert@zaremba.ch>

docs/intro/README.md

@@ -10,7 +10,7 @@ This introduction gives a quick start on the Cosmos SDK.
 
 1. [Overview](./overview.md)
 2. [Application-Specific Blockchains](./why-app-specific.md)
-3. [Architecture of an SDK Application](./sdk-app-architecture.md)
+3. [Architecture of a Cosmos SDK Application](./sdk-app-architecture.md)
 4. [Cosmos SDK Design Overview](./sdk-design.md)
 
 After reading the introduction material, head over to the [basics](../basics/README.md) to learn more.

docs/intro/overview.md

@@ -4,7 +4,7 @@ order: 1
 
 # High-level Overview
 
-## What is the SDK?
+## What is the Cosmos SDK?
 
 The [Cosmos-SDK](https://github.com/cosmos/cosmos-sdk) is an open-source framework for building multi-asset public Proof-of-Stake (PoS) <df value="blockchain">blockchains</df>, like the Cosmos Hub, as well as permissioned Proof-Of-Authority (PoA) blockchains. Blockchains built with the Cosmos SDK are generally referred to as **application-specific blockchains**.
 
@@ -22,15 +22,15 @@ Learn more about [application-specific blockchains](./why-app-specific.md).
 
 The Cosmos SDK is the most advanced framework for building custom application-specific blockchains today. Here are a few reasons why you might want to consider building your decentralised application with the Cosmos SDK:
 
-- The default consensus engine available within the SDK is [Tendermint Core](https://github.com/tendermint/tendermint). Tendermint is the most (and only) mature BFT consensus engine in existence. It is widely used across the industry and is considered the gold standard consensus engine for building Proof-of-Stake systems.
-- The SDK is open source and designed to make it easy to build blockchains out of composable [modules](../../x/). As the ecosystem of open source SDK modules grows, it will become increasingly easier to build complex decentralised platforms with it.
-- The SDK is inspired by capabilities-based security, and informed by years of wrestling with blockchain state-machines. This makes the Cosmos SDK a very secure environment to build blockchains.
+- The default consensus engine available within the Cosmos SDK is [Tendermint Core](https://github.com/tendermint/tendermint). Tendermint is the most (and only) mature BFT consensus engine in existence. It is widely used across the industry and is considered the gold standard consensus engine for building Proof-of-Stake systems.
+- The Cosmos SDK is open source and designed to make it easy to build blockchains out of composable [modules](../../x/). As the ecosystem of open source Cosmos SDK modules grows, it will become increasingly easier to build complex decentralised platforms with it.
+- The Cosmos SDK is inspired by capabilities-based security, and informed by years of wrestling with blockchain state-machines. This makes the Cosmos SDK a very secure environment to build blockchains.
 - Most importantly, the Cosmos SDK has already been used to build many application-specific blockchains that are already in production. Among others, we can cite [Cosmos Hub](https://hub.cosmos.network), [IRIS Hub](https://irisnet.org), [Binance Chain](https://docs.binance.org/), [Terra](https://terra.money/) or [Kava](https://www.kava.io/). [Many more](https://cosmos.network/ecosystem) are building on the Cosmos SDK.
 
 ## Getting started with the Cosmos SDK
 
-- Learn more about the [architecture of an SDK application](./sdk-app-architecture.md)
-- Learn how to build an application-specific blockchain from scratch with the [SDK Tutorial](https://cosmos.network/docs/tutorial)
+- Learn more about the [architecture of a Cosmos SDK application](./sdk-app-architecture.md)
+- Learn how to build an application-specific blockchain from scratch with the [Cosmos SDK Tutorial](https://cosmos.network/docs/tutorial)
 
 ## Next {hide}
 

docs/intro/sdk-app-architecture.md

@@ -32,7 +32,7 @@ In practice, the transactions are bundled in blocks to make the process more eff
 
 In a blockchain context, the state machine is deterministic. This means that if a node is started at a given state and replays the same sequence of transactions, it will always end up with the same final state.
 
-The Cosmos SDK gives developers maximum flexibility to define the state of their application, transaction types and state transition functions. The process of building state-machines with the SDK will be described more in depth in the following sections. But first, let us see how the state-machine is replicated using **Tendermint**.
+The Cosmos SDK gives developers maximum flexibility to define the state of their application, transaction types and state transition functions. The process of building state-machines with the Cosmos SDK will be described more in depth in the following sections. But first, let us see how the state-machine is replicated using **Tendermint**.
 
 ## Tendermint
 
@@ -94,4 +94,4 @@ Any application built on Tendermint needs to implement the ABCI interface in ord
 
 ## Next {hide}
 
-Read about the [high-level design principles of the SDK](./sdk-design.md) {hide}
+Read about the [high-level design principles of the Cosmos SDK](./sdk-design.md) {hide}

docs/intro/sdk-design.md

@@ -4,7 +4,7 @@ order: 4
 
 # Main Components of the Cosmos SDK
 
-The Cosmos SDK is a framework that facilitates the development of secure state-machines on top of Tendermint. At its core, the SDK is a boilerplate implementation of the [ABCI](./sdk-app-architecture.md#abci) in Golang. It comes with a [`multistore`](../core/store.md#multistore) to persist data and a [`router`](../core/baseapp.md#routing) to handle transactions.
+The Cosmos SDK is a framework that facilitates the development of secure state-machines on top of Tendermint. At its core, the Cosmos SDK is a boilerplate implementation of the [ABCI](./sdk-app-architecture.md#abci) in Golang. It comes with a [`multistore`](../core/store.md#multistore) to persist data and a [`router`](../core/baseapp.md#routing) to handle transactions.
 
 Here is a simplified view of how transactions are handled by an application built on top of the Cosmos SDK when transferred from Tendermint via `DeliverTx`:
 
@@ -15,7 +15,7 @@ Here is a simplified view of how transactions are handled by an application buil
 
 ## `baseapp`
 
-`baseapp` is the boilerplate implementation of a Cosmos SDK application. It comes with an implementation of the ABCI to handle the connection with the underlying consensus engine. Typically, a Cosmos SDK application extends `baseapp` by embedding it in [`app.go`](../basics/app-anatomy.md#core-application-file). See an example of this from the SDK application tutorial:
+`baseapp` is the boilerplate implementation of a Cosmos SDK application. It comes with an implementation of the ABCI to handle the connection with the underlying consensus engine. Typically, a Cosmos SDK application extends `baseapp` by embedding it in [`app.go`](../basics/app-anatomy.md#core-application-file). See an example of this from the Cosmos SDK application tutorial:
 
 +++ https://github.com/cosmos/sdk-tutorials/blob/c6754a1e313eb1ed973c5c91dcc606f2fd288811/app.go#L72-L92
 
@@ -31,7 +31,7 @@ The multistore abstraction is used to divide the state in distinct compartments,
 
 ## Modules
 
-The power of the Cosmos SDK lies in its modularity. SDK applications are built by aggregating a collection of interoperable modules. Each module defines a subset of the state and contains its own message/transaction processor, while the SDK is responsible for routing each message to its respective module.
+The power of the Cosmos SDK lies in its modularity. Cosmos SDK applications are built by aggregating a collection of interoperable modules. Each module defines a subset of the state and contains its own message/transaction processor, while the Cosmos SDK is responsible for routing each message to its respective module.
 
 Here is a simplified view of how a transaction is processed by the application of each full-node when it is received in a valid block:
 
@@ -80,16 +80,16 @@ Here is a simplified view of how a transaction is processed by the application o
                                        v
 ```
 
-Each module can be seen as a little state-machine. Developers need to define the subset of the state handled by the module, as well as custom message types that modify the state (*Note:* `messages` are extracted from `transactions` by `baseapp`). In general, each module declares its own `KVStore` in the `multistore` to persist the subset of the state it defines. Most developers will need to access other 3rd party modules when building their own modules. Given that the Cosmos-SDK is an open framework, some of the modules may be malicious, which means there is a need for security principles to reason about inter-module interactions. These principles are based on [object-capabilities](../core/ocap.md). In practice, this means that instead of having each module keep an access control list for other modules, each module implements special objects called `keepers` that can be passed to other modules to grant a pre-defined set of capabilities.
+Each module can be seen as a little state-machine. Developers need to define the subset of the state handled by the module, as well as custom message types that modify the state (*Note:* `messages` are extracted from `transactions` by `baseapp`). In general, each module declares its own `KVStore` in the `multistore` to persist the subset of the state it defines. Most developers will need to access other 3rd party modules when building their own modules. Given that the Cosmos SDK is an open framework, some of the modules may be malicious, which means there is a need for security principles to reason about inter-module interactions. These principles are based on [object-capabilities](../core/ocap.md). In practice, this means that instead of having each module keep an access control list for other modules, each module implements special objects called `keepers` that can be passed to other modules to grant a pre-defined set of capabilities.
 
-SDK modules are defined in the `x/` folder of the SDK. Some core modules include:
+Cosmos SDK modules are defined in the `x/` folder of the Cosmos SDK. Some core modules include:
 
 - `x/auth`: Used to manage accounts and signatures.
 - `x/bank`: Used to enable tokens and token transfers.
 - `x/staking` + `x/slashing`: Used to build Proof-Of-Stake blockchains.
 
-In addition to the already existing modules in `x/`, that anyone can use in their app, the SDK lets you build your own custom modules. You can check an [example of that in the tutorial](https://tutorials.cosmos.network/).
+In addition to the already existing modules in `x/`, that anyone can use in their app, the Cosmos SDK lets you build your own custom modules. You can check an [example of that in the tutorial](https://tutorials.cosmos.network/).
 
 ## Next {hide}
 
-Learn more about the [anatomy of an SDK application](../basics/app-anatomy.md) {hide}
+Learn more about the [anatomy of a Cosmos SDK application](../basics/app-anatomy.md) {hide}

docs/intro/why-app-specific.md

@@ -78,4 +78,4 @@ The fundamental issue here is that the governance of the application and the gov
 
 ## Next {hide}
 
-Learn more about the [high-level architecture](./sdk-app-architecture.md) of an SDK application {hide}
+Learn more about the [high-level architecture](./sdk-app-architecture.md) of a Cosmos SDK application {hide}