diff --git a/docs/btcli-permissions.md b/docs/btcli/btcli-permissions.md similarity index 91% rename from docs/btcli-permissions.md rename to docs/btcli/btcli-permissions.md index cf3f3068b1..456b4e8261 100644 --- a/docs/btcli-permissions.md +++ b/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)
btcli config @@ -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) :::
@@ -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).
`btcli weight` diff --git a/docs/btcli/btcli-playground.md b/docs/btcli/btcli-playground.md index a155ddc9ae..f437c26809 100644 --- a/docs/btcli/btcli-playground.md +++ b/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. diff --git a/docs/btcli.md b/docs/btcli/btcli.md similarity index 99% rename from docs/btcli.md rename to docs/btcli/btcli.md index adddc37323..8546ab0ea8 100644 --- a/docs/btcli.md +++ b/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 diff --git a/docs/btcli/overview.md b/docs/btcli/overview.md index 20cc4c597b..d15782ddfe 100644 --- a/docs/btcli/overview.md +++ b/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) \ No newline at end of file +- [`btcli reference document`](./btcli.md) diff --git a/docs/bittensor-networks.md b/docs/concepts/bittensor-networks.md similarity index 97% rename from docs/bittensor-networks.md rename to docs/concepts/bittensor-networks.md index 911613145f..bb7a16c8ed 100644 --- a/docs/bittensor-networks.md +++ b/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). | diff --git a/docs/subnets/bt-logging-levels.md b/docs/concepts/bt-logging-levels.md similarity index 100% rename from docs/subnets/bt-logging-levels.md rename to docs/concepts/bt-logging-levels.md diff --git a/docs/subnets/commit-reveal.md b/docs/concepts/commit-reveal.md similarity index 80% rename from docs/subnets/commit-reveal.md rename to docs/concepts/commit-reveal.md index fed26eede2..f79e27912e 100644 --- a/docs/subnets/commit-reveal.md +++ b/docs/concepts/commit-reveal.md @@ -1,4 +1,3 @@ - import ThemedImage from '@theme/ThemedImage'; import useBaseUrl from '@docusaurus/useBaseUrl'; @@ -6,11 +5,11 @@ import useBaseUrl from '@docusaurus/useBaseUrl'; 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. @@ -18,7 +17,7 @@ The commit reveal feature is designed to solve the weight copying problem by giv ## 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: @@ -26,13 +25,13 @@ When creating a new subnet, ensure that the miner immunity period is larger than 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,7 +61,6 @@ style={{width: 750}} /> - ## How to use the commit reveal feature As a subnet owner, set the below hyperparameters to use the commit reveal feature: @@ -70,14 +68,13 @@ As a subnet owner, set the below hyperparameters to use the commit reveal featur 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:
- ## 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). - diff --git a/docs/subnets/consensus-based-weights.md b/docs/concepts/consensus-based-weights.md similarity index 100% rename from docs/subnets/consensus-based-weights.md rename to docs/concepts/consensus-based-weights.md diff --git a/docs/root-network.md b/docs/concepts/root-network.md similarity index 92% rename from docs/root-network.md rename to docs/concepts/root-network.md index 1c2a2a4a3c..0359579aab 100644 --- a/docs/root-network.md +++ b/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. diff --git a/docs/tools.md b/docs/concepts/tools.md similarity index 76% rename from docs/tools.md rename to docs/concepts/tools.md index a83587fb09..d5d8c0a773 100644 --- a/docs/tools.md +++ b/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). diff --git a/docs/dynamic-tao/dtao-faq.md b/docs/dynamic-tao/dtao-faq.md index 70bb355190..a33a03942a 100644 --- a/docs/dynamic-tao/dtao-faq.md +++ b/docs/dynamic-tao/dtao-faq.md @@ -35,7 +35,7 @@ Held stake (alpha tokens) may increase or decrease in TAO value as the price of **Network-wide Impact**: Your stake contributes weight across all subnets where your validator operates. This means your stake extracts emissions from multiple subnets simultaneously. See [Validator stake weight](../subnets/understanding-subnets.md#validator-stake-weight) for more details. -**Proportional emission and TAO weight**: TAO and alpha are emitted to a validator's stakers in proportion to the validators' holdings in each token. See [Emission: Extraction](../emissions.md#extraction) +**Proportional emission and TAO weight**: TAO and alpha are emitted to a validator's stakers in proportion to the validators' holdings in each token. See [Emission: Extraction](../learn/emissions.md#extraction) ### Can users transfer alpha tokens (subnet tokens)? @@ -81,7 +81,7 @@ Currently, the protocol does not automatically deregister subnets. Abandoned sub **No**. Emissions are calculated by protocol logic (e.g., in `run_coinbase.rs`) and are based on network-wide parameters. Subnet founders cannot arbitrarily print tokens—emission follows the same consistent rules across all subnets. -See [Emissions](../emissions.md) +See [Emissions](../learn/emissions.md) ### What happens to previously locked registration costs from pre-Dynamic-TAO subnets? diff --git a/docs/dynamic-tao/index.md b/docs/dynamic-tao/index.md index 523a6c37ef..3122163c48 100644 --- a/docs/dynamic-tao/index.md +++ b/docs/dynamic-tao/index.md @@ -32,7 +32,7 @@ See: - [Bittensor SDK release page](https://pypi.org/project/bittensor/) - [Bittensor CLI release page](https://pypi.org/project/bittensor-cli/) -- [Upgrade the Bittensor SDK](../getting-started/installation.md#upgrade) +- [Upgrade the Bittensor SDK](../getting-started/installation.md#upgrade-the-bittensor-sdk) ### Subnet tokens/liquidity pools diff --git a/docs/dynamic-tao/sdk-cheat-sheet.md b/docs/dynamic-tao/sdk-cheat-sheet.md index 152301fa4b..e9f1605a65 100644 --- a/docs/dynamic-tao/sdk-cheat-sheet.md +++ b/docs/dynamic-tao/sdk-cheat-sheet.md @@ -2,8 +2,7 @@ title: "Dynamic TAO SDK Cheat Sheet" --- -This page provides a quick reference for the core functionalities for the Bittensor Python SDK that have changed for [Dynamic TAO](./index.md), and some example scripts to demonstrate functionality such as [viewing exchange rates](#example-viewing-exchange-rates) and [staking and unstaking](#example-staking-and-unstaking) into subnets. - +This page provides a quick reference for the core functionalities for the Bittensor Python SDK that have changed for [Dynamic TAO](./index.md), and some example scripts to demonstrate functionality such as [viewing exchange rates](#display-current-exchange-rates) and [manage staking and unstaking](#managing-stake) into subnets. Updates to the `subtensor` and `async_subtensor` modules and the `DynamicInfo` class provide new ways to view information related to new Dynamic TAO features, such as alpha token prices, token reserve amounts, and wallet balances. Functionality around staking and unstaking has been updated to reflect the new nature of staking/unstaking in Dynamic TAO. @@ -43,7 +42,6 @@ Or the following configuration for synchronous calls to Bittensor test network: sub = bt.Subtensor(network="test") ``` - ## The `DynamicInfo` object The state of a subnet, with all of the new attributes, is encapsulated in a `DynamicInfo` object. This is what is returned by the `subnet` and `all_subnets` methods. @@ -75,10 +73,13 @@ class DynamicInfo: subnet_identity: Optional[SubnetIdentity] ``` + ## Viewing subnets + Subnets evolve substantially in Dynamic TAO! Each subnet has its own currency, known as its alpha token, and an internal economy comprising a currency reserve of TAO, a reserve of its own alpha token, and a ledger of staked balances, to keep track of all of its stakers—those who have put TAO into its reserve in exchange for alpha. #### `all_subnets` + ```python all_subnets( block_number: Optional[int] = None @@ -91,88 +92,99 @@ Description: Fetches information about all subnets at a certain block height (or Returns: A list of DynamicInfo objects (detailed below). #### `subnet` + ```python subnet( - netuid: int, + netuid: int, block_number: Optional[int] = None ) -> DynamicInfo ``` + Fetches information about a single subnet identified by netuid. Returns a DynamicInfo object describing the subnet’s current state. - #### `metagraph` + ```python metagraph( - netuid: int, + netuid: int, block: Optional[int] = None ) -> bittensor.Metagraph ``` - Returns the metagraph for a specified subnet netuid. The metagraph includes detailed data on the neurons in the subnet. ## Exchange rates + You can query the DynamicInfo object for the exchange rates between TAO and alpha tokens. You can use `all_subnets` or `subnet` to get the DynamicInfo object. ```python subnet = sub.subnet(netuid=1) ``` + ### Calculate exhange rates + #### `tao_to_alpha` ```python tao_to_alpha(self, tao: Union[Balance, float, int]) -> Balance: ``` -Description: Returns an 'ideal' estimate of how much Alpha a staker would receive at the current price, *ignoring slippage*. + +Description: Returns an 'ideal' estimate of how much Alpha a staker would receive at the current price, _ignoring slippage_. Parameters: - `tao`: Amount of TAO to stake. +`tao`: Amount of TAO to stake. #### `alpha_to_tao` + ```python alpha_to_tao(self, alpha: Union[Balance, float, int]) -> Balance: ``` -Description: Returns an 'ideal' estimate of how much TAO would be yielded by unstaking at the current price, *ignoring slippage*. + +Description: Returns an 'ideal' estimate of how much TAO would be yielded by unstaking at the current price, _ignoring slippage_. Parameters: - `alpha`: Amount of Alpha to unstake. +`alpha`: Amount of Alpha to unstake. #### `tao_to_alpha_with_slippage` + ```python tao_to_alpha_with_slippage(tao: Union[Balance, float, int], percentage: bool = False) -> Union[tuple[Balance, Balance], float]: ``` + Returns an estimate of how much Alpha would a staker receive if they stake their TAO using the current pool state. Parameters: - `tao`: Amount of TAO to stake. - `percentage`: If True, returns the percentage difference between the estimated amount and ideal amount as if there was no slippage. +`tao`: Amount of TAO to stake. +`percentage`: If True, returns the percentage difference between the estimated amount and ideal amount as if there was no slippage. Returns: - Tuple of balances where the first part is the amount of Alpha received, and the - second part (slippage) is the difference between the estimated amount and ideal - amount as if there was no slippage - OR - Percentage of the slippage as a float +Tuple of balances where the first part is the amount of Alpha received, and the +second part (slippage) is the difference between the estimated amount and ideal +amount as if there was no slippage +OR +Percentage of the slippage as a float #### `alpha_to_tao_with_slippage` + ```python alpha_to_tao_with_slippage(alpha: Union[Balance, float, int], percentage: bool = False) -> Union[tuple[Balance, Balance], float]: ``` + Returns an estimate of how much TAO would a staker receive if they unstake their alpha using the current pool state. Parameters: - `alpha`: Amount of Alpha to unstake. - `percentage`: If True, returns the percentage difference between the estimated amount and ideal amount as if there was no slippage. +`alpha`: Amount of Alpha to unstake. +`percentage`: If True, returns the percentage difference between the estimated amount and ideal amount as if there was no slippage. Returns: - Tuple of balances where the first part is the amount of TAO received, and the - second part (slippage) is the difference between the estimated amount and ideal - amount as if there was no slippage - OR - Percentage of the slippage as a float +Tuple of balances where the first part is the amount of TAO received, and the +second part (slippage) is the difference between the estimated amount and ideal +amount as if there was no slippage +OR +Percentage of the slippage as a float ### Display current exchange rates @@ -197,10 +209,11 @@ print("alpha_to_tao", subnet.alpha_to_tao(100)) ## Managing stake #### `get_stake` + ```python get_stake( - hotkey_ss58: str, - coldkey_ss58: str, + hotkey_ss58: str, + coldkey_ss58: str, netuid: int ) -> bittensor.Balance @@ -208,36 +221,38 @@ get_stake( Description: Retrieves the staked balance for a given (hotkey, coldkey) pair on a specific subnet. Returns a `bittensor.Balance` object with the staked amount. Parameters: + - hotkey_ss58: Hotkey SS58 address. - coldkey_ss58: Coldkey SS58 address (owner). - netuid: Unique ID of the subnet. - - #### `add_stake` ```python async add_stake( - wallet, - hotkey: str, - netuid: int, + wallet, + hotkey: str, + netuid: int, tao_amount: Union[float, bittensor.Balance, int] ) ``` + Description: Adds (stakes) an amount of TAO (tao_amount) to a specific subnet (netuid) under the provided hotkey. Parameters: + - wallet: Your Bittensor wallet object. - hotkey: The SS58 address (hotkey) to be staked. - netuid: Unique ID of the subnet on which you want to stake. - tao_amount: Amount to stake, can be a float, integer, or bittensor.Balance object. #### `unstake` + ```python unstake( - wallet, - hotkey: str, - netuid: int, + wallet, + hotkey: str, + netuid: int, amount: Union[float, bittensor.Balance, int] ) @@ -246,16 +261,17 @@ unstake( Description: Unstakes amount of TAO from the specified hotkey on a given netuid. Parameters: + - wallet: Your Bittensor wallet object. - hotkey: The SS58 address (hotkey) from which you want to remove stake. - netuid: Unique ID of the subnet. - amount: Amount to unstake. - #### `get_balance` + ```python get_balance( - address: str, + address: str, block: Optional[int] = None ) -> bittensor.Balance @@ -264,32 +280,38 @@ get_balance( Description: Returns the current (or specified block’s) coldkey TAO balance for an address. Parameters: + - address: SS58 address to check. - block: Optional block number at which to fetch the balance. Uses the latest block if None. - #### `get_current_block` + ```python get_current_block() -> int ``` + Description: Returns the current chain block number. + #### `wait_for_block` + ```python wait_for_block( block: Optional[int] = None ) ``` + Description: Waits for the next block to arrive or waits until a specified block number is reached if provided. Update: we have added proper nonce protection allowing you to run gather operations on stake/unstake/transfers, such as: + ```python scatter_stake = await asyncio.gather(*[ sub.add_stake( hotkey, coldkey, netuid, amount ) for netuid in range(64) ] ) ``` - ### Staking + The following script incrementally stakes 3 TAO into several subnets over many blocks: ```python @@ -308,11 +330,11 @@ while total_spend < 3: for netuid in to_buy: subnet = sub.subnet(netuid) print(f"slippage for subnet {netuid}", subnet.slippage(increment)) - sub.add_stake( - wallet = wallet, - netuid = netuid, - hotkey = subnet.owner_hotkey, - tao_amount = increment, + sub.add_stake( + wallet = wallet, + netuid = netuid, + hotkey = subnet.owner_hotkey, + tao_amount = increment, ) current_stake = sub.get_stake( @@ -325,6 +347,7 @@ while total_spend < 3: print (f'netuid {netuid} price {subnet.price} stake {current_stake}') sub.wait_for_block() ``` + ```console Enter your password: Decrypting... @@ -345,6 +368,7 @@ netuid 5 price τ0.001784484 stake ε11.208213619 ... ``` + ### Unstaking The below script will reverse the effects of the above, by incrementally unstaking alpha tokens from the list of subnets to yield TAO. @@ -366,11 +390,11 @@ while total_sell < 3: subnet = sub.subnet(netuid) print(f"slippage for subnet {netuid}", subnet.alpha_slippage(increment)) - sub.remove_stake( - wallet = wallet, - netuid = netuid, - hotkey = subnet.owner_hotkey, - amount = increment, + sub.remove_stake( + wallet = wallet, + netuid = netuid, + hotkey = subnet.owner_hotkey, + amount = increment, ) current_stake = sub.get_stake( coldkey_ss58 = wallet.coldkeypub.ss58_address, @@ -382,6 +406,7 @@ while total_sell < 3: print (f'netuid {netuid} price {subnet.price} stake {current_stake}') sub.wait_for_block() ``` + ```console Enter your password: Decrypting... @@ -410,23 +435,27 @@ netuid 5 price τ0.001785179 stake ε33.619312896 You can register your hotkey on a subnet using the `burned_register` method. This is necessary for staking, mining or validating. #### `burned_register` + ```python burned_register( - wallet, - netuid: int, + wallet, + netuid: int, ) -> bool ``` Description: Registers a hotkey on a subnet. Parameters: + - wallet: Your Bittensor wallet object. - netuid: Unique ID of the subnet. Returns: + - bool: True if the registration was successful, False otherwise. Sample script: + ```python import bittensor as bt logging = bt.logging @@ -440,13 +469,13 @@ wallet.unlock_coldkey() reg = sub.burned_register(wallet=wallet, netuid=3) ``` - ### View registered subnets #### `get_netuids_for_hotkey` + ```python get_netuids_for_hotkey( - hotkey: str, + hotkey: str, ) -> list[int] ``` @@ -454,9 +483,11 @@ get_netuids_for_hotkey( Description: Returns the netuids in which a hotkey is registered. Parameters: + - hotkey: SS58 address to check. Example usage: + ```python import bittensor as bt sub = bt.Subtensor(network="test") @@ -470,10 +501,10 @@ print(netuids) ``` #### `btcli wallet overview` + You can also use the `btcli` to check subnet registrations using `btcli wallet overview`. This displays the registrations to subnets by hotkeys controlled by the wallet: - ```shell Wallet @@ -505,14 +536,13 @@ Subnet: 119: vidac Ⲃ ``` - ## View a hotkey's emissions This script displays the last day's emissions for a specified hotkey on all subnets on which the hotkey is registered. This could be useful for a miner to see how much they've been extracting from the different subnets, if they've been mining on several. -Be aware that daily emissions can fluctuate widely. See [Emissions](../emissions.md). +Be aware that daily emissions can fluctuate widely. See [Emissions](../learn/emissions.md). ```python from bittensor.core.async_subtensor import AsyncSubtensor @@ -534,7 +564,7 @@ async def main(): all_sn_dynamic_info = {info.netuid: info for info in all_sn_dynamic_info_list} daily_blocks = (60 * 60 * 24) / BLOCKTIME # Number of blocks per day - + print(f"Hotkey: {HOTKEY}") @@ -542,10 +572,10 @@ async def main(): metagraphs = await asyncio.gather(*[ subtensor.metagraph(netuid=id) for id in NETUIDS]) for id in NETUIDS: print(f"UID: {id}") - + metagraph = metagraphs[id] tempo_multiplier = daily_blocks / metagraph.tempo - + subnet_info = all_sn_dynamic_info.get(id) uid = metagraph.hotkeys.index(HOTKEY) if HOTKEY in metagraph.hotkeys else None @@ -565,4 +595,4 @@ async def main(): asyncio.run(main()) -``` \ No newline at end of file +``` diff --git a/docs/errors/index.md b/docs/errors/index.md index aaa6b7e49a..e2fef265a2 100644 --- a/docs/errors/index.md +++ b/docs/errors/index.md @@ -7,6 +7,7 @@ title: "Subtensor Error Codes" This section documents the various types of errors that can arise from Subtensor, the blockchain underlying the Bittensor network. These errors can surface through different interfaces including the Bittensor CLI (`btcli`), the Bittensor Python SDK, or extrinsic transaction interfaces such as PolkadotJS. + Subtensor errors can be categorized into three main types: @@ -21,14 +22,14 @@ Most errors from the Bittensor network are returned in the following format: ```json { - "code": 1010, - "message": "Invalid Transaction", - "data": "Custom error: [Error Code]" + "code": 1010, + "message": "Invalid Transaction", + "data": "Custom error: [Error Code]" } ``` ## Related -- [Bittensor CLI](../btcli.md) - Command line interface documentation -- [Bittensor Python SDK](../bt-api-ref.md) - Python SDK documentation -- [Subtensor Nodes](../subtensor-nodes/index.md) - Information about running Subtensor nodes \ No newline at end of file +- [Bittensor CLI](../btcli/btcli.md) - Command line interface documentation +- [Bittensor Python SDK](../sdk/bt-api-ref.md) - Python SDK documentation +- [Subtensor Nodes](../subtensor-nodes/index.md) - Information about running Subtensor nodes diff --git a/docs/errors-and-troubleshooting.md b/docs/errors/troubleshooting.md similarity index 86% rename from docs/errors-and-troubleshooting.md rename to docs/errors/troubleshooting.md index 34922ec656..64a420f117 100644 --- a/docs/errors-and-troubleshooting.md +++ b/docs/errors/troubleshooting.md @@ -4,7 +4,7 @@ title: "Troubleshooting" # Troubleshooting -This document presents helpful hints to troubleshoot the errors you may get while working in the Bittensor ecosystem. +This document presents helpful hints to troubleshoot the errors you may get while working in the Bittensor ecosystem. ## Priority is too low @@ -16,7 +16,6 @@ Running a `btcli` command sometimes gives me the below error: **Likely cause and remedy**: This means that you are submitting the same, duplicate transaction that you have already submitted. For example, if you are running a script, it is trying to submit transactions too quickly, most likely. You just have to wait for a few minutes before you run the command again. - ## SSLCertVerificationError Running any `btcli` command gives the following error, on macOS: @@ -36,14 +35,14 @@ Go to the folder where Python is installed, e.g., in my case (Mac OS) it is inst **Remedy 2**: Run the below commands: -- On macOS when not using any Python virtual environment: - ```bash - brew reinstall openssl - ``` +- On macOS when not using any Python virtual environment: + ```bash + brew reinstall openssl + ``` - On macOS when using a virtual environment: - ```bash - pip install urllib3 --force-reinstall - ``` + ```bash + pip install urllib3 --force-reinstall + ``` ## KeyFileError @@ -55,8 +54,8 @@ KeyFileError: Keyfile at: /path/to/.bittensor/wallets/some-coldkey/hotkeys/someh See: -- [Miner registration](./miners/index.md#miner-registration) -- [Validator registration](./validators/index.md#validator-registration) +- [Miner registration](../miners/index.md#miner-registration) +- [Validator registration](../validators/index.md#validator-registration) ## Balances.transfer not found @@ -64,8 +63,7 @@ See: ValueError: Call function 'Balances.transfer' not found ``` -**Likely cause and remedy**: You are working with an older version of Bittensor. Update your Bittensor to the latest version. See [Install Bittensor](./getting-started/installation.md). - +**Likely cause and remedy**: You are working with an older version of Bittensor. Update your Bittensor to the latest version. See [Install Bittensor](../getting-started/installation.md). ## Genesis mismatch @@ -75,4 +73,4 @@ Reason: Genesis mismatch. Banned, disconnecting. These messages are mostly harmless and you can ignore them. Your lite node will sync properly. See the "best" block numbers in the terminal log. If these block numbers are closer or approaching the current block as seen on either [https://bittensor.com/scan](https://bittensor.com/scan) or [Polkadot JS](https://polkadot.js.org/apps/?rpc=wss%3A%2F%2Fentrypoint-finney.opentensor.ai%3A443#/explorer), then your local node is syncing properly. -You get these error messages very often because one or the other Bittensor blockchain validator nodes is running an older version of Polkadot SDK. When it says, "Banned, disconnecting", it is saying the mismatched blockchain validator node is being disconnected. This usually is fine because you don't need to be connected to all the blockchain validator nodes. +You get these error messages very often because one or the other Bittensor blockchain validator nodes is running an older version of Polkadot SDK. When it says, "Banned, disconnecting", it is saying the mismatched blockchain validator node is being disconnected. This usually is fine because you don't need to be connected to all the blockchain validator nodes. diff --git a/docs/evm-tutorials/convert-h160-to-ss58.md b/docs/evm-tutorials/convert-h160-to-ss58.md index 9d83e00a13..bb46fecefa 100644 --- a/docs/evm-tutorials/convert-h160-to-ss58.md +++ b/docs/evm-tutorials/convert-h160-to-ss58.md @@ -7,7 +7,7 @@ import { CreatePartial } from "./\_create-mm-wallet.mdx"; # Convert Ethereum (H160) Address to Substrate (SS58) -This tutorial demonstrates how to convert between Ethereum (H160) and Substrate (SS58) addresses. This is useful for moving across the boundary between [EVM wallets and Subtensor Wallets on the Bittensor blockchain](./#evm-wallets-and-subtensor-wallets-on-the-bittensor-blockchain). +This tutorial demonstrates how to convert between Ethereum (H160) and Substrate (SS58) addresses. This is useful for moving across the boundary between [EVM wallets and Subtensor Wallets on the Bittensor blockchain](./index.md#evm-and-subtensor-wallets-on-the-bittensor-blockchian). In what follows, we'll create a wallet in Metamask and convert it's public key to ss58 format in order to target it with a balance transfer using BTCLI. diff --git a/docs/evm-tutorials/index.md b/docs/evm-tutorials/index.md index 75684fdac1..e1f882a2b1 100644 --- a/docs/evm-tutorials/index.md +++ b/docs/evm-tutorials/index.md @@ -38,9 +38,9 @@ Bittensor EVM smart contracts are executed solely on the **Bittensor blockchain, See: - [Examples and Precompiles](./examples.md) -- [EVM on Testnet](./evm-testnet-with-metamask-wallet) -- [EVM on Local Chain](./evm-localnet-with-metamask-wallet) -- [EVM on Mainnet](./evm-mainnet-with-metamask-wallet) +- [EVM on Testnet](./evm-testnet-with-metamask-wallet.md) +- [EVM on Local Chain](./evm-localnet-with-metamask-wallet.md) +- [EVM on Mainnet](./evm-mainnet-with-metamask-wallet.md) - [Opentensor Foundation Blogpost: EVM on Bittensor](https://blog.bittensor.com/evm-on-bittensor-draft-6f323e69aff7) ## EVM and Subtensor wallets on the Bittensor blockchian @@ -52,7 +52,7 @@ The holder of a private key for an ss58 address based on the corresponding publi Similarly, creating an Ethereum wallet gives you control of the h160 private key for the corresponding public key. :::info -You can easily [convert an h160 address to an ss58 address](./convert-h160-to-ss58), or vice versa, but this does _not_ yield the corresponding private key. This means that if you create a wallet in Bittensor, you will not be able to sign Ethereum contracts with it, nor versa. +You can easily [convert an h160 address to an ss58 address](./convert-h160-to-ss58.md), or vice versa, but this does _not_ yield the corresponding private key. This means that if you create a wallet in Bittensor, you will not be able to sign Ethereum contracts with it, nor versa. ::: Hence, in the context of Bittensor EVM we can distinguish between: diff --git a/docs/evm-tutorials/subnet-precompile.md b/docs/evm-tutorials/subnet-precompile.md index 914311c8a4..ac94cb1759 100644 --- a/docs/evm-tutorials/subnet-precompile.md +++ b/docs/evm-tutorials/subnet-precompile.md @@ -10,30 +10,25 @@ import useBaseUrl from '@docusaurus/useBaseUrl'; This precompile allows you to interact with Bittensor subnets through EVM smart contracts, affording functionality for registering networks, viewing and setting network parameters, and querying network state. This page: -- described the precompile's [available functions](#available-functions) on the precompile -- demonstrates the precompile's usage with [example scripts](#example-script). - +- described the precompile's [available functions](#available-functions) on the precompile +- demonstrates the precompile's usage with [example scripts](#example-scripts). The subnet precompile is available at address `0x803` (2051 in decimal). View the [source on GitHub](https://github.com/opentensor/subtensor/blob/main/precompiles/src/subnet.rs) - - - :::info permissions Subnet operations have distinct requirements! - Creating a subnet, i.e. [`registerNetwork`,](#registernetwork) requires a coldkey with sufficient TAO to cover the current burn cost. - See [burn cost for subnet creation](../local-build/create-subnet#burn-cost). + See [burn cost for subnet creation](../local-build/create-subnet#subnet-creation-cost). - Setting subnet hyperparameters requires the private key for the coldkey that owns the subnet (the one that created it, unless this has been transferred). ::: - ## Available Functions The subnet precompile provides comprehensive functionality for subnet management and configuration. All functions are categorized below: @@ -45,28 +40,33 @@ The subnet precompile provides comprehensive functionality for subnet management Create/register a new subnet, without setting identity information. **Parameters:** + - `hotkey` (bytes32): The hotkey (32 bytes) that will own the network **Returns:** + - None (payable function) **Description:** Registers a new subnet on the Bittensor network. The caller becomes the subnet owner and can manage subnet parameters. -#### `registerNetworkWithIdentity` +#### `registerNetworkWithIdentity` + Registers a new subnet with detailed identity information. **Parameters:** + - `hotkey` (bytes32): The hotkey that will own the network - `subnetName` (string): Name of the subnet (max 256 chars) - `githubRepo` (string): GitHub repository URL (max 1024 chars) - `subnetContact` (string): Contact information (max 1024 chars) -- `subnetUrl` (string): Subnet website URL (max 1024 chars) +- `subnetUrl` (string): Subnet website URL (max 1024 chars) - `discord` (string): Discord server invite (max 256 chars) - `description` (string): Subnet description (max 1024 chars) - `additional` (string): Additional information (max 1024 chars) **Returns:** + - None (payable function) **Description:** @@ -75,384 +75,498 @@ Registers a new subnet with comprehensive identity metadata that helps users und ### Rate Limiting #### `getServingRateLimit` + Gets the serving rate limit for a subnet. **Parameters:** + - `netuid` (uint16): The subnetwork ID **Returns:** + - `uint64`: The serving rate limit value #### `setServingRateLimit` + Sets the serving rate limit for a subnet. **Parameters:** + - `netuid` (uint16): The subnetwork ID - `servingRateLimit` (uint64): The new serving rate limit value **Returns:** + - None (payable function) ### Difficulty Management #### `getMinDifficulty` + Gets the minimum difficulty for a subnet. **Parameters:** + - `netuid` (uint16): The subnetwork ID **Returns:** + - `uint64`: The minimum difficulty value #### `setMinDifficulty` + Sets the minimum difficulty for a subnet. **Parameters:** + - `netuid` (uint16): The subnetwork ID - `minDifficulty` (uint64): The new minimum difficulty value **Returns:** + - None (payable function) #### `getMaxDifficulty` + Gets the maximum difficulty for a subnet. **Parameters:** + - `netuid` (uint16): The subnetwork ID **Returns:** + - `uint64`: The maximum difficulty value #### `setMaxDifficulty` + Sets the maximum difficulty for a subnet. **Parameters:** + - `netuid` (uint16): The subnetwork ID - `maxDifficulty` (uint64): The new maximum difficulty value **Returns:** + - None (payable function) #### `getDifficulty` + Gets the current difficulty for a subnet. **Parameters:** + - `netuid` (uint16): The subnetwork ID **Returns:** + - `uint64`: The current difficulty value #### `setDifficulty` + Sets the current difficulty for a subnet. **Parameters:** + - `netuid` (uint16): The subnetwork ID - `difficulty` (uint64): The new difficulty value **Returns:** + - None (payable function) ### Weight Management #### `getWeightsVersionKey` + Gets the weights version key for a subnet. **Parameters:** + - `netuid` (uint16): The subnetwork ID **Returns:** + - `uint64`: The weights version key value #### `setWeightsVersionKey` + Sets the weights version key for a subnet. **Parameters:** + - `netuid` (uint16): The subnetwork ID - `weightsVersionKey` (uint64): The new weights version key value **Returns:** + - None (payable function) #### `getWeightsSetRateLimit` + Gets the weights set rate limit for a subnet. **Parameters:** + - `netuid` (uint16): The subnetwork ID **Returns:** + - `uint64`: The weights set rate limit value #### `setWeightsSetRateLimit` ⚠️ **DEPRECATED** + Sets the weights set rate limit for a subnet. **This function is deprecated. Subnet owners cannot set weight setting rate limits.** **Parameters:** + - `netuid` (uint16): The subnetwork ID - `weightsSetRateLimit` (uint64): The weights set rate limit value (ignored) **Returns:** + - None (payable function) **Description:** This function still exists for backward compatibility but performs no operation and returns successfully. #### `getMaxWeightLimit` + Gets the maximum weight limit for a subnet. **Parameters:** + - `netuid` (uint16): The subnetwork ID **Returns:** + - `uint16`: The maximum weight limit value #### `setMaxWeightLimit` + Sets the maximum weight limit for a subnet. **Parameters:** + - `netuid` (uint16): The subnetwork ID - `maxWeightLimit` (uint16): The new maximum weight limit value **Returns:** + - None (payable function) #### `getMinAllowedWeights` + Gets the minimum allowed weights for a subnet. **Parameters:** + - `netuid` (uint16): The subnetwork ID **Returns:** + - `uint16`: The minimum allowed weights value #### `setMinAllowedWeights` + Sets the minimum allowed weights for a subnet. **Parameters:** + - `netuid` (uint16): The subnetwork ID - `minAllowedWeights` (uint16): The new minimum allowed weights value **Returns:** + - None (payable function) ### Consensus Parameters #### `getAdjustmentAlpha` + Gets the adjustment alpha parameter for a subnet. **Parameters:** + - `netuid` (uint16): The subnetwork ID **Returns:** + - `uint64`: The adjustment alpha value #### `setAdjustmentAlpha` + Sets the adjustment alpha parameter for a subnet. **Parameters:** + - `netuid` (uint16): The subnetwork ID - `adjustmentAlpha` (uint64): The new adjustment alpha value **Returns:** + - None (payable function) #### `getKappa` + Gets the kappa parameter for a subnet. **Parameters:** + - `netuid` (uint16): The subnetwork ID **Returns:** + - `uint16`: The kappa value #### `setKappa` + Sets the kappa parameter for a subnet. **Parameters:** + - `netuid` (uint16): The subnetwork ID - `kappa` (uint16): The new kappa value **Returns:** + - None (payable function) #### `getRho` + Gets the rho parameter for a subnet. **Parameters:** + - `netuid` (uint16): The subnetwork ID **Returns:** + - `uint16`: The rho value #### `setRho` + Sets the rho parameter for a subnet. **Parameters:** + - `netuid` (uint16): The subnetwork ID - `rho` (uint16): The new rho value **Returns:** + - None (payable function) #### `getAlphaSigmoidSteepness` + Gets the alpha sigmoid steepness parameter for a subnet. **Parameters:** + - `netuid` (uint16): The subnetwork ID **Returns:** + - `uint16`: The alpha sigmoid steepness value #### `setAlphaSigmoidSteepness` + Sets the alpha sigmoid steepness parameter for a subnet. **Parameters:** + - `netuid` (uint16): The subnetwork ID - `steepness` (uint16): The new alpha sigmoid steepness value **Returns:** + - None (payable function) #### `getAlphaValues` + Gets the alpha low and high values for a subnet. **Parameters:** + - `netuid` (uint16): The subnetwork ID **Returns:** + - `uint16`: The alpha low value - `uint16`: The alpha high value #### `setAlphaValues` + Sets the alpha low and high values for a subnet. **Parameters:** + - `netuid` (uint16): The subnetwork ID - `alphaLow` (uint16): The new alpha low value - `alphaHigh` (uint16): The new alpha high value **Returns:** + - None (payable function) ### Network Activity #### `getImmunityPeriod` + Gets the immunity period for a subnet. **Parameters:** + - `netuid` (uint16): The subnetwork ID **Returns:** + - `uint16`: The immunity period value #### `setImmunityPeriod` + Sets the immunity period for a subnet. **Parameters:** + - `netuid` (uint16): The subnetwork ID - `immunityPeriod` (uint16): The new immunity period value **Returns:** + - None (payable function) #### `getActivityCutoff` + Gets the activity cutoff for a subnet. **Parameters:** + - `netuid` (uint16): The subnetwork ID **Returns:** + - `uint16`: The activity cutoff value #### `setActivityCutoff` + Sets the activity cutoff for a subnet. **Parameters:** + - `netuid` (uint16): The subnetwork ID - `activityCutoff` (uint16): The new activity cutoff value **Returns:** + - None (payable function) ### Registration Control #### `getNetworkRegistrationAllowed` + Gets whether network registration is allowed for a subnet. **Parameters:** + - `netuid` (uint16): The subnetwork ID **Returns:** + - `bool`: Whether network registration is allowed #### `setNetworkRegistrationAllowed` + Sets whether network registration is allowed for a subnet. **Parameters:** + - `netuid` (uint16): The subnetwork ID - `registrationAllowed` (bool): Whether to allow network registration **Returns:** + - None (payable function) #### `getNetworkPowRegistrationAllowed` + Gets whether PoW registration is allowed for a subnet. **Parameters:** + - `netuid` (uint16): The subnetwork ID **Returns:** + - `bool`: Whether PoW registration is allowed #### `setNetworkPowRegistrationAllowed` + Sets whether PoW registration is allowed for a subnet. **Parameters:** + - `netuid` (uint16): The subnetwork ID - `registrationAllowed` (bool): Whether to allow PoW registration **Returns:** + - None (payable function) ### Burn Management #### `getMinBurn` + Gets the minimum burn amount for a subnet. **Parameters:** + - `netuid` (uint16): The subnetwork ID **Returns:** + - `uint64`: The minimum burn amount #### `setMinBurn` ⚠️ **DEPRECATED** + Sets the minimum burn amount for a subnet. **This function is deprecated. Subnet owners cannot set the minimum burn anymore.** **Parameters:** + - `netuid` (uint16): The subnetwork ID - `minBurn` (uint64): The minimum burn amount (ignored) **Returns:** + - None (payable function) **Description:** This function still exists for backward compatibility but performs no operation and returns successfully. #### `getMaxBurn` + Gets the maximum burn amount for a subnet. **Parameters:** + - `netuid` (uint16): The subnetwork ID **Returns:** + - `uint64`: The maximum burn amount #### `setMaxBurn` ⚠️ **DEPRECATED** + Sets the maximum burn amount for a subnet. **This function is deprecated. Subnet owners cannot set the maximum burn anymore.** **Parameters:** + - `netuid` (uint16): The subnetwork ID - `maxBurn` (uint64): The maximum burn amount (ignored) **Returns:** + - None (payable function) **Description:** @@ -461,117 +575,153 @@ This function still exists for backward compatibility but performs no operation ### Bonds and Moving Averages #### `getBondsMovingAverage` + Gets the bonds moving average for a subnet. **Parameters:** + - `netuid` (uint16): The subnetwork ID **Returns:** + - `uint64`: The bonds moving average value #### `setBondsMovingAverage` + Sets the bonds moving average for a subnet. **Parameters:** + - `netuid` (uint16): The subnetwork ID - `bondsMovingAverage` (uint64): The new bonds moving average value **Returns:** + - None (payable function) ### Feature Toggles #### `getCommitRevealWeightsEnabled` + Gets whether commit-reveal weights are enabled for a subnet. **Parameters:** + - `netuid` (uint16): The subnetwork ID **Returns:** + - `bool`: Whether commit-reveal weights are enabled #### `setCommitRevealWeightsEnabled` + Sets whether commit-reveal weights are enabled for a subnet. **Parameters:** + - `netuid` (uint16): The subnetwork ID - `enabled` (bool): Whether to enable commit-reveal weights **Returns:** + - None (payable function) #### `getCommitRevealWeightsInterval` + Gets the commit-reveal weights interval for a subnet. **Parameters:** + - `netuid` (uint16): The subnetwork ID **Returns:** + - `uint64`: The commit-reveal weights interval value #### `setCommitRevealWeightsInterval` + Sets the commit-reveal weights interval for a subnet. **Parameters:** + - `netuid` (uint16): The subnetwork ID - `interval` (uint64): The new commit-reveal weights interval value **Returns:** + - None (payable function) #### `getLiquidAlphaEnabled` + Gets whether liquid alpha is enabled for a subnet. **Parameters:** + - `netuid` (uint16): The subnetwork ID **Returns:** + - `bool`: Whether liquid alpha is enabled #### `setLiquidAlphaEnabled` + Sets whether liquid alpha is enabled for a subnet. **Parameters:** + - `netuid` (uint16): The subnetwork ID - `enabled` (bool): Whether to enable liquid alpha **Returns:** + - None (payable function) #### `getYuma3Enabled` + Gets whether Yuma3 consensus is enabled for a subnet. **Parameters:** + - `netuid` (uint16): The subnetwork ID **Returns:** + - `bool`: Whether Yuma3 consensus is enabled #### `setYuma3Enabled` + Sets whether Yuma3 consensus is enabled for a subnet. **Parameters:** + - `netuid` (uint16): The subnetwork ID - `enabled` (bool): Whether to enable Yuma3 consensus **Returns:** + - None (payable function) ### Transfer Control #### `toggleTransfers` + Toggles transfers on/off for a subnet. **Parameters:** + - `netuid` (uint16): The subnetwork ID - `toggle` (bool): Whether to enable or disable transfers **Returns:** + - None (payable function) ## Example Scripts + [Example source on GitHub](https://github.com/opentensor/evm-bittensor/blob/main/examples/subnet.js) + ### Javascript + ```js const { ethers, assert } = require("ethers"); const { ApiPromise, WsProvider, Keyring } = require("@polkadot/api"); @@ -867,8 +1017,8 @@ async function main() { } main().catch(console.error); - ``` + ### Solidity [Example source on GitHub](https://github.com/opentensor/evm-bittensor/blob/main/solidity/subnet.sol) diff --git a/docs/getting-started/install-btcli.md b/docs/getting-started/install-btcli.md index 82590c01f9..9bc3b90f0e 100644 --- a/docs/getting-started/install-btcli.md +++ b/docs/getting-started/install-btcli.md @@ -21,7 +21,7 @@ To install `btcli`, you must have Python version 3.9-3.12. See config file on [G ## Developer reference -For a full developer reference, see the [Bittensor CLI reference document](../btcli.md). +For a full developer reference, see the [Bittensor CLI reference document](../btcli/btcli.md). ## Install on macOS and Linux diff --git a/docs/getting-started/installation.md b/docs/getting-started/installation.md index c3ee27c8b8..b2150e6f22 100644 --- a/docs/getting-started/installation.md +++ b/docs/getting-started/installation.md @@ -216,4 +216,4 @@ The Python interpreter output will look like below. ## Developer reference -For a full developer reference of the Bittensor SDK, see the [Bittensor SDK section](../bt-api-ref.md). +For a full developer reference of the Bittensor SDK, see the [Bittensor SDK section](../sdk/bt-api-ref.md). diff --git a/docs/governance.md b/docs/governance/governance.md similarity index 96% rename from docs/governance.md rename to docs/governance/governance.md index 31104c694f..f9b7e6bbcd 100644 --- a/docs/governance.md +++ b/docs/governance/governance.md @@ -6,7 +6,7 @@ title: "Governance Overview" Bittensor's governance protocol transitions the management of the network from centralization within the foundation to community ownership over time. -The first stage of this transition to decentralized management is the creation of a bicameral legislature. In this stage, the [Triumvirate](./glossary.md#triumvirate) creates proposals for the [Senate](./senate.md) to approve. +The first stage of this transition to decentralized management is the creation of a bicameral legislature. In this stage, the [Triumvirate](../resources/glossary.md#triumvirate) creates proposals for the [Senate](./senate.md) to approve. Triumvirate members are Opentensor Foundation employees, while the Senate is formed from the top K delegate hotkeys. @@ -39,9 +39,11 @@ Consider the following: **Triumvirate** `Bob` has a novel concept for a subnet and wishes to deploy it on the Bittensor network. `Bob` creates a proposal with the calldata: + ```python SubtensorModule.SudoAddNetwork(netuid, tempo, modality) ``` + and sends the transaction to the network in order to broadcast the proposal. **Senate** diff --git a/docs/senate.md b/docs/governance/senate.md similarity index 94% rename from docs/senate.md rename to docs/governance/senate.md index 232be41196..e103388b4e 100644 --- a/docs/senate.md +++ b/docs/governance/senate.md @@ -4,7 +4,7 @@ title: "Senate" # Senate -The Senate is a group of delegates who have elected to participate in proposals, and who control a significant portion of total network stake. +The Senate is a group of delegates who have elected to participate in proposals, and who control a significant portion of total network stake. All members of the network who have delegated stake to any of these Senate members are represented by the party that controls the delegate they've chosen to stake with. This allows any holder within the network to be represented, and to make their opinion known by delegating with organizations who represent their interests. @@ -14,10 +14,10 @@ In order to participate in the Senate, a coldkey must: - Have registered with any subnetwork as a hotkey-coldkey pair. - Have a hotkey stake value is greater than 2% of the network's total stake amount, through delegation or self-stake. -- Have elected to participate in the Senate. +- Have elected to participate in the Senate. -Once all four of the requirements have been fulfilled by a coldkey-hotkey pair, they can vote on any proposal created by the [Triumvirate](glossary#triumvirate). +Once all four of the requirements have been fulfilled by a coldkey-hotkey pair, they can vote on any proposal created by the [Triumvirate](../resources/glossary#triumvirate). In the case that the Senate has all twelve seats filled, and a delegate wishes to join, they will replace the lowest stake member as long as they have more stake in the network. diff --git a/docs/governance/senators-btcli-guide.md b/docs/governance/senators-btcli-guide.md index 00b2a24235..0d897ed9d5 100644 --- a/docs/governance/senators-btcli-guide.md +++ b/docs/governance/senators-btcli-guide.md @@ -6,25 +6,25 @@ title: "Senator's Guide to `BTCLI`" Governance participants (senate members, sudo-level accounts) can propose changes, cast votes, or execute privileged commands that affect the entire network. They must have a **coldkey** with the relevant governance role (senate membership or sudo privileges). -See [Requirements for Senate participation](../senate) +See [Requirements for Senate participation](./senate) -This page discusses btcli considerations specifically for Senators. For general coverage of BTCLI and permissions stuff, see: [Bittensor CLI: Permissions Guide](../btcli-permissions) +This page discusses btcli considerations specifically for Senators. For general coverage of BTCLI and permissions stuff, see: [Bittensor CLI: Permissions Guide](../btcli/btcli-permissions) -See also: [Coldkey and Hotkey Workstation Security](../getting-started/coldkey-hotkey-security). +See also: [Coldkey and Hotkey Workstation Security](../keys/coldkey-hotkey-security). - -See: [Senate](../senate). +See: [Senate](./senate). ## **Commands most relevant to governance:** + **Senate / Proposals** (coldkey with senator role): - - `btcli sudo senate` - - `btcli sudo proposals` - - `btcli sudo senate-vote` - - `btcli sudo senate_vote` + +- `btcli sudo senate` +- `btcli sudo proposals` +- `btcli sudo senate-vote` +- `btcli sudo senate_vote` ## Key rotation If you suspect your coldkey may have been leaked, you can request to swap it out of your wallet, using an extrinsic blockchain transaction. This operation has a 5 day waiting period, during which your coldkey will be locked. The cost of this coldkey swap transaction is 0.1 TAO. -See [Rotate/Swap your Coldkey](../subnets/schedule-coldkey-swap) - +See [Rotate/Swap your Coldkey](../keys/schedule-coldkey-swap) diff --git a/docs/index.md b/docs/index.md index acd733296d..ac0d501fa8 100644 --- a/docs/index.md +++ b/docs/index.md @@ -30,7 +30,6 @@ import { SiFuturelearn } from "react-icons/si"; import { GoNumber } from "react-icons/go"; import { VscFileMedia } from "react-icons/vsc"; - # Bittensor Documentation Bittensor is an open source platform where participants produce best-in-class digital commodities, including compute power, storage space, artificial intelligence (AI) inference and training, protein folding, financial markets prediction, and many more. @@ -52,7 +51,7 @@ Browse the subnets and explore links to their code repositories on [TAO.app](htt ## Participate - You can participate in an existing subnet as either a subnet validator or a subnet miner, or by staking your TAO to running validators. @@ -168,7 +166,7 @@ See [Legacy Bittensor 7.4.0 Documentation](pathname:///legacy-python-api/html/in **Extrinsics** option on the [polkadot.js.org/apps](https://polkadot.js.org/apps/?rpc=wss%3A%2F%2Fentrypoint-finney.opentensor.ai%3A443#/extrinsics) website. - ::: +:::danger If you do not do this step, then you will not see **Developer** > **Extrinsics** option on the [polkadot.js.org/apps](https://polkadot.js.org/apps/?rpc=wss%3A%2F%2Fentrypoint-finney.opentensor.ai%3A443#/extrinsics) website. +::: ## Steps for Polkadot JS @@ -73,7 +73,7 @@ Open your web browser and navigate to the Polkadot.js Apps website (https://polk ### Step 2: Navigate to the Extrinsics page -From the top navigation menu, proceed to **Developer** > **Extrinsics** to open the Extrinsics page. If you do not see this option, then make sure you successfully imported your source coldkey into the Polkadot JS extension, and connected this source coldkey account to the Polkadot.js Apps website. +From the top navigation menu, proceed to **Developer** > **Extrinsics** to open the Extrinsics page. If you do not see this option, then make sure you successfully imported your source coldkey into the Polkadot JS extension, and connected this source coldkey account to the Polkadot.js Apps website. ### Step 3: Select your source coldkey account @@ -83,17 +83,17 @@ Locate the drop-down section labeled **using the selected account** and select y Locate the drop-down section labeled **submit the following extrinsic** and select `subtensorModule`. -### Step 5: Choose the `scheduleSwapColdkey` function +### Step 5: Choose the `scheduleSwapColdkey` function -After selecting the `subtensorModule`, a second drop-down menu will appear on the right side of it. From this drop-down select the `scheduleSwapColdkey` option. +After selecting the `subtensorModule`, a second drop-down menu will appear on the right side of it. From this drop-down select the `scheduleSwapColdkey` option. -### Step 6: Provide the destination coldkey +### Step 6: Provide the destination coldkey Provide your destination coldkey in the `newColdkey: AccountId32` field. ### Step 7: Submit the transaction -Check again that you have provided the correct source and destination coldkeys. +Check again that you have provided the correct source and destination coldkeys. Scroll down to the bottom of the page and click on the **Submit Transaction** button. Polkadot.js will prompt you to sign the transaction using the selected account. After you sign the transaction, the signed transaction will be broadcast to the Subtensor. diff --git a/docs/getting-started/wallets.md b/docs/keys/wallets.md similarity index 94% rename from docs/getting-started/wallets.md rename to docs/keys/wallets.md index 3a1c20afb0..357ed3f06b 100644 --- a/docs/getting-started/wallets.md +++ b/docs/keys/wallets.md @@ -10,7 +10,7 @@ import useBaseUrl from '@docusaurus/useBaseUrl'; In Bittensor (like other cryptocurrency applications), a _wallet_ is a tool for proving your identity, signing transactions, accessing your TAO, and managing your stake in subnets. This page introduces the core concepts involved. -For detailed procedures for handling wallets and keys, see: [Working with keys](../working-with-keys.md) +For detailed procedures for handling wallets and keys, see: [Working with keys](./working-with-keys.md) For detailed security considerations, see: [Coldkey and Hotkey Workstation Security](./coldkey-hotkey-security.md) @@ -52,23 +52,23 @@ Different wallet applications have different levels of functionality: - The mobile app and Chrome extension allow for staking and transfer of TAO balalnces, but do not include any hotkey management or advanced functionality. - - Note that the Chome extension is compatible with a hardware wallet, which can be a strong security option. This implies using a laptop as your [coldkey workstation](../getting-started/coldkey-hotkey-security). + - Note that the Chome extension is compatible with a hardware wallet, which can be a strong security option. This implies using a laptop as your [coldkey workstation](./coldkey-hotkey-security). - - The mobile app depends on using a secure phone as a [coldkey workstation](../getting-started/coldkey-hotkey-security). + - The mobile app depends on using a secure phone as a [coldkey workstation](./coldkey-hotkey-security). -- `btcli` and the SDK allow for hotkey management and other advanced functionality. These require a laptop as a [coldkey workstation](../getting-started/coldkey-hotkey-security). +- `btcli` and the SDK allow for hotkey management and other advanced functionality. These require a laptop as a [coldkey workstation](./coldkey-hotkey-security). :::tip Note that you can also check balances on an unsecure device without entering your coldkey private key. For example, using [https://bittensor.com/scan](https://bittensor.com/scan). These website can be considered permissionless wallet applications. -See [Coldkey and Hotkey Workstation Security: Permissionless workstation](../getting-started/coldkey-hotkey-security#permissionless-workstation) +See [Coldkey and Hotkey Workstation Security: Permissionless workstation](./coldkey-hotkey-security#permissionless-workstation) ::: ## The seed phrase a.k.a. mnemonic The **_seed phrase_** (a.k.a. 'menemonic' or 'recovery phrase') is a series of (at least 12) words that is generated together with your wallet's cryptographic key pair, and which can be used to recover the coldkey private key. This seed phrase is therefore a human-usable way to save access to the cryptographic wallet offline, and to import the cryptographic wallet into a wallet application. -Arguably the most important operational goal when handling Bittensor wallets is to avoid losing or leaking your seed phrase. Make sure you [Handle your Seed Phrase/Mnemonic Securely](../keys/handle-seed-phrase). +Arguably the most important operational goal when handling Bittensor wallets is to avoid losing or leaking your seed phrase. Make sure you [Handle your Seed Phrase/Mnemonic Securely](./handle-seed-phrase). ## Wallet applications @@ -113,7 +113,7 @@ It is also required for creating and registering hotkeys, and for subnet managem **Encryption**: A coldkey is only stored on your disk in an encrypted form, and requires an encryption password. -See [Coldkey and Hotkey Workstation Security](../getting-started/coldkey-hotkey-security) for concrete security details about working with coldkeys. +See [Coldkey and Hotkey Workstation Security](./coldkey-hotkey-security) for concrete security details about working with coldkeys.
Metagraph Properties @@ -134,28 +133,28 @@ In the Bittensor Python SDK, the `Metagraph` class encapsulates the following in | `version` | Bittensor version number | | `n` | Total number of neurons registered on the subnet | | `block` | Block number when the metagraph record was retrieved | -| `total_stake` | Total [stake weight](../glossary.md#stake-weight) (α + τ × 0.18) across all neurons | -| **Stake** / `S` | Total [stake weight](../glossary.md#stake-weight) (α + τ × 0.18) of each neuron, determining consensus power and emissions | +| `total_stake` | Total [stake weight](../resources/glossary.md#stake-weight) (α + τ × 0.18) across all neurons | +| **Stake** / `S` | Total [stake weight](../resources/glossary.md#stake-weight) (α + τ × 0.18) of each neuron, determining consensus power and emissions | | **Alpha Stake** / `AS` | Alpha token stake (α) for each neuron | -| **Tao Stake** / `TS` | [TAO](../glossary.md#tao-τ) token stake (τ) for each neuron | -| **Ranks** / `R` | Final performance scores after [consensus](../glossary.md#consensus-score) weight clipping - [stake-weighted](../glossary.md#stake-weight) sum of clipped weights that directly determine emissions to miners | -| **Trust** / `T` | [Consensus alignment](../glossary.md#trust) ratio (final rank / pre-rank) - measures how much consensus clipping affected the rank, where 1.0 indicates perfect consensus alignment | -| **Validator Trust** / `Tv` | [Validator trust](../glossary.md#validator-trust) - sum of clipped weights set by each validator, measuring validator influence in consensus | -| **Consensus** / `C` | [Consensus score](../glossary.md#consensus-score) - stake-weighted median of weights per neuron, serving as consensus threshold for weight clipping | -| **Incentive** / `I` | Normalized ranks representing [incentive](../glossary.md#incentives) allocation for miners based on performance | -| **Emission** / `E` | Token [emission](../glossary.md#emission) amounts in [RAO](../glossary.md#rao) (10^-9 TAO) per block | -| **Dividends** / `D` | [Bond](../glossary.md#validator-miner-bonds)-based rewards for validators from their investments in miners | -| **Bonds** / `B` | Inter-neuronal [bond matrix](../glossary.md#validator-miner-bonds) representing validator investments in miners, used to calculate validator emissions | -| **Weights** / `W` | [Weight matrix](../glossary.md#weight-matrix) (validator → miner assignments) formed from validator weight vectors, input for [Yuma Consensus](../glossary.md#yuma-consensus) | -| `uids` | Unique [UID](../glossary.md#uid-slot) identifiers for each neuron | -| `hotkeys` | Neuron [hotkey](../glossary.md#hotkey) addresses | -| `coldkeys` | Neuron [coldkey](../glossary.md#coldkey) addresses | +| **Tao Stake** / `TS` | [TAO](../resources/glossary.md#tao-tau) token stake (τ) for each neuron | +| **Ranks** / `R` | Final performance scores after [consensus](../resources/glossary.md#consensus-score) weight clipping - [stake-weighted](../resources/glossary.md#stake-weight) sum of clipped weights that directly determine emissions to miners | +| **Trust** / `T` | [Consensus alignment](../resources/glossary.md#trust) ratio (final rank / pre-rank) - measures how much consensus clipping affected the rank, where 1.0 indicates perfect consensus alignment | +| **Validator Trust** / `Tv` | [Validator trust](../resources/glossary.md#validator-trust) - sum of clipped weights set by each validator, measuring validator influence in consensus | +| **Consensus** / `C` | [Consensus score](../resources/glossary.md#consensus-score) - stake-weighted median of weights per neuron, serving as consensus threshold for weight clipping | +| **Incentive** / `I` | Normalized ranks representing [incentive](../resources/glossary.md#incentives) allocation for miners based on performance | +| **Emission** / `E` | Token [emission](../resources/glossary.md#emission) amounts in [RAO](../resources/glossary.md#rao) (10^-9 TAO) per block | +| **Dividends** / `D` | [Bond](../resources/glossary.md#validator-miner-bonds)-based rewards for validators from their investments in miners | +| **Bonds** / `B` | Inter-neuronal [bond matrix](../resources/glossary.md#validator-miner-bonds) representing validator investments in miners, used to calculate validator emissions | +| **Weights** / `W` | [Weight matrix](../resources/glossary.md#weight-matrix) (validator → miner assignments) formed from validator weight vectors, input for [Yuma Consensus](../resources/glossary.md#yuma-consensus) | +| `uids` | Unique [UID](../resources/glossary.md#uid-slot) identifiers for each neuron | +| `hotkeys` | Neuron [hotkey](../resources/glossary.md#hotkey) addresses | +| `coldkeys` | Neuron [coldkey](../resources/glossary.md#coldkey) addresses | | `addresses` | Network IP addresses | -| `axons` | Network connection details for [axon](../glossary.md#axon) servers | -| `neurons` | Complete [neuron](../glossary.md#neuron) objects with all metadata | -| `active` | Neuron activity status within the [`activity_cutoff`](./subnet-hyperparameters.md#activity_cutoff) window | +| `axons` | Network connection details for [axon](../resources/glossary.md#axon) servers | +| `neurons` | Complete [neuron](../resources/glossary.md#neuron) objects with all metadata | +| `active` | Neuron activity status within the [`activity_cutoff`](./subnet-hyperparameters.md#activitycutoff) window | | `last_update` | Last update block numbers for staleness detection | -| `validator_permit` | Boolean array indicating whether each neuron has [validator permits](../glossary.md#validator-permit) to set weights and participate in consensus | +| `validator_permit` | Boolean array indicating whether each neuron has [validator permits](../resources/glossary.md#validator-permit) to set weights and participate in consensus | | `name` | Subnet name | | `symbol` | Subnet token symbol | | `network_registered_at` | Registration block when subnet was created | @@ -163,28 +162,26 @@ In the Bittensor Python SDK, the `Metagraph` class encapsulates the following in | `max_uids` | Maximum allowed neurons (typically 256) | | `identities` | List of chain identities | | `identity` | Subnet identity information | -| `pruning_score` | List of pruning scores based on emissions, used for [deregistration](../glossary.md#deregistration) when subnet is full | -| `block_at_registration` | List of registration blocks for each neuron, used for [immunity period](../glossary.md#immunity-period) calculations | -| `tao_dividends_per_hotkey` | [TAO](../glossary.md#tao-τ) dividends by hotkey | +| `pruning_score` | List of pruning scores based on emissions, used for [deregistration](../resources/glossary.md#deregistration) when subnet is full | +| `block_at_registration` | List of registration blocks for each neuron, used for [immunity period](../resources/glossary.md#immunity-period) calculations | +| `tao_dividends_per_hotkey` | [TAO](../resources/glossary.md#tao-tau) dividends by hotkey | | `alpha_dividends_per_hotkey` | Alpha dividends by hotkey | | `last_step` | Last step block number | -| `tempo` | [Tempo](../glossary.md#tempo) - block interval for updates (360 blocks = 72 minutes) | +| `tempo` | [Tempo](../resources/glossary.md#tempo) - block interval for updates (360 blocks = 72 minutes) | | `blocks_since_last_step` | Blocks since last step | -| `owner_coldkey` | Subnet owner [coldkey](../glossary.md#coldkey) | -| `owner_hotkey` | Subnet owner [hotkey](../glossary.md#hotkey) | +| `owner_coldkey` | Subnet owner [coldkey](../resources/glossary.md#coldkey) | +| `owner_hotkey` | Subnet owner [hotkey](../resources/glossary.md#hotkey) | | `hparams` | Subnet [hyperparameters](./subnet-hyperparameters.md) (`MetagraphInfoParams`) | | `pool` | Liquidity pool information (`MetagraphInfoPool`) | | `emissions` | Emission configuration (`MetagraphInfoEmissions`) |
- - - ### Neuron Info A neuron represents any registered participant on the subnet, whether a miner or a validator. See also: + - [Understanding Neurons](../learn/neurons.md) - [NeuronInfo class specification, SDK reference](pathname:///python-api/html/autoapi/bittensor/core/chain_data/neuron_info/index.html#bittensor.core.chain_data.neuron_info.NeuronInfo) @@ -192,31 +189,31 @@ See also: Neuron Info Properties | Name | Description | --|-- -`uid` | Unique [UID](../glossary.md#uid-slot) identifier for the neuron within the subnet -`hotkey` | [Hotkey](../glossary.md#hotkey) address for network operations and signing -`coldkey` | [Coldkey](../glossary.md#coldkey) address for secure storage and high-risk operations -`stake` | Total [stake weight](../glossary.md#stake-weight) (α + τ × 0.18) determining consensus power and emissions -`rank` | Final [performance rank](../glossary.md#rank) after consensus weight clipping, directly determining emissions -`trust` | [Consensus alignment](../glossary.md#trust) ratio (final rank / pre-rank) measuring impact of consensus filtering -`consensus` | [Consensus score](../glossary.md#consensus-score) - stake-weighted median of weights serving as clipping threshold -`incentive` | Normalized [incentive](../glossary.md#incentives) score representing reward allocation for miners -`emission` | Token [emission](../glossary.md#emission) rate in [RAO](../glossary.md#rao) per block -`dividends` | [Bond](../glossary.md#validator-miner-bonds)-based dividend amount for validators -`validator_trust` | [Validator trust](../glossary.md#validator-trust) measuring validator influence in consensus -`active` | Activity status within the [`activity_cutoff`](./subnet-hyperparameters.md#activity_cutoff) window +`uid` | Unique [UID](../resources/glossary.md#uid-slot) identifier for the neuron within the subnet +`hotkey` | [Hotkey](../resources/glossary.md#hotkey) address for network operations and signing +`coldkey` | [Coldkey](../resources/glossary.md#coldkey) address for secure storage and high-risk operations +`stake` | Total [stake weight](../resources/glossary.md#stake-weight) (α + τ × 0.18) determining consensus power and emissions +`rank` | Final [performance rank](../resources/glossary.md#rank) after consensus weight clipping, directly determining emissions +`trust` | [Consensus alignment](../resources/glossary.md#trust) ratio (final rank / pre-rank) measuring impact of consensus filtering +`consensus` | [Consensus score](../resources/glossary.md#consensus-score) - stake-weighted median of weights serving as clipping threshold +`incentive` | Normalized [incentive](../resources/glossary.md#incentives) score representing reward allocation for miners +`emission` | Token [emission](../resources/glossary.md#emission) rate in [RAO](../resources/glossary.md#rao) per block +`dividends` | [Bond](../resources/glossary.md#validator-miner-bonds)-based dividend amount for validators +`validator_trust` | [Validator trust](../resources/glossary.md#validator-trust) measuring validator influence in consensus +`active` | Activity status within the [`activity_cutoff`](./subnet-hyperparameters.md#activitycutoff) window `last_update` | Last update block number for staleness detection -`validator_permit` | Boolean indicating [validator permit](../glossary.md#validator-permit) status for weight setting and consensus participation -`weights` | [Weight vector](../glossary.md#weight-vector) assignments from this neuron to others -`bonds` | [Bond](../glossary.md#validator-miner-bonds) investments from this neuron to others -`axon_info` | Network connection details for the [axon](../glossary.md#axon) server +`validator_permit` | Boolean indicating [validator permit](../resources/glossary.md#validator-permit) status for weight setting and consensus participation +`weights` | [Weight vector](../resources/glossary.md#weight-vector) assignments from this neuron to others +`bonds` | [Bond](../resources/glossary.md#validator-miner-bonds) investments from this neuron to others +`axon_info` | Network connection details for the [axon](../resources/glossary.md#axon) server
- ### Axons An axon represents a server run by a registered miner, capable of answering requests by validators. See also: + - [Understanding Neurons](../learn/neurons.md) - [Axon class specification, SDK reference](pathname:///python-api/html/autoapi/bittensor/core/axon/index.html#module-bittensor.core.axon) - [Axon class specification, SDK reference](pathname:///python-api/html/autoapi/bittensor/core/axon/index.html#module-bittensor.core.axon) @@ -224,16 +221,17 @@ See also:
Axon Properties -| Name | Description | ---|-- -`hotkey` | Neuron [hotkey](../glossary.md#hotkey) address -`coldkey` | Neuron [coldkey](../glossary.md#coldkey) address -`ip` | IP address for the [axon](../glossary.md#axon) server -`port` | Port number for the axon server -`ip_type` | IP type (IPv4/IPv6) -`version` | Protocol version for axon-dendrite communication -`placeholder1` | Reserved field for future use -`placeholder2` | Reserved field for future use +| Name | Description | +| -------------- | --------------------------------------------------------------- | +| `hotkey` | Neuron [hotkey](../resources/glossary.md#hotkey) address | +| `coldkey` | Neuron [coldkey](../resources/glossary.md#coldkey) address | +| `ip` | IP address for the [axon](../resources/glossary.md#axon) server | +| `port` | Port number for the axon server | +| `ip_type` | IP type (IPv4/IPv6) | +| `version` | Protocol version for axon-dendrite communication | +| `placeholder1` | Reserved field for future use | +| `placeholder2` | Reserved field for future use | +
### MetagraphInfoParams @@ -241,43 +239,45 @@ See also: Represents the hyperparameters of a subnet. See also: + - [Subnet Hyperparameters](./subnet-hyperparameters) - [MetagraphInfoParams class specification, SDK reference](pathname:///python-api/html/autoapi/bittensor/core/chain_data/metagraph_info/index.html#bittensor.core.chain_data.metagraph_info.MetagraphInfoParams)
MetagraphInfoParams (Hyperparams) Properties -| Name | Description | ----|---- -`activity_cutoff` | Activity cutoff threshold -`adjustment_alpha` | Adjustment alpha parameter -`adjustment_interval` | Adjustment interval -`alpha_high` | Alpha high threshold -`alpha_low` | Alpha low threshold -`bonds_moving_avg` | Bonds moving average -`burn` | Burn amount -`commit_reveal_period` | Commit reveal period -`commit_reveal_weights_enabled` | Commit reveal weights enabled -`difficulty` | Network difficulty -`immunity_period` | Immunity period -`kappa` | Kappa parameter -`liquid_alpha_enabled` | Liquid alpha enabled -`max_burn` | Maximum burn -`max_difficulty` | Maximum difficulty -`max_regs_per_block` | Max registrations per block -`max_validators` | Maximum validators -`max_weights_limit` | Maximum weights limit -`min_allowed_weights` | Minimum allowed weights -`min_burn` | Minimum burn -`min_difficulty` | Minimum difficulty -`pow_registration_allowed` | POW registration allowed -`registration_allowed` | Registration allowed -`rho` | Rho parameter -`serving_rate_limit` | Serving rate limit -`target_regs_per_interval` | Target registrations per interval -`tempo` | [Tempo](../glossary.md#tempo) - block interval for updates (360 blocks = 72 minutes) -`weights_rate_limit` | [Weights](../glossary.md#weight-vector) rate limit for submissions -`weights_version` | [Weights](../glossary.md#weight-vector) version for protocol compatibility +| Name | Description | +| ------------------------------- | ---------------------------------------------------------------------------------------------- | +| `activity_cutoff` | Activity cutoff threshold | +| `adjustment_alpha` | Adjustment alpha parameter | +| `adjustment_interval` | Adjustment interval | +| `alpha_high` | Alpha high threshold | +| `alpha_low` | Alpha low threshold | +| `bonds_moving_avg` | Bonds moving average | +| `burn` | Burn amount | +| `commit_reveal_period` | Commit reveal period | +| `commit_reveal_weights_enabled` | Commit reveal weights enabled | +| `difficulty` | Network difficulty | +| `immunity_period` | Immunity period | +| `kappa` | Kappa parameter | +| `liquid_alpha_enabled` | Liquid alpha enabled | +| `max_burn` | Maximum burn | +| `max_difficulty` | Maximum difficulty | +| `max_regs_per_block` | Max registrations per block | +| `max_validators` | Maximum validators | +| `max_weights_limit` | Maximum weights limit | +| `min_allowed_weights` | Minimum allowed weights | +| `min_burn` | Minimum burn | +| `min_difficulty` | Minimum difficulty | +| `pow_registration_allowed` | POW registration allowed | +| `registration_allowed` | Registration allowed | +| `rho` | Rho parameter | +| `serving_rate_limit` | Serving rate limit | +| `target_regs_per_interval` | Target registrations per interval | +| `tempo` | [Tempo](../resources/glossary.md#tempo) - block interval for updates (360 blocks = 72 minutes) | +| `weights_rate_limit` | [Weights](../resources/glossary.md#weight-vector) rate limit for submissions | +| `weights_version` | [Weights](../resources/glossary.md#weight-vector) version for protocol compatibility | +
### MetagraphInfoPool @@ -285,10 +285,10 @@ See also: Contains information about the subnet's liquidity pool See also: + - [Understanding Subnets: Liquidity pools](./understanding-subnets#liquidity-pools). - [MetagraphInfoPool class specification, SDK reference](pathname:///python-api/html/autoapi/bittensor/core/chain_data/metagraph_info/index.html#bittensor.core.chain_data.metagraph_info.MetagraphInfoPool) -
MetagraphInfoPool properties | Name | Description | @@ -305,36 +305,33 @@ See also: Contains detailed information about the subnet's emissions. See also: -- [Emissions](../emissions). -- [MetagraphInfoEmissions class specification, SDK reference](pathname:///python-api/html/autoapi/bittensor/core/chain_data/metagraph_info/index.html#bittensor.core.chain_data.metagraph_info.MetagraphInfoPool) +- [Emissions](../learn/emissions). +- [MetagraphInfoEmissions class specification, SDK reference](pathname:///python-api/html/autoapi/bittensor/core/chain_data/metagraph_info/index.html#bittensor.core.chain_data.metagraph_info.MetagraphInfoPool)
MetagraphInfoEmissions properties | Name | Description | --|-- -`alpha_out_emission` | Alpha token outflow [emission](../glossary.md#emission) rate -`alpha_in_emission` | Alpha token inflow [emission](../glossary.md#emission) rate -`subnet_emission` | Subnet [emission](../glossary.md#emission) rate to participants -`tao_in_emission` | [TAO](../glossary.md#tao-τ) token inflow [emission](../glossary.md#emission) rate -`pending_alpha_emission` | Pending alpha token [emission](../glossary.md#emission) amount -`pending_root_emission` | Pending root network [emission](../glossary.md#emission) amount +`alpha_out_emission` | Alpha token outflow [emission](../resources/glossary.md#emission) rate +`alpha_in_emission` | Alpha token inflow [emission](../resources/glossary.md#emission) rate +`subnet_emission` | Subnet [emission](../resources/glossary.md#emission) rate to participants +`tao_in_emission` | [TAO](../resources/glossary.md#tao-tau) token inflow [emission](../resources/glossary.md#emission) rate +`pending_alpha_emission` | Pending alpha token [emission](../resources/glossary.md#emission) amount +`pending_root_emission` | Pending root network [emission](../resources/glossary.md#emission) amount
- - ## Python Code Examples This section provides practical examples of working with the Bittensor metagraph using the Python SDK. Each example demonstrates different aspects of metagraph analysis and data extraction. -Code examples can be found [here](https://github.com/latent-to/developer-docs/tree/main/static/code-examples/) **Prerequisites**: + - Bittensor Python SDK installed (`pip install bittensor`) - Network connection to access Bittensor blockchain - Python 3.7+ environment - ### Basic Metagraph Information This example shows how to access basic metagraph metadata and subnet information: @@ -348,7 +345,7 @@ def main(): # Initialize metagraph for subnet 1 print("Initializing metagraph for subnet 1...") metagraph = Metagraph(netuid=1, network="finney", sync=True) - + # Get basic metagraph metadata print("\n=== Basic Metagraph Metadata ===") print(f"Network: {metagraph.network}") @@ -366,10 +363,9 @@ def main(): print(f"Owner: {metagraph.owner_coldkey}") if __name__ == "__main__": - main() + main() ``` - ### Neuron Metrics Analysis This example demonstrates stake distribution and neuron metrics analysis: @@ -383,7 +379,7 @@ def main(): # Initialize metagraph for subnet 1 print("Initializing metagraph for subnet 1...") metagraph = Metagraph(netuid=1, network="finney", sync=True) - + # Get all neuron UIDs uids = metagraph.uids print(f"\nNeuron UIDs: {uids.tolist()}") @@ -408,10 +404,9 @@ def main(): print(f" {i+1}. UID {uid}: {stake:.2f} τ") if __name__ == "__main__": - main() + main() ``` - ### Performance and Ranking Analysis This example shows how to analyze neuron performance, ranks, and trust scores: @@ -425,7 +420,7 @@ def main(): # Initialize metagraph for subnet 1 print("Initializing metagraph for subnet 1...") metagraph = Metagraph(netuid=1, network="finney", sync=True) - + # Get performance metrics ranks = metagraph.R # Performance ranks trust = metagraph.T # Trust scores @@ -464,10 +459,9 @@ def main(): print("\nNo validators found in this subnet.") if __name__ == "__main__": - main() + main() ``` - ### Economic Analysis This example demonstrates analysis of economic metrics like incentives, emissions, and dividends: @@ -481,7 +475,7 @@ def main(): # Initialize metagraph for subnet 1 print("Initializing metagraph for subnet 1...") metagraph = Metagraph(netuid=1, network="finney", sync=True) - + # Get economic metrics incentives = metagraph.I # Incentive scores emissions = metagraph.E # Emission rates @@ -511,10 +505,9 @@ def main(): print(f"Dividend std dev: {dividends.std().item():.4f}") if __name__ == "__main__": - main() + main() ``` - ### Network Connectivity Analysis This example shows how to analyze network addresses and axon information: @@ -528,7 +521,7 @@ def main(): # Initialize metagraph for subnet 1 print("Initializing metagraph for subnet 1...") metagraph = Metagraph(netuid=1, network="finney", sync=True) - + # Get network information axons = metagraph.axons uids = metagraph.uids @@ -565,11 +558,9 @@ def main(): print(f" UID {uid}: IP={axon.ip}, Port={axon.port}, Hotkey={hotkey}") if __name__ == "__main__": - main() + main() ``` - - ### Weight Matrix Analysis This example demonstrates weight matrix analysis (requires `lite=False`): @@ -583,19 +574,19 @@ def main(): # Initialize metagraph for subnet 1 with full sync (not lite) print("Initializing metagraph for subnet 1 (full sync)...") metagraph = Metagraph(netuid=1, network="finney", lite=False, sync=True) - + uids = metagraph.uids - + # Get weight matrix (requires lite=False) if not metagraph.lite and hasattr(metagraph, 'weights') and metagraph.weights.size > 0: weights = metagraph.W # Weight matrix - + print(f"\n=== Weight Matrix Analysis ===") print(f"Weight matrix shape: {weights.shape}") print(f"Total weights: {weights.sum().item():.4f}") print(f"Average weight: {weights.mean().item():.4f}") print(f"Max weight: {weights.max().item():.4f}") - + # Find miners receiving most weights weight_received = weights.sum(axis=0) # Sum of incoming weights top_receivers = weight_received.argsort()[::-1][:10] @@ -604,7 +595,7 @@ def main(): uid = uids[idx].item() total_weight = weight_received[idx].item() print(f" {i+1}. UID {uid}: {total_weight:.4f}") - + # Find validators sending most weights weight_sent = weights.sum(axis=1) # Sum of outgoing weights top_senders = weight_sent.argsort()[::-1][:10] @@ -613,7 +604,7 @@ def main(): uid = uids[idx].item() total_weight = weight_sent[idx].item() print(f" {i+1}. UID {uid}: {total_weight:.4f}") - + # Find highest set weight max_weight_idx = weights.argmax() sender_idx = max_weight_idx // weights.shape[1] @@ -625,7 +616,7 @@ def main(): print("Weights not available. Make sure to use lite=False when initializing the metagraph.") if __name__ == "__main__": - main() + main() ``` ### Bond Analysis @@ -641,18 +632,18 @@ def main(): # Initialize metagraph for subnet 1 with full sync (not lite) print("Initializing metagraph for subnet 1 (full sync)...") metagraph = Metagraph(netuid=1, network="finney", lite=False, sync=True) - + uids = metagraph.uids - + # Get bond matrix (requires lite=False) if not metagraph.lite and hasattr(metagraph, 'bonds') and metagraph.bonds.size > 0: bonds = metagraph.B # Bond matrix - + print(f"\n=== Bond Matrix Analysis ===") print(f"Bond matrix shape: {bonds.shape}") print(f"Total bonds: {bonds.sum().item():.4f}") print(f"Average bond: {bonds.mean().item():.4f}") - + # Find miners with most bonds bonds_received = bonds.sum(axis=0) # Sum of incoming bonds top_bonded = bonds_received.argsort()[::-1][:10] @@ -665,10 +656,9 @@ def main(): print("Bonds not available. Make sure to use lite=False when initializing the metagraph.") if __name__ == "__main__": - main() + main() ``` - ### Neuron Activity Analysis This example demonstrates analyzing validator activity: @@ -682,7 +672,7 @@ def main(): # Initialize metagraph for subnet 1 print("Initializing metagraph for subnet 1...") metagraph = Metagraph(netuid=1, network="finney", sync=True) - + # Get activity information active = metagraph.active # Activity status last_update = metagraph.last_update # Last update blocks @@ -716,7 +706,7 @@ def main(): print("\nNo validators found in this subnet.") if __name__ == "__main__": - main() + main() ``` ### Subnet Economics @@ -732,7 +722,7 @@ def main(): # Initialize metagraph for subnet 1 print("Initializing metagraph for subnet 1...") metagraph = Metagraph(netuid=1, network="finney", sync=True) - + # Get subnet hyperparameters hparams = metagraph.hparams print(f"\n=== Subnet Hyperparameters ===") @@ -771,11 +761,9 @@ def main(): print(f" Pending root emission: {emissions.pending_root_emission}") if __name__ == "__main__": - main() + main() ``` - - ### Advanced Analysis Examples This example demonstrates advanced analysis techniques including correlations and [Gini coefficient](https://en.wikipedia.org/wiki/Gini_coefficient) of stake distribution. @@ -790,7 +778,7 @@ def main(): # Initialize metagraph for subnet 1 print("Initializing metagraph for subnet 1...") metagraph = Metagraph(netuid=1, network="finney", sync=True) - + # Get basic metrics stakes = metagraph.S ranks = metagraph.R @@ -815,7 +803,7 @@ def main(): # Network efficiency analysis (if weights are available) if not metagraph.lite and hasattr(metagraph, 'weights') and metagraph.weights.size > 0: weights = metagraph.W - + print("\n=== Network Efficiency Analysis ===") # Calculate network efficiency (average path length) non_zero_weights = weights[weights > 0] @@ -848,10 +836,9 @@ def main(): print(f"Could not calculate stake concentration metrics: {e}") if __name__ == "__main__": - main() + main() ``` - ### Async Usage This example demonstrates async metagraph usage: @@ -866,11 +853,11 @@ async def analyze_metagraph(): # Create async metagraph print("Creating async metagraph...") metagraph = await async_metagraph(netuid=1, network="finney", lite=False) - + # Perform analysis stakes = metagraph.S print(f"Total stake: {stakes.sum().item():.2f}") - + # Sync to latest block print("Syncing to latest block...") await metagraph.sync() @@ -882,7 +869,7 @@ async def main(): if __name__ == "__main__": # Run async analysis - asyncio.run(main()) + asyncio.run(main()) ``` ### Complete Neuron Information @@ -898,10 +885,10 @@ def main(): # Initialize metagraph for subnet 1 print("Initializing metagraph for subnet 1...") metagraph = Metagraph(netuid=1, network="finney", sync=True) - + # Get complete neuron information for first 5 neurons print("=== Complete Neuron Information (First 5 Neurons) ===") - + for i in range(min(5, metagraph.n.item())): neuron = metagraph.neurons[i] print(f"\nNeuron {i}:") @@ -924,19 +911,22 @@ def main(): print(f" ---") if __name__ == "__main__": - main() + main() ``` ## Source Code References ### Core Implementation + - **Metagraph Class**: [`bittensor/bittensor/core/metagraph.py`](https://github.com/opentensor/bittensor/blob/main/bittensor/core/metagraph.py) - **Chain Data**: [`bittensor/bittensor/core/chain_data/metagraph_info.py`](https://github.com/opentensor/bittensor/blob/main/bittensor/core/chain_data/metagraph_info.py) - **Subtensor RPC**: [`subtensor/pallets/subtensor/src/rpc_info/metagraph.rs`](https://github.com/opentensor/subtensor/blob/main/pallets/subtensor/src/rpc_info/metagraph.rs) ### Consensus Algorithm + - **Yuma Consensus**: [`subtensor/pallets/subtensor/src/epoch/run_epoch.rs`](https://github.com/opentensor/subtensor/blob/main/pallets/subtensor/src/epoch/run_epoch.rs) - **Mathematical Operations**: [`subtensor/pallets/subtensor/src/epoch/math.rs`](https://github.com/opentensor/subtensor/blob/main/pallets/subtensor/src/epoch/math.rs) ### Key Constants + - **TAO Stake Weight**: [`bittensor/bittensor/core/settings.py:7`](https://github.com/opentensor/bittensor/blob/main/bittensor/core/settings.py#L7) - `ROOT_TAO_STAKE_WEIGHT = 0.18` diff --git a/docs/subnets/subnet-creators-btcli-guide.md b/docs/subnets/subnet-creators-btcli-guide.md index 4a796cd44d..cab7f0bc64 100644 --- a/docs/subnets/subnet-creators-btcli-guide.md +++ b/docs/subnets/subnet-creators-btcli-guide.md @@ -4,23 +4,26 @@ title: "Subnet Creator's Guide to `BTCLI`" # Subnet Creator's Guide to `BTCLI` -Subnet creators define and manage new subnets, specifying parameters like burn cost, hyperparameters, or other chain-level configurations. This role inherently requires a **coldkey** with sufficient balance/permissions to create or update subnets. +Subnet creators define and manage new subnets, specifying parameters like burn cost, hyperparameters, or other chain-level configurations. This role inherently requires a **coldkey** with sufficient balance/permissions to create or update subnets. -This page discusses btcli stuff specifically for Subnet Creators. For general coverage of BTCLI and permissions stuff, see: [Bittensor CLI: Permissions Guide](../btcli-permissions) +This page discusses btcli stuff specifically for Subnet Creators. For general coverage of BTCLI and permissions stuff, see: [Bittensor CLI: Permissions Guide](../btcli/btcli-permissions) -See also: [Coldkey and Hotkey Workstation Security](../getting-started/coldkey-hotkey-security). +See also: [Coldkey and Hotkey Workstation Security](../keys/coldkey-hotkey-security). ## Subnet Creator Requirements -To create a new subnet, you need a coldkey with sufficient TAO to pay the burn cost for creating a subnet +To create a new subnet, you need a coldkey with sufficient TAO to pay the burn cost for creating a subnet To modify a subnet, you need the coldkey associated with ownership of the subnet ## `btcli` commands for subnet creators + ### monitor subnet + Permissionless, use `btcli subnet show` or `btcli view dashboard`. ### create subnet + Requires coldkey with sufficient TAO. `btcli subnet create` @@ -32,5 +35,4 @@ Configure your subnet's hyperparameters with `btcli sudo set`. Requires the cold If you suspect your coldkey may have been leaked, you can request to swap it out of your wallet, using an extrinsic blockchain transaction. This operation has a 5 day waiting period, during which your coldkey will be locked. The cost of this coldkey swap transaction is 0.1 TAO. -See [Rotate/Swap your Coldkey](../subnets/schedule-coldkey-swap) - +See [Rotate/Swap your Coldkey](../keys/schedule-coldkey-swap) diff --git a/docs/subnets/subnet-hyperparameters.md b/docs/subnets/subnet-hyperparameters.md index 2f9b2210e7..322533f931 100644 --- a/docs/subnets/subnet-hyperparameters.md +++ b/docs/subnets/subnet-hyperparameters.md @@ -171,7 +171,7 @@ The number of blocks for the stake to become inactive for the purpose of epoch i The moving average of bonds. The higher bonds yield to higher dividends for validators. -See [Yuma Consensus: bonding mechanics](../yuma-consensus#bonding-mechanics). +See [Yuma Consensus: bonding mechanics](../learn/yuma-consensus#bonding-mechanics). ### BondsPenalty @@ -190,7 +190,7 @@ See [Yuma Consensus: bonding mechanics](../yuma-consensus#bonding-mechanics). **Description**: The magnitude of the penalty subtracted from weights for exceeding consensus, for a specific subnet. -See [Yuma Consensus: Penalizing out-of-consensus bonds](../yuma-consensus#penalizing-out-of-consensus-bonds). +See [Yuma Consensus: Penalizing out-of-consensus bonds](../learn/yuma-consensus#penalizing-out-of-consensus-bonds). ### BondsResetEnabled @@ -226,7 +226,7 @@ Determines whether or not bonds are reset-enabled. How long, in blocks, the consensus weights for a subnet remain time-lock encrypted, preventing weight-copying. -See [Commit Reveal](./commit-reveal) +See [Commit Reveal](../concepts/commit-reveal) ### CommitRevealWeightsEnabled @@ -242,7 +242,7 @@ See [Commit Reveal](./commit-reveal) **Description**: -Enables [Commit Reveal](./commit-reveal) +Enables [Commit Reveal](../concepts/commit-reveal) ### Difficulty @@ -294,7 +294,7 @@ The number of blocks after registration when a miner is protected from deregistr The consensus majority ratio: The weights set by validators who have lower normalized stake than Kappa are not used in calculating consensus, which affects ranks, which affect incentives. -the consensus threshold for bond-clipping during [Yuma Consensus](../yuma-consensus) +the consensus threshold for bond-clipping during [Yuma Consensus](../learn/yuma-consensus) ### LiquidAlphaEnabled @@ -310,7 +310,7 @@ the consensus threshold for bond-clipping during [Yuma Consensus](../yuma-consen **Description**: -Enables the [liquid alpha ](./consensus-based-weights) feature. +Enables the [liquid alpha ](../concepts/consensus-based-weights) feature. ### MaxAllowedValidators @@ -567,7 +567,7 @@ Maximum number of neuron registrations allowed per interval. Interval is `Adjust **Description**: Length of subnet tempo in blocks. -See [Emission](../emissions.md) +See [Emission](../learn/emissions.md) ### ToggleTransfer @@ -671,7 +671,7 @@ The following variables are global and/or can only be configured with `root` per The duration in blocks of the waiting period before a coldkey swap. -See [Rotate/Swap your Coldkey](./schedule-coldkey-swap) +See [Rotate/Swap your Coldkey](../keys/schedule-coldkey-swap) diff --git a/docs/subnets/understanding-subnets.md b/docs/subnets/understanding-subnets.md index c643eda022..6d1f1cb357 100644 --- a/docs/subnets/understanding-subnets.md +++ b/docs/subnets/understanding-subnets.md @@ -64,8 +64,6 @@ Run the `btcli subnet list` command with the Dynamic TAO-enabled `btcli` to view ... ``` -See: [Using Dynamic TAO](./index.md#using-dynamic-tao) - ## Price/rate of alpha tokens ### Ideal price @@ -107,7 +105,7 @@ Each block: - the subnet's alpha reserve (increasing available liquidity) - alpha outstanding (incentives for miners, validators, and subnet creators) -See [Emissions](../emissions.md). +See [Emissions](../learn/emissions.md). ## Decentralized evaluation of subnets @@ -119,7 +117,7 @@ In Dynamic TAO, the relative weight is determined organically according to the e In Dynamic TAO, Subnet Zero—or _Root Subnet_—is a special subnet. It is the only subnet that does not have its own $\alpha$ currency. No miners can register on subnet zero, and no validation work is performed. However validators can register, and $\tau$-holders can stake to those validators, as with any other subnet. This offers a mechanism for $\tau$-holders to stake $\tau$ into validators in a subnet-agnostic way. This works because the weight of a validator in a subnet includes both their share of that subnet's $\alpha$ and their share of TAO staked into the root subnet. -Over time, the emissions generated by TAO staked into Subnet Zero will decrease, relative to stake held in the alpha currency of active subnets. See [Note on evolution of Bittensor token economy](../emissions.md#note-on-evolution-of-bittensor-token-economy). +Over time, the emissions generated by TAO staked into Subnet Zero will decrease, relative to stake held in the alpha currency of active subnets. See [Note on evolution of Bittensor token economy](../learn/emissions.md#note-on-evolution-of-bittensor-token-economy). ## Validator stake weight diff --git a/docs/subnets/working-with-subnets.md b/docs/subnets/working-with-subnets.md index 761a6114b8..8aa8dbfee6 100644 --- a/docs/subnets/working-with-subnets.md +++ b/docs/subnets/working-with-subnets.md @@ -4,10 +4,10 @@ title: "Working with Subnets" # Working with Subnets -Subnets are composed of a discrete number of UIDs. The subnet validators and subnet miners are associated with these UIDs. Each UID in the subnet belongs to a unique [hotkey](../getting-started/wallets.md#coldkey-and-hotkey) which in turn is connected to a unique **coldkey** which was used during registration. The Yuma Consensus runs on these UIDs. This section presents a few examples showing how to work with subnets. +Subnets are composed of a discrete number of UIDs. The subnet validators and subnet miners are associated with these UIDs. Each UID in the subnet belongs to a unique [hotkey](../keys/wallets.md#what-are-wallets-and-keys) which in turn is connected to a unique **coldkey** which was used during registration. The Yuma Consensus runs on these UIDs. This section presents a few examples showing how to work with subnets. -Transfer is transfer from cold to cold -Registration takes tao from cold +Transfer is transfer from cold to cold +Registration takes tao from cold Hotkey Tao movement is only stake add and remove and it’s loaded by emissions while mining Root delegation/undelegation is hotkey Tao movement to a strangers hotkey and it’s loaded by the activities of the strangers emission validation activities @@ -15,7 +15,7 @@ Root delegation/undelegation is hotkey Tao movement to a strangers hotkey and it Show all currently running subnets on Bittensor: -```bash +```bash btcli subnets list ``` @@ -41,7 +41,6 @@ assert subnet.uids.tolist() == [ 0, 1, 2, ... 1022, 1023 ] ## Extracting UID information - ```python import bittensor as bt subnet = bt.metagraph( netuid = 1 ) @@ -51,7 +50,7 @@ print ('uid', uid, ' owned by hotkey:', subnet.hotkeys[ uid ], 'associated with ## Viewing parameters -The below code prints stake `S` on the subnet and the weights `W` set by the subnet validators in the subnet. +The below code prints stake `S` on the subnet and the weights `W` set by the subnet validators in the subnet. ```python numbered dark import bittensor as bt @@ -62,7 +61,7 @@ print ('subnet 1 validator weights', subnet.W ) ## Viewing dividends -The below code prints the subnet validator dividends, `D`. +The below code prints the subnet validator dividends, `D`. ```python import bittensor as bt diff --git a/docs/subtensor-nodes/subtensor-rate-limits.md b/docs/subtensor-nodes/subtensor-rate-limits.md index e80734e3fb..c662b9502d 100644 --- a/docs/subtensor-nodes/subtensor-rate-limits.md +++ b/docs/subtensor-nodes/subtensor-rate-limits.md @@ -9,4 +9,4 @@ We strongly encourage you to run your own local lite node. If you must query an - Any OTF-provided lite node will rate limit the requests to one request per second, per IP address. Note that this rate limit may change dynamically based on the network or application requirements. - A request can be either WS/WSS or HTTP/HTTPS. - If you exceed the rate limit, you will receive 429 error code. You will then have to wait until the rate limit window has expired. -- You can avoid OTF-lite node rate limits by running your own local lite node. You can run a lite node either [Using Docker](./using-docker.md#run-a-lite-node-on-mainchain) or [Using Source](./using-source.md#lite-node-on-mainchain). +- You can avoid OTF-lite node rate limits by running your own local lite node. You can run a lite node either [Using Docker](./using-docker.md#using-lite-nodes) or [Using Source](./using-source#lite-node-on-mainchain). diff --git a/docs/subtensor-nodes/using-docker.md b/docs/subtensor-nodes/using-docker.md index d3f50a3086..21f8a49df5 100644 --- a/docs/subtensor-nodes/using-docker.md +++ b/docs/subtensor-nodes/using-docker.md @@ -15,8 +15,6 @@ To run a subtensor node with Docker, follow the below steps. We have not tested subtensor node installation scripts on any cloud service. In addition, if you are using Runpod cloud service, then note that this service is already [containerized](https://docs.runpod.io/pods/overview). Hence, the only option available to you for Runpod is to install a subtensor node by [compiling from source](using-source.md). **Note that we have not tested any subtensor installation steps on Runpod.** ::: -If you are already running a subtensor node using Docker, then go directly to [Step 5 Prepare to Run ](#step-5-prepare-to-run). The below steps 1 through 4 are for first time users only. - ## Prerequisites Before you begin, make sure you have installed the following on your machine: diff --git a/docs/subnets/child-hotkeys.md b/docs/validators/child-hotkeys.md similarity index 91% rename from docs/subnets/child-hotkeys.md rename to docs/validators/child-hotkeys.md index 9f2bf7d4bb..3df8686e0f 100644 --- a/docs/subnets/child-hotkeys.md +++ b/docs/validators/child-hotkeys.md @@ -7,12 +7,10 @@ import useBaseUrl from '@docusaurus/useBaseUrl'; # Child Hotkeys -This guide describes the **child hotkeys** feature and how to use it. With the child hotkeys, a subnet validator is no longer required to use the same delegate hotkey for every subnet they validate in. The subnet validator can use a separate **child hotkey** per subnet. The subnet validator does this by re-delegating a portion of their stake from their delegate hotkey to this separate child hotkey on a subnet. The originating delegate hotkey is called the **parent hotkey**. +This guide describes the **child hotkeys** feature and how to use it. With the child hotkeys, a subnet validator is no longer required to use the same delegate hotkey for every subnet they validate in. The subnet validator can use a separate **child hotkey** per subnet. The subnet validator does this by re-delegating a portion of their stake from their delegate hotkey to this separate child hotkey on a subnet. The originating delegate hotkey is called the **parent hotkey**. The owner of this child hotkey would then validate in the subnet on behalf of the parent hotkey. The child hotkey would receive a percentage `take` from the resulting dividends. - -
-See the above diagram. Without the child hotkeys, a subnet validator's delegate hotkey would have to sign all the validation operations in all the subnets. This exposes the delegate hotkey in all the subnets. An attacker can get hold of the delegate hotkey from any one subnet in order to take over the validation operations with this hotkey, thereby crippling this subnet validator in all their subnets across the entire Bittensor network. +See the above diagram. Without the child hotkeys, a subnet validator's delegate hotkey would have to sign all the validation operations in all the subnets. This exposes the delegate hotkey in all the subnets. An attacker can get hold of the delegate hotkey from any one subnet in order to take over the validation operations with this hotkey, thereby crippling this subnet validator in all their subnets across the entire Bittensor network.
- See the above diagram. With the child hotkeys, if an attacker steals a child hotkey, then only those subnets are at risk where this child hotkey is used as the delegate hotkey. -## Benefits of child hotkeys +## Benefits of child hotkeys - **Security for parent hotkeys**: Re-delegating stake to multiple child hotkeys enhances the security of the parent hotkey. Each child hotkey can validate on a specific subnet using a different machine. The child hotkey would sign the validation operations on behalf of the parent hotkey: There is no need to use the parent hotkey on any of these subnets. As a consequence, the exposure of the parent hotkey can be minimized. The parent hotkey can even be moved to a secure location until it is needed, for example, to revoke a child hotkey. - **Validators can easily scale up**: As Bittensor scales up towards hundreds of subnets, it is not practical for a single delegate to validate in every single subnet. With child hotkeys, a validator can easily make this feasible by re-delegating and offloading the validating operations to multiple child hotkeys. - **Increased bandwidth for a subnet owner**: A validator can also re-delegate to a subnet owner's hotkey. The subnet owner would then do the validation work on the subnet, in exchange for a percentage `take` from the resulting dividends. A subnet owner can increase their access bandwidth into their own subnet in this way. - A child hotkey and a parent hotkey need not be owned by the same entity. -- A validator can re-delegate to a hotkey of any other validator on any subnet. After re-delegation, the hotkey that is the source of the stake is called **parent hotkey** and the hotkey that receives this re-delegated stake is called **child hotkey**. +- A validator can re-delegate to a hotkey of any other validator on any subnet. After re-delegation, the hotkey that is the source of the stake is called **parent hotkey** and the hotkey that receives this re-delegated stake is called **child hotkey**. :::tip "Child hotkey" and "parent hotkey" are terms of convenience The terms "child hotkey" and "parent hotkey" are only terms of convenience. There is nothing inherently different about a "child hotkey" that separates it from a "parent hotkey". Neither have any special attributes compared to a normal hotkey. ::: @@ -59,25 +56,26 @@ See the above diagram. With the child hotkeys, if an attacker steals a child hot The child hotkey features are as follows: -- A hotkey must be registered on a subnet before it can be used as a parent hotkey. The hotkey can be registered on any subnet. +- A hotkey must be registered on a subnet before it can be used as a parent hotkey. The hotkey can be registered on any subnet. - A parent hotkey can have multiple child hotkeys. Similarly, a child hotkey can have more than one parent hotkey. - A child hotkey can exist as a registered hotkey in multiple netuids simultaneously. -- **IMPORTANT**: For a given `netuid`, say, `netuid 5`, a single parent hotkey can have at most five (`5`) child hotkeys. Moreover, the same parent hotkey on a different `netuid 11` can have another set of `5` child hotkeys. Alternately, on this `netuid 11` the same parent hotkey can also have the same (`5`) child hotkeys that are in the netuid `5`. -- While setting the child hotkeys, the proportion field can have proportions that add to less than `1.0`. The proportion that was not assigned to the child hotkeys will remain with the parent hotkey. However, a proportion cannot be zero. A `0` proportion value will result in an error. Furthermore, in a given subnet, the sum of all proportions must not exceed `1.0`. +- **IMPORTANT**: For a given `netuid`, say, `netuid 5`, a single parent hotkey can have at most five (`5`) child hotkeys. Moreover, the same parent hotkey on a different `netuid 11` can have another set of `5` child hotkeys. Alternately, on this `netuid 11` the same parent hotkey can also have the same (`5`) child hotkeys that are in the netuid `5`. +- While setting the child hotkeys, the proportion field can have proportions that add to less than `1.0`. The proportion that was not assigned to the child hotkeys will remain with the parent hotkey. However, a proportion cannot be zero. A `0` proportion value will result in an error. Furthermore, in a given subnet, the sum of all proportions must not exceed `1.0`. ## Rate limits The following rate limits apply for child hotkeys: - A child hotkey's take rate can only be adjusted once per 30 days. -- One successful execution of `set_children` or `revoke_children` is allowed for every 720 blocks. +- One successful execution of `set_children` or `revoke_children` is allowed for every 720 blocks. ## Minimum stake The minimum stake you can redelegate to a child hotkey is as follows: + - **Testnet**: 100 testnet TAO. - **Mainnet**: 1000 TAO. - + --- ## Installing @@ -100,20 +98,21 @@ btcli stake set_children --netuid --children \ @@ -216,17 +215,18 @@ or ```bash btcli stake revoke_children ``` + and follow the prompts. ## Setting child hotkey take -This command sets the take percentage of the child hotkey for a given `netuid`. The `take` can be between `0` (0%) and `0.18` (18%). +This command sets the take percentage of the child hotkey for a given `netuid`. The `take` can be between `0` (0%) and `0.18` (18%). -A child hotkey's `take` is subnet-specific, i.e., a child hotkey can have one `take` in one `netuid` and a different `take` in another `netuid`. +A child hotkey's `take` is subnet-specific, i.e., a child hotkey can have one `take` in one `netuid` and a different `take` in another `netuid`. -The child hotkey take rate is an attribute of the child hotkey and this take rate applies to all the parent hotkeys for which this hotkey is the child hotkey. +The child hotkey take rate is an attribute of the child hotkey and this take rate applies to all the parent hotkeys for which this hotkey is the child hotkey. -The child hotkey can also set its delegate take separately from the child hotkey take. That is, a child hotkey can carry two separate take rates: the child hotkey take rate and the delegate take rate. For the delegate take rate, see [Set delegate take](../btcli.md#set-delegate-take). +The child hotkey can also set its delegate take separately from the child hotkey take. That is, a child hotkey can carry two separate take rates: the child hotkey take rate and the delegate take rate. For the delegate take rate, see [Set delegate take](../btcli/btcli.md#btcli-sudo-set-take). ### Usage @@ -242,7 +242,7 @@ btcli stake set_childkey_take \ - `--hotkey`: SS58. A single SS58 of the child hotkey. Note that this `--hotkey` parameter expects child hotkey whereas the `--hotkey` parameter of the [Setting a child hotkey](#parameters) expects parent hotkey. - `--take`: Floating. A value between `0` (0%) and `0.18` (18%). Default value is `0`. -- `--netuid`: Integer. The `netuid` in which this child hotkey's `take` is applicable. Note that a child hotkey's `take` is subnet-specific, i.e., a child hotkey can have one `take` in one `netuid` and a different `take` in another `netuid`. +- `--netuid`: Integer. The `netuid` in which this child hotkey's `take` is applicable. Note that a child hotkey's `take` is subnet-specific, i.e., a child hotkey can have one `take` in one `netuid` and a different `take` in another `netuid`. ### Example @@ -267,7 +267,6 @@ btcli stake get_childkey_take \ --wallet.name ``` - ### Example ```bash diff --git a/docs/validators/index.md b/docs/validators/index.md index 1e7a4e27e2..20490592cb 100644 --- a/docs/validators/index.md +++ b/docs/validators/index.md @@ -7,7 +7,7 @@ import useBaseUrl from '@docusaurus/useBaseUrl'; # Validating in Bittensor -All validating in Bittensor occurs within a subnet. Each subnet independently produces the digital commodities that are its purpose, with each subnet creator defining a different _incentive mechanism_ for validators to use in judging miners' work. The validator's work is to apply this incentive mechanism to miners, using it to score their performance, and then to submit these weights to the Bittensor blockchain.  The validator scores of miners' performance determine the proportion of the subnet's emissions allocated to each miner, according to the Yuma Consensus algorithm. See [Emissions](../emissions.md). +All validating in Bittensor occurs within a subnet. Each subnet independently produces the digital commodities that are its purpose, with each subnet creator defining a different _incentive mechanism_ for validators to use in judging miners' work. The validator's work is to apply this incentive mechanism to miners, using it to score their performance, and then to submit these weights to the Bittensor blockchain.  The validator scores of miners' performance determine the proportion of the subnet's emissions allocated to each miner, according to the Yuma Consensus algorithm. See [Emissions](../learn/emissions.md). Browse the subnets and explore links to their code repositories on [TAO.app' subnets listings](https://tao.app). @@ -222,7 +222,7 @@ After providing your wallet name at the prompt, you will see output like: ### Meaning of ACTIVE -In the above table, the `ACTIVE` row applies only to UIDs that are subnet validators. It shows whether the UID is actively setting weights within the [`activity_cutoff`](../subnets/subnet-hyperparameters#activity_cutoff) window. If the UID has not set weights on the blockchain for the `activity_cutoff` duration, then the Yuma Consensus will consider this subnet validator offline, i.e., turned off (`False`). +In the above table, the `ACTIVE` row applies only to UIDs that are subnet validators. It shows whether the UID is actively setting weights within the [`activity_cutoff`](../subnets/subnet-hyperparameters#activitycutoff) window. If the UID has not set weights on the blockchain for the `activity_cutoff` duration, then the Yuma Consensus will consider this subnet validator offline, i.e., turned off (`False`). ## Checking the registration status diff --git a/docs/validators/validators-btcli-guide.md b/docs/validators/validators-btcli-guide.md index 98e6ec4f8a..c100c9207c 100644 --- a/docs/validators/validators-btcli-guide.md +++ b/docs/validators/validators-btcli-guide.md @@ -7,30 +7,32 @@ title: "Validator's Guide to `BTCLI`" Validators evaluate miner performance, and post their evaluations to the blockchain. This page discusses considerations specific to validators when using `btcli`. :::note Transaction Fees -Certain validator operations incur transaction fees. See [Transaction Fees in Bittensor](../fees.md) for details. +Certain validator operations incur transaction fees. See [Transaction Fees in Bittensor](../learn/fees.md) for details. ::: -For general coverage of `btcli` permissions and requirements, see: [Bittensor CLI: Permissions Guide](../btcli-permissions) +For general coverage of `btcli` permissions and requirements, see: [Bittensor CLI: Permissions Guide](../btcli/btcli-permissions) -See also: [Coldkey and Hotkey Workstation Security](../getting-started/coldkey-hotkey-security). +See also: [Coldkey and Hotkey Workstation Security](../keys/coldkey-hotkey-security). :::tip tips It is highly recommended to use a unique hotkey per subnet. -Note that hotkeys are not encrypted by default, but can be password [optionally encrypted](../working-with-keys#encrypting-the-hotkey). +Note that hotkeys are not encrypted by default, but can be password [optionally encrypted](../keys/working-with-keys#encrypting-the-hotkey). ::: ## Requirements for validator functions ### Unpermissioned workstation (public keys only): + - Check balances - Monitor emissions and other metagraph info - Check subnet alpha prices across Bittensor ### Coldkey workstation: + - Create/import coldkey - Manage TAO and alpha stake -- Create and register a hotkey on a secure coldkey workstation then transfer the hotkey file or mnemonic to the validator workstation: `btcli wallet new-hotkey` , `btcli wallet regen-hotkey` +- Create and register a hotkey on a secure coldkey workstation then transfer the hotkey file or mnemonic to the validator workstation: `btcli wallet new-hotkey` , `btcli wallet regen-hotkey` - Transfer/rotate TAO and alpha stake in case of key compromise - Rotate hotkeys in case of compromise - Register a hotkey on a subnet with `btcli subnets register`, `btcli subnets pow-register` @@ -40,9 +42,9 @@ Note that hotkeys are not encrypted by default, but can be password [optionally These require a hotkey with an active validator permit on the subnet. Run in a live environment (the validator node), which is a hotkey workstation. -- `btcli weights reveal`, `btcli weights commit` -- `btcli wt reveal`, `btcli wt commit` -- `btcli weight reveal`, `btcli weight commit` +- `btcli weights reveal`, `btcli weights commit` +- `btcli wt reveal`, `btcli wt commit` +- `btcli weight reveal`, `btcli weight commit` ### Weight-setting requirements @@ -52,5 +54,4 @@ To set weights, a validator must meet several requirements. See [Requirements fo If you suspect your coldkey may have been leaked, you can request to swap it out of your wallet, using an extrinsic blockchain transaction. This operation has a 5 day waiting period, during which your coldkey will be locked. The cost of this coldkey swap transaction is 0.1 TAO. -See [Rotate/Swap your Coldkey](../subnets/schedule-coldkey-swap) - +See [Rotate/Swap your Coldkey](../keys/schedule-coldkey-swap) diff --git a/docusaurus.config.js b/docusaurus.config.js index dfc319b768..3294e41898 100644 --- a/docusaurus.config.js +++ b/docusaurus.config.js @@ -18,6 +18,7 @@ const config = { title: "Bittensor", tagline: "Developer Documentation", favicon: "img/favicon.ico", + trailingSlash: false, // Set the production url of your site here url: "https://docs.learnbittensor.org", // Set the // pathname under which your site is served @@ -98,7 +99,7 @@ const config = { }, { from: "/recycled-tao", - to: "/glossary", + to: "/resources/glossary", }, { to: "/subnets/walkthrough-prompting", @@ -113,15 +114,15 @@ const config = { from: "/subnet-pages", }, { - to: "/subnets/schedule-coldkey-swap", + to: "/keys/schedule-coldkey-swap", from: "/schedule-key-swap", }, { - to: "/subnets/schedule-coldkey-swap", + to: "/keys/schedule-coldkey-swap", from: "/subnets/schedule-key-swap", }, { - to: "/bt-api-ref", + to: "/sdk/bt-api-ref", from: "/reference/bittensor-api-ref", }, { @@ -210,7 +211,7 @@ const config = { { position: "left", label: "Bittensor SDK Reference", - to: "bt-api-ref", + to: "sdk/bt-api-ref", }, { position: "left", @@ -229,7 +230,7 @@ const config = { className: "custom_algolia", }, { - to: "bittensor-rel-notes", + to: "resources/bittensor-rel-notes", label: "Releases", position: "left", }, diff --git a/sidebars.js b/sidebars.js index a52a82341b..b4d27ef213 100644 --- a/sidebars.js +++ b/sidebars.js @@ -23,7 +23,7 @@ const sidebars = { "index", { type: "doc", - id: "bittensor-rel-notes", + id: "resources/bittensor-rel-notes", label: "Releases", }, "btcli/btcli-playground", @@ -35,16 +35,16 @@ const sidebars = { collapsed: true, items: [ "learn/introduction", - "questions-and-answers", + "resources/questions-and-answers", "subnets/understanding-subnets", "learn/neurons", "learn/anatomy-of-incentive-mechanism", - "emissions", + "learn/emissions", "learn/ema", - "yuma-consensus", - "subnets/yc3-blog", - "fees", - "community-links", + "learn/yuma-consensus", + "learn/yc3-blog", + "learn/yuma3-migration-guide", + "learn/fees", ], }, { @@ -55,7 +55,7 @@ const sidebars = { link: { type: "doc", id: "staking-and-delegation/delegation" }, items: [ "staking-and-delegation/delegation", - "staking-and-delegation/stakers-btcli-guide", + "staking-and-delegation/stakers-btcli-guide", "staking-and-delegation/managing-stake-btcli", "staking-and-delegation/managing-stake-sdk", "learn/price-protection", @@ -81,7 +81,7 @@ const sidebars = { link: { type: "doc", id: "validators/index" }, items: [ "validators/index", - "subnets/child-hotkeys", + "validators/child-hotkeys", "validators/validators-btcli-guide", ], }, @@ -109,7 +109,6 @@ const sidebars = { "subnets/walkthrough-prompting", "tutorials/basic-subnet-tutorials", "tutorials/ocr-subnet-tutorial", - "subnets/yuma3-migration-guide", ], }, { @@ -121,8 +120,8 @@ const sidebars = { items: [ "getting-started/install-btcli", "btcli/btcli-playground", - "btcli-permissions", - "btcli", + "btcli/btcli-permissions", + "btcli/btcli", "staking-and-delegation/managing-stake-btcli", ], }, @@ -134,10 +133,10 @@ const sidebars = { items: [ "getting-started/installation", "sdk/env-vars", - "bt-api-ref", + "sdk/bt-api-ref", "sdk/subtensor-api", "getting-started/install-wallet-sdk", - "migration_guide", + "sdk/migration-guide", "subnets/asyncio", "sdk/managing-subtensor-connections", ], @@ -149,26 +148,26 @@ const sidebars = { collapsible: true, collapsed: true, items: [ - "getting-started/wallets", + "keys/wallets", "keys/handle-seed-phrase", - "getting-started/coldkey-hotkey-security", - "working-with-keys", + "keys/coldkey-hotkey-security", + "keys/working-with-keys", "keys/multisig", - "subnets/schedule-coldkey-swap", + "keys/schedule-coldkey-swap", ], }, { type: "category", label: "Tools and Special Features", - link: { type: "doc", id: "tools" }, + link: { type: "doc", id: "concepts/tools" }, collapsible: true, collapsed: true, items: [ - "bittensor-networks", - "subnets/commit-reveal", - "subnets/consensus-based-weights", - "subnets/bt-logging-levels", - "utilities", + "concepts/bittensor-networks", + "concepts/commit-reveal", + "concepts/consensus-based-weights", + "concepts/bt-logging-levels", + "resources/utilities", ], }, @@ -250,7 +249,11 @@ const sidebars = { label: "Governance", collapsible: true, collapsed: true, - items: ["governance", "senate", "governance/senators-btcli-guide"], + items: [ + "governance/governance", + "governance/senate", + "governance/senators-btcli-guide", + ], }, { type: "category", @@ -271,11 +274,12 @@ const sidebars = { "errors/index", "errors/custom", "errors/subtensor", - "errors-and-troubleshooting", + "errors/troubleshooting", ], }, - "media-assets", - "glossary", + "resources/glossary", + "resources/community-links", + "resources/media-assets", ], };