Registering

Fee and Registration Period

Details coming soon!

The fee is non-refundable.

Length of Registration

Once a subnet is registered, it begins its registration period, which lasts for one week (see Phases Overview). Within this time, users can delegate stake to the subnet, users can register & activate subnet nodes under the subnet based on the initial coldkeys, and the owner can activate the subnet if the activation conditions are met.

While in the registration period, if the owner attempts to activate the subnet and the activation conditions are not met, the call will not fail and will not activate the subnet.

---

Registration Variables

Each registrar must supply a few variables to register (see RegistrationSubnetData). These are the variables required to register a subnet.

More variables can be set in the subnet owner section.

pub struct RegistrationSubnetData<AccountId> {
    pub name: Vec<u8>,
    pub repo: Vec<u8>,
    pub description: Vec<u8>,
    pub misc: Vec<u8>,
    pub min_stake: u128,
    pub max_stake: u128,
    pub delegate_stake_percentage: u128,
    pub initial_coldkeys: BTreeMap<AccountId, u32>,
    pub key_types: BTreeSet<KeyType>,
    pub bootnodes: BTreeSet<BoundedVec<u8, DefaultMaxVectorLength>>,
}

Name

• The unique name of the subnet.

Repo

• The unique GitHub or similar link to the source code of the subnet for nodes to run.

Description

• A description of the subnet.

Misc

• Miscellaneous information.

Min Stake

• Minimum required stake balance to register a node.

Max Stake

• The maximum allowable stake balance for a subnet node.

Delegate Stake Percentage

• The percentage ratio of emissions given to delegate stakers.

Initial coldkeys

A list of whitelisted coldkeys and how many nodes each coldkey can register while the subnet is in the registration phase.

• Each subnet should be decentralized and is treated as such. Similar to starting a blockchain, trusted nodes should always be the initial nodes in the system to set the standard of trust. Therefore, the registrar must register with a list of coldkeys that are allowed to register nodes. These nodes are automatically classified as a Validator (See subnet node classifications).

• These coldkeys are removed once a subnet is activated.

Key Types

The key types the subnet utilizes for signature authentication. The key types parameter allows subnet and overwatch nodes to know which key types are available to generate their peer IDs to communicate with other nodes. Subnets can choose from the 4 available key types.

Key types must be accurate because not only may subnet nodes use them to generate subnet validator node private keys, but Overwatch Nodes use them as well. If Overwatch Nodes can't access the subnet due to incorrect key types, it will impact the subnet's Overwatch weight.

See libp2p documentation for more information.

Four key types are supported:

• RSA

• Ed25519

• Secp256k1

• ECDSA

Note

The subnet template currently supports RSA and Ed25519.

---

Extrinsic

pub fn register_subnet(
    origin: OriginFor<T>, 
    subnet_data: RegistrationSubnetData<T::AccountId>,
)