# Register

A subnet node registers itself and transfers at least the minimum required balance as a stake. This registration is used as the subnets' proof-of-stake.

#### Call `register_subnet_node` to register

```rust
pub fn register_subnet_node(
    origin: OriginFor<T>,
    subnet_id: u32,
    hotkey: T::AccountId,
    peer_info: PeerInfo,
    bootnode_peer_info: Option<PeerInfo>,
    client_peer_info: Option<PeerInfo>,
    delegate_reward_rate: u128,
    stake_to_be_added: u128,
    unique: Option<BoundedVec<u8, DefaultMaxVectorLength>>,
    non_unique: Option<BoundedVec<u8, DefaultMaxVectorLength>>,
    delegate_account: Option<DelegateAccount<T::AccountId>>,
    max_burn_amount: u128,
)
```

### Registration Inputs

### `subnet_id`

The subnet ID to register the node to.

### `hotkey`

The hotkey of the node. This key is used to run non-fund-based extrinsics, such as consensus (validating and attesting).

{% hint style="info" %}

1. Hotkeys are network-unique. Meaning, no one hotkey can be used twice.&#x20;
   * This enhances overall network security. In the event a subnet/node gets hacked, it can be accurately identified if the hotkey was used in multiple subnets.
2. Hotkeys can also never match the coldkey.
   {% endhint %}

### `peer_info`

```rust
pub struct PeerInfo {
    pub peer_id: PeerId,
    pub multiaddr: Option<BoundedVec<u8, DefaultMaxVectorLength>>,
}
```

The peer ID and optional multiaddress of the node. This is used for signature validation within the subnet, proof-of-stake, and more.

### `bootnode_peer_info` (Optional)

```rust
pub struct PeerInfo {
    pub peer_id: PeerId,
    pub multiaddr: Option<BoundedVec<u8, DefaultMaxVectorLength>>,
}
```

The bootnode/bootstrap peer ID and optional multiaddress of the node. This is used for signature validation within the subnet, proof-of-stake, and more.

### `client_peer_info` (Optional)

```rust
pub struct PeerInfo {
    pub peer_id: PeerId,
    pub multiaddr: Option<BoundedVec<u8, DefaultMaxVectorLength>>,
}
```

The client peer ID and optional multiaddress of the node. This is used for signature validation within the subnet, proof-of-stake, and more.

### `delegate_reward_rate`

The rate of rewards given to users who stake to the node.

### `stake_to_be_added`

The amount of stake to be added. The blockchain has a minimum required of 100 TENSOR, but subnets may require more (check subnet documentation for required proof-of-stake balance).

### `unique`

An arbitrary value unique to the subnet.

### `non_unique`

An arbitrary value.

### `delegate_account` (Optional)

```rust
pub struct DelegateAccount<AccountId> {
    pub account_id: AccountId,
    pub rate: u128,
}
```

The [delegate account](/network/subnet-node/delegate-account.md) being an `account_id` and `rate`. A fraction of the emissions, based on the rate, for this node will be allocated to this account.

The rate is based on `1e18 == 1.0 == 100%`.

**For example**, if the rate is 50%, half of the emissions associated with this node will be allocated to the management of the delegate account.

### `max_burn_amount`

The maximum amount the registering node is willing to burn to join the subnet.

***

Once registered, the node is given the **Registered** [**classification**](/network/subnet-node/classifications.md), **put into a queue**, and given a **start epoch**.&#x20;

### Queue

The length of the queue is based on epochs and is unique to each subnet.

### Start Epoch

The start epoch is the epoch a node must activate itself on; otherwise, it can no longer activate.

#### Note

A subnet can utilize **grace epochs** (`ActivationGraceEpochs`) that allow nodes to register on the **start epoch, plus the grace epochs**.


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.hypertensor.org/network/subnet-node/register.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.