Summary
# What is Bittensor RPC and how do you connect to it? Bittensor is a decentralized AI network built on a Substrate-based Layer 1 chain (Subtensor) with an optional Frontier EVM runtime. To interact with the network—whether querying subnet states, submitting inference requests, or deploying smart contracts—you need a Bittensor RPC endpoint. This guide explains the available RPC methods, network types (Finney mainnet and testnet), and how to choose a reliable provider. OnFinality provides public and dedicated Bittensor RPC endpoints for both Substrate and EVM interfaces, supporting developers building on Bittensor’s AI subnets.
In practice, the useful question is not just whether an endpoint exists. Teams should check supported methods, traffic shape, monitoring, pricing, and the path from testing to production. That turns the page from a definition into a decision tool: it helps you decide what to test first, what belongs in staging, and when a production workload may need stronger isolation or clearer request visibility. If you already know the network you need, open /networks/bittensor-finney after using this checklist so you can test the endpoint against your real methods.
Key Takeaways
- Bittensor uses a Substrate-based L1 (Subtensor) with an optional EVM runtime for smart contracts.
- The mainnet is called Finney (Chain ID 964 for EVM); testnet uses Chain ID 945.
- Public RPC endpoints are available from multiple providers, including OnFinality, Nodies, and blockmachine.
- OnFinality offers both public and dedicated Bittensor RPC endpoints with global load balancing.
- Common RPC methods include chain_getBlockHash, substrate_* calls, and standard EVM JSON-RPC methods.
- For production workloads, dedicated nodes provide higher throughput, lower latency, and support terms-backed reliability.
- Always verify endpoint authenticity and rate limits before integrating into your application.
Understanding Bittensor's Architecture
Bittensor is a decentralized AI network that enables machine learning models to collaborate and compete. Its core blockchain, Subtensor, is built with Substrate and uses a Proof-of-Authority consensus. On top of Subtensor, a Frontier EVM runtime provides Ethereum compatibility, allowing developers to deploy Solidity smart contracts.
The network is organized into subnets, each specializing in a specific AI task (e.g., text generation, image recognition). Validators and miners register on-chain and communicate via the Bittensor protocol. To interact with the network programmatically, you need an RPC endpoint that exposes both Substrate-specific and EVM JSON-RPC methods.
- Consensus: Proof-of-Authority (PoA) with 12-second block times.
- Native token: TAO, used for gas and staking.
- EVM Chain ID: 964 (mainnet), 945 (testnet).
- Substrate methods: chain_getBlockHash, state_getStorage, substrate_*.
- EVM methods: eth_blockNumber, eth_call, eth_sendRawTransaction.
| Criterion | What to check | Why it matters |
|---|---|---|
| Network | Finney (mainnet) vs testnet | Mainnet uses real TAO; testnet uses test TAO for development. |
| RPC Interface | Substrate vs EVM | Choose based on whether you need native Substrate calls or Ethereum-compatible JSON-RPC. |
| Endpoint Type | Public vs dedicated | Public endpoints have rate limits; dedicated nodes offer higher throughput and reliability. |
Bittensor infrastructure decision checklist
Use this checklist to turn the Bittensor infrastructure question into a practical infrastructure decision instead of a generic provider comparison.
Start with the workflow you need to support, then verify the endpoint, method coverage, test environment, and next step before relying on it in production.
- List the exact RPC methods, chains, and environments your app will call.
- Test with the same request pattern your frontend, backend, bot, dashboard, or indexer will use.
- Check whether archive, trace, WebSocket, testnet, analytics, or dedicated-node access is actually required.
- Review pricing, usage visibility, and upgrade paths before moving sustained traffic.
| Criterion | What to check | Why it matters |
|---|---|---|
| Workload fit | Does the provider support the Bittensor infrastructure methods and environments your product depends on? | A provider that works for a quick read may still be a poor fit for wallets, trading systems, indexers, or release pipelines. |
| Operational visibility | Can the team see request volume, errors, limits, and usage patterns? | Visibility makes it easier to debug failed requests and plan capacity before users feel the problem. |
| Scaling path | Is there a clear path from shared RPC to higher-capacity plans or dedicated nodes? | The right starting point should not force a rebuild when traffic or reliability requirements increase. |
Public Bittensor RPC Endpoints
Several providers offer public Bittensor RPC endpoints for both mainnet and testnet. Below are commonly used endpoints. Note that public endpoints may have rate limits and are not recommended for production workloads requiring high availability.
OnFinality provides a public endpoint for the Finney mainnet: https://bittensor-finney.api.onfinality.io/public. This endpoint supports both Substrate and EVM methods and is monitored for availability. For testnet, OnFinality also offers endpoints upon request.
- Finney (Mainnet) – OnFinality: https://bittensor-finney.api.onfinality.io/public
- Finney (Mainnet) – Nodies: https://bittensor-public.nodies.app
- Lite (Mainnet) – blockmachine: https://rpc.blockmachine.io
- Lite (Mainnet) – Opentensor.ai: https://lite.chain.opentensor.ai
- Testnet – Nodies: https://bittensor-testnet-public.nodies.app
- Testnet Lite – Opentensor.ai: https://test.chain.opentensor.ai
How to Connect to Bittensor RPC
Connecting to a Bittensor RPC endpoint is straightforward. You can use standard HTTP POST requests with JSON-RPC payloads. For Substrate methods, the endpoint expects a JSON-RPC 2.0 request. For EVM methods, the same endpoint can be used if the provider supports the EVM interface.
Below is an example using curl to call the chain_getBlockHash method on the Finney mainnet via OnFinality's public endpoint.
- Replace the URL with your chosen endpoint.
- Use Content-Type: application/json.
- For EVM methods, use eth_ prefixed methods (e.g., eth_blockNumber).
- WebSocket (WSS) endpoints are also available for real-time subscriptions.
Choosing a Bittensor RPC Provider
When selecting a Bittensor RPC provider, consider factors such as latency, throughput, reliability, and support for both Substrate and EVM interfaces. Public endpoints are suitable for development and light usage, but for production applications, a dedicated node or a premium RPC service is recommended.
OnFinality offers dedicated Bittensor nodes with global deployment, load balancing, and 24/7 support. This ensures low-latency access and high availability for your AI applications. Additionally, OnFinality's RPC API service provides easy integration with automatic failover.
- Latency: Choose a provider with nodes near your user base.
- Throughput: Check rate limits and whether dedicated nodes are available.
- Reliability: Look for support terms-backed availability documents.
- Interface Support: Ensure the provider supports both Substrate and EVM methods if needed.
- Pricing: Compare free tier limits and paid plans.
| Criterion | What to check | Why it matters |
|---|---|---|
| Provider | OnFinality, Nodies, blockmachine, Opentensor.ai | Each offers different endpoint types, rate limits, and support levels. |
| Endpoint Type | Public vs dedicated | Dedicated nodes provide more predictable resource planning and are ideal for production. |
| Network Support | Finney, Lite, Testnet | Lite networks may have reduced functionality; testnet is for development. |
Common Bittensor RPC Methods
Bittensor exposes a wide range of RPC methods. Below are some commonly used ones for both Substrate and EVM interfaces.
- Substrate: chain_getBlockHash, chain_getHeader, state_getStorage, state_call, author_submitExtrinsic.
- EVM: eth_blockNumber, eth_getBalance, eth_call, eth_sendRawTransaction, eth_getTransactionReceipt.
- Bittensor-specific: subtensorModule.getSubnetInfo, subtensorModule.getNeuronInfo (via state_call).
Best Practices for Using Bittensor RPC
To ensure a smooth experience when integrating Bittensor RPC endpoints, follow these best practices:
Always use a reliable provider with redundancy. For critical applications, implement failover between multiple endpoints. Monitor your RPC usage to avoid hitting rate limits. Use WebSocket connections for real-time data like new blocks or events. Keep your API keys secure and rotate them regularly.
- Implement retry logic with exponential backoff for transient failures.
- Cache frequently accessed data (e.g., subnet info) to reduce RPC calls.
- Use batch requests when possible to improve efficiency.
- Test on testnet before deploying to mainnet.
Frequently Asked Questions
What is the Bittensor RPC endpoint for mainnet?
Public endpoints include https://bittensor-finney.api.onfinality.io/public (OnFinality), https://bittensor-public.nodies.app (Nodies), and https://lite.chain.opentensor.ai (Opentensor.ai). For production, consider a dedicated node.
Does Bittensor support EVM RPC methods?
Yes, Bittensor has a Frontier EVM runtime. The EVM Chain ID is 964 for mainnet and 945 for testnet. You can use standard Ethereum JSON-RPC methods like eth_call and eth_sendRawTransaction.
What is the difference between Finney and Lite networks?
Finney is the mainnet with full functionality. Lite is a lighter version that may have reduced features or higher rate limits. For production, use Finney endpoints.
Can I use OnFinality for Bittensor testnet?
Yes, OnFinality provides testnet endpoints. Contact support or check the network page for details.
How do I get a dedicated Bittensor node?
OnFinality offers dedicated Bittensor nodes. Visit the dedicated node page or contact sales for a custom quote.
Ethereum
Solana
Polygon
Base
Arbitrum
BNB Chain
Polkadot
Optimism
