> For the complete documentation index, see [llms.txt](https://docs.hypertensor.org/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.hypertensor.org/subnet-template/client.md).

# Client

## Client Access in Subnets

Some subnets are designed not just for peer-to-peer coordination between nodes, but also for **serving external clients** — such as user-facing applications like chatbots, dashboards, or streaming interfaces.

In these cases, the subnet must support a way for **clients to connect and make RPC calls** without becoming full DHT participants.

#### What is a Client?

A **client** is a lightweight node that:

* Connects to the subnet’s DHT
* **Is not stored** in other nodes’ routing tables
* Can **call RPC methods** on full nodes (e.g., to request inference or submit inputs)
* Does **not host protocols or participate in consensus, scoring, or validation**

This makes clients ideal for frontend apps, API services, or read-only integrations.

***

#### Security Considerations

For secure access:

* Only nodes with a **valid proof-of-stake** should be allowed to call RPC methods on the subnet.
* If the subnet provides a public interface (like a web-based chatbot), **at least one full node should host the frontend**.
* Optionally, subnets can define a **custom "client role"** or staking requirement to enable external developers to build frontends in return for rewards or incentives.

{% hint style="info" %}
This is why Hypertensor subnet nodes require 3 peer IDs: the main peer ID, the bootstrap peer ID, and the client peer ID. This way, those who connect can be verified to have a proof-of-stake.
{% endhint %}

#### The Subnet Template comes with built-in client logic:

* [Session Manager](/subnet-template/client/sessions.md)
* [Routing](/subnet-template/client/routing.md)