How do I connect to the Bittensor network for RPC access?

Quick recommendation: managed RPC vs. running your own Finney node

If you are building on Bittensor, the first decision is how you will talk to the chain. You have three realistic options:

• Public RPC endpoint – fine for prototyping, reading balances, and testing extrinsics. Not ideal for production workloads that need consistent throughput or WebSocket subscriptions.
• Managed RPC provider – a service like OnFinality gives you a hosted endpoint with HTTP and WebSocket support, so you skip node maintenance, upgrades, and sync time. This is the usual choice for dApps, dashboards, and subnet tooling that need reliable access without running infrastructure.
• Dedicated node – you get isolated resources for high-volume or latency-sensitive workloads. This makes sense when you need predictable performance, custom pruning, or private access.

For most developers, a managed RPC endpoint is the fastest path to a working integration. If you later hit rate limits or need dedicated capacity, you can move to a dedicated node without changing your application logic. See RPC pricing and supported RPC networks for current options.

What the Bittensor network exposes to developers

Bittensor is a decentralized network for machine learning. Its mainnet, Finney, is built on Substrate, which means it exposes a JSON-RPC interface similar to Polkadot and other Substrate chains. You can query chain state, submit transactions, and subscribe to events using standard Substrate tooling.

Key facts for developers:

• Chain name: Bittensor Finney Mainnet
• Native token: TAO (9 decimals)
• RPC transport: HTTP and WebSocket
• Public endpoint (OnFinality): https://bittensor-finney.api.onfinality.io/public
• WebSocket endpoint: wss://bittensor-finney.api.onfinality.io/public-ws

These endpoints are suitable for development and light production use. For heavier workloads, consider a dedicated node.

Chain settings at a glance

When you configure a wallet, SDK, or indexer for Bittensor, you need the correct chain parameters. The table below summarizes what to use.

If you are using a JavaScript wallet or SDK, you can configure the endpoint like this:

import { ApiPromise, WsProvider } from '@polkadot/api';

const provider = new WsProvider('wss://bittensor-finney.api.onfinality.io/public-ws');
const api = await ApiPromise.create({ provider });

const chain = await api.rpc.system.chain();
console.log(`Connected to ${chain}`);

For HTTP-only clients, you can use the public endpoint with curl:

curl -H "Content-Type: application/json" \
  -d '{"jsonrpc":"2.0","method":"chain_getBlock","params":[],"id":1}' \
  https://bittensor-finney.api.onfinality.io/public

Connecting your application: HTTP vs. WebSocket

Substrate chains support both HTTP and WebSocket transports. The right choice depends on your use case.

• HTTP is stateless and works well for one-off queries, cron jobs, and serverless functions. Each request opens a new connection, so it is less efficient for high-frequency polling.
• WebSocket keeps a persistent connection and supports subscriptions. Use it for real-time dashboards, event listeners, and any application that needs to react to new blocks or extrinsics as they happen.

If you are building a subnet dashboard that shows live staking or emission data, WebSocket is usually the better fit. For a backend service that periodically checks balances, HTTP is simpler.

Production readiness checklist

Before you ship a Bittensor integration, run through these checks:

1. Endpoint redundancy – Do you have a fallback RPC endpoint if the primary one is unavailable? Managed providers often offer multiple regions or a failover URL.
2. Rate limits – Understand the request limits on your plan. Public endpoints are shared and may throttle under load. If you need consistent throughput, move to a dedicated node.
3. WebSocket stability – If you rely on subscriptions, test reconnection logic. Networks can drop connections, and your app should recover gracefully.
4. Data freshness – For staking or emission calculations, confirm that your node is fully synced and not lagging behind the chain head.
5. Monitoring – Set up alerts for endpoint errors, latency spikes, and subscription drops. A simple health check that calls chain_getBlock every minute can catch issues early.

If you would rather not manage these concerns yourself, a managed RPC service like OnFinality handles node upgrades, sync, and availability so you can focus on your application. For workloads that need isolated resources, a dedicated node gives you a private endpoint with predictable performance.

Common pitfalls when integrating with Bittensor

Developers new to Substrate chains often run into a few recurring issues:

• Incorrect SS58 prefix – Bittensor uses the default Substrate prefix (42). If you generate addresses with a different prefix, they will not be valid on Finney.
• Assuming EVM compatibility – Bittensor is not an EVM chain. You cannot use ethers.js or viem directly. Use Substrate libraries like @polkadot/api or py-substrate-interface.
• Ignoring existential deposit – Substrate chains have a minimum balance requirement for accounts to exist. Check the current existential deposit before funding new accounts.
• Hardcoding block times – Block times can vary. Do not assume a fixed interval for emissions or staking rewards; always read from the chain.
• Skipping metadata updates – When the runtime upgrades, the chain metadata changes. Your client should fetch the latest metadata to avoid decoding errors.

When to move from public RPC to a dedicated node

Public RPC endpoints are a great starting point, but they are shared. As your usage grows, you may notice slower response times or rate limiting during peak periods. Signs that you need a dedicated node include:

• Your application makes thousands of requests per minute.
• You need WebSocket subscriptions with guaranteed delivery.
• You require custom pruning or archive data.
• You want a private endpoint that is not shared with other users.

A dedicated Bittensor node from OnFinality gives you isolated resources and a private endpoint. You can learn more on the Bittensor Finney network page.

Monitoring your Bittensor RPC connection

Once you are in production, monitoring is essential. Here is a simple Node.js script that checks the health of your endpoint by fetching the latest block:

const fetch = require('node-fetch');

async function checkHealth() {
  const res = await fetch('https://bittensor-finney.api.onfinality.io/public', {
    method: 'POST',
    headers: { 'Content-Type': 'application/json' },
    body: JSON.stringify({
      jsonrpc: '2.0',
      method: 'chain_getHeader',
      params: [],
      id: 1
    })
  });
  const data = await res.json();
  console.log('Latest block:', parseInt(data.result.number, 16));
}

checkHealth().catch(console.error);

Run this on a schedule and alert if the block number stops increasing or the request fails. For WebSocket connections, also monitor for unexpected disconnects and implement exponential backoff on reconnect.

Key Takeaways

• Bittensor's mainnet, Finney, is a Substrate-based chain with HTTP and WebSocket RPC endpoints.
• Use the OnFinality public endpoint for development: https://bittensor-finney.api.onfinality.io/public and wss://bittensor-finney.api.onfinality.io/public-ws.
• For production, evaluate managed RPC or a dedicated node based on your throughput, latency, and isolation needs.
• Always configure fallback endpoints and monitor for rate limits, sync lag, and WebSocket drops.
• Bittensor is not EVM-compatible; use Substrate tooling like @polkadot/api.

Frequently Asked Questions

Can I use MetaMask with Bittensor?
No. Bittensor is not an EVM chain, so MetaMask and other Ethereum wallets are not compatible. Use a Substrate-compatible wallet like Polkadot.js or Talisman.

What is the difference between Bittensor and Finney?
Finney is the name of the Bittensor mainnet. When you connect to the Bittensor network, you are connecting to Finney.

Do I need a dedicated node to run a subnet?
Not necessarily. Many subnet operations can be done with a managed RPC endpoint. However, if you run validators or high-frequency services, a dedicated node may provide better performance and reliability.

How do I get TAO for testing?
TAO is the native token on Finney mainnet. There is no official testnet faucet for TAO. For development, you can test against a local Substrate node or use small amounts of real TAO.

Does OnFinality support Bittensor WebSocket subscriptions?
Yes, the public WebSocket endpoint supports subscriptions. For production use, consider a dedicated node to avoid shared rate limits. See RPC pricing for details.

Next steps

If you are ready to connect, start with the public endpoint and build your integration. When you need more capacity or isolation, explore OnFinality's RPC API and dedicated nodes. You can also review how to choose an RPC provider to compare options systematically.