Resumen
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:
| Criterion | What to check | Why it matters |
|---|---|---|
| Network type | Mainnet (Finney) or testnet? | Different endpoints, chain IDs, and token values. Testnet uses Test TAO. |
| API layer | Substrate native or EVM? | Bittensor offers both. Substrate for chain state, EVM for smart contracts. |
| Endpoint type | Shared public, shared premium, or dedicated? | Public endpoints have rate limits; dedicated nodes offer consistent performance. |
| Geographic latency | Provider node locations | Lower latency reduces response times for time-sensitive applications. |
| Reliability guarantees | Upstream redundancy, failover | Ensure your provider maintains high availability and handles load spikes. |
| Archive data | Full history needed? | Archive nodes allow historical queries; essential for analytics or auditing. |
| Support for WebSockets | Real-time subscriptions? | Required for live feeds (e.g., new blocks, event logs). |
| Pricing model | Pay-as-you-go vs. fixed monthly | Match 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:
| Field | Value |
|---|---|
| Network Name | Bittensor Finney |
| RPC URL (EVM) | https://lite.chain.opentensor.ai/ or any provider endpoint |
| Chain ID | 964 (0x3C4) |
| Currency Symbol | TAO |
| Block Explorer | https://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:
| Field | Value |
|---|---|
| Network Name | Bittensor Testnet |
| RPC URL (EVM) | https://test.chain.opentensor.ai/ or provider endpoint |
| Chain ID | 945 (0x3B1) |
| Currency Symbol | Test TAO |
| Block Explorer | https://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:
| Criterion | What to check | Why it matters |
|---|---|---|
| API layer support | Substrate and EVM | Ensure the provider exposes both; some only offer one. |
| Rate limits | Requests per second (RPS) | Production dApps need high RPS; shared free endpoints may throttle. |
| Geographic distribution | Node locations | Global nodes reduce latency for users worldwide. |
| Uptime SLA | Provider's historical uptime | Important for production applications. |
| WebSocket support | Real-time subscriptions | Required for live updates (e.g., new blocks, events). |
| Archive access | Full historical state | Needed for analytics or backtesting. |
| Pricing transparency | Per-request or fixed monthly | Choose 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.aimay return429 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.