chore: update documentation from cosmos-sdk/docs (#243)

docs/build/architecture/adr-023-protobuf-naming.md

@@ -70,7 +70,7 @@ Further guidelines to be described below.
 Names should be descriptive enough to convey their meaning and distinguish
 them from other names.
 
-Given that we are using fully-qualifed names within
+Given that we are using fully-qualified names within
 `google.protobuf.Any` as well as within gRPC query routes, we should aim to
 keep names concise, without going overboard. The general rule of thumb should
 be if a shorter name would convey more or else the same thing, pick the shorter

docs/build/architecture/adr-063-core-module-api.md

@@ -226,7 +226,7 @@ type HasServices interface {
 
 ```
 
-Because of the `cosmos.msg.v1.service` protobuf option, required for `Msg` services, the same `ServiceRegitrar` can be
+Because of the `cosmos.msg.v1.service` protobuf option, required for `Msg` services, the same `ServiceRegistrar` can be
 used to register both `Msg` and query services.
 
 #### Genesis

docs/build/building-modules/11-structure.md

@@ -45,7 +45,6 @@ x/{module_name}
 │   ├── genesis.go
 │   ├── grpc_query.go
 │   ├── hooks.go
-│   ├── invariants.go
 │   ├── keeper.go
 │   ├── keys.go
 │   ├── msg_server.go

docs/build/migrations/02-upgrading.md

@@ -44,6 +44,15 @@ To be able to simulate nested messages within a transaction, message types conta
 the nested messages. By implementing this interface, the BaseApp can simulate these nested messages during
 transaction simulation. -->
 
+### Modules
+
+#### `x/params`
+
+The `x/params` module has been removed from the Cosmos SDK.  The following [migration](https://github.com/cosmos/cosmos-sdk/blob/828fcf2f05db0c4759ed370852b6dacc589ea472/x/mint/migrations/v2/migrate.go) 
+and [PR])(https://github.com/cosmos/cosmos-sdk/pull/12363) can be used as a reference for migrating a legacy params module to the supported module-managed params paradigm.
+
+More information can be found in the [deprecation notice](https://github.com/cosmos/cosmos-sdk/blob/main/UPGRADING.md#xparams).
+
 ## [v0.52.x](https://github.com/cosmos/cosmos-sdk/releases/tag/v0.52.0-beta.1)
 
 Documentation to migrate an application from v0.50.x to server/v2 is available elsewhere.
@@ -1276,7 +1285,7 @@ The `params` module was deprecated since v0.46. The Cosmos SDK has migrated away
 Cosmos SDK modules now store their parameters directly in its respective modules.
 The `params` module will be removed in `v0.50`, as mentioned [in v0.46 release](https://github.com/cosmos/cosmos-sdk/blob/v0.46.1/UPGRADING.md#xparams). It is strongly encouraged to migrate away from `x/params` before `v0.50`.
 
-When performing a chain migration, the params table must be initizalied manually. This was done in the modules keepers in previous versions.
+When performing a chain migration, the params table must be initialized manually. This was done in the modules keepers in previous versions.
 Have a look at `simapp.RegisterUpgradeHandlers()` for an example.
 
 #### `x/crisis`

docs/user/run-node/01-run-node.md

@@ -198,7 +198,7 @@ Local state sync work similar to normal state sync except that it works off a lo
 
 1. As mentioned in https://docs.cometbft.com/v0.37/core/state-sync, one must set a height and hash in the config.toml along with a few rpc servers (the afromentioned link has instructions on how to do this). 
 2. Run `<appd snapshot restore <height> <format>` to restore a local snapshot (note: first load it from a file with the *load* command). 
-3. Bootsrapping Comet state in order to start the node after the snapshot has been ingested. This can be done with the bootstrap command `<app> comet bootstrap-state`
+3. Bootstrapping Comet state in order to start the node after the snapshot has been ingested. This can be done with the bootstrap command `<app> comet bootstrap-state`
 
 ### Snapshots Commands