DEV Community

Zhuoxin Sun
Zhuoxin Sun

Posted on • Originally published at onfinality.io

Bittensor RPC Guide: Endpoints, Methods, and Providers

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.

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 SLA-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.

Access reliable Bittensor RPC endpoints with low latency and high throughput. Sign up for a free API key. Get Free API Key.

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.

View detailed network specifications and endpoint URLs for the Bittensor Finney mainnet. View Network Details.

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.

For high-volume applications, consider a dedicated Bittensor node with guaranteed resources and custom configuration. Learn About Dedicated Nodes.

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.
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 guaranteed performance and are ideal for production.
Network Support Finney, Lite, Testnet Lite networks may have reduced functionality; testnet is for development.

Not sure which provider fits your needs? Read our guide on choosing an RPC provider for production Web3 apps. Read the Guide.

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.

FAQ

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.

Related resources

Originally published at OnFinality.

Top comments (0)