DEV Community: OnFinality

BNB Smart Chain API: Endpoints, Methods, and Best Practices

OnFinality — Wed, 05 Aug 2026 02:31:11 +0000

Quick Answer: What Is the BNB Smart Chain API?

The BNB Smart Chain API is a set of JSON-RPC endpoints that let applications read and write data on BNB Smart Chain (BSC). It follows the Ethereum JSON-RPC standard, so if you've used eth_getBalance or eth_sendRawTransaction on Ethereum, you already know how to use BSC. The API is the bridge between your dApp and the chain—whether you're fetching a token balance, submitting a swap, or listening for new blocks.

Decision Guide: Choosing the Right BNB Smart Chain API Access

Before you start coding, decide how your app will connect to BSC. The choice affects latency, reliability, and cost. Here's a quick framework:

Prototyping or hackathon: Use a public RPC endpoint. It's free and fine for light testing, but it may rate-limit or become unreliable under load.
Production dApp with moderate traffic: Use a managed RPC provider. You get stable endpoints, higher throughput, and support. OnFinality offers BNB Smart Chain RPC endpoints with predictable pricing and a list of supported networks.
High-throughput or data-heavy workloads: Consider a dedicated node. You get exclusive access, no noisy neighbors, and the ability to run archive or trace queries without impacting other users.
Need WebSocket for real-time updates: Ensure your provider supports WSS endpoints. Most managed providers do, but public endpoints often don't.

Chain Settings at a Glance

When configuring your wallet or dApp, you'll need these BSC network parameters:

Parameter	Mainnet	Testnet
Chain ID	56	97
Currency	BNB	tBNB
RPC URL	`https://bsc-dataseed.binance.org/` (public)	`https://data-seed-prebsc-1-s1.binance.org:8545/` (public)
Block explorer	`https://bscscan.com`	`https://testnet.bscscan.com`

For production, replace the public URL with a managed endpoint from a provider like OnFinality. You can find the official BSC endpoints in the BNB Chain docs.

Essential JSON-RPC Methods for BSC

Because BSC is EVM-compatible, the core methods are identical to Ethereum. Here are the ones you'll use most:

eth_blockNumber – get the latest block number
eth_getBalance – get the balance of an address
eth_call – execute a read-only contract call
eth_sendRawTransaction – broadcast a signed transaction
eth_getTransactionReceipt – get the receipt of a transaction
eth_getLogs – fetch event logs
eth_estimateGas – estimate gas for a transaction

BSC also has some BEP-specific methods, like eth_getFinalizedBlock for fast finality (BEP-126). Check the official API list for the full reference.

Making Your First Request with cURL

You can test any RPC endpoint with a simple cURL command. Replace YOUR_RPC_URL with your endpoint.

curl -X POST YOUR_RPC_URL \
  -H "Content-Type: application/json" \
  -d '{
    "jsonrpc": "2.0",
    "method": "eth_blockNumber",
    "params": [],
    "id": 1
  }'

Expected response:

{
  "jsonrpc": "2.0",
  "id": 1,
  "result": "0x1a2b3c"
}

The result is a hex-encoded block number. Convert it to decimal to get the human-readable number.

Using the API with ethers.js or viem

If you're building a JavaScript dApp, use a library like ethers or viem. Here's an example with viem:

import { createPublicClient, http } from 'viem';
import { bsc } from 'viem/chains';

const client = createPublicClient({
  chain: bsc,
  transport: http('YOUR_RPC_URL'),
});

const blockNumber = await client.getBlockNumber();
console.log('Current block number:', blockNumber);

const balance = await client.getBalance({
  address: '0x...',
});
console.log('Balance (BNB):', Number(balance) / 1e18);

With ethers v6:

import { ethers } from 'ethers';

const provider = new ethers.JsonRpcProvider('YOUR_RPC_URL');
const blockNumber = await provider.getBlockNumber();
console.log('Current block number:', blockNumber);

WebSocket Subscriptions for Real-Time Data

For live updates—like new blocks or pending transactions—use WebSocket. Most managed providers offer WSS endpoints.

import { createPublicClient, webSocket } from 'viem';
import { bsc } from 'viem/chains';

const client = createPublicClient({
  chain: bsc,
  transport: webSocket('wss://YOUR_WSS_URL'),
});

const unwatch = client.watchBlockNumber({
  onBlockNumber: (blockNumber) => {
    console.log('New block:', blockNumber);
  },
});

Common Pitfalls and How to Avoid Them

Rate limiting: Public endpoints often throttle requests. If you hit 429 errors, switch to a managed provider or implement retry logic.
Chain ID mismatch: Ensure your app uses chain ID 56 for mainnet and 97 for testnet. A wrong chain ID will cause transaction failures.
Gas estimation: BSC gas prices can spike during congestion. Use eth_estimateGas and set a reasonable gas limit to avoid failed transactions.
Finality: BSC has fast finality (BEP-126), but not all nodes support the new finality methods. If you rely on finality, check your provider's support.
WebSocket disconnects: Implement reconnection logic to handle dropped connections.

Production Readiness Checklist

Before you ship, verify these points:

[ ] Use a managed RPC provider with a reliable SLA, not a public endpoint.
[ ] Set up monitoring for RPC errors and latency.
[ ] Implement fallback to a secondary provider in case of outage.
[ ] Use WebSocket for real-time features, but with reconnection handling.
[ ] Test on BNB testnet first.
[ ] Review RPC pricing to choose the right plan for your traffic.

Key Takeaways

The BNB Smart Chain API is EVM-compatible, so you can reuse Ethereum tooling.
Choose your access method based on your workload: public for testing, managed for production, dedicated for high throughput.
Use the correct chain ID and testnet endpoints during development.
Monitor your RPC usage and plan for rate limits.

Frequently Asked Questions

What is the difference between BNB Smart Chain and BNB Beacon Chain?

BNB Smart Chain is an EVM-compatible blockchain for smart contracts and dApps, while BNB Beacon Chain handles staking and governance. The API for BSC is what you'll use for most development.

Can I use Ethereum libraries with BSC?

Yes, because BSC is EVM-compatible, you can use ethers, viem, web3.js, and other Ethereum libraries with the BSC API.

What is the BSC testnet API?

It's the same JSON-RPC API but on the testnet network (chain ID 97). Use it to test your dApp without real funds. OnFinality provides BNB testnet RPC endpoints.

How do I get a BNB Smart Chain API key?

You don't need a key for public endpoints, but for production, you'll want a managed provider. OnFinality offers API keys through its API service.

What is the cost of using the BNB Smart Chain API?

Public endpoints are free but unreliable. Managed providers charge based on usage. Check RPC pricing for details.

How do I choose between a shared and dedicated node?

Shared nodes are cost-effective for most apps. Dedicated nodes are better for high traffic, data-intensive workloads, or when you need archive data. See dedicated node options.

Related resources

Originally published at OnFinality.

Blockchain API Service: What It Is and How to Choose

OnFinality — Wed, 05 Aug 2026 02:30:38 +0000

Quick recommendation: what to look for first

If you are evaluating a blockchain API service, start by mapping your workload to the type of access you need. A simple wallet or dApp that reads balances and sends transactions can often use a shared public endpoint. An analytics platform that replays historical state or a high-throughput trading bot usually needs archive data or a dedicated node.

Before comparing vendors, write down your expected request volume, whether you need WebSocket subscriptions, and whether you need trace or archive methods. That short list will filter most options immediately. For a practical starting point, you can test any JSON-RPC endpoint with a single curl command, as shown later in this article.

What a blockchain API service actually does

A blockchain API service is a hosted layer that lets your application interact with one or more blockchain networks without you operating nodes. Instead of syncing a full node and keeping it healthy, you send HTTP or WebSocket requests to a provider's endpoint, and the provider routes them to the underlying network.

The most common interface is JSON-RPC, a stateless protocol where each request is a JSON object with a method and parameters. For example, eth_blockNumber returns the latest block number on an Ethereum-compatible chain. Providers often also offer REST endpoints for higher-level data like token balances or transaction history, but the core is usually RPC.

A blockchain API service is not the same as a block explorer API. Explorer APIs, like Blockchain.com's, give you access to indexed data such as blocks, transactions, and addresses for a specific chain. RPC services give you direct access to node methods, which is what you need to build a dApp that submits transactions or reads contract state.

Types of blockchain API services

The market splits into a few broad categories. Knowing which one fits your project avoids paying for features you do not need or hitting limits you did not expect.

Public RPC endpoints

Public endpoints are free and open, often run by the network foundation or community. They are fine for prototyping and low-volume testing. The tradeoff is reliability: they can rate-limit aggressively, go down during network congestion, or change without notice. You should not depend on them for a production app.

Shared RPC providers

Shared providers operate clusters of nodes and expose them through a single API key or URL. Multiple customers share the same infrastructure, which keeps costs low. You get better reliability than public endpoints, but you are still subject to fair-use limits. This is the most common choice for early-stage dApps and developer tools.

Dedicated nodes

A dedicated node gives you exclusive access to a synchronized node instance. You can run heavy queries, use archive or trace methods, and avoid noisy-neighbor effects. This is the right choice for analytics platforms, indexers, and applications with sustained high request rates. Dedicated nodes cost more, but they offer predictable performance.

Data and indexer APIs

Some services go beyond raw RPC and provide indexed, human-readable data. They might offer REST endpoints for token prices, NFT metadata, or transaction history. These are convenient, but they add a layer of abstraction. If you need raw on-chain state, you still need an RPC service.

How to evaluate a blockchain API service

Once you know the type you need, compare providers on a few concrete criteria. The table below summarizes what to check and why it matters.

Criterion	What to check	Why it matters
Network coverage	Which chains are supported, including testnets	Avoids switching providers for each chain you add
Method support	Does it support archive, trace, or debug methods?	Analytics and debugging need more than basic methods
Rate limits	Requests per second and daily caps	Determines if your traffic fits a shared plan
WebSocket support	Real-time subscriptions for pending transactions or logs	Essential for dApps that need live updates
Reliability	Historical uptime and redundancy	Production apps need consistent availability
Pricing model	Pay-as-you-go vs. monthly subscription	Aligns cost with your actual usage
Support	Documentation, community, and SLAs	Helps you resolve issues quickly

For a deeper dive into provider selection, see our guide on choosing an RPC provider.

Making your first JSON-RPC request

Most blockchain API services follow the same JSON-RPC pattern. Here is a curl example that fetches the latest block number from an Ethereum-compatible endpoint. Replace the URL with your provider's endpoint.

curl -X POST https://your-provider.example/v1/your-api-key \
  -H "Content-Type: application/json" \
  -d '{"jsonrpc":"2.0","method":"eth_blockNumber","params":[],"id":1}'

The response will look like this:

{"jsonrpc":"2.0","id":1,"result":"0x134c2b4"}

The result is a hex-encoded block number. You can convert it to decimal to see the current height.

If you are using a JavaScript library like ethers or viem, the provider handles the JSON-RPC details for you. Here is a viem example:

import { createPublicClient, http } from 'viem';
import { mainnet } from 'viem/chains';

const client = createPublicClient({
  chain: mainnet,
  transport: http('https://your-provider.example/v1/your-api-key'),
});

const blockNumber = await client.getBlockNumber();
console.log(blockNumber);

Common use cases and which service fits

Different applications have different needs. Here is a quick mapping to help you decide.

Wallet or simple dApp: A shared RPC provider is usually enough. You need basic methods like eth_getBalance, eth_sendRawTransaction, and eth_call.
DeFi dashboard: You might need WebSocket subscriptions for price updates and pending transactions. A shared provider with WebSocket support works.
Analytics platform: You need archive data to query historical state. A dedicated node with archive access is the right choice.
High-frequency trading bot: Low latency and high throughput are critical. A dedicated node with a private connection minimizes network overhead.
NFT marketplace: You need to read token metadata and track transfers. A data API can simplify this, but you still need RPC for minting and trading.

Build versus buy: when to run your own node

Running your own node gives you full control and avoids per-request fees. It is a good learning experience and can be cost-effective for a single chain with steady traffic. However, it comes with operational overhead: you need to handle sync, upgrades, monitoring, and failover. If you support multiple chains, the cost multiplies.

A blockchain API service shifts that burden to the provider. You pay a subscription or usage fee, but you get redundancy, security patches, and support. For most teams, the tradeoff favors using a service, especially in the early stages. As you scale, you can revisit the decision and possibly run a hybrid setup.

Getting started with OnFinality

OnFinality offers a blockchain API service that covers a wide range of networks, including Ethereum, Solana, Polkadot, and many others. You can start with a free tier and upgrade as your needs grow. Our RPC pricing page explains the plans, and our supported networks page lists all available chains.

To get started, create an API key, choose your network, and use the endpoint in your application. You can also request a dedicated node if you need exclusive access or archive data.

Key Takeaways

A blockchain API service lets you interact with blockchains without running your own nodes.
Public endpoints are fine for testing, but production apps need a reliable provider.
Choose between shared and dedicated nodes based on your workload and performance needs.
Evaluate providers on network coverage, method support, rate limits, WebSocket support, and pricing.
Start with a simple JSON-RPC request to test any service before committing.

Frequently Asked Questions

What is the difference between a blockchain API and an RPC?

A blockchain API is a broad term for any interface that lets you interact with a blockchain. RPC (Remote Procedure Call) is a specific protocol, usually JSON-RPC, that is the standard for node communication. Most blockchain API services expose RPC endpoints.

Do I need a blockchain API service to build a dApp?

Yes, in most cases. Your dApp needs to read and write data on-chain, and a blockchain API service provides the connection. You could run your own node, but that adds significant operational overhead.

How much does a blockchain API service cost?

Pricing varies widely. Some providers offer free tiers with rate limits, while dedicated nodes can cost hundreds of dollars per month. Check the provider's pricing page for details. OnFinality's RPC pricing is transparent and scales with usage.

Can I use a blockchain API service for multiple chains?

Yes, many providers support multiple networks. OnFinality, for example, supports dozens of chains through a single API key. This simplifies your infrastructure and reduces the number of vendors you need to manage.

What is an archive node and why would I need it?

An archive node stores the full historical state of a blockchain, allowing you to query past balances and contract states. It is essential for analytics platforms and applications that need to audit historical data. Not all API services offer archive access, so check before you commit.

How do I choose between a shared and a dedicated node?

Start with a shared node if your traffic is moderate and you want to keep costs low. Move to a dedicated node when you need consistent performance, heavy queries, or archive/trace methods. Monitor your usage and upgrade when you hit limits.

What should I do if my requests are rate-limited?

First, check your provider's rate limit policy. You can optimize your code to cache responses and reduce request frequency. If you still need more throughput, consider upgrading to a higher tier or a dedicated node. OnFinality's dedicated node option gives you exclusive access without shared limits.

Are blockchain API services secure?

Reputable providers implement security best practices, such as encryption, access controls, and monitoring. However, you should always protect your API keys and never expose them in client-side code. Use environment variables and server-side proxies when possible.

Can I switch providers later?

Yes, most providers use standard JSON-RPC, so switching is usually straightforward. You update your endpoint URL and API key. However, if you rely on provider-specific features like webhooks or data APIs, you may need to adjust your code. Plan for portability from the start.

What is the best blockchain API service for beginners?

For beginners, a provider with a generous free tier and good documentation is ideal. OnFinality offers a free tier and a simple onboarding process. You can start with a public endpoint and upgrade as your project grows.

Related resources

Originally published at OnFinality.

Bittensor TAO Mining: Hardware, Setup, and RPC Tips

OnFinality — Wed, 05 Aug 2026 02:30:06 +0000

Quick Recommendation: Pick a Subnet Before You Buy Hardware

Before you spend money on GPUs or start configuring a miner, decide which subnet you want to mine on. Bittensor is not a single mining algorithm. Each subnet defines its own work, scoring, and hardware requirements. The subnet you choose determines your hardware, your expected rewards, and your competition.

For beginners, the best approach is to start with a subnet that matches your existing skills and hardware. If you have a gaming PC with a modern GPU, you can mine on subnets that require inference or compute. If you have storage capacity, look for storage-focused subnets. If you have no specialized hardware, you can still mine on subnets that reward lightweight tasks, but expect lower rewards.

Check the subnet's emission rate and the number of registered miners. High-emission subnets attract more competition, while new subnets may offer easier entry but lower immediate rewards. Use a Bittensor explorer to compare subnets before committing.

Once you pick a subnet, you need a reliable connection to the Bittensor chain. Your miner must register a hotkey and periodically send heartbeats and score updates. If your RPC endpoint is slow or unreliable, your miner may miss deadlines and get deregistered. Consider using a managed RPC provider like OnFinality to keep your miner connected without running your own archive node. See RPC pricing and supported RPC networks for options.

What Is TAO Mining on Bittensor?

Bittensor is a decentralized machine intelligence network. Instead of solving hash puzzles, miners produce digital commodities—compute, inference, storage, prediction—that validators score. The network pays miners in TAO based on the value they contribute.

Mining on Bittensor involves three roles:

Miners provide the commodity and are scored by validators.
Validators score miners and set weights.
Subnet creators define the incentive mechanism for their subnet.

As a miner, you register a hotkey on a subnet and receive a UID. Your miner software then performs the subnet's task and submits results to the chain. Validators verify your work and assign scores. Your TAO rewards depend on your score relative to other miners and the subnet's emission rate.

Unlike proof-of-work, there is no block reward for hashing. Instead, TAO is emitted continuously to subnets based on their stake and performance. This means your mining income is not fixed; it varies with your performance and the subnet's success.

Hardware Requirements: What You Actually Need

Hardware requirements vary by subnet. Some subnets require high-end GPUs, while others can run on a CPU or even a Raspberry Pi. Always check the subnet's documentation before buying hardware.

Here is a general breakdown:

Subnet Type	Example Tasks	Typical Hardware
Inference	Text generation, image generation	High-end GPU (e.g., NVIDIA A100, RTX 4090)
Compute	Machine learning training, data processing	Multiple GPUs or TPUs
Storage	Data storage and retrieval	Large hard drives, decent CPU
Prediction	Market prediction, forecasting	CPU with good RAM
Lightweight	Simple tasks, API calls	CPU, low RAM

For a gaming PC, you can start with subnets that require a single GPU. Many subnets have a minimum hardware requirement listed in their README. If you exceed the minimum, you may have an advantage, but competition is fierce.

Keep in mind that mining on Bittensor is not passive. You need to keep your miner online and responsive. If your hardware fails or your internet drops, you may miss deadlines and lose your UID.

How to Register a Hotkey and Start Mining

To mine on Bittensor, you need a wallet with a coldkey and a hotkey. The coldkey holds your TAO, and the hotkey is used for mining operations. You can create a wallet using the Bittensor CLI or the Bittensor SDK.

Here is a basic workflow:

Install the Bittensor SDK and CLI using uv or pip.
Create a wallet with btcli wallet create.
Fund your coldkey with TAO for registration fees and transaction costs.
Register your hotkey on your chosen subnet with btcli subnet register.
Run your miner using the subnet's miner script.

Registration costs a small amount of TAO and may require a stake. The exact fee varies by subnet and network congestion.

Here is an example of registering a hotkey using the CLI:

# Create a new wallet
btcli wallet create --wallet-name my_miner

# Register your hotkey on subnet 1
btcli subnet register --netuid 1 --wallet-name my_miner --hotkey my_hotkey

After registration, you will receive a UID. Your miner software will use this UID to submit work. Make sure your miner is configured with your wallet and hotkey.

Choosing the Right RPC Endpoint for Your Miner

Your miner needs to communicate with the Bittensor chain to register, submit scores, and stay active. The default endpoint may be a public RPC provided by the Bittensor team, but public endpoints can be rate-limited or unreliable.

For production mining, you have two options:

Run your own subtensor node and use its RPC endpoint.
Use a managed RPC provider like OnFinality.

Running your own node gives you full control but requires storage, bandwidth, and maintenance. A managed RPC provider handles the infrastructure for you, offering reliable endpoints with failover and load balancing. This is especially useful if you run multiple miners or need high availability.

OnFinality provides Bittensor RPC endpoints that you can use with your miner. Check the Bittensor Finney network page for endpoint details. You can also compare RPC pricing to see if managed RPC fits your budget.

Here is an example of setting your miner to use a custom RPC endpoint:

import bittensor as bt

subtensor = bt.subtensor(network="wss://your-endpoint.onfinality.io")
# Now use subtensor to query the chain

Make sure your endpoint supports WebSocket connections, as many miner operations use WebSocket for real-time updates.

Common Failure Modes and How to Debug Them

Mining on Bittensor can fail in several ways. Here are common issues and how to fix them:

Deregistration: If your miner misses too many deadlines, you may be deregistered. Check your miner logs for errors and ensure your RPC endpoint is responsive.
Stale scores: If your miner submits scores late, validators may ignore them. Use a low-latency RPC endpoint and ensure your miner is not overloaded.
Connection errors: If your RPC endpoint goes down, your miner cannot communicate with the chain. Use a provider with failover, or run your own node with monitoring.
Insufficient stake: Some subnets require a minimum stake to stay registered. Check your subnet's requirements.
Hardware failure: If your GPU overheats or your disk fills up, your miner may crash. Monitor your hardware and set up alerts.

To debug, start by checking your miner logs. Look for error codes and messages. The Bittensor SDK provides machine-readable error codes that can help you identify the issue. If you are using a managed RPC provider, check their status page for outages.

Here is a simple monitoring script that checks if your miner is still registered:

import bittensor as bt

subtensor = bt.subtensor(network="wss://your-endpoint.onfinality.io")
wallet = bt.wallet(name="my_miner", hotkey="my_hotkey")

uid = subtensor.get_uid_for_hotkey(wallet.hotkey.ss58_address, netuid=1)
if uid is None:
    print("Miner is deregistered!")
else:
    print(f"Miner is registered with UID {uid}")

Monitoring Your Miner and Maximizing Rewards

To maximize your TAO rewards, you need to monitor your miner's performance and adjust your strategy. Key metrics to track:

Score: Your score relative to other miners on the subnet.
Emission: The amount of TAO your subnet receives.
Uptime: The percentage of time your miner is online and submitting work.
Latency: The time it takes for your miner to submit results.

Use a Bittensor explorer like Taostats to monitor your miner's status and the subnet's health. You can also set up alerts for deregistration or score drops.

If your score is low, consider improving your hardware, optimizing your miner code, or switching to a less competitive subnet. If your subnet's emission is declining, you may want to migrate to a more promising subnet.

Remember that mining is competitive. Even with the best hardware, you may not earn a profit if the subnet is oversaturated. Do your research and be prepared to adapt.

Key Takeaways

Bittensor TAO mining is not proof-of-work; it involves providing useful work that validators score.
Choose a subnet that matches your hardware and skills before investing in equipment.
Register a hotkey and fund your wallet with TAO for fees.
Use a reliable RPC endpoint to keep your miner connected and avoid deregistration.
Monitor your miner's score, uptime, and emission to maximize rewards.
Consider managed RPC providers like OnFinality for high availability and failover.

Frequently Asked Questions

Can I mine Bittensor with a gaming PC?

Yes, many subnets require only a single GPU, which a gaming PC can provide. Check the subnet's hardware requirements before starting.

What is the best subnet to mine on?

There is no single best subnet. It depends on your hardware, skills, and risk tolerance. High-emission subnets are competitive, while new subnets may offer easier entry.

How much does it cost to register a miner?

Registration costs a small amount of TAO, which varies by subnet and network congestion. You also need TAO for transaction fees.

Do I need to run my own node to mine?

No, you can use a public RPC endpoint or a managed provider like OnFinality. Running your own node gives you more control but requires maintenance.

What happens if my miner goes offline?

If your miner misses deadlines, you may be deregistered. Use monitoring and reliable RPC to minimize downtime.

Can I mine on multiple subnets?

Yes, you can register your hotkey on multiple subnets, but you need to run separate miner instances for each.

Is TAO mining profitable?

Profitability depends on your hardware, electricity costs, subnet competition, and TAO price. Do your own research and start small.

For more details on RPC endpoints and network support, visit our supported RPC networks page and RPC pricing page.

Related resources

Originally published at OnFinality.

Best JSON-RPC API Provider for Blockchain Projects

OnFinality — Wed, 05 Aug 2026 02:29:33 +0000

Decision Guide: How to Shortlist a JSON-RPC Provider

Before comparing vendors, define the workload your project actually needs. A simple balance-checking dApp has different requirements than a high-throughput indexer or a trading bot. Start by answering these questions:

Which chains do you need? Multi-chain projects should look for broad network coverage, while single-chain projects can prioritize depth on that chain.
What data access do you require? Archive data, trace methods, and WebSocket subscriptions are not available from every provider.
What is your traffic pattern? Spiky traffic needs flexible scaling, while steady traffic might benefit from predictable flat-rate pricing.
What is your budget? Compute-unit pricing can be unpredictable; request-based or flat-rate models are easier to forecast.

Once you have these answers, you can filter providers by the criteria below. For a deeper dive into the general selection process, see our guide on choosing an RPC provider.

What Is a JSON-RPC API Provider?

A JSON-RPC API provider runs blockchain nodes and exposes them via the JSON-RPC protocol. This lets your application read blockchain state, submit transactions, and subscribe to events without running your own infrastructure. Providers handle node synchronization, uptime, and scaling, so you can focus on building.

The protocol is standardized across most chains—Ethereum, BNB Chain, Polygon, and many others—but each chain has its own method set and quirks. A good provider abstracts these differences while giving you access to the full method surface.

Key Evaluation Criteria for JSON-RPC Providers

When comparing providers, focus on these technical and operational factors:

Method Support

Not all providers support every JSON-RPC method. For example, trace_* methods (like trace_block or trace_transaction) are essential for debugging and analytics but are resource-intensive and often restricted. Similarly, eth_getLogs with large block ranges can be limited. Check whether the provider supports the methods your application depends on.

Data Access: Archive vs. Full Nodes

Archive nodes store the complete historical state, enabling queries like eth_getBalance at any past block. Full nodes only keep recent state. If your project needs historical data, you need archive access. Some providers include archive data in higher tiers or as an add-on.

WebSocket Support

Real-time applications—like DEXs, trading bots, or notification systems—need WebSocket subscriptions (eth_subscribe) for push updates. Verify that the provider offers stable WebSocket endpoints and supports the subscription types you need.

Rate Limits and Fair Use

Every provider has rate limits, but they vary in transparency. Some use compute units (CUs) that weight methods differently, making costs unpredictable. Others use simple request counts or flat-rate tiers. Understand the limits and how they align with your traffic.

Uptime and Reliability

Look for providers with a track record of high availability, but be wary of absolute guarantees. Check if they offer multi-region redundancy and automatic failover. A provider that routes requests across multiple nodes can reduce the impact of individual node failures.

Pricing Model

Pricing models vary widely:

Compute-unit based: Each method costs a certain number of CUs. This can be flexible but hard to predict.
Request-based: Simple per-request pricing, easier to forecast.
Flat-rate tiers: Predictable monthly cost for a set of requests or capacity.
Free tiers: Useful for testing and small projects, but often have strict limits.

Choose a model that matches your budget and traffic predictability. For a transparent, request-based approach, check our RPC pricing.

Comparing Provider Types: Shared vs. Dedicated

Providers offer two main access modes:

Shared nodes: Multiple customers use the same node. This is cost-effective but can suffer from noisy neighbors and rate limiting.
Dedicated nodes: You get a private node or cluster. This offers better performance, isolation, and customization, but at a higher cost.

For production workloads with high throughput or strict latency requirements, dedicated nodes are often worth the investment. For development or low-traffic apps, shared nodes may suffice.

Workload-to-Provider Fit Table

Workload	Recommended Provider Type	Key Requirements
Simple dApp (balance, transactions)	Shared node	Basic methods, low latency
High-frequency trading bot	Dedicated node	WebSocket, low latency, high throughput
Indexer / analytics	Dedicated node	Archive data, trace methods, high request volume
Multi-chain wallet	Shared or dedicated	Broad network coverage, WebSocket
NFT marketplace	Shared or dedicated	`eth_getLogs`, WebSocket for events

How to Test a JSON-RPC Provider Before Committing

Before signing up, run a few practical tests:

Check method coverage: Send a request for a method you need, like trace_block, and see if it returns data.
Measure latency: Use a script to time requests from your deployment region.
Test WebSocket: Subscribe to a stream and see if it stays connected under load.
Review documentation: Clear docs and examples indicate a mature provider.
Check support: How responsive is their support team? Do they have a status page?

Here's a simple curl example to test a JSON-RPC endpoint:

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

For a more comprehensive test, use a script that sends a mix of read and write calls.

Common Pitfalls When Choosing a Provider

Ignoring archive needs: You might need historical data later; check if the provider offers it.
Overlooking WebSocket: If your app needs real-time updates, ensure WebSocket is supported.
Underestimating rate limits: Read the fine print on rate limits and compute units.
Not planning for failover: Relying on a single provider is risky. Consider a multi-provider strategy.
Choosing based on price alone: The cheapest option may lack critical features or reliability.

Why OnFinality for JSON-RPC Access?

OnFinality provides a reliable JSON-RPC API service with a focus on transparency and developer experience. We support a wide range of networks—from Ethereum and BNB Chain to Polkadot and Solana—and offer both shared and dedicated node options. Our pricing is request-based, so you can predict your costs without worrying about compute-unit formulas. You can explore our supported networks and pricing to see if we fit your project.

Key Takeaways

The best JSON-RPC provider depends on your specific workload, chain requirements, and budget.
Evaluate method support, archive data, WebSocket, rate limits, and pricing model.
Consider dedicated nodes for high-throughput or latency-sensitive applications.
Test providers with real requests before committing.
Plan for failover by using multiple providers or a provider with strong redundancy.

Frequently Asked Questions

What is the difference between a JSON-RPC provider and a data API provider?

A JSON-RPC provider gives you raw access to blockchain nodes, allowing you to call any method. A data API provider (like Covalent or Moralis) offers higher-level, indexed data via REST endpoints, which is easier to consume but less flexible.

Do I need archive node access?

If your application queries historical state (e.g., balances at past blocks), you need archive access. Otherwise, a full node may suffice.

How do I handle rate limits?

Understand the provider's rate limit policy and choose a plan that matches your traffic. For spiky traffic, consider a provider with flexible scaling or use multiple providers.

Can I use multiple RPC providers?

Yes, many teams use a fallback strategy where a secondary provider handles requests if the primary fails. This improves reliability but requires careful configuration.

What is a compute unit?

A compute unit is a measure of the computational cost of a JSON-RPC method. Providers use CUs to price requests, but the exact formula is often opaque. Request-based pricing is more transparent.

How do I migrate to a new provider?

Migration typically involves updating your RPC endpoint URL in your application configuration. Test thoroughly before switching to avoid downtime.

Related resources

Originally published at OnFinality.

Asset Hub Polkadot: RPC Endpoints, Assets, and Smart Contracts

OnFinality — Wed, 05 Aug 2026 02:29:00 +0000

Quick Recommendation: How to Connect to Asset Hub Polkadot

If you are building an application that needs to read balances, submit transactions, or query asset metadata on Asset Hub Polkadot, the fastest path is to use a managed RPC endpoint. You can start with the public endpoint wss://asset-hub-polkadot-rpc.polkadot.io for testing, but for production workloads you should evaluate a dedicated or high-tier public RPC provider that offers consistent performance and reliability. OnFinality provides RPC endpoints for Asset Hub Polkadot and other Polkadot system chains, with options ranging from free public endpoints to dedicated nodes. Check the supported networks list to confirm availability and see RPC pricing for rate limits and plan details.

For most developers, the decision comes down to:

Prototyping or low-traffic apps: Public endpoints are fine, but be aware of rate limits and potential downtime.
Production dApps: Use a managed provider with multiple endpoints, WebSocket support, and failover capabilities.
High-throughput or archival needs: Consider a dedicated node to avoid shared resource contention.

What Is Asset Hub Polkadot?

Asset Hub Polkadot (formerly known as Statemint) is a system parachain on the Polkadot network. It is designed to provide core functionality for issuing and managing on-chain assets, including fungible tokens, non-fungible tokens (NFTs), and, more recently, smart contracts. While the relay chain (Polkadot) handles security and consensus, Asset Hub focuses on asset logic—minting, burning, transferring, and metadata—efficiently and cost-effectively.

Key features include:

Native asset creation: Create and manage tokens with configurable permissions and metadata.
NFT support: Mint and transfer non-fungible assets.
Smart contracts: Deploy and interact with smart contracts using the pallet-revive (formerly pallet-contracts).
XCM integration: Move assets across parachains using cross-consensus messaging.
Low fees: Transactions on Asset Hub are typically cheaper than on the relay chain.

After the runtime upgrade to version 2.0.0, Asset Hub also hosts balances, staking, and governance features that previously lived on the relay chain, making it the primary network for everyday Polkadot activity.

Why Use Asset Hub Polkadot?

Asset Hub provides a standardized framework for asset management that is native to the Polkadot ecosystem. Here are the main reasons developers and projects choose it:

Cost efficiency: Creating and transferring assets on Asset Hub is significantly cheaper than on the relay chain.
Interoperability: Assets issued on Asset Hub can be transferred to other parachains via XCM, enabling cross-chain applications.
Smart contract support: With the addition of smart contract capabilities, developers can build DeFi, gaming, and other applications directly on Asset Hub.
Security: As a system parachain, Asset Hub benefits from the same shared security as the relay chain.

Chain Settings at a Glance

When connecting your application to Asset Hub Polkadot, you need the correct network configuration. Here are the essential details:

Setting	Value
Network Name	Asset Hub Polkadot
Chain ID	1000 (para ID)
RPC Endpoint (HTTPS)	`https://asset-hub-polkadot-rpc.polkadot.io`
RPC Endpoint (WSS)	`wss://asset-hub-polkadot-rpc.polkadot.io`
Token Symbol	DOT
Token Decimals	10
Block Explorer	Subscan

Note: These are public endpoints. For production, consider using a managed provider like OnFinality, which offers dedicated endpoints with better reliability. Check the Polkadot network page for OnFinality's specific endpoints.

Connecting to Asset Hub Polkadot with RPC

To interact with Asset Hub Polkadot, you can use JSON-RPC calls. Here's a simple curl example to get the latest block number:

curl -H "Content-Type: application/json" \
  -d '{"id":1, "jsonrpc":"2.0", "method":"chain_getHeader", "params":[]}' \
  https://asset-hub-polkadot-rpc.polkadot.io

For WebSocket subscriptions (e.g., listening to new blocks), you can use a tool like wscat or a JavaScript library. Here's an example using the ws package in Node.js:

const WebSocket = require('ws');

const ws = new WebSocket('wss://asset-hub-polkadot-rpc.polkadot.io');

ws.on('open', function open() {
  ws.send(JSON.stringify({
    id: 1,
    jsonrpc: '2.0',
    method: 'chain_subscribeNewHeads',
    params: []
  }));
});

ws.on('message', function incoming(data) {
  console.log(data.toString());
});

For higher-level interaction, you can use the Polkadot.js API. Here's an example of querying the balance of an account:

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

async function main() {
  const provider = new WsProvider('wss://asset-hub-polkadot-rpc.polkadot.io');
  const api = await ApiPromise.create({ provider });

  const address = 'YOUR_ADDRESS_HERE';
  const { data: { free } } = await api.query.system.account(address);
  console.log('Free balance:', free.toString());

  await api.disconnect();
}

main().catch(console.error);

Managing Assets on Asset Hub Polkadot

Asset Hub supports both native and foreign assets. Native assets are issued directly on the parachain, while foreign assets are representations of assets from other chains, managed via XCM.

Creating a Fungible Asset

To create a new fungible asset, you need to submit an extrinsic using the assets pallet. Here's an example using Polkadot.js:

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

async function createAsset() {
  const provider = new WsProvider('wss://asset-hub-polkadot-rpc.polkadot.io');
  const api = await ApiPromise.create({ provider });

  const keyring = new Keyring({ type: 'sr25519' });
  const alice = keyring.addFromUri('//Alice');

  const tx = api.tx.assets.create(
    1, // asset ID
    alice.address, // admin
    1000000, // min balance
    100 // decimals
  );

  const hash = await tx.signAndSend(alice);
  console.log('Transaction hash:', hash.toHex());

  await api.disconnect();
}

createAsset().catch(console.error);

Transferring Assets

Transferring a fungible asset is straightforward:

const tx = api.tx.assets.transfer(
  1, // asset ID
  'RECIPIENT_ADDRESS',
  1000 // amount
);

NFTs

Asset Hub also supports NFTs through the uniques and nfts pallets. You can mint, transfer, and manage NFTs with similar extrinsics.

Smart Contracts on Asset Hub Polkadot

With the introduction of smart contract support, Asset Hub allows developers to deploy Wasm-based smart contracts using the pallet-revive. This opens up possibilities for building DeFi, gaming, and other applications directly on the network.

To deploy a contract, you typically use the polkadot.js UI or a development framework like @polkadot/contracts. The process involves:

Compile your contract to Wasm.
Upload the code to the chain.
Instantiate the contract with initial parameters.

Here's a simplified example of uploading contract code using Polkadot.js:

const code = fs.readFileSync('my_contract.wasm');
const tx = api.tx.contracts.upload(code, null, null);

Note that smart contract support is relatively new, so check the latest runtime documentation for exact APIs and requirements.

Common Pitfalls and Troubleshooting

When working with Asset Hub Polkadot, developers often encounter these issues:

Incorrect endpoint: Using a relay chain endpoint instead of the Asset Hub endpoint. Make sure you are connecting to asset-hub-polkadot.
Rate limiting: Public endpoints may throttle requests. If you hit rate limits, consider upgrading to a paid plan or dedicated node.
WebSocket disconnects: For long-running subscriptions, ensure your client handles reconnection logic.
Asset ID conflicts: When creating assets, choose a unique asset ID to avoid collisions.
Existential deposit (ED): Accounts must maintain a minimum balance (ED) to remain active. If an account drops below ED, it may be reaped.

Monitoring and Production Readiness

For production applications, you should monitor your RPC endpoints to ensure they are healthy. Here's a simple health check script using curl:

curl -s -X POST https://asset-hub-polkadot-rpc.polkadot.io \
  -H "Content-Type: application/json" \
  -d '{"jsonrpc":"2.0","method":"system_health","params":[],"id":1}'

A healthy response will include "isSyncing": false and "peers": >0. If you are using OnFinality, you can also set up uptime monitoring and alerts through your dashboard.

Key Takeaways

Asset Hub Polkadot is the system parachain for asset management, NFTs, and smart contracts in the Polkadot ecosystem.
It offers low fees, XCM interoperability, and shared security with the relay chain.
For development, use the public RPC endpoints; for production, consider a managed provider like OnFinality for reliability and support.
Common operations include creating and transferring assets, minting NFTs, and deploying smart contracts.
Always monitor your endpoints and handle rate limits and reconnections gracefully.

Frequently Asked Questions

What is the difference between Asset Hub Polkadot and the Polkadot relay chain?

The relay chain provides security and consensus, while Asset Hub handles asset logic and smart contracts. After the migration, Asset Hub also hosts balances, staking, and governance.

Can I deploy ERC-20 style tokens on Asset Hub Polkadot?

Yes, you can create fungible assets that behave similarly to ERC-20 tokens, but they are native to the Substrate runtime and use the assets pallet.

How do I get DOT for transaction fees on Asset Hub?

You need DOT to pay for transaction fees. You can acquire DOT from exchanges or faucets, and then transfer it to your Asset Hub account via XCM or a direct transfer.

Is Asset Hub Polkadot compatible with Ethereum tools?

No, Asset Hub is a Substrate-based chain, so it uses Polkadot.js and Substrate APIs. However, with smart contract support, you can use Wasm-based contracts, which are different from EVM contracts.

Where can I find the official documentation for Asset Hub?

Refer to the Polkadot Developer Docs and the Polkadot Wiki for detailed information.

How do I choose between public and dedicated RPC endpoints?

For production apps with high traffic, dedicated endpoints offer better performance and reliability. Evaluate your workload, rate limits, and budget. OnFinality offers flexible RPC pricing and dedicated node options.

Related resources

Originally published at OnFinality.

Dedicated Web3 Servers: When to Rent Infrastructure Instead of Running It

OnFinality — Wed, 05 Aug 2026 02:28:27 +0000

Decision guide: bare metal, cloud VM, or managed node service?

Before you compare hardware specs, decide which operational model fits your team. The choice usually comes down to three options:

Bare metal dedicated servers give you a physical machine with full root access, custom networking, and predictable performance. You handle OS updates, node software, monitoring, and failover yourself.
Cloud VMs (AWS, GCP, etc.) offer flexible scaling and lower upfront cost, but shared hypervisors and variable network performance can affect node sync and RPC latency.
Managed node services (like OnFinality's dedicated node offering) abstract away server management, patching, and scaling. You get a dedicated RPC endpoint without operating the hardware.

A quick heuristic: if you're running a validator or need low-level hardware control, bare metal is often the right fit. If you're building a dApp and just need reliable RPC access, a managed service saves significant engineering time. If you need both, you can run your own infrastructure for critical components and use a managed service for public-facing RPC.

What counts as a dedicated Web3 server?

A dedicated Web3 server is a single-tenant physical machine provisioned specifically for blockchain workloads. Unlike shared hosting, you get the entire CPU, RAM, storage, and network bandwidth. This matters for several reasons:

Consistent performance: No noisy neighbors competing for resources.
Full control: You can install custom kernels, tune network stacks, and configure firewalls.
Compliance and security: Some teams need to keep validator keys in a specific jurisdiction or on hardware they control.

Typical workloads include running full nodes, validator clients, indexers, and RPC endpoints. The hardware requirements vary by chain. For example, a Solana validator needs high clock speeds and fast NVMe storage, while an Ethereum archive node requires terabytes of SSD and large RAM.

Build-versus-buy tradeoffs

Running your own dedicated server gives you maximum flexibility, but it comes with hidden costs:

Time to maintain: You're responsible for OS patches, node software upgrades, and security hardening.
Scaling: Adding capacity means ordering new hardware or provisioning new servers, which can take days.
Geographic distribution: To reduce latency and improve decentralization, you may need servers in multiple regions, increasing complexity.

Managed services shift these burdens to a provider. OnFinality, for example, offers RPC pricing that includes free tier options and dedicated nodes that are provisioned quickly. You trade some control for operational simplicity.

What to look for in a dedicated Web3 server provider

If you decide to rent bare metal, evaluate providers on these criteria:

Criterion	What to check	Why it matters
Network quality	Bandwidth, peering, DDoS protection	Node sync and RPC latency depend on network path
Hardware specs	CPU generation, RAM, NVMe vs SATA	Blockchain workloads are I/O and compute intensive
Location	Data center regions	Proximity to other nodes and users reduces latency
Support	24/7 availability, response time	Downtime during a chain fork can be costly
Pricing model	Flat vs metered bandwidth	Predictable costs avoid egress surprises

Some providers specialize in Web3 and offer pre-configured node images. Others are general-purpose hosting companies. The right choice depends on your technical expertise and operational needs.

When a managed node service makes more sense

For many teams, especially those building dApps or indexers, a managed node service is more practical than renting dedicated servers. Here's why:

Faster time to market: You can get an RPC endpoint in minutes, not days.
Automatic scaling: Providers handle traffic spikes without you provisioning new hardware.
Built-in monitoring and failover: You don't have to build your own alerting and redundancy.

OnFinality's dedicated node service gives you a private RPC endpoint with dedicated resources, while the public API service offers shared endpoints for testing and low-traffic apps. You can start with a free tier and upgrade as you grow.

Example: connecting to a dedicated RPC endpoint

Once you have a dedicated RPC endpoint, you can use it like any other JSON-RPC URL. Here's a simple curl example to check the latest block number on an Ethereum-compatible chain:

curl -X POST https://your-dedicated-endpoint.example.com \
  -H "Content-Type: application/json" \
  -d '{"jsonrpc":"2.0","method":"eth_blockNumber","params":[],"id":1}'

In a JavaScript dApp using ethers.js, you can set the provider like this:

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

const provider = new ethers.JsonRpcProvider("https://your-dedicated-endpoint.example.com");

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

getBlockNumber();

Common pitfalls when running your own node

Even with dedicated hardware, you can run into issues:

Insufficient storage: Archive nodes grow quickly. Plan for 2-3x the current chain size.
Network misconfiguration: Firewall rules that block peer-to-peer ports can prevent sync.
Underpowered CPU: Some chains require high single-thread performance for block validation.
Lack of monitoring: Without alerts, you may not notice a stalled node until users complain.

Monitoring your dedicated server

Set up basic monitoring to catch problems early. A simple script can check if your node is responding:

#!/bin/bash
ENDPOINT="http://localhost:8545"
if curl -s -X POST $ENDPOINT -H "Content-Type: application/json" \
  -d '{"jsonrpc":"2.0","method":"eth_blockNumber","params":[],"id":1}' | grep -q "result"; then
  echo "Node is healthy"
else
  echo "Node is down"
  # Send alert via Slack, PagerDuty, etc.
fi

Key Takeaways

Dedicated Web3 servers provide predictable performance and control for blockchain workloads.
Evaluate build-versus-buy tradeoffs: bare metal requires significant operational overhead.
Managed node services like OnFinality can reduce time-to-market and simplify scaling.
When choosing a provider, compare network quality, hardware specs, location, and support.
Always monitor your node health and plan for storage growth.

Frequently Asked Questions

What is the difference between a dedicated server and a cloud VM?

A dedicated server is a physical machine exclusively for your use, while a cloud VM shares underlying hardware with other tenants. Dedicated servers offer more consistent performance and control.

Do I need a dedicated server to run a blockchain node?

Not necessarily. Many nodes run fine on cloud VMs, but dedicated servers are recommended for validators or high-traffic RPC endpoints where performance and reliability are critical.

Can I use a managed node service instead of renting a dedicated server?

Yes. Managed services like OnFinality provide dedicated RPC endpoints without you having to manage hardware. This is often the best choice for dApp developers.

How much does a dedicated Web3 server cost?

Costs vary widely based on hardware specs and provider. Entry-level servers start around $100-200 per month, while high-end configurations can exceed $1000. Managed node services often have usage-based pricing with free tiers.

What chains can I run on a dedicated server?

Most major blockchains can be run on dedicated hardware. OnFinality supports a wide range of networks; see the supported networks page for details.

Related resources

Originally published at OnFinality.

Dedicated TON Node: When to Use One and How to Choose

OnFinality — Wed, 05 Aug 2026 02:27:55 +0000

Quick recommendation: Do you need a dedicated TON node?

Before diving into setup and provider details, decide whether a dedicated node is the right investment for your project. A dedicated TON node gives you a single-tenant instance with your own RPC endpoint, but it also means you take on more operational responsibility and cost.

Consider a dedicated node if:

Your application has sustained traffic that regularly hits shared endpoint rate limits.
You need low-latency access for time-sensitive operations like trading or gaming.
You require custom node configuration, such as archive mode or specific ADNL settings.
You want to avoid noisy-neighbor effects from other users on shared infrastructure.
You need predictable performance for production SLAs.

If your project is still in development or has modest traffic, a shared RPC endpoint may be sufficient. OnFinality offers both shared and dedicated options, so you can start with a shared endpoint and upgrade as your needs grow. Check the supported RPC networks page to see TON availability.

What is a dedicated TON node?

A dedicated TON node is a full node that runs exclusively for your project. Unlike shared nodes, where multiple users share the same compute resources, a dedicated node is isolated, giving you full control over the node's configuration and performance.

TON nodes come in different modes:

Full node: Stores the latest blockchain state and serves data to lite-clients. It prunes older blocks to manage storage.
Archive node: Stores the entire blockchain history, including old blocks and states. Required for explorers and analytics services.
Validator node: Participates in consensus and block production. Usually not needed for RPC purposes.

For most RPC use cases, a full node or archive node is what you need. A dedicated node gives you a private endpoint that you can use for your dApp, wallet, or backend service.

Dedicated vs shared TON nodes: What's the difference?

The main difference between dedicated and shared nodes is resource isolation. With a shared node, you share CPU, memory, and network bandwidth with other users. This can lead to performance variability and rate limits. A dedicated node gives you exclusive access to the hardware, so you get consistent performance and clear rate limits (within the hardware's capacity).

Here's a quick comparison:

Aspect	Shared Node	Dedicated Node
Resource isolation	Shared with others	Exclusive to you
Rate limits	Common	clear rate limits (hardware-bound)
Performance	Variable	Consistent
Configuration	Limited	Full control
Cost	Lower	Higher
Operational effort	Provider handles	More responsibility

How to evaluate a dedicated TON node provider

When choosing a provider for a dedicated TON node, consider the following criteria:

Node type: Does the provider offer full, archive, and validator nodes? Do you need archive mode for historical data?
Protocol support: TON uses ADNL (Abstract Datagram Network Layer) for low-level communication. Does the provider support ADNL in addition to the standard HTTP API?
Hardware specifications: What CPU, RAM, and storage are allocated? NVMe storage is important for fast state access.
Geographic location: Where are the data centers? Choose a location close to your users to reduce latency.
Support and maintenance: Who handles node updates, monitoring, and troubleshooting? Direct engineering access can be valuable.
Pricing model: Is it a flat monthly fee or usage-based? Are there overage charges?

OnFinality's dedicated node service provides isolated infrastructure with flexible configuration. You can also compare pricing on the RPC pricing page.

Setting up a dedicated TON node: What to expect

Setting up a dedicated TON node involves several steps:

Choose your node type: Decide between full, archive, or validator.
Select a provider: Pick a provider that meets your requirements.
Provision the node: The provider deploys the node on dedicated hardware.
Sync the blockchain: The node downloads and verifies the blockchain state. This can take hours or days depending on the mode.
Configure access: Set up your RPC endpoint, API keys, and security settings.
Monitor and maintain: Keep the node updated and monitor its health.

Many providers offer managed dedicated nodes, where they handle the setup and maintenance for you. This can save time and reduce operational overhead.

TON RPC endpoint example

Once your dedicated node is running, you can interact with it using standard JSON-RPC calls. Here's an example using curl to get the latest block:

curl -X POST https://your-dedicated-endpoint.ton -H "Content-Type: application/json" -d '{
  "jsonrpc": "2.0",
  "method": "ton_getBlock",
  "params": [{"workchain": -1, "shard": -9223372036854775808, "seqno": 123}],
  "id": 1
}'

Note that TON's RPC methods differ from Ethereum's. You'll use methods like ton_getBlock, ton_getTransaction, and ton_sendMessage. For a full list, refer to the TON documentation.

Common pitfalls and troubleshooting

Running a dedicated TON node comes with its own challenges:

Sync issues: If your node falls behind, it may take time to catch up. Ensure you have enough storage and bandwidth.
ADNL configuration: ADNL is a low-level protocol that requires careful setup. If you're not familiar, consider using a provider that supports it.
Rate limiting: Even with a dedicated node, your provider may impose limits. Clarify this before signing up.
Maintenance windows: Providers may schedule maintenance that could affect availability. Ask about their policies.

If you encounter issues, check the node logs and ensure your configuration matches the provider's recommendations.

Key Takeaways

A dedicated TON node provides exclusive resources and a private RPC endpoint, ideal for production workloads.
Choose between full, archive, and validator nodes based on your use case.
Evaluate providers on hardware, protocol support, location, and support.
Managed dedicated nodes can reduce operational burden.
Always clarify rate limits and maintenance policies before committing.

Frequently Asked Questions

What is the difference between a full node and an archive node on TON?

A full node stores the latest blockchain state and prunes older blocks, while an archive node stores the entire history. Archive nodes are needed for explorers and historical data queries.

Do I need a dedicated TON node for a small dApp?

Probably not. Shared endpoints are often sufficient for development and low-traffic applications. You can upgrade to a dedicated node when your traffic grows.

Can I run a TON validator node as an RPC endpoint?

Yes, but validator nodes have additional responsibilities and may not be optimized for RPC serving. It's usually better to run a separate full node for RPC.

How long does it take to sync a TON archive node?

Sync time varies based on hardware and network conditions. It can take several days for an archive node. Providers may offer snapshots to speed up the process.

What is ADNL and why is it important for TON?

ADNL (Abstract Datagram Network Layer) is a secure, low-level communication protocol used by TON. Some advanced use cases require ADNL support, so check if your provider offers it.

Related resources

Originally published at OnFinality.

Arbitrum RPC Endpoint: Chain Settings and How to Connect

OnFinality — Wed, 05 Aug 2026 02:27:22 +0000

Quick reference: Arbitrum RPC endpoints and chain settings

If you just need the endpoint and chain details to configure a wallet or start coding, here is the short version. The official public RPC endpoints are rate-limited and do not support WebSocket, so they are fine for prototyping but not for production traffic.

Network	RPC URL	Chain ID	Explorer
Arbitrum One	`https://arb1.arbitrum.io/rpc`	42161	Arbiscan
Arbitrum Nova	`https://nova.arbitrum.io/rpc`	42170	Nova Explorer
Arbitrum Sepolia (testnet)	`https://sepolia-rollup.arbitrum.io/rpc`	421614	Sepolia Arbiscan

For production applications, you will typically use a managed RPC provider that offers higher rate limits, WebSocket support, and archive data. OnFinality provides RPC endpoints for Arbitrum and other networks, with pricing that scales with your usage.

How to connect to Arbitrum with curl

Arbitrum is EVM-compatible, so you can use standard JSON-RPC methods. Here is a quick curl example to get the latest block number:

curl https://arb1.arbitrum.io/rpc \
  -X POST \
  -H "Content-Type: application/json" \
  --data '{"jsonrpc":"2.0","method":"eth_blockNumber","params":[],"id":1}'

You should get a response like:

{"jsonrpc":"2.0","id":1,"result":"0x1d4c4b"}

The result is a hex-encoded block number. Convert it to decimal to get the current block height.

Using ethers.js or viem with Arbitrum

Most developers use a library like ethers.js or viem. Here is an example with ethers v6:

import { ethers } from "ethers";

const provider = new ethers.JsonRpcProvider("https://arb1.arbitrum.io/rpc");
const blockNumber = await provider.getBlockNumber();
console.log(blockNumber);

With viem, you can create a public client:

import { createPublicClient, http } from "viem";
import { arbitrum } from "viem/chains";

const client = createPublicClient({
  chain: arbitrum,
  transport: http("https://arb1.arbitrum.io/rpc"),
});

const blockNumber = await client.getBlockNumber();
console.log(blockNumber);

Adding Arbitrum to MetaMask or other wallets

If you want to add Arbitrum One to MetaMask manually, use these settings:

Network Name: Arbitrum One
New RPC URL: https://arb1.arbitrum.io/rpc
Chain ID: 42161
Currency Symbol: ETH
Block Explorer URL: https://arbiscan.io

For Arbitrum Nova, use chain ID 42170 and explorer https://nova.arbiscan.io. For Arbitrum Sepolia, use chain ID 421614 and explorer https://sepolia.arbiscan.io.

Official public endpoints vs. managed providers

The official public RPC endpoints are operated by the Arbitrum team and are free to use. However, they have limitations:

No WebSocket support: The public endpoints do not support wss:// connections. If your dApp needs real-time updates, you need a provider that offers WebSocket.
Rate limits: Public endpoints are shared and can be throttled under heavy load.
No archive data: They only serve recent state. If you need historical state, you need an archive node.
Sequencer endpoint: The sequencer endpoint (https://arb1-sequencer.arbitrum.io/rpc) only supports eth_sendRawTransaction and eth_sendRawTransactionConditional. It is not a general-purpose RPC endpoint.

For production, you should use a managed RPC provider that offers:

Higher rate limits and dedicated throughput
WebSocket support for subscriptions
Archive data and trace methods
Global edge caching for low latency
Failover and redundancy

OnFinality provides Arbitrum RPC endpoints as part of its supported networks, with flexible pricing for both shared and dedicated nodes.

How to choose an Arbitrum RPC provider

When evaluating an RPC provider for Arbitrum, consider these criteria:

Criterion	What to check	Why it matters
Rate limits	Requests per second (RPS) and daily quota	Determines if your app can handle peak traffic
WebSocket support	Does the provider offer `wss://` endpoints?	Needed for real-time data and subscriptions
Archive data	Does the provider offer archive nodes?	Required for historical queries and analytics
Trace methods	Does the provider support `debug_traceTransaction`?	Needed for debugging and indexing
Global coverage	Are there endpoints in multiple regions?	Reduces latency for users worldwide
Uptime SLA	What is the reliability expectations?	Ensures reliability for production apps
Pricing model	Pay-as-you-go vs. subscription	Affects cost predictability

For a deeper dive, see our guide on how to choose an RPC provider.

Common pitfalls and troubleshooting

1. Using the sequencer endpoint for general queries

The sequencer endpoint only accepts transaction submission. If you call eth_call or eth_getBalance on it, you will get an error. Use the regular RPC endpoint for reads.

2. WebSocket not supported on public endpoint

If you try to connect via wss://arb1.arbitrum.io/rpc, it will fail. Use a provider that supports WebSocket, or poll the HTTP endpoint instead.

3. Rate limiting

If you get 429 Too Many Requests, you are hitting the rate limit. Consider upgrading to a paid plan or using a dedicated node.

4. Chain ID mismatch

Make sure your wallet or dApp uses the correct chain ID: 42161 for Arbitrum One, 42170 for Nova, 421614 for Sepolia. A mismatch will cause transactions to be rejected.

5. Gas estimation issues

Arbitrum uses a different gas model than Ethereum. Use eth_estimateGas with the appropriate parameters, and be aware that L1 data fees are included in the gas price.

Monitoring your Arbitrum RPC health

To ensure your dApp stays healthy, monitor your RPC endpoint's latency and error rate. You can use a simple script to check the latest block number periodically:

while true; do
  curl -s -X POST https://arb1.arbitrum.io/rpc \
    -H "Content-Type: application/json" \
    --data '{"jsonrpc":"2.0","method":"eth_blockNumber","params":[],"id":1}' \
    | jq -r '.result' \
    | xargs printf "Block: %d\n"
  sleep 10
done

If the block number does not increase over time, your endpoint may be stale. Consider using a provider with failover.

Key Takeaways

The official Arbitrum RPC endpoints are https://arb1.arbitrum.io/rpc (One), https://nova.arbitrum.io/rpc (Nova), and https://sepolia-rollup.arbitrum.io/rpc (Sepolia).
Public endpoints are rate-limited and do not support WebSocket, so they are not suitable for production.
Use a managed provider like OnFinality for higher rate limits, WebSocket, archive data, and reliability.
Always verify the chain ID and use the correct endpoint for the network you intend to interact with.

Frequently Asked Questions

What is the Arbitrum RPC endpoint?

The Arbitrum RPC endpoint is a URL that allows wallets and dApps to communicate with the Arbitrum blockchain via JSON-RPC. The mainnet endpoint is https://arb1.arbitrum.io/rpc.

Does Arbitrum support WebSocket?

The official public RPC does not support WebSocket. You need a third-party provider that offers WebSocket endpoints, such as OnFinality.

How do I get an Arbitrum RPC URL?

You can use the public endpoint https://arb1.arbitrum.io/rpc for testing, or sign up for a managed provider to get a private endpoint with higher limits.

What is the chain ID for Arbitrum One?

The chain ID for Arbitrum One is 42161. For Arbitrum Nova it is 42170, and for Arbitrum Sepolia it is 421614.

Can I use the sequencer endpoint for general RPC calls?

No, the sequencer endpoint only supports eth_sendRawTransaction and eth_sendRawTransactionConditional. Use the regular RPC endpoint for other methods.

Related resources

Originally published at OnFinality.

Abstract RPC Provider: How to Evaluate and Choose

OnFinality — Wed, 05 Aug 2026 02:26:49 +0000

Quick recommendation: what to check before picking an Abstract RPC provider

If you are evaluating an Abstract RPC provider, the first thing to decide is whether you need a shared public endpoint or a dedicated node. Public endpoints are fine for prototyping and light usage, but production apps usually need a provider that offers:

Reliable uptime with load balancing across multiple nodes.
Support for Ethereum JSON-RPC plus zkSync-specific methods like eth_sendRawTransaction with paymaster params.
WebSocket support for real-time subscriptions.
Archive data if you need historical state or want to run indexers.
Clear rate limits and pricing that match your traffic.

Start by testing the provider's endpoint with your actual workload. Use the network page at Abstract network to get an endpoint and run a few calls. Then compare providers on the criteria below.

What is Abstract and why does it need a special RPC provider?

Abstract is a zero-knowledge rollup Layer 2 built on zkSync's ZK Stack, designed for consumer crypto applications. It inherits Ethereum's security while offering lower fees and faster transactions. It also features native account abstraction through the Abstract Global Wallet (AGW), letting users interact with apps using email or social logins.

Because Abstract is an EVM-compatible rollup, it exposes the standard Ethereum JSON-RPC interface, but it also adds zkSync-specific methods for things like paymasters and transaction batching. A good Abstract RPC provider must support both sets of methods.

How to evaluate an Abstract RPC provider

When comparing providers, focus on the following criteria:

Criterion	What to check	Why it matters
Network coverage	Mainnet and testnet (Sepolia) support	You need both for development and production
API compatibility	Full Ethereum JSON-RPC + zkSync methods	Missing methods break your dApp
Performance	Latency, throughput, and rate limits	Slow or throttled endpoints degrade user experience
Reliability	Uptime history, redundancy, failover	Downtime means lost transactions and users
Data availability	Archive data, trace support	Needed for indexers, analytics, and debugging
WebSocket support	WSS endpoints for subscriptions	Essential for real-time features
Pricing model	Pay-as-you-go vs. subscription	Must match your budget and traffic
Support	Documentation, community, SLAs	Helps you resolve issues quickly

Abstract network details at a glance

Here are the key network parameters you'll need to configure your wallet or dApp:

Parameter	Mainnet	Testnet
Network name	Abstract Mainnet	Abstract Testnet
Chain ID	2741	11124
Currency symbol	ETH	ETH
Block explorer	Abscan	Testnet explorer

How to connect to Abstract RPC

You can connect to Abstract using any Ethereum-compatible library. Here's an example using ethers.js:

import { ethers } from "ethers";

const provider = new ethers.JsonRpcProvider("https://rpc.example.com/abstract");

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

getBlockNumber();

For a WebSocket subscription, use:

const wsProvider = new ethers.WebSocketProvider("wss://rpc.example.com/abstract");

wsProvider.on("block", (blockNumber) => {
  console.log("New block:", blockNumber);
});

What methods does an Abstract RPC provider need to support?

Beyond standard Ethereum methods, you should verify support for zkSync-specific methods:

eth_sendRawTransaction with paymaster parameters
zks_getConfirmedTokens
zks_getBridgeContracts
zks_estimateFee

Check the provider's documentation to confirm they support these.

Common pitfalls when using an Abstract RPC provider

Using the wrong chain ID – Double-check that you're using 2741 for mainnet and 11124 for testnet.
Ignoring rate limits – Public endpoints often have strict limits; use a provider with higher limits for production.
Not handling WebSocket reconnections – Implement reconnection logic to avoid missed events.
Assuming archive data is included – Archive access is often a paid add-on.

How to test an Abstract RPC provider

Before committing, run a simple load test to see how the provider handles concurrent requests. You can use a tool like hey or a custom script. Here's a basic curl example:

curl https://rpc.example.com/abstract \
  -X POST \
  -H "Content-Type: application/json" \
  --data '{"jsonrpc":"2.0","method":"eth_blockNumber","params":[],"id":1}'

Monitor response times and error rates. Also test WebSocket connections for stability.

When to consider a dedicated Abstract node

If your application has high traffic, requires low latency, or needs custom configuration, a dedicated node might be better. Dedicated nodes offer:

Isolated resources – No noisy neighbors.
Custom settings – You can tune the node for your use case.
Higher rate limits – No shared throttling.

OnFinality offers dedicated node options for teams that need this level of control.

How to choose between free and paid Abstract RPC providers

Free endpoints are great for development, but they often have rate limits and no uptime guarantees. For production, consider a paid provider that offers:

Service level agreements – reliability expectations (but verify the terms).
Priority support – Faster resolution of issues.
Scalable pricing – Pay for what you use.

Check RPC pricing to see how OnFinality structures its plans.

Key Takeaways

Abstract is an EVM-compatible ZK rollup, so your RPC provider must support both Ethereum and zkSync methods.
Evaluate providers on network coverage, API compatibility, performance, reliability, data availability, and pricing.
Use the correct chain IDs: 2741 for mainnet, 11124 for testnet.
Test your provider with real workloads before going to production.
Consider a dedicated node if you need higher throughput or custom configuration.

Frequently Asked Questions

What is an Abstract RPC provider?

An Abstract RPC provider is a service that offers JSON-RPC endpoints to interact with the Abstract blockchain. It handles node infrastructure, so you don't have to run your own node.

How do I get an Abstract RPC endpoint?

You can get a free endpoint from public providers or sign up for a paid service. OnFinality provides endpoints for Abstract on its network page.

What is the Abstract chain ID?

The Abstract mainnet chain ID is 2741, and the testnet chain ID is 11124.

Does Abstract support WebSocket?

Yes, most providers offer WSS endpoints for real-time subscriptions.

Can I use Ethereum libraries with Abstract?

Yes, because Abstract is EVM-compatible, you can use ethers.js, viem, web3.js, and other Ethereum tools.

What are zkSync-specific RPC methods?

Methods like zks_estimateFee and zks_getBridgeContracts that are unique to zkSync-based rollups.

How do I choose between a shared and dedicated Abstract RPC?

Shared endpoints are cost-effective for low to medium traffic. Dedicated nodes are better for high traffic, low latency, or custom needs.

Does OnFinality support Abstract?

Yes, OnFinality provides Abstract RPC endpoints. Check the supported networks page for details.

Related resources

Originally published at OnFinality.

Sepolia Beacon RPC: Endpoints, Methods, and Setup

OnFinality — Tue, 04 Aug 2026 01:29:59 +0000

Sepolia Beacon RPC Decision Checklist

Before you start building on the Sepolia beacon chain, make sure you have:

A working Beacon RPC endpoint (public or private)
An understanding of the consensus layer API structure (/eth/v1/...)
A way to authenticate if you're using a provider with API keys
A block explorer for the beacon chain (e.g., Beaconcha.in) for debugging
Awareness of rate limits on public endpoints

What Is the Sepolia Beacon RPC?

The Sepolia Beacon RPC is the API endpoint for the consensus layer of the Sepolia testnet. While the standard Sepolia RPC (often called the execution RPC) lets you interact with smart contracts and transactions, the Beacon RPC exposes data about validators, attestations, beacon blocks, and finality. This is essential for staking applications, validator monitoring tools, and any dapp that needs to understand the state of the proof-of-stake chain.

Sepolia is a permissioned testnet with a closed set of validators, which makes it more stable and predictable than other testnets. This makes it a good choice for testing staking-related features or any application that depends on consensus data.

Key Beacon RPC Endpoints

Beacon RPC endpoints follow the standard Ethereum consensus API specification. The base URL is typically https://<provider>/eth/v1/ or https://<provider>/eth/v2/. Here are the most common paths:

/eth/v1/beacon/genesis – Get the genesis time and fork version
/eth/v1/beacon/headers – Get beacon block headers
/eth/v1/beacon/blocks/{block_id} – Get a specific beacon block
/eth/v1/beacon/states/{state_id}/validators – Get validator information
/eth/v1/beacon/states/{state_id}/finality_checkpoints – Get current finality checkpoints
/eth/v1/validator/duties/attester/{epoch} – Get attester duties (requires authentication)

Common Beacon RPC Methods

Here are a few examples of how to call these endpoints using curl:

# Get the genesis information
curl https://your-provider.com/eth/v1/beacon/genesis

# Get the latest beacon block header
curl https://your-provider.com/eth/v1/beacon/headers/head

# Get validators for the current state
curl https://your-provider.com/eth/v1/beacon/states/head/validators

These endpoints return JSON responses that include fields like slot, proposer_index, state_root, and body_root. You can use these to track the health of the beacon chain, monitor validator performance, or build dashboards.

Sepolia Beacon RPC vs. Execution RPC

It's important to understand the difference between the two RPC types:

Aspect	Beacon RPC	Execution RPC
Layer	Consensus layer	Execution layer
Data	Validators, blocks, finality	Transactions, smart contracts, balances
API style	RESTful (`/eth/v1/...`)	JSON-RPC (`eth_*` methods)
Use cases	Staking, monitoring, consensus analysis	dapps, DeFi, NFT, general Web3

Most applications need both. For example, a staking dashboard might use the Beacon RPC to show validator status and the execution RPC to show rewards in ETH.

How to Choose a Sepolia Beacon RPC Provider

When selecting a provider for Sepolia Beacon RPC, consider the following criteria:

Criterion	What to check	Why it matters
Endpoint support	Does the provider offer `/eth/v1` and `/eth/v2` endpoints?	Ensures compatibility with your tooling
Rate limits	What are the request limits on free/public tiers?	Public endpoints can throttle your app
Uptime	Does the provider publish status or uptime history?	Testnet reliability affects your development flow
Authentication	Is an API key required?	Affects how you configure your app
WebSocket support	Is there a WebSocket endpoint for real-time data?	Useful for subscriptions and live updates
Geographic distribution	Are there multiple regions?	Reduces latency for global users

For production-grade testnet development, you might want a provider that offers dedicated nodes or higher rate limits. OnFinality provides RPC services for Sepolia and many other networks, with options for dedicated nodes if you need more control.

Setting Up Your Development Environment

To start using the Sepolia Beacon RPC, you'll typically:

Get an endpoint – Either use a public endpoint or sign up for a provider like OnFinality to get a private endpoint with an API key.
Configure your tool – Many tools like curl, Postman, or custom scripts can use the endpoint directly.
Test the connection – Run a simple request like /eth/v1/beacon/genesis to verify.

Here's an example using JavaScript with fetch:

const endpoint = 'https://your-provider.com/eth/v1/beacon/genesis';

fetch(endpoint)
  .then(response => response.json())
  .then(data => console.log(data.data));

Troubleshooting Common Issues

401 Unauthorized: If you're using a provider with an API key, make sure you've included it in the request header or URL.
Rate limiting: Public endpoints often have strict rate limits. If you hit them, consider upgrading to a paid plan or using a dedicated node.
Endpoint not found: Double-check the URL path. The Beacon API uses /eth/v1/ and /eth/v2/ prefixes, not the JSON-RPC path.
Data inconsistency: If you see different results from different providers, it might be due to syncing delays. Check the slot and epoch in the response.

Key Takeaways

The Sepolia Beacon RPC gives you access to consensus layer data, essential for staking and validator applications.
Use the standard /eth/v1/ and /eth/v2/ endpoints for compatibility.
Choose a provider that offers reliable uptime, reasonable rate limits, and the endpoints you need.
OnFinality provides RPC services for Sepolia and many other networks, with pricing that scales with your needs.

Frequently Asked Questions

What is the difference between Sepolia Beacon RPC and Sepolia RPC?

The Sepolia Beacon RPC is for the consensus layer, while the standard Sepolia RPC is for the execution layer. They serve different purposes and have different API styles.

Can I use the Sepolia Beacon RPC to send transactions?

No, the Beacon RPC is read-only for consensus data. To send transactions, you need the execution RPC.

Is the Sepolia Beacon RPC free?

Many providers offer free public endpoints, but they may have rate limits. For higher limits, you may need a paid plan.

How do I get an API key for Sepolia Beacon RPC?

If you use a provider like OnFinality, you can sign up and create an API key from the dashboard. The key is then used in your requests.

What is the chain ID for Sepolia?

The chain ID is 11155111, and the network ID is also 11155111.

Next Steps

Now that you understand the Sepolia Beacon RPC, you can start building your testnet application. If you need a reliable endpoint, check out OnFinality's supported networks and RPC pricing to find a plan that fits your needs.

Related resources

Originally published at OnFinality.

How to Choose a Kaia RPC Provider for Production Apps

OnFinality — Tue, 04 Aug 2026 01:29:26 +0000

Kaia RPC Provider Decision Checklist

Before you commit to a Kaia RPC provider, run through this checklist so you don't discover a blocker after you've built your app:

Reliability: Public endpoints can throttle or go down under load. For production, look for a provider with an uptime commitment and redundant infrastructure.
Latency: Where are the provider's nodes located? If your users are in Asia, a provider with nodes in that region will give lower round-trip times.
Data access: Do you need archive data or trace methods? Not all providers offer them. Verify support for methods like kaia_getLogs, debug_traceTransaction, and kaia_call.
WebSocket support: For real-time subscriptions (e.g., pending transactions, new blocks), you need a WSS endpoint. Check if it's included and whether it has separate rate limits.
Rate limits: Public endpoints often cap requests per second. Read the fine print to avoid sudden 429s. Some providers offer higher limits on paid plans.
Pricing model: Compare pay-as-you-go, flat-rate, and dedicated node plans. Some providers have free tiers for low-volume testing.
Support: What happens when something breaks? Look for 24/7 support, a status page, and clear documentation.

Why the Right Kaia RPC Provider Matters

Kaia (formerly Klaytn) is an enterprise-focused L1 blockchain designed for high throughput and low latency, particularly popular in Asia for fintech and consumer apps. If you're building a dApp on Kaia, your RPC provider is the bridge between your app and the chain. A slow or unreliable provider can cause timeouts, failed transactions, and a poor user experience.

Public RPC endpoints are convenient for testing, but they're not built for production workloads. They can be rate-limited, have no uptime guarantee, and may not support advanced methods like tracing. That's why most production teams use a managed RPC provider or run their own node.

Public vs. Private Kaia RPC: What's the Difference?

Public endpoints are free and easy to use, but they come with trade-offs:

Rate limits: Public nodes often throttle requests to prevent abuse. You might hit a cap during traffic spikes.
No SLA: There's no guarantee of uptime. If the node goes down, your app goes down.
Limited data: Some public endpoints don't serve archive data or support trace methods.
Shared infrastructure: You're sharing the node with many other users, so performance can be unpredictable.

Private RPC providers (like OnFinality) offer dedicated or shared infrastructure with higher reliability, better performance, and more features. You get a dedicated endpoint URL, often with WebSocket support, archive data, and higher rate limits. The trade-off is cost, but for production apps, it's often worth it.

Key Criteria for Evaluating a Kaia RPC Provider

When comparing providers, focus on these criteria:

Criterion	What to check	Why it matters
Reliability	Uptime SLA, redundancy, status page	Downtime means lost revenue and user trust.
Latency	Node locations, p95 response times	High latency slows your app and can cause timeouts.
Data access	Archive data, trace methods, `kaia_getLogs` support	Some dApps need historical data or debugging tools.
WebSocket support	WSS endpoint, subscription methods	Real-time features require WebSocket.
Rate limits	Requests per second, daily/monthly caps	Hitting limits breaks your app.
Pricing	Cost per request, flat fees, free tier	You need predictable costs as you scale.
Support	24/7 support, documentation, community	When something breaks, you need help fast.

How to Test a Kaia RPC Provider Before Committing

Before you sign up, test the provider's endpoint with a few basic calls. Here's a quick way to check if the endpoint is responsive and returns correct data:

curl -X POST https://your-provider-endpoint \
  -H "Content-Type: application/json" \
  -d '{"jsonrpc":"2.0","method":"kaia_blockNumber","params":[],"id":1}'

You should get a response like:

{"jsonrpc":"2.0","id":1,"result":"0x123456"}

Also test a kaia_getBlockByNumber call to see if you can retrieve block data. If you need WebSocket, try connecting with a tool like wscat and subscribing to new heads.

Common Pitfalls When Choosing a Kaia RPC Provider

Ignoring rate limits: You might not notice them during testing, but they'll hit you in production. Always check the provider's rate limit policy.
Not checking WebSocket support: If your app needs real-time updates, a provider without WSS will be a dead end.
Assuming archive data is included: Archive nodes are more expensive to run. Some providers charge extra or don't offer it at all.
Choosing based on price alone: The cheapest provider might have poor reliability or support. Factor in the cost of downtime.
Not testing from your target region: Latency varies by location. Test from where your users are.

How to Migrate Between Kaia RPC Providers

If you're already using a provider and want to switch, the process is usually straightforward:

Get a new endpoint: Sign up with the new provider and get your RPC URL.
Update your config: Change the RPC URL in your dApp's configuration. If you use a library like ethers.js or web3.js, you'll update the provider URL.
Test thoroughly: Run your test suite against the new endpoint. Check that all methods work, including WebSocket subscriptions.
Monitor for a while: Run both endpoints in parallel for a few days to compare performance and reliability.
Switch over: Once you're confident, switch your production traffic to the new provider.

OnFinality as a Kaia RPC Provider

OnFinality offers managed Kaia RPC endpoints as part of its API service. You get a dedicated endpoint URL with support for both mainnet and testnet, WebSocket, and archive data. OnFinality's infrastructure is designed for high reliability and low latency, with nodes in multiple regions. You can start with a free tier and scale up as needed. Check the RPC pricing page for details.

OnFinality also supports dedicated nodes if you need a single-tenant infrastructure for maximum performance and isolation. This is useful for high-traffic apps or when you need custom configuration.

Key Takeaways

Public Kaia RPC endpoints are fine for testing but not for production.
Evaluate providers on reliability, latency, data access, WebSocket support, rate limits, and pricing.
Test endpoints with basic calls before committing.
Watch out for hidden limitations like missing archive data or WebSocket.
OnFinality offers managed Kaia RPC with flexible pricing and dedicated node options.

Frequently Asked Questions

What is the best Kaia RPC provider?

There's no single "best" provider; it depends on your needs. Evaluate providers based on the criteria in this guide. OnFinality is one option that offers managed Kaia RPC endpoints with a free tier.

Can I use public Kaia RPC endpoints for production?

It's not recommended. Public endpoints have rate limits and no uptime guarantee. For production, use a managed provider or run your own node.

Does OnFinality support Kaia testnet?

Yes, OnFinality supports both Kaia mainnet and testnet (Kairos). You can get endpoints for both through the API service.

How do I get a Kaia RPC URL from OnFinality?

Sign up for an OnFinality account, go to the API service, and create a Kaia endpoint. You'll get a URL you can use in your dApp.

What is the difference between shared and dedicated Kaia RPC?

Shared RPC means you share infrastructure with other users, which is cheaper but can have variable performance. Dedicated RPC gives you a single-tenant node for consistent performance and more control. OnFinality offers both options.

How do I troubleshoot Kaia RPC errors?

Common errors include rate limiting (HTTP 429), timeouts, and method not supported. Check the provider's documentation and status page. For OnFinality, you can contact support for help.

For more on choosing an RPC provider, see our guide on how to choose an RPC provider. Also, explore supported RPC networks to see if OnFinality covers other chains you need.

Related resources

Originally published at OnFinality.

SORA Network RPC: Endpoints, Setup, and Best Practices

OnFinality — Tue, 04 Aug 2026 01:28:54 +0000

SORA Network decision checklist

Before you build on SORA, make sure you have covered these points:

Understand the network's purpose: SORA is a Substrate-based chain focused on a decentralized economic system with the XOR token. It is not an EVM chain, so you will use Substrate RPC methods.
Choose the right endpoint: For production, use a managed RPC provider or run your own node. Public endpoints are for testing only.
Check WebSocket support: For real-time updates, you need WSS. Ensure your provider supports it.
Verify archive data needs: If you need historical state, confirm the provider offers archive nodes.
Plan for rate limits: Free tiers have limits. Estimate your traffic and choose a plan that fits.
Secure your API key: If using a managed service, keep your key secret and rotate it regularly.
Test with a simple call: Use chain_getBlockHash to verify connectivity before building.
Monitor performance: Set up alerts for latency and error rates to catch issues early.

What is the SORA Network?

The SORA Network is a decentralized blockchain designed to create a sovereign economic system. It uses the XOR token as its native asset, managed by a token bonding curve to adjust supply based on demand. The network supports democratic governance, allowing token holders to propose and vote on funding for projects. SORA also integrates with Polkaswap, a decentralized exchange, and aims for interoperability with other chains like Ethereum and Polkadot.

For developers, SORA offers a Substrate-based environment, meaning you can use standard Substrate RPC methods to interact with the chain. This includes querying balances, submitting transactions, and reading chain metadata.

Why RPC endpoints matter for SORA developers

RPC (Remote Procedure Call) endpoints are the gateway to the blockchain. They allow your dApp to read data and send transactions. Without a reliable endpoint, your application can experience downtime, slow responses, or failed transactions. For SORA, you need endpoints that support both HTTPS and WSS, as well as the specific methods required by Substrate.

When choosing an RPC provider, consider factors like uptime, latency, rate limits, and whether they offer archive data. A managed provider can save you the operational overhead of running your own node, but you should evaluate their performance and pricing.

How to connect to SORA: endpoints and setup

To connect to the SORA Network, you need an RPC endpoint. Here are the typical formats:

HTTPS: https://sora.api.onfinality.io/public (example, replace with actual)
WSS: wss://sora.api.onfinality.io/public (example, replace with actual)

You can test connectivity with a simple curl command:

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

For JavaScript, use the @polkadot/api library:

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

const wsProvider = new WsProvider('wss://sora.api.onfinality.io/public');
const api = await ApiPromise.create({ provider: wsProvider });

const chain = await api.rpc.system.chain();
console.log('Connected to', chain.toString());

Evaluating RPC providers for SORA

When choosing an RPC provider for SORA, use this checklist:

Criterion	What to check	Why it matters
Uptime	Historical uptime stats	Downtime breaks your app
Latency	Response time from your region	Slow responses hurt UX
Rate limits	Requests per second allowed	Limits can throttle your app
Archive data	Availability of historical state	Needed for analytics and debugging
WebSocket support	WSS endpoint availability	Required for real-time subscriptions
Security	API key management and encryption	Protects your data and access
Pricing	Cost per request or monthly fee	Must fit your budget
Support	Documentation and response times	Helps when issues arise

OnFinality offers RPC services for many networks, including SORA. You can check supported RPC networks and RPC pricing for details. For high-traffic or production workloads, consider a dedicated node for more control and performance.

Common pitfalls when using SORA RPC

Using public endpoints in production: Public endpoints are often rate-limited and unreliable. Use a managed provider or your own node.
Ignoring WebSocket for subscriptions: If you need live updates, you must use WSS. HTTPS only supports request-response.
Not handling rate limits: Even with a provider, you may hit limits. Implement retry logic and backoff.
Assuming EVM compatibility: SORA is Substrate-based, so use Substrate RPC methods, not Ethereum JSON-RPC.
Forgetting archive data: For historical queries, you need an archive node. Not all providers offer this.

Troubleshooting SORA RPC issues

If you encounter problems, try these steps:

Check your endpoint: Ensure the URL is correct and includes the right protocol (https/wss).
Test with a simple call: Use chain_getBlockHash to verify connectivity.
Review rate limits: If you get 429 errors, you are exceeding limits. Upgrade your plan or add caching.
Check for network issues: Use tools like ping or traceroute to diagnose latency.
Contact support: If using a provider, reach out for help. OnFinality offers support for its services.

Key Takeaways

The SORA Network is a Substrate-based blockchain focused on a decentralized economic system.
RPC endpoints are essential for dApp development; choose a reliable provider.
Evaluate providers based on uptime, latency, rate limits, archive data, and support.
Use WebSocket for real-time data and handle rate limits gracefully.
OnFinality provides RPC services for SORA and other networks; check supported networks and pricing.

Frequently Asked Questions

What is the SORA Network?

The SORA Network is a decentralized blockchain platform that aims to create a sovereign economic system. It uses the XOR token and a token bonding curve to manage supply, and it supports democratic governance and cross-chain interoperability.

How do I get a SORA RPC endpoint?

You can use a public endpoint for testing, but for production, consider a managed RPC provider like OnFinality. Visit supported networks to see if SORA is available and get your endpoint.

Is SORA compatible with Ethereum?

No, SORA is Substrate-based, so it uses Substrate RPC methods. However, it can interoperate with Ethereum through bridges.

What is the XOR token?

XOR is the native token of the SORA Network, used for governance, transaction fees, and as a medium of exchange. Its supply is managed by a bonding curve.

Can I run my own SORA node?

Yes, you can run a full node, but it requires technical expertise and maintenance. A managed provider can simplify this.

What are the rate limits for SORA RPC?

Rate limits vary by provider. OnFinality offers different plans; check RPC pricing for details.

Related resources

Originally published at OnFinality.