Most blockchain explainers start with tokens. Bittensor is easier to understand if you start with a question: what if the thing being incentivized wasn't a transfer of value, but a piece of machine intelligence? Bittensor is built around that idea. It is described as a decentralized machine-learning network where subnets coordinate intelligence and TAO incentives. If you are a developer arriving from an EVM chain, the shape of the system will feel unfamiliar at first, but the mental model is learnable in an afternoon.
Two layers, two jobs
The first thing to internalize is that Bittensor has two distinct layers, and they are not the same kind of thing.
The Subtensor chain is the ledger. It records the economic and organizational facts of the network: subnet registration, metagraph state, hotkeys and UIDs, stake positions, weights, hyperparameters, and the subnet registration cost. It is a Substrate-based chain, so it speaks Substrate JSON-RPC over HTTPS and WebSocket, and it settles in TAO, the native token. When you ask a Bittensor node a question, you are almost always asking Subtensor about chain state.
The subnets are where the intelligence work actually happens. Each subnet is identified by a netuid, and each one coordinates its own participants: miners who produce outputs, and validators who evaluate them. The chain does not run the models. It records who is registered, what weights validators have published, and how the economics are arranged. That split matters enormously for how you design software.
A useful analogy: think of Subtensor as the registry office and the subnets as workshops. The registry tells you who is licensed, where they sit, and what the rules are. It does not tell you whether the workshop's product is any good. Judging that is the validators' job, and the evidence of their judgment lands back on the registry as weights.
The metagraph is the object you will keep coming back to
If you take one concept with you, make it the metagraph. For a given netuid, the metagraph is the on-chain view of that subnet's participants: UIDs, hotkeys, validator and miner state, and the relationships between them. Practically every interesting Bittensor query is either a metagraph read or something adjacent to one.
Here is a small pattern that shows up constantly in real dashboards. A subnet explorer wants to show a leaderboard. It first lists the subnets available, then, for a chosen netuid, pulls the metagraph, then joins that against stake and weight data to rank participants. None of those steps require running inference. They are all chain reads. That is why the RPC layer, not the model layer, is where most beginner projects spend their first week.
Common application patterns
A few shapes recur often enough to name.
Monitoring and observability. A miner wants to know whether its hotkey is still registered on a subnet, what its UID is, and whether its membership has changed. A validator wants to see metagraph data, current weights, subnet configuration, and staking state. Both of these are read-heavy and tolerant of small delays, but they need consistency over time.
Analytics and dashboards. Aggregating subnet metadata, registration costs, stake positions, and alpha or subnet token data into something a human can scan. This is where query volume climbs and where people start thinking about whether a shared endpoint is enough or whether their backfills deserve dedicated capacity.
Wallets and staking interfaces. Showing TAO balances, delegation, and stake positions. This is a lower-volume but higher-stakes workload, since a stale or inconsistent read confuses users quickly.
Services that consume subnet output. An application that depends on a subnet's results still needs chain context: which subnet, which participants, which weights. The chain is the coordination record even when the computation happens elsewhere.
Where the connection actually happens
Bittensor's RPC surface is Substrate JSON-RPC, not Ethereum JSON-RPC. That single fact changes your tooling. You will not reach for a generic EVM library and expect things to work. You will use Substrate-aware clients, or the btcli tooling, which accepts a custom endpoint through its network flag. The reference material for Bittensor connectivity shows exactly this pattern: btcli pointed at a WebSocket endpoint, querying metagraph data for a netuid and returning JSON. Once you can run that one command successfully, you have proved your whole read path.
OnFinality is one option for that connection layer, offering managed Subtensor RPC over HTTPS and WebSocket on Bittensor Finney mainnet so you can query subnet and validator state without operating your own node. The reference notes a public rate limit of 5 requests per second and higher authenticated throughput on paid plans, which is the sort of detail worth checking before you point a polling loop at anything.
A few connectivity habits worth forming early
Decide between HTTP and WebSocket deliberately. HTTP is simple and fine for dashboards that refresh on a human timescale. WebSocket subscriptions earn their keep when you want to follow chain updates without continuously polling, which matters for validators watching subnet activity and for miners tracking registration changes.
Ask for finalized state when correctness matters. If your workflow needs stronger consistency, querying finalized data rather than the head of the chain removes a class of confusing edge cases. This is not a Bittensor quirk so much as a Substrate habit, and it is worth adopting early.
Budget your request rate. Metagraph queries are not free in the way a single balance check feels free. A dashboard with twenty panels each refreshing on a short timer adds up fast. If you find yourself backfilling history or running a public explorer, that is the moment to evaluate dedicated nodes rather than discovering the limit in production.
Respect the netuid boundary. Almost every query is scoped to a subnet. Writing code that assumes a single global namespace will produce bugs that look mysterious until you realize you were reading a different subnet's metagraph than you intended.
A balanced closing note
Bittensor rewards a certain amount of patience. The incentive design is genuinely unusual, and the fact that computation lives outside the chain while coordination lives inside it means you cannot treat it like a smart contract platform with a different logo. But the developer experience is more tractable than it first appears. Once you separate the ledger from the workshops, learn the metagraph, and set up a reliable way to read Subtensor state, the rest is iteration. Start with one query against one netuid. Confirm what you get back. Then build outward from there, and let your RPC choices follow the workload rather than the other way around.
Useful Resources:
• managed Subtensor RPC over HTTPS and WebSocket
Useful Resources: