docs: update sdk & tm version links in docs (#12976)

* docs: update sdk & tm version links in docs * revert unrelated change
2022-08-20 08:42:13 +02:00
parent dc361be9e3
commit 77a96d5fe1
61 changed files with 311 additions and 310 deletions
@@ -28,11 +28,11 @@ It is possible for developers to define the order of execution between the `Begi

 See an example implementation of `BeginBlocker` from the `distribution` module:

-+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/x/distribution/abci.go#L14-L38
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0/x/distribution/abci.go#L14-L38

 and an example implementation of `EndBlocker` from the `staking` module:

-+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/x/staking/abci.go#L22-L27
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0/x/staking/abci.go#L22-L27

 ## Next {hide}

@@ -18,7 +18,7 @@ Registration of errors is handled via the [`errors` package](https://github.com/

 Example:

-+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/x/distribution/types/errors.go#L1-L21
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0/x/distribution/types/errors.go#L1-L21

 Each custom module error must provide the codespace, which is typically the module name
 (e.g. "distribution") and is unique per module, and a uint32 code. Together, the codespace and code
@@ -38,7 +38,7 @@ execution.

 Example:

-+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/x/bank/keeper/keeper.go#L143-L184
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0/x/bank/keeper/keeper.go#L143-L184

 Regardless if an error is wrapped or not, the Cosmos SDK's `errors` package provides a function to determine if
 an error is of a particular kind via `Is`.
@@ -17,7 +17,7 @@ The subset of the genesis state defined from a given module is generally defined

 See an example of `GenesisState` protobuf message definition from the `auth` module:

-+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/proto/cosmos/auth/v1beta1/genesis.proto
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0/proto/cosmos/auth/v1beta1/genesis.proto

 Next we present the main genesis-related methods that need to be implemented by module developers in order for their module to be used in Cosmos SDK applications.

@@ -25,13 +25,13 @@ 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:

-+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/x/auth/module.go#L45-L49
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0/x/auth/module.go#L45-L49

 ### `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:

-+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/x/auth/types/genesis.go#L61-L74
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0/x/auth/types/genesis.go#L61-L74

 ## Other Genesis Methods

@@ -45,7 +45,7 @@ The [module manager](./module-manager.md#manager) of the application is responsi

 See an example of `InitGenesis` from the `auth` module:

-+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/x/auth/keeper/genesis.go#L8-L27
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0/x/auth/keeper/genesis.go#L8-L27

 ### `ExportGenesis`

@@ -53,7 +53,7 @@ The `ExportGenesis` method is executed whenever an export of the state is made.

 See an example of `ExportGenesis` from the `auth` module.

-+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/x/auth/keeper/genesis.go#L29-L41
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0/x/auth/keeper/genesis.go#L29-L41

 ## Next {hide}

@@ -14,7 +14,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:

-+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/types/invariant.go#L9
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.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.

@@ -51,9 +51,9 @@ func AllInvariants(k Keeper) sdk.Invariant {

 Finally, module developers need to implement the `RegisterInvariants` method as part of the [`AppModule` interface](./module-manager.md#appmodule). Indeed, the `RegisterInvariants` method of the module, implemented in the `module/module.go` file, typically only defers the call to a `RegisterInvariants` method implemented in the `keeper/invariants.go` file. The `RegisterInvariants` method registers a route for each `Invariant` function in the [`InvariantRegistry`](#invariant-registry):

-+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/x/staking/keeper/invariants.go#L12-L21
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0/x/staking/keeper/invariants.go#L12-L21

-For more, see an example of [`Invariant`s implementation from the `staking` module](https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/x/staking/keeper/invariants.go).
+For more, see an example of [`Invariant`s implementation from the `staking` module](https://github.com/cosmos/cosmos-sdk/blob/v0.46.0/x/staking/keeper/invariants.go).

 ## Invariant Registry

@@ -61,17 +61,17 @@ 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:

-+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/types/invariant.go#L14-L17
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.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:

-+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/x/crisis/keeper/keeper.go#L49-L53
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0/x/crisis/keeper/keeper.go#L49-L53

 The `InvariantRegistry` is therefore typically instantiated by instantiating the `keeper` of the `crisis` module in the [application's constructor function](../basics/app-anatomy.md#constructor-function).

 `Invariant`s can be checked manually via [`message`s](./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:

-+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/x/crisis/abci.go#L12-L21
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.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).

@@ -36,7 +36,7 @@ type Keeper struct {

 For example, here is the type definition of the `keeper` from the `staking` module:

-+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/x/staking/keeper/keeper.go#L21-L29
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0/x/staking/keeper/keeper.go#L21-L29

 Let us go through the different parameters:

@@ -74,13 +74,13 @@ and the method will go through the following steps:
 2. Marshal `value` to `[]byte` using the codec `cdc`.
 3. Set the encoded value in the store at location `key` using the `Set(key []byte, value []byte)` method of the store.

-For more, see an example of `keeper`'s [methods implementation from the `staking` module](https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/x/staking/keeper/keeper.go).
+For more, see an example of `keeper`'s [methods implementation from the `staking` module](https://github.com/cosmos/cosmos-sdk/blob/v0.46.0/x/staking/keeper/keeper.go).

 The [module `KVStore`](../core/store.md#kvstore-and-commitkvstore-interfaces) also provides an `Iterator()` method which returns an `Iterator` object to iterate over a domain of keys.

 This is an example from the `auth` module to iterate accounts:

-+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/x/auth/keeper/account.go#L76-L90
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0/x/auth/keeper/account.go#L76-L90

 ## Next {hide}

@@ -22,7 +22,7 @@ Defining Protobuf `Msg` services is the recommended way to handle messages. A Pr

 See an example of a `Msg` service definition from `x/bank` module:

-+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/proto/cosmos/bank/v1beta1/tx.proto#L12-L19
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0/proto/cosmos/bank/v1beta1/tx.proto#L12-L19

 Each `Msg` service method must have exactly one argument, which must implement the `sdk.Msg` interface, and a Protobuf response. The naming convention is to call the RPC argument `Msg<service-rpc-name>` and the RPC response `Msg<service-rpc-name>Response`. For example:

@@ -49,7 +49,7 @@ Amino `LegacyMsg`s can be defined as protobuf messages. The messages definition

 A `LegacyMsg` is typically accompanied by a standard constructor function, that is called from one of the [module's interface](./module-interfaces.md). `message`s also need to implement the `sdk.Msg` interface:

-+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/types/tx_msg.go#L10-L22
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0/types/tx_msg.go#L10-L22

 It extends `proto.Message` and contains the following methods:

@@ -59,11 +59,11 @@ It extends `proto.Message` and contains the following methods:
 * `GetSignBytes() []byte`: Return the canonical byte representation of the message. Used to generate a signature.
 * `GetSigners() []AccAddress`: Return the list of signers. The Cosmos SDK will make sure that each `message` contained in a transaction is signed by all the signers listed in the list returned by this method.

-+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/x/auth/migrations/legacytx/stdsign.go#L20-L36
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0/x/auth/migrations/legacytx/stdsign.go#L20-L36

 See an example implementation of a `message` from the `gov` module:

-+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/x/gov/types/v1/msgs.go#L106-L138
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0/x/gov/types/v1/msgs.go#L106-L138

 ## Queries

@@ -75,7 +75,7 @@ Queries should be defined using [Protobuf services](https://developers.google.co

 Here's an example of such a `Query` service definition:

-+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/proto/cosmos/auth/v1beta1/query.proto#L13-L59
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0/proto/cosmos/auth/v1beta1/query.proto#L13-L59

 As `proto.Message`s, generated `Response` types implement by default `String()` method of [`fmt.Stringer`](https://pkg.go.dev/fmt#Stringer).

@@ -108,7 +108,7 @@ Store queries query directly for store keys. They use `clientCtx.QueryABCI(req a

 See following examples:

-+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/baseapp/abci.go#L756-L777
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0/baseapp/abci.go#L756-L777

 ## Next {hide}

@@ -22,7 +22,7 @@ Transaction commands typically have their own `tx.go` file that lives within the

 Here is an example from the `x/bank` module:

-+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/x/bank/client/cli/tx.go#L35-L71
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0/x/bank/client/cli/tx.go#L35-L71

 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.

@@ -42,17 +42,17 @@ In general, the getter function does the following:

 Each module must implement `NewTxCmd()`, which aggregates all of the transaction commands of the module. Here is an example from the `x/bank` module:

-+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/x/bank/client/cli/tx.go#L17-L33
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0/x/bank/client/cli/tx.go#L17-L33

 Each module must also implement the `GetTxCmd()` method for `AppModuleBasic` that simply returns `NewTxCmd()`. This allows the root command to easily aggregate all of the transaction commands for each module. Here is an example:

-+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/x/bank/module.go#L70-L73
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0/x/bank/module.go#L70-L73

 ### Query Commands

 [Queries](./messages-and-queries.md#queries) allow users to gather information about the application or network state; they are routed by the application and processed by the module in which they are defined. Query commands typically have their own `query.go` file in the module's `./client/cli` folder. Like transaction commands, they are specified in getter functions. Here is an example of a query command from the `x/auth` module:

-+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/x/auth/client/cli/query.go#L83-L125
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0/x/auth/client/cli/query.go#L83-L125

 In the example, `GetAccountCmd()` creates and returns a query command that returns the state of an account based on the provided account address.

@@ -72,11 +72,11 @@ In general, the getter function does the following:

 Each module must implement `GetQueryCmd()`, which aggregates all of the query commands of the module. Here is an example from the `x/auth` module:

-+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/x/auth/client/cli/query.go#L25-L42
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0/x/auth/client/cli/query.go#L25-L42

 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:

-+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/x/auth/client/cli/query.go#L32-L50
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0/x/auth/client/cli/query.go#L32-L50

 ### Flags

@@ -102,13 +102,13 @@ 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.

-+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/client/flags/flags.go#L103-L131
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0/client/flags/flags.go#L103-L131

 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.

-+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/client/flags/flags.go#L92-L101
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0/client/flags/flags.go#L92-L101

 ## gRPC

@@ -120,7 +120,7 @@ In order to do that, modules must implement `RegisterGRPCGatewayRoutes(clientCtx

 Here's an example from the `x/auth` module:

-+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/x/auth/module.go#L61-L66
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0/x/auth/module.go#L61-L66

 ## gRPC-gateway REST

@@ -128,7 +128,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:

-+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/proto/cosmos/auth/v1beta1/query.proto#L13-L59
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0/proto/cosmos/auth/v1beta1/query.proto#L13-L59

 gRPC gateway is started in-process along with the application and Tendermint. It can be enabled or disabled by setting gRPC Configuration `enable` in [`app.toml`](../run-node/run-node.md#configuring-the-node-using-apptoml).

@@ -29,7 +29,7 @@ are only used for genesis can take advantage of the `Module` patterns without ha

 The `AppModuleBasic` interface defines the independent methods modules need to implement.

-+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/types/module/module.go#L47-L60
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0/types/module/module.go#L47-L60

 Let us go through the methods:

@@ -48,7 +48,7 @@ All the `AppModuleBasic` of an application are managed by the [`BasicManager`](#

 The `AppModuleGenesis` interface is a simple embedding of the `AppModuleBasic` interface with two added methods.

-+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/types/module/module.go#L140-L146
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0/types/module/module.go#L140-L146

 Let us go through the two added methods:

@@ -61,7 +61,7 @@ It does not have its own manager, and exists separately from [`AppModule`](#appm

 The `AppModule` interface defines the inter-dependent methods that modules need to implement.

-+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/types/module/module.go#L148-L176
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0/types/module/module.go#L148-L176

 `AppModule`s are managed by the [module manager](#manager). This interface embeds the `AppModuleGenesis` interface so that the manager can access all the independent and genesis inter-dependent methods of the module. This means that a concrete type implementing the `AppModule` interface must either implement all the methods of `AppModuleGenesis` (and by extension `AppModuleBasic`), or include a concrete type that does as parameter.

@@ -105,7 +105,7 @@ Module managers are used to manage collections of `AppModuleBasic` and `AppModul

 The `BasicManager` is a structure that lists all the `AppModuleBasic` of an application:

-+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/types/module/module.go#L62-L72
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0/types/module/module.go#L62-L72

 It implements the following methods:

@@ -122,7 +122,7 @@ It implements the following methods:

 The `Manager` is a structure that holds all the `AppModule` of an application, and defines the order of execution between several key components of these modules:

-+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/types/module/module.go#L216-L225
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0/types/module/module.go#L216-L225

 The module manager is used throughout the application whenever an action on a collection of modules is required. It implements the following methods:

@@ -144,7 +144,7 @@ The module manager is used throughout the application whenever an action on a co

 Here's an example of a concrete integration within an application:

-+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/simapp/app.go#L342-L409
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0/simapp/app.go#L342-L409

 ## Next {hide}

@@ -19,15 +19,15 @@ 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:

-+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/x/bank/types/tx.pb.go#L288-L294
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0/x/bank/types/tx.pb.go#L288-L294

 When possible, the existing module's [`Keeper`](keeper.md) should implement `MsgServer`, otherwise a `msgServer` struct that embeds the `Keeper` can be created, typically in `./keeper/msg_server.go`:

-+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/x/bank/keeper/msg_server.go#L14-L16
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0/x/bank/keeper/msg_server.go#L14-L16

 `msgServer` methods can retrieve the `sdk.Context` from the `context.Context` parameter method using the `sdk.UnwrapSDKContext`:

-+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/x/bank/keeper/msg_server.go#L27-L27
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0/x/bank/keeper/msg_server.go#L27-L27

 `sdk.Msg` processing usually follows these 3 steps:

@@ -77,11 +77,11 @@ 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 sdk.Context, res proto.Message, err error)`:

-+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/baseapp/msg_service_router.go#L127
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0/baseapp/msg_service_router.go#L127

 This method takes care of marshaling the `res` parameter to protobuf and attaching any events on the `ctx.EventManager()` to the `sdk.Result`.

-+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/proto/cosmos/base/abci/v1beta1/abci.proto#L88-L109
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0/proto/cosmos/base/abci/v1beta1/abci.proto#L88-L109

 This diagram shows a typical structure of a Protobuf `Msg` service, and how the message propagates through the module.

@@ -93,7 +93,7 @@ New [telemetry metrics](../core/telemetry.md) can be created from `msgServer` me

 This is an example from the `x/auth/vesting` module:

-+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/x/auth/vesting/msg_server.go#L73-L85
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0/x/auth/vesting/msg_server.go#L73-L85

 ## Next {hide}

@@ -15,7 +15,7 @@ A Protobuf Query service processes [`queries`](./messages-and-queries.md#queries

 The `querier` type defined in the Cosmos SDK will be deprecated in favor of [gRPC Services](#grpc-service). It specifies the typical structure of a `querier` function:

-+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/types/queryable.go#L9
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0/types/queryable.go#L9

 Let us break it down:

@@ -43,7 +43,7 @@ from the store. Therefore, the Cosmos SDK provides a function `sdk.UnwrapSDKCont

 Here's an example implementation for the bank module:

-+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/x/bank/keeper/grpc_query.go
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0/x/bank/keeper/grpc_query.go

 ### Legacy Queriers

@@ -70,7 +70,7 @@ This simple switch returns a `querier` function specific to the type of the rece

 The `querier` functions themselves are pretty straightforward. They generally fetch a value or values from the state using the [`keeper`](./keeper.md). Then, they marshall the value(s) using the [`codec`](../core/encoding.md) and return the `[]byte` obtained as result.

-For a deeper look at `querier`s, see this [example implementation of a `querier` function](https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/x/gov/keeper/querier.go) from the bank module.
+For a deeper look at `querier`s, see this [example implementation of a `querier` function](https://github.com/cosmos/cosmos-sdk/blob/v0.46.0/x/gov/keeper/querier.go) from the bank module.

 ## Next {hide}

@@ -32,7 +32,7 @@ for the key-value pairs from the stores to be decoded (_i.e_ unmarshalled)
 to their corresponding types. In particular, it matches the key to a concrete type
 and then unmarshals the value from the `KVPair` to the type provided.

-You can use the example [here](https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/x/distribution/simulation/decoder.go) from the distribution module to implement your store decoders.
+You can use the example [here](https://github.com/cosmos/cosmos-sdk/blob/v0.46.0/x/distribution/simulation/decoder.go) from the distribution module to implement your store decoders.

 ### Randomized genesis

@@ -43,13 +43,13 @@ Once the module genesis parameter are generated randomly (or with the key and
 values defined in a `params` file), they are marshaled to JSON format and added
 to the app genesis JSON to use it on the simulations.

-You can check an example on how to create the randomized genesis [here](https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/x/staking/simulation/genesis.go).
+You can check an example on how to create the randomized genesis [here](https://github.com/cosmos/cosmos-sdk/blob/v0.46.0/x/staking/simulation/genesis.go).

 ### Randomized parameter changes

 The simulator is able to test parameter changes at random. The simulator package from each module must contain a `RandomizedParams` func that will simulate parameter changes of the module throughout the simulations lifespan.

-You can see how an example of what is needed to fully test parameter changes [here](https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/x/staking/simulation/params.go)
+You can see how an example of what is needed to fully test parameter changes [here](https://github.com/cosmos/cosmos-sdk/blob/v0.46.0/x/staking/simulation/params.go)

 ### Random weighted operations

@@ -62,7 +62,7 @@ Operations on the simulation are simulated using the full [transaction cycle](..

 Shown below is how weights are set:

-+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/x/staking/simulation/operations.go#L17-L75
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0/x/staking/simulation/operations.go#L17-L75

 As you can see, the weights are predefined in this case. Options exist to override this behavior with different weights. One option is to use `*rand.Rand` to define a random weight for the operation, or you can inject your own predefined weights.

@@ -82,7 +82,7 @@ them to be used on the parameters.

 Now that all the required functions are defined, we need to integrate them into the module pattern within the `module.go`:

-+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/x/distribution/module.go
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0/x/distribution/module.go

 ## App Simulator manager

@@ -41,7 +41,7 @@ func (am AppModule) RegisterServices(cfg module.Configurator) {

 Since these migrations are functions that need access to a Keeper's store, use a wrapper around the keepers called `Migrator` as shown in this example:

-+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/x/bank/keeper/migrations.go#L9-L27
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.46.0/x/bank/keeper/migrations.go#L9-L27

 ## Writing Migration Scripts

@@ -54,4 +54,4 @@ func (m Migrator) Migrate1to2(ctx sdk.Context) error {
 }
 ```

-To see example code of changes that were implemented in a migration of balance keys, check out [migrateBalanceKeys](https://github.com/cosmos/cosmos-sdk/blob/v0.46.0-rc1/x/bank/migrations/v2/store.go#L50-L71). For context, this code introduced migrations of the bank store that updated addresses to be prefixed by their length in bytes as outlined in [ADR-028](../architecture/adr-028-public-key-addresses.md).
+To see example code of changes that were implemented in a migration of balance keys, check out [migrateBalanceKeys](https://github.com/cosmos/cosmos-sdk/blob/v0.46.0/x/bank/migrations/v2/store.go#L50-L71). For context, this code introduced migrations of the bank store that updated addresses to be prefixed by their length in bytes as outlined in [ADR-028](../architecture/adr-028-public-key-addresses.md).