Skip to content
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
2 changes: 1 addition & 1 deletion docs/btcli.md
Original file line number Diff line number Diff line change
Expand Up @@ -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`. |
Expand Down
13 changes: 12 additions & 1 deletion docs/glossary.md
Original file line number Diff line number Diff line change
Expand Up @@ -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
Expand Down Expand Up @@ -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:
Expand All @@ -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:
Expand All @@ -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.
Expand Down Expand Up @@ -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.
Expand Down Expand Up @@ -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
Expand Down
29 changes: 16 additions & 13 deletions docs/learn/ema.md
Original file line number Diff line number Diff line change
@@ -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$.

$$
Expand All @@ -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}}
Expand All @@ -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)

Expand All @@ -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)
Loading