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.

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.

The Mesh Template comes with built-in client logic:

PreviousProtobufNextRouting

Last updated