[docs] updated page metadata and minor fixes (#35059)

feat: updated metadata

docs/build-cli-usage.sh

@@ -58,6 +58,6 @@ in_subcommands=0
 while read -r subcommand rest; do
   [[ $subcommand == "SUBCOMMANDS:" ]] && in_subcommands=1 && continue
   if ((in_subcommands)); then
-      section "$(cargo -q run -p solana-cli -- help "$subcommand" | sed -e 's|'"$HOME"'|~|g' -e 's/[[:space:]]\+$//')" "####" >> "$out"
+      section "$(cargo -q run -p solana-cli -- help "$subcommand" | sed -e 's|'"$HOME"'|~|g' -e 's/[[:space:]]\+$//')" "###" >> "$out"
   fi
 done <<<"$usage">>"$out"

docs/publish-docs.sh

@@ -62,7 +62,7 @@ cat > "$CONFIG_FILE" <<EOF
     { "source": "/wallet-guide/file-system-wallet", "destination": "/cli/wallets/file-system" },
     { "source": "/wallet-guide/hardware-wallet", "destination": "/cli/wallets/hardware-wallet" },
     { "source": "/wallet-guide/hardware-wallet/ledger", "destination": "/cli/wallets/hardware-wallet/ledger" },
-    { "source": "/cluster/overview", "destination": "/clusters/index" },
+    { "source": "/cluster/overview", "destination": "/clusters" },
     { "source": "/cluster/bench-tps", "destination": "/clusters/benchmark" },
     { "source": "/cluster/performance-metrics", "destination": "/clusters/metrics" },
     { "source": "/running-validator", "destination": "/operations" },

docs/sidebars.js

@@ -79,10 +79,6 @@ module.exports = {
       type: "category",
       label: "Operating a Validator",
       // collapsed: false,
-      link: {
-        type: "doc",
-        id: "operations/index",
-      },
       items: [
         {
           type: "autogenerated",

docs/src/architecture.md

@@ -1,7 +1,8 @@
 ---
-title: Architecture
-sidebar_label: Overview
+title: Solana Validator Architecture
 sidebar_position: 0
+sidebar_label: Overview
+pagination_label: Solana Validator Architecture
 ---
 
-In this section, we will describe the architecture.
+In this section, we will describe the architecture of the Solana Validator.

docs/src/cli/.usage.md.header

@@ -1,5 +1,6 @@
 ---
 title: Solana CLI Reference and Usage
+pagination_label: Solana CLI Reference and Usage
 sidebar_label: Reference & Usage
 sidebar_position: 3
 ---

docs/src/cli/examples/choose-a-cluster.md

@@ -1,5 +1,7 @@
 ---
-title: Connecting to a Cluster
+title: Connecting to a Cluster with the Solana CLI
+pagination_label: "Solana CLI: Connecting to a Cluster"
+sidebar_label: Connecting to a Cluster
 ---
 
 See [Solana Clusters](../../clusters/available.md) for general information about the

docs/src/cli/examples/delegate-stake.md

@@ -1,10 +1,7 @@
 ---
-title: Staking
----
-
-For an overview of staking, read first the
-[Staking and Inflation FAQ](https://solana.com/staking).
-
+title: Staking SOL with the Solana CLI
+pagination_label: "Solana CLI: Staking"
+sidebar_label: Staking
 ---
 
 After you have [received SOL](./transfer-tokens.md), you might consider putting it
@@ -15,6 +12,11 @@ valid block of transactions in the blockchain. Solana then generates new SOL
 periodically to reward stakers and validators. You earn more rewards the more
 stake you delegate.
 
+:::info
+For an overview of staking, read first the
+[Staking and Inflation FAQ](https://solana.com/staking).
+:::
+
 ## Create a Stake Account
 
 To delegate stake, you will need to transfer some tokens into a stake account.

docs/src/cli/examples/deploy-a-program.md

@@ -1,5 +1,7 @@
 ---
-title: Deploy a Program
+title: Deploy a Solana Program with the CLI
+pagination_label: "Solana CLI: Deploy a Program"
+sidebar_label: Deploy a Program
 ---
 
 Developers can deploy on-chain
@@ -23,9 +25,7 @@ to:
 Once deployed, anyone can execute the program by sending transactions that
 reference it to the cluster.
 
-## Usage
-
-### Deploy a program
+## How to deploy a program
 
 To deploy a program, you will need the location of the program's shared object
 (the program binary `.so`):
@@ -60,7 +60,7 @@ generated automatically by the program build tools:
 ./path-to-program/program-keypair.json
 ```
 
-### Showing a program account
+## Showing a program account
 
 To get information about a deployed program:
 
@@ -89,7 +89,7 @@ Data Length: 5216 (0x1460) bytes
 - `Data Length` is the size of the space reserved for deployments. The actual
   space used by the currently deployed program may be less.
 
-### Redeploy a program
+## Redeploy a Solana program
 
 A program can be redeployed to the same address to facilitate rapid development,
 bug fixes, or upgrades. If a program id is not provided, the program will be
@@ -111,7 +111,7 @@ size (in bytes) that the program is expected to become (plus some wiggle room).
 solana program deploy --max-len 200000 <PROGRAM_FILEPATH>
 ```
 
-### Extend a program
+## Extend a program
 
 If a program has already been deployed, and a redeployment goes beyond the
 `max_len` of the account, it's possible to extend the program to fit the larger
@@ -121,7 +121,7 @@ redeployment:
 solana program extend <PROGRAM_ID> <ADDITIONAL_BYTES>
 ```
 
-### Resuming a failed deploy
+## Resuming a failed deploy
 
 If program deployment fails, there will be a hanging intermediate buffer account
 that contains a non-zero balance. In order to recoup that balance you may resume
@@ -159,7 +159,7 @@ Then issue a new `deploy` command and specify the buffer:
 solana program deploy --buffer <KEYPAIR_PATH> <PROGRAM_FILEPATH>
 ```
 
-### Closing program and buffer accounts, and reclaiming their lamports
+## Closing program and buffer accounts, and reclaiming their lamports
 
 Both program and buffer accounts can be closed and their lamport balances
 transferred to a recipient's account.
@@ -214,7 +214,7 @@ To show all buffer accounts regardless of the authority
 solana program show --buffers --all
 ```
 
-### Set a program's upgrade authority
+## Set a program's upgrade authority
 
 The program's upgrade authority must be present to deploy a program. If no
 authority is specified during program deployment, the default keypair is used as
@@ -245,7 +245,7 @@ they do not have access to. The `--skip-new-upgrade-authority-signer-check`
 option relaxes the signer check. This can be useful for situations where the new
 upgrade authority is an offline signer or a multisig.
 
-### Immutable programs
+## Immutable programs
 
 A program can be marked immutable, which prevents all further redeployments, by
 specifying the `--final` flag during deployment:
@@ -260,7 +260,7 @@ Or anytime after:
 solana program set-upgrade-authority <PROGRAM_ADDRESS> --final
 ```
 
-### Dumping a program to a file
+## Dumping a program to a file
 
 The deployed program may be dumped back to a local file:
 
@@ -283,7 +283,7 @@ $ truncate -r dump.so extended.so
 $ sha256sum extended.so dump.so
 ```
 
-### Using an intermediary Buffer account
+## Using an intermediary Buffer account
 
 Instead of deploying directly to the program account, the program can be written
 to an intermediary buffer account. Intermediary accounts can be useful for
@@ -328,7 +328,7 @@ account are refunded to a spill account.
 
 Buffers also support `show` and `dump` just like programs do.
 
-### Upgrading program using offline signer as authority
+## Upgrading program using offline signer as authority
 
 Some security models require separating the signing process from the transaction broadcast, such that the signing keys can be completely disconnected from any network, also known as [offline signing](offline-signing.md).
 

docs/src/cli/examples/durable-nonce.md

@@ -1,5 +1,7 @@
 ---
-title: Durable Transaction Nonces
+title: Durable Transaction Nonces in the Solana CLI
+pagination_label: "Solana CLI: Durable Transaction Nonces"
+sidebar_label: Durable Transaction Nonces
 ---
 
 Durable transaction nonces are a mechanism for getting around the typical short

docs/src/cli/examples/offline-signing.md

@@ -1,5 +1,7 @@
 ---
-title: Offline Transaction Signing
+title: Offline Transaction Signing with the Solana CLI
+pagination_label: "Solana CLI: Offline Transaction Signing"
+sidebar_label: Offline Transaction Signing
 ---
 
 Some security models require keeping signing keys, and thus the signing

docs/src/cli/examples/sign-offchain-message.md

@@ -1,5 +1,7 @@
 ---
-title: Off-Chain Message Signing
+title: Off-Chain Message Signing with the Solana CLI
+pagination_label: "Solana CLI: Off-Chain Message Signing"
+sidebar_label: Off-Chain Message Signing
 ---
 
 Off-chain message signing is a method of signing non-transaction messages with

docs/src/cli/examples/test-validator.md

@@ -1,5 +1,6 @@
 ---
 title: Solana Test Validator
+pagination_label: "Solana CLI: Test Validator"
 sidebar_label: Test Validator
 ---
 

docs/src/cli/examples/transfer-tokens.md

@@ -1,5 +1,7 @@
 ---
-title: Send and Receive Tokens
+title: Send and Receive Tokens with the Solana CLI
+pagination_label: "Solana CLI: Send and Receive Tokens"
+sidebar_label: Send and Receive Tokens
 ---
 
 This page describes how to receive and send SOL tokens using the command line

docs/src/cli/index.md

@@ -1,7 +1,8 @@
 ---
 title: Solana CLI Tool Suite
-sidebar_label: Overview
 sidebar_position: 0
+sidebar_label: Overview
+pagination_label: Solana CLI Tool Suite
 ---
 
 In this section, we will describe how to use the Solana command-line tools to
@@ -19,6 +20,6 @@ secure access to your Solana accounts.
 To get started using the Solana Command Line (CLI) tools:
 
 - [Install the Solana CLI Tool Suite](./install.md)
-- [Choose a Cluster](./examples/choose-a-cluster.md)
-- [Create a Wallet](./wallets/index.md)
 - [Introduction to our CLI conventions](./intro.md)
+- [Create a Wallet using the CLI](./wallets/index.md)
+- [Choose a Cluster to connect to using the CLI](./examples/choose-a-cluster.md)

docs/src/cli/install.md

@@ -1,5 +1,6 @@
 ---
 title: Install the Solana CLI
+pagination_label: Install the Solana CLI
 sidebar_label: Installation
 sidebar_position: 1
 ---

docs/src/cli/intro.md

@@ -1,5 +1,6 @@
 ---
 title: Introduction to the Solana CLI
+pagination_label: Introduction to the Solana CLI
 sidebar_label: Introduction
 sidebar_position: 2
 ---
@@ -45,7 +46,7 @@ solana-keygen pubkey <KEYPAIR>
 Below, we show how to resolve what you should put in `<KEYPAIR>` depending
 on your wallet type.
 
-#### Paper Wallet
+## Paper Wallet
 
 In a paper wallet, the keypair is securely derived from the seed words and
 optional passphrase you entered when the wallet was created. To use a paper
@@ -59,7 +60,7 @@ To display the wallet address of a Paper Wallet:
 solana-keygen pubkey prompt://
 ```
 
-#### File System Wallet
+## File System Wallet
 
 With a file system wallet, the keypair is stored in a file on your computer.
 Replace `<KEYPAIR>` with the complete file path to the keypair file.
@@ -71,7 +72,7 @@ For example, if the file system keypair file location is
 solana-keygen pubkey /home/solana/my_wallet.json
 ```
 
-#### Hardware Wallet
+## Hardware Wallet
 
 If you chose a hardware wallet, use your
 [keypair URL](./wallets/hardware/index.md#specify-a-hardware-wallet-key),

docs/src/cli/wallets/file-system.md

@@ -1,5 +1,7 @@
 ---
-title: File System Wallets
+title: File System Wallets using the CLI
+pagination_label: File System Wallets using the CLI
+sidebar_label: File System Wallets
 sidebar_position: 2
 ---
 

docs/src/cli/wallets/hardware/index.md

@@ -1,5 +1,6 @@
 ---
 title: Using Hardware Wallets in the Solana CLI
+pagination_label: "Using Hardware Wallets in the Solana CLI"
 sidebar_label: Using in the Solana CLI
 sidebar_position: 0
 ---

docs/src/cli/wallets/hardware/ledger.md

@@ -1,5 +1,6 @@
 ---
 title: Using Ledger Nano Hardware Wallets in the Solana CLI
+pagination_label: "Hardware Wallets in the Solana CLI: Ledger Nano"
 sidebar_label: Ledger Nano
 ---
 

docs/src/cli/wallets/index.md

@@ -1,5 +1,6 @@
 ---
-title: Command Line Wallets
+title: Solana Wallets with the CLI
+pagination_label: Command Line Wallets
 sidebar_label: Overview
 sidebar_position: 0
 ---

docs/src/cli/wallets/paper.md

@@ -1,5 +1,7 @@
 ---
-title: Paper Wallets
+title: Paper Wallets using the Solana CLI
+pagination_label: Paper Wallets using the CLI
+sidebar_label: Paper Wallets
 sidebar_position: 1
 ---
 

docs/src/clusters/available.md

@@ -1,5 +1,7 @@
 ---
-title: Solana Clusters
+title: Available Solana Clusters
+sidebar_label: Solana Clusters
+pagination_label: Available Solana Clusters
 ---
 
 Solana maintains several different clusters with different purposes.

docs/src/clusters/index.md

@@ -1,7 +1,8 @@
 ---
-title: A Solana Cluster
-sidebar_label: Overview
+title: Overview of a Solana Cluster
 sidebar_position: 0
+sidebar_label: Overview
+pagination_label: Overview of a Solana Cluster
 ---
 
 A Solana cluster is a set of validators working together to serve client transactions and maintain the integrity of the ledger. Many clusters may coexist. When two clusters share a common genesis block, they attempt to converge. Otherwise, they simply ignore the existence of the other. Transactions sent to the wrong one are quietly rejected. In this section, we'll discuss how a cluster is created, how nodes join the cluster, how they share the ledger, how they ensure the ledger is replicated, and how they cope with buggy and malicious nodes.

docs/src/clusters/metrics.md

@@ -1,5 +1,7 @@
 ---
-title: Performance Metrics
+title: Solana Cluster Performance Metrics
+sidebar_label: Performance Metrics
+pagination_label: Cluster Performance Metrics
 ---
 
 Solana cluster performance is measured as average number of transactions per second that the network can sustain \(TPS\). And, how long it takes for a transaction to be confirmed by super majority of the cluster \(Confirmation Time\).

docs/src/consensus/commitments.md

@@ -1,5 +1,7 @@
 ---
-title: Commitment Status
+title: Solana Commitment Status
+sidebar_label: Commitment Status
+pagination_label: Consensus Commitment Status
 description:
   "Processed, confirmed, and finalized. Learn the differences between the
   different commitment statuses on the Solana blockchain."

docs/src/consensus/leader-rotation.md

@@ -1,5 +1,7 @@
 ---
-title: Leader Rotation
+title: Solana Leader Rotation
+sidebar_label: Leader Rotation
+pagination_label: Leader Rotation
 ---
 
 At any given moment, a cluster expects only one validator to produce ledger entries. By having only one leader at a time, all validators are able to replay identical copies of the ledger. The drawback of only one leader at a time, however, is that a malicious leader is capable of censoring votes and transactions. Since censoring cannot be distinguished from the network dropping packets, the cluster cannot simply elect a single node to hold the leader role indefinitely. Instead, the cluster minimizes the influence of a malicious leader by rotating which node takes the lead.

docs/src/index.mdx

@@ -3,10 +3,10 @@ slug: /
 id: home
 title: Home
 sidebar_label: Home
+pagination_label: Solana Validator Documentation Home
 description: "Solana is a high performance network that is utilized for a range
   of use cases, \
   including finance, NFTs, payments, and gaming."
-# displayed_sidebar: introductionSidebar
 ---
 
 # Solana Validator Documentation

docs/src/operations/_category_.json

@@ -2,9 +2,5 @@
   "position": 4,
   "label": "Operating a Validator",
   "collapsible": true,
-  "collapsed": true,
-  "link": {
-    "type": "doc",
-    "id": "operations/index"
-  }
+  "collapsed": true
 }

docs/src/operations/best-practices/general.md

@@ -1,6 +1,7 @@
 ---
-title: Validator Operations Best Practices
+title: Solana Validator Operations Best Practices
 sidebar_label: General Operations
+pagination_label: "Best Practices: Validator Operations"
 ---
 
 After you have successfully setup and started a

docs/src/operations/best-practices/monitoring.md

@@ -1,6 +1,7 @@
 ---
-title: Validator Monitoring Best Practices
+title: Solana Validator Monitoring Best Practices
 sidebar_label: Monitoring
+pagination_label: "Best Practices: Validator Monitoring"
 ---
 
 It is essential that you have monitoring in place on your validator. In the event that your validator is delinquent (behind the rest of the network) you want to respond immediately to fix the issue. One very useful tool to monitor your validator is [`solana-watchtower`](#solana-watchtower).

docs/src/operations/best-practices/security.md

@@ -1,6 +1,7 @@
 ---
-title: Validator Security Best Practices
+title: Solana Validator Security Best Practices
 sidebar_label: Security
+pagination_label: "Best Practices: Validator Security"
 ---
 
 Being a system administrator for an Ubuntu computer requires technical knowledge of the system and best security practices. The following list should help you get started and is considered the bare minimum for keeping your system safe.

docs/src/operations/guides/restart-cluster.md

@@ -1,4 +1,10 @@
-## Restarting a cluster
+---
+title: "Restarting a Solana Cluster"
+# really high number to ensure it is listed last in the sidebar
+sidebar_position: 999
+sidebar_label: Restart a Cluster
+pagination_label: "Validator Guides: Restart a Cluster"
+---
 
 ### Step 1. Identify the latest optimistically confirmed slot for the cluster
 

docs/src/operations/guides/validator-failover.md

@@ -1,5 +1,8 @@
 ---
-title: Failover Setup
+title: "Validator Guide: Setup Node Failover"
+sidebar_position: 9
+sidebar_label: Node Failover
+pagination_label: "Validator Guides: Node Failover"
 ---
 
 A simple two machine instance failover method is described here, which allows you to:

docs/src/operations/guides/validator-info.md

@@ -1,5 +1,8 @@
 ---
-title: Publishing Validator Info
+title: "Validator Guide: Publishing Validator Info"
+sidebar_position: 1
+sidebar_label: Publishing Validator Info
+pagination_label: "Validator Guides: Publishing Validator Info"
 ---
 
 You can publish your validator information to the chain to be publicly visible to other users.

docs/src/operations/guides/validator-monitor.md

@@ -1,5 +1,8 @@
 ---
-title: Monitoring a Validator
+title: "Validator Guide: Monitoring a Validator"
+sidebar_position: 2
+sidebar_label: Monitoring a Validator
+pagination_label: "Validator Guides: Monitoring a Validator"
 ---
 
 ## Check Gossip

docs/src/operations/guides/validator-stake.md

@@ -1,5 +1,8 @@
 ---
-title: Staking
+title: "Validator Guide: Staking"
+sidebar_position: 3
+sidebar_label: Staking
+pagination_label: "Validator Guides: Staking"
 ---
 
 **By default your validator will have no stake.** This means it will be

docs/src/operations/guides/validator-start.md

@@ -1,5 +1,8 @@
 ---
-title: Starting a Validator
+title: "Validator Guide: Starting a Validator"
+sidebar_position: 0
+sidebar_label: Starting a Validator
+pagination_label: "Validator Guides: Starting a Validator"
 ---
 
 ## Configure Solana CLI

docs/src/operations/guides/validator-troubleshoot.md

@@ -1,5 +1,8 @@
 ---
-title: Troubleshooting
+title: "Validator Guide: Troubleshooting"
+sidebar_position: 4
+sidebar_label: Troubleshooting
+pagination_label: "Validator Guides: Troubleshooting"
 ---
 
 There is a `#validator-support` Discord channel available to reach other

docs/src/operations/guides/vote-accounts.md

@@ -1,5 +1,8 @@
 ---
-title: Vote Account Management
+title: "Validator Guide: Vote Account Management"
+sidebar_position: 5
+sidebar_label: Vote Account Management
+pagination_label: "Validator Guides: Vote Account Management"
 ---
 
 This page describes how to set up an on-chain _vote account_. Creating a vote

docs/src/operations/prerequisites.md

@@ -1,7 +1,8 @@
 ---
 title: Solana Validator Prerequisites
-sidebar_label: Prerequisites
 sidebar_position: 2
+sidebar_label: Prerequisites
+pagination_label: Prerequisites to run a Validator
 ---
 
 Operating a Solana validator is an interesting and rewarding task. Generally speaking, it requires someone with a technical background but also involves community engagement and marketing.

docs/src/operations/requirements.md

@@ -1,7 +1,8 @@
 ---
-title: Validator Requirements
-sidebar_label: Requirements
+title: Solana Validator Requirements
 sidebar_position: 3
+sidebar_label: Requirements
+pagination_label: Requirements to Operate a Validator
 ---
 
 ## Minimum SOL requirements

docs/src/operations/validator-or-rpc-node.md

@@ -1,7 +1,8 @@
 ---
 title: Consensus Validator or RPC Node?
-sidebar_label: Validator vs RPC Node
 sidebar_position: 1
+sidebar_label: Validator vs RPC Node
+pagination_label: Consensus Validator vs RPC Node
 ---
 
 Operators who run a [consensus validator](../what-is-a-validator.md) have much

docs/src/runtime/programs.md

@@ -1,5 +1,7 @@
 ---
-title: "Native Programs"
+title: "Native Programs in the Solana Runtime"
+pagination_label: Runtime Native Programs
+sidebar_label: Native Programs
 ---
 
 Solana contains a small handful of native programs, which are required to run

docs/src/runtime/sysvars.md

@@ -1,5 +1,7 @@
 ---
-title: Sysvar Cluster Data
+title: Solana Sysvar Cluster Data
+pagination_label: Runtime Sysvar Cluster Data
+sidebar_label: Sysvar Cluster Data
 ---
 
 Solana exposes a variety of cluster state data to programs via

docs/src/runtime/zk-token-proof.md

@@ -1,5 +1,7 @@
 ---
-title: ZK Token Proof Program
+title: Solana ZK Token Proof Program
+pagination_label: Native ZK Token Proof Program
+sidebar_label: ZK Token Proof Program
 ---
 
 The native Solana ZK Token proof program verifies a number of zero-knowledge

docs/src/validator/anatomy.md

@@ -1,7 +1,8 @@
 ---
 title: Anatomy of a Validator
-sidebar_label: Anatomy
 sidebar_position: 1
+sidebar_label: Anatomy
+pagination_label: Anatomy of a Validator
 ---
 
 ![Validator block diagrams](/img/validator.svg)

docs/src/validator/blockstore.md

@@ -1,6 +1,8 @@
 ---
-title: Blockstore
+title: Blockstore in a Solana Validator
 sidebar_position: 3
+sidebar_label: Blockstore
+pagination_label: Validator Blockstore
 ---
 
 After a block reaches finality, all blocks from that one on down to the genesis block form a linear chain with the familiar name blockchain. Until that point, however, the validator must maintain all potentially valid chains, called _forks_. The process by which forks naturally form as a result of leader rotation is described in [fork generation](../consensus/fork-generation.md). The _blockstore_ data structure described here is how a validator copes with those forks until blocks are finalized.

docs/src/validator/geyser.md

@@ -1,5 +1,7 @@
 ---
-title: Geyser Plugins
+title: Solana Validator Geyser Plugins
+sidebar_label: Geyser Plugins
+pagination_label: Validator Geyser Plugins
 ---
 
 ## Overview

docs/src/validator/gossip.md

@@ -1,6 +1,8 @@
 ---
-title: Gossip Service
+title: Gossip Service in a Solana Validator
 sidebar_position: 5
+sidebar_label: Gossip Service
+pagination_label: Validator Gossip Service
 ---
 
 The Gossip Service acts as a gateway to nodes in the

docs/src/validator/runtime.md

@@ -1,6 +1,8 @@
 ---
-title: Runtime
+title: Solana Runtime on a Solana Validator
 sidebar_position: 6
+sidebar_label: Runtime
+pagination_label: Validator Runtime
 ---
 
 The runtime is a concurrent transaction processor. Transactions specify their data dependencies upfront and dynamic memory allocation is explicit. By separating program code from the state it operates on, the runtime is able to choreograph concurrent access. Transactions accessing only read-only accounts are executed in parallel whereas transactions accessing writable accounts are serialized. The runtime interacts with the program through an entrypoint with a well-defined interface. The data stored in an account is an opaque type, an array of bytes. The program has full control over its contents.

docs/src/validator/tpu.md

@@ -1,7 +1,8 @@
 ---
-title: Transaction Processing Unit
-sidebar_label: TPU
+title: Transaction Processing Unit in a Solana Validator
 sidebar_position: 2
+sidebar_label: TPU
+pagination_label: Validator's Transaction Processing Unit (TPU)
 ---
 
 TPU (Transaction Processing Unit) is the logic of the validator

docs/src/validator/tvu.md

@@ -1,7 +1,8 @@
 ---
-title: Transaction Validation Unit
-sidebar_label: TVU
+title: Transaction Validation Unit in a Solana Validator
 sidebar_position: 3
+sidebar_label: TVU
+pagination_label: Validator's Transaction Validation Unit (TVU)
 ---
 
 TVU (Transaction Validation Unit) is the logic of the validator