updates

Author: evanorti

sdk/next/learn/concepts/cli-grpc-rest.mdx

@@ -32,7 +32,7 @@ All endpoints default to `localhost` and must be configured to be accessible ove
 
 The CLI is the primary tool for developers and operators interacting with a chain from the terminal. Most Cosmos SDK chains ship a single binary that acts as both the server process and the CLI client. It is common to append a `d` suffix to the binary name to indicate that it is a daemon process, such as `exampled` or `simd`.
 
-{/* todo: link to node tutorial page */}
+For a hands-on walkthrough of running a local chain and using the CLI, see the [Running and Testing](/sdk/next/tutorials/example/05-run-and-test) tutorial.
 
 When used as a client, the CLI constructs a transaction or query, signs it if required, and submits it through the node client interface.
 
@@ -67,11 +67,11 @@ exampled tx counter add 10 \
 
 Gas limits the computational work a transaction can perform. The full gas model is explained in [Execution Context, Gas, and Events](/sdk/next/learn/concepts/context-gas-events).
 
-{/* todo: link to node tutorial page on how to use the CLI*/}
+For a full CLI reference for the example chain, see [CLI reference](/sdk/next/tutorials/example/05-run-and-test#cli-reference) in the Running and Testing tutorial.
 
 ### How modules expose CLI commands with `AutoCLI`
 
-In modern Cosmos SDK applications, modules expose CLI commands through **`AutoCLI`**. `AutoCLI` reads a module's protobuf service definitions and generates CLI commands automatically, without requiring modules to hand-write Cobra command boilerplate. The counter snippets in this section are from the minimal counter module example. {/* TODO: link to minimal counter module example when it is published in the docs */}
+In modern Cosmos SDK applications, modules expose CLI commands through **`AutoCLI`**. `AutoCLI` reads a module's protobuf service definitions and generates CLI commands automatically, without requiring modules to hand-write Cobra command boilerplate. The counter snippets in this section are from the minimal counter module example. See the [Build a Module from Scratch](/sdk/next/tutorials/example/03-build-a-module) tutorial.
 
 A module opts into `AutoCLI` by implementing `AutoCLIOptions()` on its `AppModule`:
 
@@ -248,7 +248,7 @@ Some CometBFT RPC endpoints are directly related to the Cosmos SDK:
 
 ## End-to-end interaction flow
 
-To illustrate how these interfaces connect, here is the path of a `counter add` transaction from the user's terminal to a state change on the chain. This example follows the minimal counter module example's CLI shape. {/* TODO: link to minimal counter module example when it is published in the docs */}
+To illustrate how these interfaces connect, here is the path of a `counter add` transaction from the user's terminal to a state change on the chain. This example follows the minimal counter module example's CLI shape. See the [Build a Module from Scratch](/sdk/next/tutorials/example/03-build-a-module#step-9-autocli) tutorial.
 
 ```
 User runs: exampled tx counter add 10 --from mykey --chain-id example-1

sdk/next/learn/concepts/context-gas-events.mdx

@@ -99,7 +99,7 @@ If gas is exhausted during execution, `ConsumeGas` panics with `ErrorOutOfGas`.
 
 ### Block gas limit
 
-In addition to the per-transaction gas meter, there is a block-level gas meter that tracks total gas consumed by all transactions in a block. The block gas limit prevents a single block from consuming unbounded computation. If a transaction would cause the block's gas total to exceed the limit, it is excluded from the block.
+In addition to the per-transaction gas meter, there is a block-level gas meter that tracks total gas consumed by all transactions in a block. The block gas limit prevents a single block from consuming unbounded computation. If a transaction would cause the block's gas total to exceed the limit, it is excluded from the block. The block gas limit and minimum gas prices are configured in [`app.toml`](/sdk/next/tutorials/example/05-run-and-test#apptoml).
 
 ## Events
 

sdk/next/learn/concepts/encoding.mdx

@@ -41,7 +41,7 @@ The Cosmos SDK uses protobuf in two encoding modes:
 
 **Binary encoding** is the default for everything that participates in consensus: transactions written to blocks, state stored in KV stores, and genesis data. Binary encoding is compact and deterministic. When a transaction is broadcast to the network, it travels as protobuf binary. When a module writes state, it serializes values to protobuf binary before calling `Set` on the store.
 
-**JSON encoding** is used for human-readable output: the CLI, gRPC-gateway REST endpoints, and off-chain tooling. The Cosmos SDK uses protobuf's JSON encoding (`ProtoMarshalJSON`) rather than standard Go JSON, which preserves field names from the `.proto` schema and handles special types like `Any` correctly.
+**JSON encoding** is used for human-readable output: the [CLI, gRPC-gateway REST endpoints](/sdk/next/learn/concepts/cli-grpc-rest), and off-chain tooling. The Cosmos SDK uses protobuf's JSON encoding (`ProtoMarshalJSON`) rather than standard Go JSON, which preserves field names from the `.proto` schema and handles special types like `Any` correctly.
 
 It is important to keep in mind that **binary encoding is consensus-critical**. Two validators must produce identical binary bytes for identical data. JSON is only used where humans or external clients need to read the data; it never influences the AppHash.
 
@@ -123,13 +123,13 @@ Most public and persisted data types in modern SDK modules are defined in `.prot
 
 Each module defines its transaction messages in a `tx.proto` file. The `MsgSend` definition above is an example. When a user submits a transaction, the SDK serializes the transaction body (including its messages) to binary using protobuf before broadcasting it.
 
-[todo: link to tutorial tx.proto section]
+For a hands-on example, see [tx.proto](/sdk/next/tutorials/example/03-build-a-module#txproto) in the Build a Module tutorial.
 
 ### Queries
 
 Modules define their query services in `query.proto`. Request and response types are protobuf messages. The SDK uses gRPC for queries, and gRPC uses protobuf as its serialization format by definition.
 
-[todo: link to tutorial query proto section]
+For a hands-on example, see [query.proto](/sdk/next/tutorials/example/03-build-a-module#queryproto) in the Build a Module tutorial.
 
 ### State types
 
@@ -277,7 +277,7 @@ func RegisterLegacyAminoCodec(cdc *codec.LegacyAmino) {
 
 `RegisterInterfaces` is required for every module that defines message types. Without it, the SDK cannot decode those messages from transactions. `RegisterLegacyAminoCodec` is optional and only needed for Ledger hardware wallet support via `SIGN_MODE_LEGACY_AMINO_JSON`.
 
-{/* todo: link to tutorial codec.go section */}
+For an example of interface registration in a working module, see [Interface Registration](/sdk/next/tutorials/example/03-build-a-module#interface-registration) in the Build a Module tutorial.
 
 ## Proto-to-code generation workflow
 
@@ -351,6 +351,8 @@ func (m msgServer) Add(ctx context.Context, req *types.MsgAdd) (*types.MsgAddRes
 
 The generated gRPC service stub is registered with BaseApp's message router, connecting the handler to the transaction execution pipeline automatically.
 
+To learn how to build a module from scratch using this workflow, visit the [Module building tutorial](/sdk/next/tutorials/example/00-overview)
+
 ## Legacy Amino encoding
 
 Before protobuf, the Cosmos SDK used a custom serialization format called **Amino** for transaction encoding, JSON signing documents, and interface serialization. Protobuf has replaced it in all of those roles. The `LegacyAmino` codec still exists for backward compatibility, but is not used in the consensus-critical path.

sdk/next/learn/concepts/lifecycle.mdx

@@ -6,14 +6,14 @@ In the [Transactions, Messages, and Queries](/sdk/next/learn/concepts/transactio
 
 Before building with the Cosmos SDK, it's important to connect the high-level architecture from [SDK Application Architecture](/sdk/next/learn/intro/sdk-app-architecture) with how blocks and transactions actually execute in code.
 
-A Cosmos SDK application can be conceptually split into layers:
+The following components are essential for understanding the lifecycle of a transaction in the Cosmos SDK:
 
 - [CometBFT](/cometbft) (consensus engine) — orders and proposes blocks
 - [ABCI](/sdk/next/learn/intro/sdk-app-architecture#abci-application-blockchain-interface) (Application-Blockchain Interface) — the protocol CometBFT uses to talk to the Cosmos SDK application
 - SDK application ([`BaseApp`](/sdk/next/learn/concepts/baseapp) + [modules](/sdk/next/learn/concepts/modules)) — the deterministic state machine that executes transactions
 - [Protobuf schemas](/sdk/next/learn/concepts/encoding) — define transactions, messages, state, and query types
 
-This page maps the block and transaction lifecycle back to those layers.
+This page maps the block and transaction lifecycle back to those components.
 
 ## ABCI overview
 
@@ -203,4 +203,4 @@ CometBFT drives block processing through ABCI. `BaseApp` implements ABCI and orc
 - Message execution within a transaction is atomic: all messages commit or none do
 - `FinalizeBlock` computes and returns the app hash; `Commit` persists state to disk
 
-Protobuf ensures canonical encoding so all validators interpret transactions identically. The next section, [Intro to Modules](/sdk/next/learn/concepts/modules), turns from block execution to the module structure that actually implements chain logic.
+[Protobuf](/sdk/next/learn/concepts/encoding) ensures canonical encoding so all validators interpret transactions identically. The next section, [Intro to Modules](/sdk/next/learn/concepts/modules), turns from block execution to the module structure that actually implements chain logic.

sdk/next/learn/concepts/modules.mdx

@@ -8,7 +8,7 @@ In the Cosmos SDK, **modules** define that logic.
 
 Modules are the fundamental building blocks of a Cosmos SDK application. Each module encapsulates a specific piece of functionality, such as accounts, token transfers, validator management, governance, or any custom logic you define.
 
-{/* TODO: link to counter module example walkthrough when it is published in the docs */}
+To see a complete working module, follow the [Build a module tutorial series](/sdk/next/tutorials/example/00-overview).
 
 ## Why modules exist
 
@@ -106,7 +106,7 @@ The `MsgServer` is responsible for:
 - Delegating to keeper methods that validate inputs, enforce business rules, and perform state transitions
 - Returning a response
 
-The following example is from the minimal counter module tutorial example, which walks you through building a module that lets users increment a shared counter. {/* TODO: link to Build a Module tutorial */}
+The following example is from the minimal counter module tutorial example, which walks you through building a module that lets users increment a shared counter. See the [Build a Module from Scratch](/sdk/next/tutorials/example/03-build-a-module) tutorial.
 
 The following is the counter module's `Add` handler which is the `MsgServer` method that processes a request to increment the counter:
 
@@ -123,7 +123,7 @@ func (m msgServer) Add(ctx context.Context, request *types.MsgAddRequest) (*type
 
 In the minimal tutorial, `Add` is permissionless and delegates directly to the keeper. The handler itself contains almost no business logic. That keeps `msg_server.go` focused on request handling, while the keeper owns the actual state transition.
 
-The full counter module example adds richer patterns on top of that minimal shape. For privileged messages like `MsgUpdateParams`, the `MsgServer` checks the caller against the stored authority before proceeding: {/* TODO: link to counter module example walkthrough */}
+The full counter module example adds richer patterns on top of that minimal shape. For privileged messages like `MsgUpdateParams`, the `MsgServer` checks the caller against the stored authority before proceeding. See the [Full Counter Module Walkthrough](/sdk/next/tutorials/example/04-counter-walkthrough#params-and-authority).
 
 ```go
 func (m msgServer) UpdateParams(ctx context.Context, msg *types.MsgUpdateParams) (*types.MsgUpdateParamsResponse, error) {
@@ -150,7 +150,7 @@ A module's **`Keeper`** is its state access layer. It owns the module's `KVStore
 
 The `MsgServer` and `QueryServer` both embed the keeper. It is best practice for business logic to be implemented in keeper methods rather than the `MsgServer`, so the same rules apply whether the caller is a message handler, a block hook, or a governance proposal.
 
-The following keeper example is from the minimal counter module example. It holds a single state item and shows the smallest useful keeper shape. {/* TODO: link to minimal counter module example */}
+The following keeper example is from the minimal counter module example. It holds a single state item and shows the smallest useful keeper shape. See [Step 5: Keeper](/sdk/next/tutorials/example/03-build-a-module#step-5-keeper) in the tutorial.
 
 ```go
 type Keeper struct {
@@ -185,7 +185,7 @@ Each module defines an `expected_keepers.go` file that declares the interfaces i
 
 This design keeps dependencies auditable and prevents accidental or unsafe cross-module state mutation.
 
-{/* TODO: link to minimal counter module example section on expected keepers */}
+To see expected keepers and cross-module fee collection in practice, see [Expected keepers and fee collection](/sdk/next/tutorials/example/04-counter-walkthrough#expected-keepers-and-fee-collection) in the Full Counter Module Walkthrough.
 
 ### Params
 
@@ -197,8 +197,7 @@ The authority address is set at keeper construction time in [`app.go`](/sdk/next
 
 For chain-level consensus parameters, the [`x/consensus`](/sdk/next/build/modules/consensus) module manages them centrally; it also supports [`AuthorityParams`](/sdk/next/build/modules/consensus/README#authorityparams), which lets governance update the authority address on-chain without a software upgrade.
 
-{/* TODO: link to params section of the module tutorial when published */}
-
+To see params implemented in a working module, see [Params and authority](/sdk/next/tutorials/example/04-counter-walkthrough#params-and-authority) in the Full Counter Module Walkthrough.
 
 ### Block hooks
 
@@ -245,7 +244,7 @@ Each module implements:
 During `InitChain`, `BaseApp` calls each module's `InitGenesis` to populate its state from `genesis.json`.
 
 For where this happens in the block lifecycle, see [InitChain (genesis only)](/sdk/next/learn/concepts/lifecycle#initchain-genesis-only).
-{/* todo: link to tutorial genesis section */}
+For a walkthrough of genesis implementation, see [Step 2: Proto files](/sdk/next/tutorials/example/03-build-a-module#step-2-proto-files) and [Step 8: module.go](/sdk/next/tutorials/example/03-build-a-module#step-8-modulego) in the Build a Module tutorial.
 
 ## Built-in and custom modules
 
@@ -324,6 +323,8 @@ proto/myapp/mymodule/v1/
 - `module.go`: Connects the module to the application and registers genesis handlers, block hooks, and message and query services.
 - `.proto` files: Define messages, queries, state schemas, and genesis state. Go code is generated from these files and used throughout the module.
 
+Check out the [Module Tutorial](/sdk/next/tutorials/example/00-overview) to learn how to build a module from scratch. 
+
 ## Modules in context
 
 Putting everything together you've learned so far:

sdk/next/learn/concepts/sdk-structure.mdx

@@ -14,7 +14,7 @@ Every SDK application is composed of three main elements:
 - [Modules](/sdk/next/learn/concepts/modules): self-contained units of business logic, state, messages, and queries
 - [`app.go`](/sdk/next/learn/concepts/app-go): the wiring layer that instantiates `BaseApp`, registers modules, and configures the application at startup
 
-`BaseApp` and `app.go` are covered in depth in the next two sections. This page focuses on how they are organized in the codebase.
+`BaseApp` and `app.go` are covered in depth in the next two sections. This page focuses on how they are organized in the codebase. To see all of this in action, follow the [Build a Chain tutorial series](/sdk/next/tutorials/example/00-overview).
 
 ## Repository structure
 

sdk/next/learn/concepts/store.mdx

@@ -107,7 +107,7 @@ The IAVL tree does not store data in memory. It writes versioned nodes to a data
 
 The Cosmos SDK uses [CometBFT's `db` package](https://github.com/cometbft/cometbft-db) to abstract over the database implementation. The default backend is [goleveldb](https://github.com/syndtr/goleveldb). Other supported backends include [PebbleDB](https://github.com/cockroachdb/pebble), [RocksDB](https://github.com/facebook/rocksdb), and memDB (in-memory, for testing).
 
-The database backend is selected at node startup and configured in `app.toml`. Application code never interacts with it directly; the store layer owns that boundary.
+The database backend is selected at node startup and configured in [`app.toml`](/sdk/next/tutorials/example/05-run-and-test#apptoml). Application code never interacts with it directly; the store layer owns that boundary.
 
 ## Store types in the SDK
 
@@ -245,7 +245,7 @@ KVStores populated
 
 For information on how modules define their genesis methods (`DefaultGenesis`, `ValidateGenesis`, `InitGenesis`, `ExportGenesis`) and initialization ordering, see [Intro to Modules](/sdk/next/learn/concepts/modules) and [Transaction Lifecycle](/sdk/next/learn/concepts/lifecycle).
 
-{/* todo: link to genesis in tutorial */}
+For a walkthrough of genesis implementation in a module, see [Step 2: Proto files](/sdk/next/tutorials/example/03-build-a-module#step-2-proto-files) and [Step 8: module.go](/sdk/next/tutorials/example/03-build-a-module#step-8-modulego) in the Build a Module tutorial.
 
 ## Next steps
 

sdk/next/learn/concepts/testing.mdx

@@ -4,7 +4,7 @@ title: Testing in the SDK
 
 The Cosmos SDK provides a layered testing approach that mirrors the architecture of the framework itself. Tests are organized into three levels, each testing a progressively larger slice of the application. This page uses the counter module example in the `example` repo, not the minimal counter module example, because the fuller module includes the testing surfaces needed for these examples.
 
-{/* TODO: link to counter module example walkthrough when it is published in the docs throughout this page. */}
+The examples on this page come from the [Full Counter Module Walkthrough](/sdk/next/tutorials/example/04-counter-walkthrough#unit-tests) and [Running and Testing](/sdk/next/tutorials/example/05-run-and-test) tutorials.
 
 ## Three testing levels