Bump font weight docs website and fix link

docs/basics/accounts.md

@@ -5,7 +5,7 @@ synopsis: This document describes the in-built accounts system of the Cosmos SDK
 
 # Accounts 
 
-## Pre-requisite Readings
+## Pre-requisite Readings {hide}
 
 - [Anatomy of an SDK Application](./app-anatomy.md) {prereq}
 
@@ -129,6 +129,6 @@ Of note, the `Marhsal()` and `Bytes()` method both return the same raw `[]byte`
 
 +++ https://github.com/cosmos/cosmos-sdk/blob/master/types/address.go#L230-L243
 
-## Next
+## Next {hide}
 
 Learn about [gas and fees](./gas-fees.md).

docs/basics/app-anatomy.md

@@ -3,9 +3,9 @@ order: 1
 synopsis: "This document describes the core parts of a Cosmos SDK application. Throughout the document, a placeholder application named `app` will be used."
 ---
 
-# Anatomy of an SDK Application
+# Anatomy of an SDK Application 
 
-## Pre-requisite Readings
+## Pre-requisite Readings {hide}
 
 - [High-level overview of the architecture of an SDK application](../intro/sdk-app-architecture.md) {prereq}
 - [Cosmos SDK design overview](../intro/sdk-design.md) {prereq}
@@ -251,6 +251,6 @@ For building the application, a [Makefile](https://en.wikipedia.org/wiki/Makefil
 
 +++ https://github.com/cosmos/sdk-tutorials/blob/86a27321cf89cc637581762e953d0c07f8c78ece/nameservice/Makefile
 
-## Next
+## Next {hide}
 
 Learn more about the [Lifecycle of a transaction](./tx-lifecycle.md).

docs/basics/gas-fees.md

@@ -3,9 +3,9 @@ order: 4
 synopsis: This document describes the default strategies to handle gas and fees within a Cosmos SDK application.
 ---
 
-# Gas and Fees
+# Gas and Fees 
 
-## Pre-requisite Readings
+## Pre-requisite Readings {hide}
 
 - [Anatomy of an SDK Application](./app-anatomy.md) {prereq}
 
@@ -83,6 +83,6 @@ This enables developers to play with various types for the transaction of their
 
 As explained above, the `anteHandler` returns a maximum limit of `gas` the transaction can consume during execution called `GasWanted`. The actual amount consumed in the end is denominated `GasUsed`, and we must therefore have `GasUsed =< GasWanted`. Both `GasWanted` and `GasUsed` are relayed to the underlying consensus engine when [`DeliverTx`](../core/baseapp.md#delivertx) returns. 
 
-## Next
+## Next {hide}
 
 Learn about [baseapp](../core/baseapp.md). 

docs/basics/tx-lifecycle.md

@@ -5,7 +5,7 @@ synopsis: "This document describes the lifecycle of a transaction from creation
 
 # Transaction Lifecycle
 
-## Pre-requisite Readings
+## Pre-requisite Readings {hide}
 
 - [Anatomy of an SDK Application](./app-anatomy.md) {prereq}
 
@@ -240,6 +240,6 @@ At this point, the transaction lifecycle of a `Tx` is over: nodes have verified
 delivered it by executing its state changes, and committed those changes. The `Tx` itself,
 in `[]byte` form, is stored in a block and appended to the blockchain.
 
-## Next
+## Next {hide}
 
 Learn about [accounts](./accounts.md).

docs/building-modules/beginblock-endblock.md

@@ -5,7 +5,7 @@ synopsis: "`BeginBlocker` and `EndBlocker` are optional methods module developer
 
 # BeginBlocker and EndBlocker
 
-## Pre-requisite Readings
+## Pre-requisite Readings {hide}
 
 - [Module Manager](./module-manager.md) {prereq}
 
@@ -33,6 +33,6 @@ and an example implementation of `EndBlocker` from the `staking` module:
 
 +++ https://github.com/cosmos/cosmos-sdk/blob/master/x/staking/handler.go#L44-L96
 
-## Next
+## Next {hide}
 
 Learn about [`keeper`s](./keeper.md).

docs/building-modules/genesis.md

@@ -5,7 +5,7 @@ synopsis: Modules generally handle a subset of the state and, as such, they need
 
 # Module Genesis
 
-## Pre-requisite Readings
+## Pre-requisite Readings {hide}
 
 - [Module Manager](./module-manager.md) {prereq}
 - [Keepers](./keeper.md) {prereq}
@@ -54,6 +54,6 @@ See an example of `ExportGenesis` from the nameservice tutorial.
 
 +++ https://github.com/cosmos/sdk-tutorials/blob/86a27321cf89cc637581762e953d0c07f8c78ece/nameservice/x/nameservice/genesis.go#L46-L57
 
-## Next
+## Next {hide}
 
 Learn about [modules interfaces](#module-interfaces.md).

docs/building-modules/handler.md

@@ -5,7 +5,7 @@ synopsis: "A `Handler` designates a function that processes [`message`s](./messa
 
 # Handlers
 
-## Pre-requisite Readings
+## Pre-requisite Readings {hide}
 
 - [Module Manager](./module-manager.md) {prereq}
 - [Messages and Queries](./messages-and-queries.md) {prereq}
@@ -71,6 +71,6 @@ Next is an example of how to return a `Result` from the `gov` module:
 
 For a deeper look at `handler`s, see this [example implementation of a `handler` function](https://github.com/cosmos/sdk-application-tutorial/blob/c6754a1e313eb1ed973c5c91dcc606f2fd288811/x/nameservice/handler.go) from the nameservice tutorial. 
 
-## Next
+## Next {hide}
 
 Learn about [queriers](./querier.md). 

docs/building-modules/intro.md

@@ -5,7 +5,7 @@ synopsis: Modules define most of the logic of SDK applications. Developers compo
 
 # Introduction to SDK Modules
 
-## Pre-requisite Readings
+## Pre-requisite Readings {hide}
 
 - [Anatomy of an SDK application](../basics/app-anatomy.md) {prereq}
 - [Lifecycle of an SDK transaction](../basics/tx-lifecycle.md) {prereq}
@@ -87,7 +87,7 @@ In addition to these components, modules implement the `AppModule` interface in
 
 Please refer to the [structure document](./structure.md) to learn about the recommended structure of a module's directory. 
 
-## Next
+## Next {hide}
 
 Read more on the [`AppModule` interface and the `module manager`](./module-manager.md)
 

docs/building-modules/invariants.md

@@ -5,7 +5,7 @@ synopsis: "An invariant is a property of the application that should always be t
 
 # Invariants
 
-## Pre-requisite Readings
+## Pre-requisite Readings {hide}
 
 - [Keepers](./keeper.md) {prereq}
 
@@ -83,6 +83,6 @@ Typically, this interface is implemented in the `keeper` of a specific module. T
 
 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).
 
-## Next
+## Next {hide}
 
 Learn about [genesis functionalities](./genesis.md). 

docs/building-modules/keeper.md

@@ -5,7 +5,7 @@ synopsis: "`Keeper`s refer to a Cosmos SDK abstraction whose role is to manage a
 
 # Keepers
 
-## Pre-requisite Readings
+## Pre-requisite Readings {hide}
 
 - [Introduction to SDK Modules](./intro.md) {prereq}
 
@@ -73,6 +73,6 @@ and go through the following steps:
 
 For more, see an example of `keeper`'s [methods implementation from the nameservice tutorial](https://github.com/cosmos/sdk-application-tutorial/blob/c6754a1e313eb1ed973c5c91dcc606f2fd288811/x/nameservice/internal/keeper/keeper.go). 
 
-## Next
+## Next {hide}
 
 Learn about [invariants](./invariants.md). 

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

@@ -5,7 +5,7 @@ synopsis: "`Message`s and `Queries` are the two primary objects handled by modul
 
 # Messages and Queries
 
-## Pre-requisite Readings
+## Pre-requisite Readings {hide}
 
 - [Introduction to SDK Modules](./intro.md) {prereq}
 
@@ -70,6 +70,6 @@ See an example of `query` return types from the `nameservice` module:
 
 +++ https://github.com/cosmos/sdk-tutorials/blob/c6754a1e313eb1ed973c5c91dcc606f2fd288811/x/nameservice/internal/types/querier.go#L5-L21
 
-## Next
+## Next {hide}
 
 Learn about [`handler`s](./handler.md).

docs/building-modules/module-interfaces.md

@@ -5,7 +5,7 @@ synopsis: This document details how to build CLI and REST interfaces for a modul
 
 # Module Interfaces
 
-## Pre-requisite Readings
+## Pre-requisite Readings {hide}
 
 * [Building Modules Intro](./intro.md) {prereq}
 
@@ -162,6 +162,6 @@ A few things to note:
 * `"GET"` is the HTTP Request method. As to be expected, queries are typically GET requests. Transactions are typically POST and PUT requests.
 
 
-## Next
+## Next {hide}
 
 Read about the recommended [module structure](./structure.md).

docs/building-modules/module-manager.md

@@ -6,7 +6,7 @@ synopsis: "Cosmos SDK modules need to implement the [`AppModule` interfaces](#ap
 
 # Module Manager
 
-## Pre-requisite Readings
+## Pre-requisite Readings {hide}
 
 - [Introduction to SDK Modules](./intro.md) {prereq}
 
@@ -139,6 +139,6 @@ The module manager is used throughout the application whenever an action on a co
 - `BeginBlock(ctx sdk.Context, req abci.RequestBeginBlock)`: At the beginning of each block, this function is called from [`baseapp`](../core/baseapp.md#beginblock) and, in turn, calls the [`BeginBlock`](./beginblock-endblock.md) function of each module, in the order defined in `OrderBeginBlockers`. It creates a child [context](../core/context.md) with an event manager to aggregate [events](../core/events.md) emitted from all modules. The function returns an `abci.ResponseBeginBlock` which contains the aforementioned events. 
 - `EndBlock(ctx sdk.Context, req abci.RequestEndBlock)`: At the end of each block, this function is called from [`baseapp`](../core/baseapp.md#endblock) and, in turn, calls the [`EndBlock`](./beginblock-endblock.md) function of each module, in the order defined in `OrderEndBlockers`. It creates a child [context](../core/context.md) with an event manager to aggregate [events](../core/events.md) emitted from all modules. The function returns an `abci.ResponseEndBlock` which contains the aforementioned events, as well as validator set updates (if any).
 
-## Next
+## Next {hide}
 
 Learn more about [`message`s and `queries`](./messages-and-queries.md).

docs/building-modules/querier.md

@@ -5,7 +5,7 @@ synopsis: "A `Querier` designates a function that processes [`queries`](./messag
 
 # Queriers
 
-## Pre-requisite Readings
+## Pre-requisite Readings {hide}
 
 - [Module Manager](./module-manager.md) {prereq}
 - [Messages and Queries](./messages-and-queries.md) {prereq}
@@ -48,6 +48,6 @@ The `querier` functions themselves are pretty straighforward. They generally fet
 
 For a deeper look at `querier`s, see this [example implementation of a `querier` function](https://github.com/cosmos/sdk-application-tutorial/blob/c6754a1e313eb1ed973c5c91dcc606f2fd288811/x/nameservice/internal/keeper/querier.go) from the nameservice tutorial. 
 
-## Next
+## Next {hide}
 
 Learn about [`BeginBlocker` and `EndBlocker`](./beginblock-endblock.md).

docs/building-modules/structure.md

@@ -81,6 +81,6 @@ allows for greater freedom of development while maintaining API stability.
 interfaces.
 - `simulation.go`: The module's simulation messages and related types (if any).
 
-## Next
+## Next {hide}
 
 Learn about [interfaces](../interfaces/interfaces-intro.md).

docs/core/baseapp.md

@@ -5,7 +5,7 @@ synopsis: This document describes `BaseApp`, the abstraction that implements the
 
 # Baseapp
 
-## Pre-requisite Readings
+## Pre-requisite Readings {hide}
 
 - [Anatomy of an SDK application](../basics/app-anatomy.md) {prereq}
 - [Lifecycle of an SDK transaction](../basics/tx-lifecycle.md) {prereq}
@@ -388,6 +388,6 @@ Each `query` comes with a `path`, which contains multiple `string`s. By conventi
 - P2P queries, which are served via the `handleQueryP2P` method. These queries return either `app.addrPeerFilter` or `app.ipPeerFilter` that contain the list of peers filtered by address or IP respectively. These lists are first initialized via `options` in `baseapp`'s [constructor](#constructor).
 - Custom queries, which encompass most queries, are served via the `handleQueryCustom` method. The `handleQueryCustom` cache-wraps the multistore before using the `queryRoute` obtained from [`app.queryRouter`](#query-routing) to map the query to the appropriate module's `querier`.
 
-## Next
+## Next {hide}
 
 Learn more about [transactions](./transactions.md).

docs/core/context.md

@@ -5,7 +5,7 @@ synopsis: The `context` is a data structure intended to be passed from function
 
 # Context
 
-## Pre-requisites Readings
+## Pre-requisites Readings {hide}
 
 - [Anatomy of an SDK Application](../basics/app-anatomy.md) {prereq}
 - [Lifecycle of a Transaction](../basics/tx-lifecycle.md) {prereq}
@@ -112,6 +112,6 @@ changes - the result is returned immediately.
 4. If the process is running in [`deliverTxMode`](./baseapp.md#delivertx) and the result indicates
 a successful run over all the messages, the cached multistore is written back to the original.
 
-## Next
+## Next {hide}
 
 Learn about the [node client](./node.md)

docs/core/encoding.md

@@ -5,7 +5,7 @@ synopsis: The `codec` is used everywhere in the Cosmos SDK to encode and decode
 
 # Encoding
 
-## Pre-requisite Reading
+## Pre-requisite Readings {hide}
 
 - [Anatomy of an SDK application](../basics/app-anatomy.md) {prereq}
 
@@ -41,6 +41,6 @@ A standard implementation of both these objects can be found in the [`auth` modu
 
 +++ https://github.com/cosmos/cosmos-sdk/blob/master/x/auth/types/stdtx.go#L241-L266
 
-## Next
+## Next {hide}
 
 Learn about [events](./events.md).

docs/core/events.md

@@ -5,7 +5,7 @@ synopsis: "`Event`s are objects that contain information about the execution of
 
 # Events
 
-## Pre-Requisite Readings
+## Pre-Requisite Readings {hide}
 
 - [Anatomy of an SDK application](../basics/app-anatomy.md) {prereq}
 
@@ -86,6 +86,6 @@ The `type` and `attribute` value of the `query` allow you to filter the specific
 
 where `senderAddress` is an address following the [`AccAddress`](../basics/accounts.md#addresses) format. 
 
-## Next
+## Next {hide}
 
 Learn about [object-capabilities](./ocap.md)

docs/core/node.md

@@ -5,7 +5,7 @@ synopsis: The main endpoint of an SDK application is the daemon client, otherwis
 
 # Node Client (Daemon)
 
-## Pre-requisite Reading
+## Pre-requisite Readings {hide}
 
 - [Anatomy of an SDK application](../basics/app-anatomy.md) {prereq}
 
@@ -65,6 +65,6 @@ if err := tmNode.Start(); err != nil {
 
 Upon starting, the node will bootstrap its RPC and P2P server and start dialing peers. During handshake with its peers, if the node realizes they are ahead, it will query all the blocks sequentially in order to catch up. Then, it will wait for new block proposals and block signatures from validators in order to make progress. 
 
-## Next
+## Next {hide}
 
 Learn about the [store](./store.md).

docs/core/store.md

@@ -5,7 +5,7 @@ synopsis: A store is a data structure that holds the state of the application.
 
 # Store
 
-## Pre-requisite Readings
+## Pre-requisite Readings {hide}
 
 - [Anatomy of an SDK application](../basics/app-anatomy.md) {prereq}
 
@@ -234,6 +234,6 @@ When `Store.{Get, Set}()` is called, the store forwards the call to its parent,
 
 When `Store.Iterator()` is called, it does not simply prefix the `Store.prefix`, since it does not work as intended. In that case, some of the elements are traversed even they are not starting with the prefix.
 
-## Next
+## Next {hide}
 
 Learn about [encoding](./encoding.md).

docs/core/transactions.md

@@ -5,7 +5,7 @@ synopsis: "`Transactions` are objects created by end-users to trigger state chan
 
 # Transactions
 
-## Pre-requisite Readings
+## Pre-requisite Readings {hide}
 
 * [Anatomy of an SDK Application](../basics/app-anatomy.md) {prereq}
 
@@ -86,6 +86,6 @@ Every message in a transaction must be signed by the addresses specified by `Get
 
 Since `message`s are module-specific types, each module needs a [`handler`](../building-modules/handler.md) to process all of its `message` types and trigger state changes within the module's scope. This design puts more responsibility on module developers, allowing application developers to reuse common functionalities without having to implement state transition logic repetitively. To read more about `handler`s, click [here](../building-modules/handler.md).
 
-## Next
+## Next {hide}
 
 Learn about the [context](./context.md).

docs/interfaces/cli.md

@@ -3,9 +3,9 @@ order: 3
 synopsis: "This document describes how to create a commmand-line interface (CLI) for an [**application**](../basics/app-anatomy.md). A separate document for implementing a CLI for an SDK [**module**](../building-modules/intro.md) can be found [here](#../building-modules/module-interfaces.md#cli)."
 ---
 
-# Command-Line Interface
+# Command-Line Interface 
 
-## Pre-requisite Readings
+## Pre-requisite Readings {hide}
 
 * [Lifecycle of a Query](./query-lifecycle.md) {prereq}