Skip to content
Open
Changes from 3 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
60 changes: 60 additions & 0 deletions bits/BIT-0016-subnet-deregistration.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,60 @@
# BIT-0016: Subnet Deregistration

- **BIT Number:** 0016
- **Title:** Subnet Deregistration
- **Author(s):** John Spiigot, Greg Zaitsev
- **Discussions-to:** [URL for discussion thread]
- **Status:** Draft
- **Type:** Core
- **Created:** 2025-08-12
- **Updated:** 2025-08-12

## 🔍 Abstract

This BIT proposes reenabling of subnet deregistration.

## 🔧 Motivation

Since the dTao launch, the non-functional subnets keep consuming emissions, as well as chain footprint and compute resources. The existing subnet deregistration (dissolve_network / remove_network) is no longer working correctly and is disabled.

## 🧪 Specification

The final specification is yet to be discussed. We can only propose several criteria to determine which subnets should be deregistered first. Note that because deregistration is an on-chain process, the criteria should only use data available on chain.

- Lack of demand for subnet Alpha token
- Low subnet price and emissions
- Unfavorable ratio and/or values of subnet parameters such as TAO and Alpha pool liquidity, Alpha circulating, Alpha issued, Alpha burned, FDV, Alpha volume, etc.
- Only allow deregistration of subnets which would have a higher value of Alpha from liquidation than from unstaking
Copy link
Collaborator

@mcjkula mcjkula Aug 14, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Only allow deregistration of subnets which would have a higher value of Alpha from liquidation than from unstaking

The table below shows which subnets would be the "first ones" to get deregistered should they be not in immunity based on the criteria of having a higher value of ALPHA from liquidation than from unstaking, sorted/ordered by lowest price first.

Netuid ALPHA price NAV Ratio
126 0.001 1.3278
103 0.0011 1.4477
105 0.0011 1.0102
128 0.0013 1.4157
122 0.0013 1.3143
86 0.0013 1.2147
102 0.0013 1.8806
127 0.0014 1.6807
109 0.0015 1.7133
94 0.0015 1.3397
111 0.0016 1.7108
107 0.0016 1.7597
108 0.0017 1.3951
97 0.0017 1.1824
121 0.0017 1.9053
74 0.0017 1.0838
90 0.0017 1.9745
59 0.0017 1.1223
66 0.0018 1.1114
38 0.0018 1.2223
80 0.0018 1.0553
60 0.0018 1.3497
24 0.0018 1.3141
47 0.0018 1.4738
70 0.0019 1.4593
104 0.0019 1.2621
91 0.0019 1.2304
76 0.0019 1.4825
113 0.002 1.0707
79 0.0021 1.5682
114 0.0021 1.7816
28 0.0021 1.2822
27 0.0022 2.1783
58 0.0022 1.6837
26 0.0023 1.177
55 0.0023 1.6008
99 0.0024 1.8332
21 0.0024 1.3293
84 0.0024 1.1841
46 0.0025 1.406
61 0.0026 1.4416
40 0.0027 1.5254
23 0.0027 1.1886
124 0.0027 1.7496
16 0.0027 1.2081
65 0.0027 1.0569
96 0.0029 2.264
32 0.0029 1.1692
69 0.003 1.0114
88 0.0031 1.082
29 0.0032 1.161
45 0.0032 1.774
42 0.0033 2.8872
18 0.0033 1.2601
22 0.0036 1.3242
72 0.0036 2.1313
20 0.0036 1.2422
57 0.0036 1.0663
2 0.0037 1.0936
30 0.0038 1.2767
98 0.0039 1.711
37 0.0042 1.1133
6 0.0043 1.3364
85 0.0046 2.2632
25 0.005 1.7122
106 0.0068 1.8086
41 0.007 1.0851
81 0.0076 2.2814
75 0.0078 1.7841
10 0.0094 1.3552
52 0.0097 1.675
53 0.0097 1.0837
68 0.0151 1.3654
13 0.0155 1.3497
1 0.0155 1.6753
19 0.0171 1.9703
34 0.02 1.789
8 0.0433 1.2997
4 0.0538 1.6608
51 0.0592 1.2926
64 0.1278 1.0166

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There is one "problem" with this criteria though, because NAV in the most simple way means ALPHA in the pool > ALPHA held by users, post-halving each new subnet would naturally lean towards a NAV < 1 given that the ALPHA injected into the pool should be halved, while the ALPHA emitted to participants will stay the same until the ALPHA halving of the subnet.

This makes older subnets more vulnerable to being registered with this criteria.


The current in-progress implementation may be used as a basis for such discussion, which is described below.

### Subnet Pruning
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I assume that's outdated, because it still mentions the old behavior (lowest emission)?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, that's just whatever starting point design was. It's an open discussion.

- Triggered when `SubnetLimit` is reached
- **Step 1:** Exclude subnets still within `NetworkImmunityPeriod`
- **Step 2:** Among the rest, find the subnet with the lowest current emission
- **Step 3:** If multiple share the same emission, pick the one with the earliest registration timestamp

### Network Dissolution

- In `dissolve_network` / `remove_network`, perform full dTao cleanup:
- Return the registration cost to the owner (or owners in case if it was a crowdloan)
- Distribute remaining Tao to α-out stakers pro-rata
- Destroy all α-in and α-out stakes
- **Adjust the owner’s returned lock cost** by subtracting the portion of total emissions the owner actually received (`owner_received_emission = E * get_float_subnet_owner_cut()`), so the final refund is `max(0, lock_cost - owner_received_emission)`.
- Maintain **root-only** access to direct calls for now

### Explicit Subnet Limit
Add new sudo hyperparameter `SubnetLimit` starting at `256`.

### High-Level Flow

```text
New Registration → check slot cap?
├─ No → register network, grant immunity
└─ Yes → prune one subnet → deregister → register new
Deregistration (manual or pruning) → destroy α-in/out → distribute Tao → remove network
```

## © Copyright

This document is licensed under [The Unlicense](https://unlicense.org/).