Logo
RPC Assistant

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

Summary

Bittensor RPC enables developers to interact with Bittensor's decentralized AI network via Substrate (subtensor) and EVM APIs. This reference covers mainnet and testnet endpoints, chain settings, code examples, and criteria for choosing an RPC provider for your dApp or AI agent.

Bittensor RPC Decision Checklist

Before integrating Bittensor RPC, evaluate these key aspects:

CriterionWhat to checkWhy it matters
Network typeMainnet (Finney) or testnet?Different endpoints, chain IDs, and token values. Testnet uses Test TAO.
API layerSubstrate native or EVM?Bittensor offers both. Substrate for chain state, EVM for smart contracts.
Endpoint typeShared public, shared premium, or dedicated?Public endpoints have rate limits; dedicated nodes offer consistent performance.
Geographic latencyProvider node locationsLower latency reduces response times for time-sensitive applications.
Reliability guaranteesUpstream redundancy, failoverEnsure your provider maintains high availability and handles load spikes.
Archive dataFull history needed?Archive nodes allow historical queries; essential for analytics or auditing.
Support for WebSocketsReal-time subscriptions?Required for live feeds (e.g., new blocks, event logs).
Pricing modelPay-as-you-go vs. fixed monthlyMatch your usage pattern to avoid overpaying or hitting limits.

Understanding Bittensor's Dual RPC Architecture

Bittensor is a decentralized AI network built on the Subtensor blockchain, a Substrate-based layer 1 chain. It also includes a Frontier EVM runtime, enabling both native Substrate RPC methods and Ethereum-compatible JSON-RPC calls. This dual architecture means developers can choose the interface that best suits their application:

  • Substrate RPC (chain_getBlockHash, state_getMetadata) – for querying chain state, staking, and subnet operations.
  • EVM RPC (eth_blockNumber, eth_call, eth_sendTransaction) – for deploying and calling smart contracts on the EVM side.

The chain ID for the EVM is 964 (mainnet) and 945 (testnet). The native token is TAO.

Bittensor Mainnet (Finney) RPC Endpoints and Chain Settings

Public mainnet endpoints (subject to rate limits):

  • https://lite.chain.opentensor.ai/ (EVM)
  • https://rpc.blockmachine.io/ (EVM)
  • https://bittensor-finney.api.onfinality.io/public (Substrate + EVM, available via API key for higher limits)
  • wss://bittensor-finney.api.onfinality.io/public (WebSocket)

Chain settings for wallet or dApp configuration:

FieldValue
Network NameBittensor Finney
RPC URL (EVM)https://lite.chain.opentensor.ai/ or any provider endpoint
Chain ID964 (0x3C4)
Currency SymbolTAO
Block Explorerhttps://taostats.io

For Substrate-native interactions, use the same endpoints with the chain_getBlock etc. methods.

Bittensor Testnet RPC Endpoints and Chain Settings

Testnet endpoints for development and testing:

  • https://test.chain.opentensor.ai/ (EVM)
  • https://bittensor-testnet.drpc.org (EVM, via dRPC)
  • wss://test.chain.opentensor.ai/ (WebSocket)

Chain settings:

FieldValue
Network NameBittensor Testnet
RPC URL (EVM)https://test.chain.opentensor.ai/ or provider endpoint
Chain ID945 (0x3B1)
Currency SymbolTest TAO
Block Explorerhttps://testnet.taostats.io

Test TAO can be requested from the Bittensor Discord or faucet (check official channels).

How to Connect to Bittensor RPC

Here's a basic curl example to fetch the latest block number via EVM JSON-RPC:

curl -X POST https://lite.chain.opentensor.ai/ \
  -H "Content-Type: application/json" \
  -d '{"jsonrpc":"2.0","method":"eth_blockNumber","params":[],"id":1}'

Using Substrate RPC to get a block hash:

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

In JavaScript (Web3.js or ethers.js):

const { ethers } = require("ethers");

const provider = new ethers.providers.JsonRpcProvider("https://lite.chain.opentensor.ai/");

async function getBlockNumber() {
  const blockNumber = await provider.getBlockNumber();
  console.log("Current Bittensor block:", blockNumber);
}

getBlockNumber();

For Substrate, use the Polkadot.js API:

const { ApiPromise, WsProvider } = require("@polkadot/api");

async function connect() {
  const provider = new WsProvider("wss://bittensor-finney.api.onfinality.io/public");
  const api = await ApiPromise.create({ provider });
  const chain = await api.rpc.system.chain();
  console.log("Connected to:", chain);
}

connect();

Bittensor RPC Provider Evaluation Criteria

When choosing an RPC provider for Bittensor, consider the following criteria:

CriterionWhat to checkWhy it matters
API layer supportSubstrate and EVMEnsure the provider exposes both; some only offer one.
Rate limitsRequests per second (RPS)Production dApps need high RPS; shared free endpoints may throttle.
Geographic distributionNode locationsGlobal nodes reduce latency for users worldwide.
Uptime SLAProvider's historical uptimeImportant for production applications.
WebSocket supportReal-time subscriptionsRequired for live updates (e.g., new blocks, events).
Archive accessFull historical stateNeeded for analytics or backtesting.
Pricing transparencyPer-request or fixed monthlyChoose a model that fits your budget and usage.

OnFinality offers both shared and dedicated Bittensor RPC endpoints with Substrate and EVM support, global load balancing, and WebSocket access. Check the Bittensor network page for up-to-date endpoint details and pricing.

Common Pitfalls and Troubleshooting

  • Wrong chain ID: When adding to MetaMask, ensure you use the correct chain ID (964 for mainnet, 945 for testnet). A common mistake is using 1 or 137.
  • Rate limiting: Public endpoints like lite.chain.opentensor.ai may return 429 Too Many Requests. Use a provider with a higher plan or dedicated node.
  • EVM vs Substrate: Some providers only expose one interface. If you need both, confirm beforehand.
  • Testnet TAO: You cannot get TAO from the mainnet faucet; use the testnet faucet (often via Discord).
  • WebSocket connections: Ensure your firewall allows WebSocket on port 443; some corporate networks block it.
  • Block finality: Bittensor uses Proof-of-Authority; ensure your application accounts for possible reorganizations (e.g., wait for a few confirmations).

Key Takeaways

  • Bittensor offers both Substrate native and EVM RPC interfaces; choose based on your application's needs.
  • Public endpoints are available for quick testing, but production applications should consider a dedicated or higher-tier shared provider for reliability and speed.
  • Always verify chain IDs and endpoint URLs from official sources to avoid phishing or misconfiguration.
  • OnFinality provides managed Bittensor RPC endpoints with flexible plans – see supported networks and pricing for details.
  • Test thoroughly on testnet before moving to mainnet, and monitor RPC performance regularly.

Frequently Asked Questions

What is Bittensor RPC? Bittensor RPC allows developers to interact with the Bittensor network programmatically, querying chain state, sending transactions, and accessing smart contracts.

What are the chain IDs for Bittensor? Mainnet: 964 (0x3C4). Testnet: 945 (0x3B1).

Do I need a separate RPC for Substrate and EVM? Some providers offer a single endpoint that handles both. Confirm with your provider.

How can I get Test TAO? Test TAO is available from the Bittensor testnet faucet, typically through the official Discord or community channels.

Can I use Bittensor RPC for free? Yes, there are public endpoints, but they come with rate limits. For production, consider a shared or dedicated plan.

Where can I find the latest Bittensor RPC endpoints? Check the official Bittensor documentation or a multi-chain RPC provider like OnFinality for up-to-date endpoints.

RPC Knowledge Base

Related RPC details

Never Worry about Infrastructure Again

OnFinality takes away the heavy lifting of DevOps so you can build smarter and faster.

Get Started