Registering

Registering

A subnet can be registered by an owner once per registration phase for a fee.

Fee and Registration Period

The subnet registration fee uses a linear decay model. The registration cost starts at a maximum value (MaxSubnetRegistrationFee) and linearly decreases to a minimum (MinSubnetRegistrationFee) over a fixed interval of epochs (SubnetRegistrationInterval). After the interval expires, the cost remains at the minimum fee.

The fee is non-refundable.

Length of Registration

Once a subnet is registered, it begins its registration period that lasts for 1 week. Within the time, users can delegate stake to the subnet, and can activate subnet nodes under the subnet based on the initial coldkeys.

---

Registration Variables

Each registrar must supply a few variables to register (see RegistrationSubnetData).

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.

Churn Limit

• Number of subnet activations per epoch.

Grace period epochs

• The grace period from the node queue epochs during which it can activate itself. For example, if a node registers on epoch 1,000 with 10 node queue epochs, it can register in between epoch 1,010, plus the grace period.

The queue epochs and churn limit are used together to calculate each subnet node's start epoch (the epoch they can activate) when they register.

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.

Registration Queue Epochs

• Number of epochs for registered nodes to be in the queue before activation.

  • This is the queue a node must be in after registration before the node can activate itself.

Node queue epochs

• Number of epochs a registered node is in the queue before it can activate itself.

Max node penalties

The maximum penalties a node can have on any epoch without being automatically removed.

• A node can acquire penalties if:

  • It is a validator and doesn't achieve a minimum of a 66% attestation ratio.

  • The validator doesn't include the node in its consensus data and receives a 66% attestation ratio or greater.

• A node will decrease its penalties if:

  • It is a validator and achieves above a 66% attestation ratio.

  • The validator includes the node in its consensus data and receives greater than a 66% attestation ratio.

A node will be removed from the blockchain if the max node penalties are reached. If a subnet employs a proof-of-stake consensus mechanism, the DHT Records validator should remove it from the current records, and the authenticator should remove the node from routing tables.

Nodes decrease penalties for every successfully attested epoch they are included in the data. Therefore, to be removed, penalties must be consecutive.

Initial coldkeys

A list of whitelisted coldkeys that can register nodes 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.

Extrinsic

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