What is Bittensor RPC and how do you connect to it?

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.

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 uptime. 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 SLA-backed uptime guarantees.
• Interface Support: Ensure the provider supports both Substrate and EVM methods if needed.
• Pricing: Compare free tier limits and paid plans.

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