Merge pull request #39 from latent-to/doc-updates

Local development docs

Author: chideraao

docs/btcli.md

@@ -686,7 +686,7 @@ btcli wallet transfer [OPTIONS]
 | `--destination`, `--dest`, `-d`                                             | TEXT    | Destination address (ss58) of the wallet (coldkey).                                  |
 | `--amount`, `-a`                                                            | FLOAT   | Amount (in TAO) to transfer.                                                         |
 | `--all`                                                                     |         | Transfer all available balance.                                                      |
-| `--all`, `-a`                                                               |         | Whether to display the balances for all the wallets.                                 |
+| `--all`                                                                     |         | Whether to display the balances for all the wallets.                                 |
 | `--period`, `-era`                                                          | INTEGER | Length (in blocks) for which the transaction should be valid.                        |
 | `--wallet-name`, `--name`, `--wallet_name`, `--wallet.name`                 | TEXT    | Name of the wallet.                                                                  |
 | `-p`, `--wallet-path`, `--wallet_path`, `--wallet.path`                     | TEXT    | Path where the wallets are located. For example: `/Users/btuser/.bittensor/wallets`. |

docs/glossary.md

@@ -44,6 +44,12 @@ A unit of data in the Bittensor blockchain, containing a collection of transacti
 
 **See also:** [Subtensor API](./sdk/subtensor-api.md)
 
+### Burn cost
+
+This refers to the required amount of TAO to be recycled when creating a new subnet, i.e., cost of registering a new subnet.
+
+**See also:** [Burn cost](./subnets/create-a-subnet.md#burn-cost)
+
 ## C
 
 ### Coldkey
@@ -465,6 +471,7 @@ Where:
 - [`bittensor/bittensor/core/metagraph.py:325-331`](https://github.com/opentensor/bittensor/blob/main/bittensor/core/metagraph.py#L325-331)
 - [`subtensor/pallets/subtensor/src/epoch/run_epoch.rs:605`](https://github.com/opentensor/subtensor/blob/main/pallets/subtensor/src/epoch/run_epoch.rs#L605)
 
+
 ### Recycling and burning
 
 Tokens (TAO and subnet-specific alpha) can be 'removed from circulation', meaning these tokens exist in neither wallet nor liquidity pool, and cannot be transacted. This can happen in two ways:
@@ -473,15 +480,18 @@ Tokens (TAO and subnet-specific alpha) can be 'removed from circulation', meanin
 
 - In contrast, when tokens are **burned** they exist in no wallet and no pool and can no longer be transacted; however they are still included in the record of token issuance, so they will not be re-emitted, and in effect will forever remain as a quantity of *missing* tokens, a difference between issuance and the effective quantity in circulation.
 
+
 #### Recycling
 
 Tokens are recycled in several cases in Bittensor operations:
 
+
 - **All transaction fees are recycled**: When transaction fees are collected, they are deducted from `TotalIssuance`, effectively recycling them back into the system for future emission. See [Transaction Fees in Bittensor](./fees)
 - **Subnet Creation fees**: When a new subnet is created, the cost is recycled, except for one TAO, which is used to initialize the subnet's TAO liquidity pool.
 - **Neuron Registration fees**: When a user registers a hotkey on a subnet to participate as a miner or validator, they are charged a registration fee in TAO. Alpha tokens worth the current swap value of the fee are taken from the subnet's alpha liquidity pool and recycled.
 - **Extrinsic transaction**: Users can manually recycle alpha tokens using the `recycle_alpha` extrinsic, which reduces both the user's stake and the subnet's `SubnetAlphaOut` tracker.
 
+
 #### Burning
 
 Subnet-specific alpha tokens are burned in several contexts:
@@ -503,6 +513,7 @@ The process of registering keys with a subnet and purchasing a UID slot.
 
 **See also:** [Subnet Miners](./miners/), [Subnet Validators](./validators/), [Working with Subnets](./subnets/working-with-subnets.md)
 
+
 ### Root Subnet/Subnet Zero
 
 Subnet Zero a.k.a. the root subnet is a special subnet. 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 staked TAO in Subnet Zero.
@@ -744,7 +755,6 @@ The relationship between these metrics creates a feedback loop: consensus determ
 A position occupied by a subnet miner or subnet validator within a subnet, identified by a unique UID. The UID is assigned to a hotkey when it is registered in a subnet, allowing the hotkey to participate as a subnet validator or subnet miner.
 
 **See also:** [Subnet Miners](./miners/), [Subnet Validators](./validators/), [Working with Subnets](./subnets/working-with-subnets.md)
-
 ### Unstaking
 
 The process of detaching TAO from a validator hotkey.
@@ -871,6 +881,7 @@ Where $\alpha$ is the EMA smoothing factor (see [Exponential Moving Average](#ex
 - Bonds are stored as sparse matrices in blockchain state
 
 **Bond Decay:**
+
 - Bonds decay over time using [EMA](#exponential-moving-average-ema) with the `bonds_moving_avg` parameter
 - Higher decay rates (larger α) make bonds more responsive to recent performance
 - Lower decay rates (smaller α) allow bonds to persist longer

docs/learn/ema.md

@@ -1,19 +1,19 @@
 ---
 title: "Exponential Moving Averages (EMAs)in Bittensor"
 ---
+
 # Exponential Moving Averages (EMAs) in Bittensor
 
-The exponential moving average (EMA) is a [mathematical technique](https://en.wikipedia.org/wiki/Exponential_smoothing) for tracking a dynamic quantity, such as a token price, over time. Specifically, EMA is a weighted moving average that exponentially decreases the weight of older data point. This extracts a signal reflecting where the value has spent *most* of its time *most recently*, stabilizing or 'smoothing' the constant noise of rapid, largely random fluctuations.
+The exponential moving average (EMA) is a [mathematical technique](https://en.wikipedia.org/wiki/Exponential_smoothing) for tracking a dynamic quantity, such as a token price, over time. Specifically, EMA is a weighted moving average that exponentially decreases the weight of older data point. This extracts a signal reflecting where the value has spent _most_ of its time _most recently_, stabilizing or 'smoothing' the constant noise of rapid, largely random fluctuations.
 
 Bittensor uses EMAs to smooth two critical dynamical values during the emission process:
 
 - Emissions to each subnet are determined by an EMA-smoothed representation of subnet price each tempo. This protects emissions from price volatility or intentional manipulation.
 
-- Emissions to participants of each subnet are determined by EMAs of instantaneous validator-miner bond-strengths. This plays an important roll in ensuring that validators and miners are fairly rewarded for innovation, as measured by eventual consensus (rather than immediate consensus) about miner weights.
+- Emissions to participants of each subnet are determined by EMAs of instantaneous validator-miner bond-strengths. This plays an important role in ensuring that validators and miners are fairly rewarded for innovation, as measured by eventual consensus (rather than immediate consensus) about miner weights.
 
 ## Mathematical definition
 
-
 The EMA of a changing value at a given time is determined by weighted average of the current value and the EMA at the last time step. The parameter factor, or 'smoothing factor' is called $\alpha$.
 
 $$
@@ -30,14 +30,12 @@ The alpha parameter controls how quickly the EMA responds to changes:
 Note that this alpha parameter is distinct from and unrelated to the usage of 'alpha' to refer to subnet-specific currencies.
 :::
 
-
-
 ## Subnet Price Emission Smoothing
 
 This use of EMA smoothing protects the network's economic model from price manipulation by making emissions extremely slow to respond to price changes.
 
 **How It Works**:
-The price EMA uses a sophisticated dynamic alpha calculation to ensures that new subnets have even slower price adaptation than mature ones.
+The price EMA uses a sophisticated dynamic alpha calculation to ensure that new subnets have even slower price adaptation than mature ones.
 
 $$
 \alpha = \frac{ \mathrm{base\_alpha} \times  \mathrm{blocks\_since\_start}}{\mathrm{blocks\_since\_start} + \mathrm{halving\_blocks}}
@@ -48,6 +46,7 @@ The value for **base_alpha** in the above is currently ~0.0003 for Bittensor mai
 :::
 
 See:
+
 - [Yuma Consensus/Coinbase emission source code](https://github.com/opentensor/subtensor/blob/main/pallets/subtensor/src/epoch/run_epoch.rs#L223)
 - [Default alpha value for subnet price smoothing](https://github.com/opentensor/subtensor/blob/main/pallets/subtensor/src/lib.rs#L828)
 
@@ -56,20 +55,24 @@ See:
 This smoothing function ensures that relationships between validators and miners evolve gradually, preventing sudden manipulation while rewarding validators who discover promising miners early.
 
 ### Basic Bond EMA (Liquid Alpha Disabled)
+
 **Default Mode**: Single $\alpha$ for all validator-miner pairs
+
 - **Default $\alpha$**: ~0.1 (10%)
 - **Response Time**: 7-22 blocks for significant changes (~1-4 minutes)
 - **Formula**
-	The EMA of the bond (BondEMA)of a validator i for a miner j, at time t, is the $\alpha$-weighted average of the instantaneous bond and the previous timestep's BondEMA:	
-	$$
-	BondEMA_{ij}^{(t)} = \alpha \times \, InstantBond_{ij} + (1-\alpha)\,BondEMA_{ij}^{(t-1)}
-	$$
+  The EMA of the bond (BondEMA)of a validator i for a miner j, at time t, is the $\alpha$-weighted average of the instantaneous bond and the previous timestep's BondEMA:
+  $$
+  BondEMA_{ij}^{(t)} = \alpha \times \, InstantBond_{ij} + (1-\alpha)\,BondEMA_{ij}^{(t-1)}
+  $$
 
 ### Advanced Bond EMA (Liquid Alpha Enabled)
+
 **Consensus-Based Mode**: Dynamic $\alpha$ per validator-miner pair based on consensus alignment
-- **$\alpha$ Range**: Dynamic between $\alpha$_low and $\alpha$_high (default: 0.7 to 0.9)
-- **Sigmoid Steepness**: Controls transition rate between $\alpha$_low and $\alpha$_high (default: 1000)
+
+- **$\alpha$ Range**: Dynamic between $\alpha$\_low and $\alpha$\_high (default: 0.7 to 0.9)
+- **Sigmoid Steepness**: Controls transition rate between $\alpha$\_low and $\alpha$\_high (default: 1000)
 - **Individual Alpha**: Each validator-miner pair gets its own $\alpha$ value
 - **Response Time**: 1-13 blocks depending on consensus alignment (~12 seconds to 2.6 minutes)
 
-See [Liquid Alpha/Consensus-Based Weights](../subnets/consensus-based-weights)
+See [Liquid Alpha/Consensus-Based Weights](../subnets/consensus-based-weights)