chore: docs fixington

client/v2/README.md

@@ -150,7 +150,7 @@ To add positional arguments to a command, use the `autocliv1.PositionalArgDescri
 Here's an example of how to define a positional argument for the `Account` method of the `auth` service:
 
 ```go reference
-https://github.com/cosmos/cosmos-sdk/blob/v0.50.0-beta.0/x/auth/autocli.go#L25-L30
+https://github.com/cosmos/cosmos-sdk/blob/v0.53.0/x/auth/autocli.go#L25-L30
 ```
 
 Then the command can be used as follows, instead of having to specify the `--address` flag:

collections/README.md

@@ -90,7 +90,7 @@ Since a module can have multiple collections, the following is expected:
 We don't want a collection to write over the state of the other collection so we pass it a prefix, which defines a storage
 partition owned by the collection.
 
-If you already built modules, the prefix translates to the items you were creating in your ``types/keys.go`` file, example: https://github.com/cosmos/cosmos-sdk/blob/v0.52.0-rc.1/x/feegrant/key.go#L16~L22
+If you already built modules, the prefix translates to the items you were creating in your ``types/keys.go`` file, example: https://github.com/cosmos/cosmos-sdk/blob/v0.53.0/x/feegrant/key.go#L25~L31
 
 your old:
 

docs/DOC_WRITING_GUIDELINES.md

@@ -31,7 +31,7 @@ It is also possible to include code snippets from GitHub files by referencing th
 
 ```md
     ```go reference
-    https://github.com/cosmos/cosmos-sdk/blob/v0.46.0/server/types/app.go#L57-L59
+    https://github.com/cosmos/cosmos-sdk/blob/v0.53.0/server/types/app.go#L68-L69
     ```
 ```
 

docs/architecture/adr-047-extend-upgrade-plan.md

@@ -19,7 +19,7 @@ It also defines a structure for providing downloadable artifacts involved in an
 The `upgrade` module in conjunction with Cosmovisor are designed to facilitate and automate a blockchain's transition from one version to another.
 
 Users submit a software upgrade governance proposal containing an upgrade `Plan`.
-The [Plan](https://github.com/cosmos/cosmos-sdk/blob/v0.44.5/proto/cosmos/upgrade/v1beta1/upgrade.proto#L12) currently contains the following fields:
+The [Plan](https://github.com/cosmos/cosmos-sdk/blob/v0.53.0/proto/cosmos/upgrade/v1beta1/upgrade.proto#L14) currently contains the following fields:
 
 * `name`: A short string identifying the new version.
 * `height`: The chain height at which the upgrade is to be performed.

docs/docs/build/abci/03-vote-extensions.md

@@ -35,7 +35,7 @@ Click [here](https://docs.cosmos.network/main/build/abci/vote-extensions) if you
 
 Similar to extending a vote, an application can also verify vote extensions from
 other validators when validating their pre-commits. For a given vote extension,
-this process MUST be deterministic. The Cosmos SDK defines [`sdk.VerifyVoteExtensionHandler`](https://github.com/cosmos/cosmos-sdk/blob/v0.50.1/types/abci.go#L29-L31):
+this process MUST be deterministic. The Cosmos SDK defines [`sdk.VerifyVoteExtensionHandler`](https://github.com/cosmos/cosmos-sdk/blob/v0.53.0/types/abci.go#L34-L36):
 
 ```go
 type VerifyVoteExtensionHandler func(Context, *abci.RequestVerifyVoteExtension) (*abci.ResponseVerifyVoteExtension, error)

docs/docs/build/building-apps/01-app-go-di.md

@@ -29,13 +29,13 @@ The `app_config.go` file is the single place to configure all modules parameters
 1. Create the `AppConfig` variable:
 
     ```go reference
-    https://github.com/cosmos/cosmos-sdk/blob/v0.53.0-rc.2/simapp/app_config.go#L289-L303
+    https://github.com/cosmos/cosmos-sdk/blob/v0.53.0/simapp/app_config.go#L293-L307
     ```
 
     Where the `appConfig` combines the [runtime](./00-runtime.md) configuration and the (extra) modules configuration.
 
     ```go reference
-    https://github.com/cosmos/cosmos-sdk/blob/v0.53.0-rc.2/simapp/app_di.go#L113-L161
+    https://github.com/cosmos/cosmos-sdk/blob/v0.53.0/simapp/app_di.go#L114-L157
     ```
 
 2. Configure the `runtime` module:
@@ -44,21 +44,21 @@ The `app_config.go` file is the single place to configure all modules parameters
     They are named in the order they should be executed by the module manager.
 
     ```go reference
-    https://github.com/cosmos/cosmos-sdk/blob/v0.53.0-rc.2/simapp/app_config.go#L103-L188
+    https://github.com/cosmos/cosmos-sdk/blob/v0.53.0/simapp/app_config.go#L104-L189
     ```
 
 3. Wire the other modules:
 
     Next to runtime, the other (depinject-enabled) modules are wired in the `AppConfig`:
 
     ```go reference
-    https://github.com/cosmos/cosmos-sdk/blob/v0.53.0-rc.2/simapp/app_config.go#L103-L286
+    https://github.com/cosmos/cosmos-sdk/blob/v0.53.0/simapp/app_config.go#L106-L289
     ```
 
     Note: the `tx` isn't a module, but a configuration. It should be wired in the `AppConfig` as well.
 
     ```go reference
-    https://github.com/cosmos/cosmos-sdk/blob/v0.53.0-rc.2/simapp/app_config.go#L222-L227
+    https://github.com/cosmos/cosmos-sdk/blob/v0.53.0/simapp/app_config.go#L226-L231
     ```
 
 See the complete `app_config.go` file for `SimApp` [here](https://github.com/cosmos/cosmos-sdk/blob/v0.53.0-rc.2/simapp/app_config.go).
@@ -111,7 +111,7 @@ A more complete example of `app.yaml` can be found [here](https://github.com/cos
 In short `depinject` and the [`runtime` package](./00-runtime.md) abstract the wiring of the app, and the `AppBuilder` is the place where the app is constructed. [`runtime`](./00-runtime.md) takes care of registering the codecs, KV store, subspaces and instantiating `baseapp`.
 
 ```go reference
-https://github.com/cosmos/cosmos-sdk/blob/v0.53.0-rc.2/simapp/app_di.go#L100-L270
+https://github.com/cosmos/cosmos-sdk/blob/v0.53.0/simapp/app_di.go#L114-L264
 ```
 
 :::warning
@@ -125,7 +125,7 @@ In this case, use `depinject.Configs` for combining the extra configuration, and
 More information on how `depinject.Configs` and `depinject.Supply` function can be found in the [`depinject` documentation](https://pkg.go.dev/cosmossdk.io/depinject).
 
 ```go reference
-https://github.com/cosmos/cosmos-sdk/blob/v0.53.0-rc.2/simapp/app_di.go#L114-L162
+https://github.com/cosmos/cosmos-sdk/blob/v0.53.0/simapp/app_di.go#L114-L157
 ```
 
 ### Registering non app wiring modules

docs/docs/build/building-apps/04-vote-extensions.md

@@ -40,7 +40,7 @@ other validators when validating their pre-commits. For a given vote extension,
 this process MUST be deterministic. The Cosmos SDK defines `sdk.VerifyVoteExtensionHandler`:
 
 ```go reference
-https://github.com/cosmos/cosmos-sdk/blob/v0.50.0-alpha.0/types/abci.go#L26-L27
+https://github.com/cosmos/cosmos-sdk/blob/v0.53.0/types/abci.go#L31-L32
 ```
 
 An application can set this handler in `app.go` via the `baseapp.SetVerifyVoteExtensionHandler`

docs/docs/build/building-modules/02-messages-and-queries.md

@@ -34,7 +34,7 @@ Each `Msg` service method must have exactly one argument, which must implement t
 See an example of a `Msg` service definition from `x/bank` module:
 
 ```protobuf reference
-https://github.com/cosmos/cosmos-sdk/blob/v0.50.0-alpha.0/proto/cosmos/bank/v1beta1/tx.proto#L13-L36
+https://github.com/cosmos/cosmos-sdk/blob/v0.53.0/proto/cosmos/bank/v1beta1/tx.proto#L13-L32
 ```
 
 ### `sdk.Msg` Interface
@@ -98,7 +98,7 @@ Queries should be defined using [Protobuf services](https://developers.google.co
 Here's an example of such a `Query` service definition:
 
 ```protobuf reference
-https://github.com/cosmos/cosmos-sdk/blob/v0.50.0-alpha.0/proto/cosmos/auth/v1beta1/query.proto#L14-L89
+https://github.com/cosmos/cosmos-sdk/blob/v0.53.0/proto/cosmos/auth/v1beta1/query.proto#L12-L78
 ```
 
 As `proto.Message`s, generated `Response` types implement by default `String()` method of [`fmt.Stringer`](https://pkg.go.dev/fmt#Stringer).
@@ -133,5 +133,5 @@ Store queries query directly for store keys. They use `clientCtx.QueryABCI(req a
 See following examples:
 
 ```go reference
-https://github.com/cosmos/cosmos-sdk/blob/v0.50.0-alpha.0/baseapp/abci.go#L864-L894
+https://github.com/cosmos/cosmos-sdk/blob/v0.53.0/baseapp/abci.go#L1050-L1074
 ```

docs/docs/build/building-modules/03-msg-services.md

@@ -24,19 +24,19 @@ As further described in [ADR 031](../architecture/adr-031-msg-service.md), this
 Protobuf generates a `MsgServer` interface based on a definition of `Msg` service. It is the role of the module developer to implement this interface, by implementing the state transition logic that should happen upon receival of each `sdk.Msg`. As an example, here is the generated `MsgServer` interface for `x/bank`, which exposes two `sdk.Msg`s:
 
 ```go reference
-https://github.com/cosmos/cosmos-sdk/blob/v0.50.0-alpha.0/x/bank/types/tx.pb.go#L550-L568
+https://github.com/cosmos/cosmos-sdk/blob/v0.53.0/x/bank/types/tx.pb.go#L538-L556
 ```
 
 When possible, the existing module's [`Keeper`](./06-keeper.md) should implement `MsgServer`, otherwise a `msgServer` struct that embeds the `Keeper` can be created, typically in `./keeper/msg_server.go`:
 
 ```go reference
-https://github.com/cosmos/cosmos-sdk/blob/v0.50.0-alpha.0/x/bank/keeper/msg_server.go#L17-L19
+https://github.com/cosmos/cosmos-sdk/blob/v0.53.0/x/bank/keeper/msg_server.go#L17-L19
 ```
 
 `msgServer` methods can retrieve the `context.Context` from the `context.Context` parameter method using the `sdk.UnwrapSDKContext`:
 
 ```go reference
-https://github.com/cosmos/cosmos-sdk/blob/v0.50.0-alpha.0/x/bank/keeper/msg_server.go#L56
+https://github.com/cosmos/cosmos-sdk/blob/v0.53.0/x/bank/keeper/msg_server.go#L56
 ```
 
 `sdk.Msg` processing usually follows these 3 steps:
@@ -95,13 +95,13 @@ These events are relayed back to the underlying consensus engine and can be used
 The invoked `msgServer` method returns a `proto.Message` response and an `error`. These return values are then wrapped into an `*sdk.Result` or an `error` using `sdk.WrapServiceResult(ctx context.Context, res proto.Message, err error)`:
 
 ```go reference
-https://github.com/cosmos/cosmos-sdk/blob/v0.50.0-alpha.0/baseapp/msg_service_router.go#L160
+https://github.com/cosmos/cosmos-sdk/blob/v0.53.0/baseapp/msg_service_router.go#L208
 ```
 
 This method takes care of marshaling the `res` parameter to protobuf and attaching any events on the `ctx.EventManager()` to the `sdk.Result`.
 
 ```protobuf reference
-https://github.com/cosmos/cosmos-sdk/blob/v0.50.0-alpha.0/proto/cosmos/base/abci/v1beta1/abci.proto#L93-L113
+https://github.com/cosmos/cosmos-sdk/blob/v0.53.0/proto/cosmos/base/abci/v1beta1/abci.proto#L90-L106
 ```
 
 This diagram shows a typical structure of a Protobuf `Msg` service, and how the message propagates through the module.
@@ -115,5 +115,5 @@ New [telemetry metrics](../../learn/advanced/09-telemetry.md) can be created fro
 This is an example from the `x/auth/vesting` module:
 
 ```go reference
-https://github.com/cosmos/cosmos-sdk/blob/v0.50.0-alpha.0/x/auth/vesting/msg_server.go#L76-L88
+https://github.com/cosmos/cosmos-sdk/blob/v0.53.0/x/auth/vesting/msg_server.go#L79-L90
 ```

docs/docs/build/building-modules/06-keeper.md

@@ -41,7 +41,7 @@ type Keeper struct {
 For example, here is the type definition of the `keeper` from the `staking` module:
 
 ```go reference
-https://github.com/cosmos/cosmos-sdk/blob/v0.50.0-alpha.0/x/staking/keeper/keeper.go#L23-L31
+https://github.com/cosmos/cosmos-sdk/blob/v0.53.0/x/staking/keeper/keeper.go#L24-L31
 ```
 
 Let us go through the different parameters:

docs/docs/build/building-modules/07-invariants.md

@@ -19,7 +19,7 @@ An invariant is a property of the application that should always be true. In the
 An `Invariant` is a function that checks for a particular invariant within a module. Module `Invariant`s must follow the `Invariant` type:
 
 ```go reference
-https://github.com/cosmos/cosmos-sdk/blob/v0.50.0-alpha.0/types/invariant.go#L9
+https://github.com/cosmos/cosmos-sdk/blob/v0.53.0/types/invariant.go#L9
 ```
 
 The `string` return value is the invariant message, which can be used when printing logs, and the `bool` return value is the actual result of the invariant check.
@@ -70,21 +70,21 @@ The `InvariantRegistry` is a registry where the `Invariant`s of all the modules
 At its core, the `InvariantRegistry` is defined in the Cosmos SDK as an interface:
 
 ```go reference
-https://github.com/cosmos/cosmos-sdk/blob/v0.50.0-alpha.0/types/invariant.go#L14-L17
+https://github.com/cosmos/cosmos-sdk/blob/v0.53.0/types/invariant.go#L14-L17
 ```
 
 Typically, this interface is implemented in the `keeper` of a specific module. The most used implementation of an `InvariantRegistry` can be found in the `crisis` module:
 
 ```go reference
-https://github.com/cosmos/cosmos-sdk/blob/v0.50.0-alpha.0/x/crisis/keeper/keeper.go#L48-L50
+https://github.com/cosmos/cosmos-sdk/blob/v0.53.0/x/crisis/keeper/keeper.go#L51-L53
 ```
 
 The `InvariantRegistry` is therefore typically instantiated by instantiating the `keeper` of the `crisis` module in the [application's constructor function](../../learn/beginner/00-app-anatomy.md#constructor-function).
 
 `Invariant`s can be checked manually via [`message`s](./02-messages-and-queries.md), but most often they are checked automatically at the end of each block. Here is an example from the `crisis` module:
 
 ```go reference
-https://github.com/cosmos/cosmos-sdk/blob/v0.50.0-alpha.0/x/crisis/abci.go#L13-L23
+https://github.com/cosmos/cosmos-sdk/blob/v0.53.0/x/crisis/abci.go#L12-L21
 ```
 
 In both cases, if one of the `Invariant`s returns false, the `InvariantRegistry` can trigger special logic (e.g. have the application panic and print the `Invariant`s message in the log).

docs/docs/build/building-modules/08-genesis.md

@@ -32,15 +32,15 @@ Next we present the main genesis-related methods that need to be implemented by
 The `DefaultGenesis()` method is a simple method that calls the constructor function for `GenesisState` with the default value for each parameter. See an example from the `auth` module:
 
 ```go reference
-https://github.com/cosmos/cosmos-sdk/blob/v0.50.0-alpha.0/x/auth/module.go#L63-L67
+https://github.com/cosmos/cosmos-sdk/blob/v0.53.0/x/auth/module.go#L61-L65
 ```
 
 ### `ValidateGenesis`
 
 The `ValidateGenesis(data GenesisState)` method is called to verify that the provided `genesisState` is correct. It should perform validity checks on each of the parameters listed in `GenesisState`. See an example from the `auth` module:
 
 ```go reference
-https://github.com/cosmos/cosmos-sdk/blob/v0.50.0-alpha.0/x/auth/types/genesis.go#L62-L75
+https://github.com/cosmos/cosmos-sdk/blob/v0.53.0/x/auth/types/genesis.go#L62-L73
 ```
 
 ## Other Genesis Methods
@@ -56,7 +56,7 @@ The [module manager](./01-module-manager.md#manager) of the application is respo
 See an example of `InitGenesis` from the `auth` module:
 
 ```go reference
-https://github.com/cosmos/cosmos-sdk/blob/v0.50.0-alpha.0/x/auth/keeper/genesis.go#L8-L35
+https://github.com/cosmos/cosmos-sdk/blob/v0.53.0/x/auth/keeper/genesis.go#L8-L32
 ```
 
 ### `ExportGenesis`
@@ -66,13 +66,13 @@ The `ExportGenesis` method is executed whenever an export of the state is made.
 See an example of `ExportGenesis` from the `auth` module.
 
 ```go reference
-https://github.com/cosmos/cosmos-sdk/blob/v0.50.0-alpha.0/x/auth/keeper/genesis.go#L37-L49
+https://github.com/cosmos/cosmos-sdk/blob/v0.53.0/x/auth/keeper/genesis.go#L36-L46
 ```
 
 ### GenesisTxHandler
 
 `GenesisTxHandler` is a way for modules to submit state transitions prior to the first block. This is used by `x/genutil` to submit the genesis transactions for the validators to be added to staking. 
 
 ```go reference
-https://github.com/cosmos/cosmos-sdk/blob/v0.50.0-alpha.0/core/genesis/txhandler.go#L3-L6
+https://github.com/cosmos/cosmos-sdk/blob/v0.53.0/core/genesis/txhandler.go#L3-L6
 ```

docs/docs/build/building-modules/09-module-interfaces.md

@@ -27,7 +27,7 @@ Transaction commands typically have their own `tx.go` file that lives within the
 Here is an example from the `x/bank` module:
 
 ```go reference
-https://github.com/cosmos/cosmos-sdk/blob/v0.50.0-alpha.0/x/bank/client/cli/tx.go#L37-L76
+https://github.com/cosmos/cosmos-sdk/blob/v0.53.0/x/bank/client/cli/tx.go#L39-L72
 ```
 
 In the example, `NewSendTxCmd()` creates and returns the transaction command for a transaction that wraps and delivers `MsgSend`. `MsgSend` is the message used to send tokens from one account to another.
@@ -49,13 +49,13 @@ In general, the getter function does the following:
 Each module can implement `NewTxCmd()`, which aggregates all of the transaction commands of the module. Here is an example from the `x/bank` module:
 
 ```go reference
-https://github.com/cosmos/cosmos-sdk/blob/v0.50.0-alpha.0/x/bank/client/cli/tx.go#L20-L35
+https://github.com/cosmos/cosmos-sdk/blob/v0.53.0/x/bank/client/cli/tx.go#L22-L35
 ```
 
 Each module then can also implement a `GetTxCmd()` method that simply returns `NewTxCmd()`. This allows the root command to easily aggregate all of the transaction commands for each module. Here is an example:
 
 ```go reference
-https://github.com/cosmos/cosmos-sdk/blob/v0.50.0-alpha.0/x/bank/module.go#L84-L86
+https://github.com/cosmos/cosmos-sdk/blob/v0.53.0/x/bank/module.go#L88-L90
 ```
 
 ### Query Commands
@@ -96,7 +96,7 @@ https://github.com/cosmos/cosmos-sdk/blob/v0.50.0-alpha.0/x/auth/client/cli/quer
 Each module must also implement the `GetQueryCmd()` method for `AppModuleBasic` that returns the `GetQueryCmd()` function. This allows for the root command to easily aggregate all of the query commands for each module. Here is an example:
 
 ```go reference
-https://github.com/cosmos/cosmos-sdk/blob/v0.50.0-alpha.0/x/bank/module.go#L84-L87
+https://github.com/cosmos/cosmos-sdk/blob/v0.53.0/x/bank/module.go#L88-L90
 ```
 
 ### Flags
@@ -124,15 +124,15 @@ For more detailed information on creating flags, visit the [Cobra Documentation]
 As mentioned in [transaction commands](#transaction-commands), there is a set of flags that all transaction commands must add. This is done with the `AddTxFlagsToCmd` method defined in the Cosmos SDK's `./client/flags` package.
 
 ```go reference
-https://github.com/cosmos/cosmos-sdk/blob/v0.50.0-alpha.0/client/flags/flags.go#L108-L138
+https://github.com/cosmos/cosmos-sdk/blob/v0.53.0/client/flags/flags.go#L110-L138
 ```
 
 Since `AddTxFlagsToCmd(cmd *cobra.Command)` includes all of the basic flags required for a transaction command, module developers may choose not to add any of their own (specifying arguments instead may often be more appropriate).
 
 Similarly, there is a `AddQueryFlagsToCmd(cmd *cobra.Command)` to add common flags to a module query command.
 
 ```go reference
-https://github.com/cosmos/cosmos-sdk/blob/v0.50.0-alpha.0/client/flags/flags.go#L95-L106```
+https://github.com/cosmos/cosmos-sdk/blob/v0.53.0/client/flags/flags.go#L99-L108```
 -->
 
 ## gRPC
@@ -146,7 +146,7 @@ In order to do that, modules must implement `RegisterGRPCGatewayRoutes(clientCtx
 Here's an example from the `x/auth` module:
 
 ```go reference
-https://github.com/cosmos/cosmos-sdk/blob/v0.50.0-alpha.0/x/auth/module.go#L71-L76
+https://github.com/cosmos/cosmos-sdk/blob/v0.53.0/x/auth/module.go#L70-L74
 ```
 
 ## gRPC-gateway REST
@@ -156,7 +156,7 @@ Applications need to support web services that use HTTP requests (e.g. a web wal
 Modules that want to expose REST queries should add `google.api.http` annotations to their `rpc` methods, such as in the example below from the `x/auth` module:
 
 ```protobuf reference
-https://github.com/cosmos/cosmos-sdk/blob/v0.50.0-alpha.0/proto/cosmos/auth/v1beta1/query.proto#L14-L89
+https://github.com/cosmos/cosmos-sdk/blob/v0.53.0/proto/cosmos/auth/v1beta1/query.proto#L12-L78
 ```
 
 gRPC gateway is started in-process along with the application and CometBFT. It can be enabled or disabled by setting gRPC Configuration `enable` in [`app.toml`](../run-node/01-run-node.md#configuring-the-node-using-apptoml-and-configtoml).

docs/docs/build/building-modules/12-errors.md

@@ -43,7 +43,7 @@ execution.
 Example:
 
 ```go reference
-https://github.com/cosmos/cosmos-sdk/blob/v0.50.0-alpha.0/x/bank/keeper/keeper.go#L141-L182
+https://github.com/cosmos/cosmos-sdk/blob/v0.53.0/x/bank/keeper/keeper.go#L122-L157
 ```
 
 Regardless if an error is wrapped or not, the Cosmos SDK's `errors` package provides a function to determine if