Docs file restructuring

docs/btcli-permissions.md → docs/btcli/btcli-permissions.md

@@ -8,16 +8,16 @@ This page details the requirements for all of the `btcli` commands.
 
 See also the `btcli` permissions guides for specific Bittensor personas:
 
-- [Staker's Guide to `BTCLI`](./staking-and-delegation/stakers-btcli-guide)
-- [Miner's Guide to `BTCLI`](./miners/miners-btcli-guide)
-- [Validator's Guide to `BTCLI`](./validators/validators-btcli-guide)
-- [Subnet Creator's Guide to `BTCLI`](./subnets/subnet-creators-btcli-guide)
-- [Senator's Guide to `BTCLI`](./governance/senators-btcli-guide)
+- [Staker's Guide to `BTCLI`](../staking-and-delegation/stakers-btcli-guide)
+- [Miner's Guide to `BTCLI`](../miners/miners-btcli-guide)
+- [Validator's Guide to `BTCLI`](../validators/validators-btcli-guide)
+- [Subnet Creator's Guide to `BTCLI`](../subnets/subnet-creators-btcli-guide)
+- [Senator's Guide to `BTCLI`](../governance/senators-btcli-guide)
 
 Other resources:
 
-- [Introduction to Wallets, Coldkeys and Hotkeys in Bittensor](./getting-started/wallets)
-- [Coldkey and Hotkey Workstation Security](./getting-started/coldkey-hotkey-security)
+- [Introduction to Wallets, Coldkeys and Hotkeys in Bittensor](../keys/wallets)
+- [Coldkey and Hotkey Workstation Security](../keys/coldkey-hotkey-security)
 
 ## Bittensor work environments and security requirements
 
@@ -28,19 +28,19 @@ The workstations you use to do this work can be referred to as a permissionless
 1. A **permissionless workstation** has only coldkey _public keys_ on it. Public keys are sufficient for viewing all information about a wallet, such as TAO and alpha stake balances. Information about wallets, subnets, miners, and validators can and should be viewed without initializing your private keys on a device, to avoid the security risk of compromising your keys.
 
    :::tip coldkey workstation security
-   See [Permissionless workstation](./getting-started/coldkey-hotkey-security#permissionless-workstation)
+   See [Permissionless workstation](../keys/coldkey-hotkey-security#permissionless-workstation)
    :::
 
 1. A **coldkey workstation** contains one or more coldkey private key in the `wallet_path`. For any coldkey associated with mainnet TAO, the coldkey workstation should be held to the highest possible security standards.
 
    :::tip coldkey workstation security
-   See [Coldkey workstation](./getting-started/coldkey-hotkey-security#coldkey-workstation)
+   See [Coldkey workstation](../keys/coldkey-hotkey-security#coldkey-workstation)
    :::
 
 1. **A hotkey workstation**—which is generally a server used for mining or validation—contains a hotkey private key in the `wallet_path` located in the `btcli config`, as well as a coldkey public key for the corresponding coldkey. Compromised hotkeys can damage your reputation if they are used to maliciously to submit inaccurate weights as a validator, or bad work as a miner. However, ownership of TAO or alpha stake can only be transferred with a coldkey, and a leaked hotkey can be swapped using the coldkey; therefore hotkey leaks are far less dangerous than coldkey leaks.
 
    :::tip hotkey workstation
-   See [Hotkey workstation security](./getting-started/coldkey-hotkey-security#hotkey-workstation)
+   See [Hotkey workstation security](../keys/coldkey-hotkey-security#hotkey-workstation)
    :::
 
 ## Requirements for `btcli` functions
@@ -49,7 +49,7 @@ The workstations you use to do this work can be referred to as a permissionless
 
 Your coldkey is your primary, fully privileged key; important for all users. This key should be handled on a maximum security **coldkey workstation** only, to avoid catastrophic loss or malicious actions if compromised.
 
-See [Coldkey and Hotkey Workstation Security](../getting-started/coldkey-hotkey-security).
+See [Coldkey and Hotkey Workstation Security](../keys/coldkey-hotkey-security).
 
 Required for:
 
@@ -85,11 +85,11 @@ Some operations require a TAO balance or alpha stake balance to execute.
 
 ### Validator Permit
 
-To set weights, a validator must meet several requirements. See [Requirements for validation](./validators/#requirements-for-validation).
+To set weights, a validator must meet several requirements. See [Requirements for validation](../validators/#requirements-for-validation).
 
 ### Senate requirements
 
-See [Senate: Requirements](./senate#requirements)
+See [Senate: Requirements](../governance/senate#requirements)
 
 ## `btcli` commands
 
@@ -102,7 +102,7 @@ The `btcli config ...` commands are used to configure `btcli`, including:
 
 These commands don't require any permissions to run. Rather, you run these commands on all `btcli` workstations to initialize them.
 
-See: [Coldkey and Hotkey Workstation Security](./getting-started/coldkey-hotkey-security)
+See: [Coldkey and Hotkey Workstation Security](../keys/coldkey-hotkey-security)
 
 <details>
   <summary>btcli config</summary>
@@ -129,7 +129,7 @@ See: [Coldkey and Hotkey Workstation Security](./getting-started/coldkey-hotkey-
 The `wallet` command is required to provision keys to `btcli`, so it can access your wallet. This is essentially the equivalent of logging in/authentication. This is true for both coldkeys, which all users require, and hotkeys, which are required only by miners and validators as well as for advanced functions.
 
 :::tip mind your keys
-See: [Coldkey and Hotkey Workstation Security](./getting-started/coldkey-hotkey-security)
+See: [Coldkey and Hotkey Workstation Security](../keys/coldkey-hotkey-security)
 :::
 
 #### Provisioning keys
@@ -288,7 +288,7 @@ See: [Coldkey and Hotkey Workstation Security](./getting-started/coldkey-hotkey-
 Read operations require public keys. Write operations (stake add, move, remove...) require a coldkey private key.
 
 :::tip mind your keys
-See: [Coldkey and Hotkey Workstation Security](./getting-started/coldkey-hotkey-security)
+See: [Coldkey and Hotkey Workstation Security](../keys/coldkey-hotkey-security)
 :::
 
 <details>
@@ -442,7 +442,7 @@ Miner and validator registering a hotkey uses a coldkey, has a TAO cost unless p
 
 Reading weights with `reveal` is permissionless.
 
-To set weights with `commit`, a validator must meet several requirements. See [Requirements for validation](./#requirements-for-validation).
+To set weights with `commit`, a validator must meet several requirements. See [Requirements for validation](#validator-permit).
 
 <details>
   <summary>`btcli weight`</summary>

docs/btcli/btcli-playground.md

@@ -20,7 +20,7 @@ This is not a secure code execution environment. This page is for practice/educa
 See:
 
 - [Handle your Seed Phrase/Mnemonic Securely](../keys/handle-seed-phrase)
-- [Coldkey and Hotkey Workstation Security](../getting-started/coldkey-hotkey-security)
+- [Coldkey and Hotkey Workstation Security](../keys/coldkey-hotkey-security)
   :::
 
 ## Import wallets and check balances.

docs/btcli.md → docs/btcli/btcli.md

@@ -6,10 +6,10 @@ title: "Bittensor CLI: btcli Reference Document"
 
 Command line interface (CLI) for Bittensor. Uses the values in the configuration file. These values can be overriden by passing them explicitly in the command line.
 
-See [Getting Started](./getting-started/install-btcli.md) to install `btcli`.
+See [Getting Started](../getting-started/install-btcli.md) to install `btcli`.
 
 :::note Transaction Fees
-Many btcli operations incur transaction fees. See [Transaction Fees in Bittensor](./fees.md) for details.
+Many BTCLI operations incur transaction fees. See [Transaction Fees in Bittensor](../learn/fees.md) for details.
 :::
 
 Command line interface (CLI) for Bittensor. Uses the values in the configuration file. These values can be

docs/btcli/overview.md

@@ -4,10 +4,10 @@ title: "Bittensor CLI Overview"
 
 # Bittensor CLI Overview
 
-The Bittensor command line interface (CLI), `btcli`, provides the simplest way to interact with the Bittensor network and its subnets from the command line. This includes managing [wallets (coldkeys and hotkeys)](../getting-started/wallets), TAO balances, transfer, staking and unstaking functions, node registration, governance functions, and more.
-
+The Bittensor command line interface (CLI), `btcli`, provides the simplest way to interact with the Bittensor network and its subnets from the command line. This includes managing [wallets (coldkeys and hotkeys)](../keys/wallets), TAO balances, transfer, staking and unstaking functions, node registration, governance functions, and more.
 
 See:
+
 - [Install `btcli`](../getting-started/install-btcli)
 - [Managing Stake with BTCLI](../staking-and-delegation/managing-stake-btcli.md)
-- [`btcli reference document`](../btcli.md)
+- [`btcli reference document`](./btcli.md)

docs/bittensor-networks.md → docs/concepts/bittensor-networks.md

@@ -15,4 +15,4 @@ The below table presents Bittensor networks and a few details:
 | **Mainnet Lite**              | wss://lite.chain.opentensor.ai:443          | None                                                       | None                                                                                                                 |
 | **Experimental Mainnet Lite** | wss://lite.finney.test.opentensor.ai:443    | None                                                       | None                                                                                                                 |
 | **Network Purpose**           | Transactions with financial value           | Test transactions with no value, constrained by tokenomics | Development and testing in fully user-controlled environment                                                         |
-| **Test TAO**                  | None                                        | Available on request (not compatible with devnet test TAO) | Available in Alice wallet. See [Access the Alice account](./local-build/provision-wallets#access-the-alice-account). |
+| **Test TAO**                  | None                                        | Available on request (not compatible with devnet test TAO) | Available in Alice wallet. See [Access the Alice account](../local-build/provision-wallets#access-the-alice-account). |

docs/subnets/commit-reveal.md → docs/concepts/commit-reveal.md

@@ -1,38 +1,37 @@
-
 import ThemedImage from '@theme/ThemedImage';
 import useBaseUrl from '@docusaurus/useBaseUrl';
 
 # Commit Reveal
 
 This page describes the **commit reveal** feature: a configurable waiting period that elapses between a) when consensus weights set by subnet validators are first committed, and b) when they are revealed publicly and included in Yuma Consensus.
 
-This feature was designed to address the issue of *weight copying* by validators. 
+This feature was designed to address the issue of _weight copying_ by validators.
 
 ## Weight copying
 
-In each Bittensor subnet, each validator scores—or *'weights'*—each miner, producing what is referred to as a [weight vector](../glossary.md#weight-vector). The weight vectors for each validator in a subnet are combined into a weight matrix. This matrix determines emissions to miners in the subnet based on the consensus evaluation of their performance, according to [Yuma Consensus](../glossary.md#yuma-consensus).
+In each Bittensor subnet, each validator scores—or _'weights'_—each miner, producing what is referred to as a [weight vector](../resources/glossary.md#weight-vector). The weight vectors for each validator in a subnet are combined into a weight matrix. This matrix determines emissions to miners in the subnet based on the consensus evaluation of their performance, according to [Yuma Consensus](../resources/glossary.md#yuma-consensus).
 
 The weight matrix is public information, and must be, so that emissions in the Bittensor platform can be transparently fair. However, this transparency makes it possible for subnet validators to free-ride on the work of other validators by copying the latest consensus rather than independently evaluating subnet miners. This is unfair and potentially degrades the quality of validation work, undermining Bittensor's ability to incentivize the best miners and produce the best digital commodities overall.
 
 The commit reveal feature is designed to solve the weight copying problem by giving would-be weight copiers access only to stale weights. Copying stale weights should result in validators departing from consensus. However, it is critical to note that this only works if the consensus weight matrix changes sufficiently on the time scale of the commit reveal interval. If the demands on miners are too static, and miner performance is very stable, weight copying will still be successful. The only solution for this is to demand continuous improvement from miners, requiring them to continuously evolve to maintain their scoring. Combined with a properly tuned Commit Reveal interval, this will keep validators honest, as well as producing the best models.
 
 ## Commit Reveal and Immunity Period
 
-The [Immunity Period](../glossary.md#immunity-period) is the interval (measured in blocks) during which a miner or validator newly registered on a subnet is 'immune' from deregistration due to performance. The duration of this period value should always be larger than the Commit Reveal interval, otherwise the immunity period will expire before a given miner's scores are available, and they may be deregistered without having their work counted.
+The [Immunity Period](../resources/glossary.md#immunity-period) is the interval (measured in blocks) during which a miner or validator newly registered on a subnet is 'immune' from deregistration due to performance. The duration of this period value should always be larger than the Commit Reveal interval, otherwise the immunity period will expire before a given miner's scores are available, and they may be deregistered without having their work counted.
 
 When creating a new subnet, ensure that the miner immunity period is larger than the commit reveal interval. When updating the immunity period or commit reveal interval hyperparameters for a subnet, use the following formula:
 
 ```
 new_immunity_period = (new_commit_reveal_period x tempo - old_commit_reveal_period x tempo) + old_immunity_period
 ```
 
-See [Subnet Hyperparameters](./subnet-hyperparameters.md).
+See [Subnet Hyperparameters](../subnets/subnet-hyperparameters.md).
 
 ## Commit reveal in detail
 
-When commit reveal is enabled, it works as follows:  
+When commit reveal is enabled, it works as follows:
 
-1. A subnet validator sets the weights normally by using [`set_weights`](pathname:///python-api/html/autoapi/bittensor/core/extrinsics/set_weights/index.html). 
+1. A subnet validator sets the weights normally by using [`set_weights`](pathname:///python-api/html/autoapi/bittensor/core/extrinsics/set_weights/index.html).
 
 2. Instead of publishing weights openly, an encrypted copy of these weights is committed to the blockchain, using an internal method called [`commit_weights`](pathname:///python-api/html/autoapi/bittensor/core/extrinsics/commit_weights/index.html).
 
@@ -62,22 +61,20 @@ style={{width: 750}}
 />
 </center>
 
-
 ## How to use the commit reveal feature
 
 As a subnet owner, set the below hyperparameters to use the commit reveal feature:
 
 1. `commit_reveal_weights_enabled` (boolean): Set this to `True` to activate the commit reveal feature for the subnet. Default value is `False`.
 2. `commit_reveal_period` (int): Set this to an integer number. This is the number of subnet tempos to elapse before revealing the weights by submitting them again to the blockchain, but now openly for everyone to see. Default value is `1`.
 
-See [Setting subnet hyperparameters](subnet-hyperparameters#setting-the-hyperparameters).
+See [Setting subnet hyperparameters](../subnets/subnet-hyperparameters.md#set-hyperparameters).
 
 :::danger Ensure that the commit reveal interval is less than your immunity period to avoid unintended miner de-registration!
 See [Commit Reveal and Immunity Period](#commit-reveal-and-immunity-period).
 :::
 
-
-Weights will be revealed immediately at the beginning of the tempo after the `commit_reveal_period`. For example, if `commit_reveal_period` value is set to `3`, then the reveal will occur at the beginning of the fourth tempo from the current tempo. The current tempo is counted as the first tempo. See the below diagram for this example: 
+Weights will be revealed immediately at the beginning of the tempo after the `commit_reveal_period`. For example, if `commit_reveal_period` value is set to `3`, then the reveal will occur at the beginning of the fourth tempo from the current tempo. The current tempo is counted as the first tempo. See the below diagram for this example:
 
 <center>
 <ThemedImage
@@ -92,10 +89,8 @@ style={{width: 750}}
 
 <br />
 
-
 ## Technical papers and blog
 
 - ACM CCS2024 Poster PDF [Solving the Free-rider Problem In Bittensor](pathname:///papers/ACM_CCS2024_Poster.pdf).
 - See [Weight Copying in Bittensor, a technical paper (PDF)](pathname:///papers/BT_Weight_Copier-29May2024.pdf).
 - Blog post, [Weight Copying in Bittensor](https://blog.bittensor.com/weight-copying-in-bittensor-422585ab8fa5).
-

docs/root-network.md → docs/concepts/root-network.md

@@ -6,7 +6,7 @@ title: "Root Network"
 
 :::tip
 
-The Root Network no longer is in operation, so this doc is a kind of historical artifact. The Root Network was decommisioned with the [Dynamic TAO](./dynamic-tao) upgrade in February 2025
+The Root Network no longer is in operation, so this doc is a kind of historical artifact. The Root Network was decommisioned with the [Dynamic TAO](../dynamic-tao/index.md) upgrade in February 2025
 :::
 
 The root network was a special kind of subnet. The root network has the `netuid` of 0.

docs/tools.md → docs/concepts/tools.md

@@ -11,36 +11,38 @@ Bittensor provides several tools to help developers, miners, and validators inte
 ## Bittensor SDK
 
 The Bittensor SDK is a Python-based library that allows developers to interact programmatically with the Bittensor network. You can use the SDK to:
+
 - Create and manage wallets
 - Register miners and validators
 - Query and monitor network activity
 - Build applications on top of Bittensor’s decentralized AI infrastructure
 
-**Learn more in the [Bittensor SDK documentation](./bt-api-ref.md)** (link for illustration).
+**Learn more in the [Bittensor SDK documentation](../sdk/bt-api-ref.md)** (link for illustration).
 
 ---
 
 ## Bittensor CLI
 
 The Bittensor command-line interface (`btcli`) provides a straightforward way to:
+
 - Create, manage, and encrypt wallet keys
 - Transfer and stake TAO
 - Perform subnet management operations (e.g., creating subnets, registering miners/validators)
 - View wallet information and network status
 
 It is designed for users who prefer quick terminal commands or those managing multiple nodes and subnet interactions.  
-**See [Bittensor CLI reference](./btcli.md)** for detailed usage instructions.
+**See [Bittensor CLI reference](../btcli/btcli.md)** for detailed usage instructions.
 
 ---
 
 ## Wallets and Keys
 
-In Bittensor (like other cryptocurrency applications), a *wallet* is a tool for managing the cryptographic key-pairs required to prove your identity, sign transactions, and access your currency
+In Bittensor (like other cryptocurrency applications), a _wallet_ is a tool for managing the cryptographic key-pairs required to prove your identity, sign transactions, and access your currency
 
 Bittensor uses a dual-key wallet structure:
-- **Coldkey** for secure storage of TAO and high-security operations  
+
+- **Coldkey** for secure storage of TAO and high-security operations
 - **Hotkey** for operational tasks like validation, mining, and day-to-day transactions
 
 Both keys are crucial for safeguarding and participating in the network.  
-**For a complete guide, see [Wallets & Keys](./getting-started/wallets)** and [Working with Keys](./working-with-keys).
-
+**For a complete guide, see [Wallets & Keys](../keys/wallets)** and [Working with Keys](../keys/working-with-keys).