TON RPC Provider Comparison: What to Check Before Going to Production

The Open Network (TON) is a sharded Layer-1 blockchain designed for high-throughput, low-cost transactions, powering a growing ecosystem of Telegram Mini Apps, DeFi protocols, and stablecoin payments. As traffic on TON grows—processing millions of transactions daily—choosing a reliable RPC provider becomes a make-or-break decision for your production application.

Unlike EVM chains, TON uses a unique architecture with workchains, shardchains, and the ADNL protocol. This means that not every RPC provider supports all TON features equally. This article walks through the key evaluation criteria, common pitfalls, and a practical checklist to help you select the best TON RPC provider for your app.

TON RPC Provider Decision Checklist

Use the table below to quickly compare providers against the most important criteria for production TON apps.

Key Evaluation Criteria in Detail

API Version Compatibility

TON currently has two main JSON-RPC API versions: v2 (legacy) and v3 (recommended). v3 introduces better error handling, reduced overhead, and new methods like sendBocReturnHash. Before signing up, verify that the provider explicitly lists support for your required API version. Most major providers support both, but some older offerings may only expose v2.

Archive Access

Many TON dApps need to query historical data—such as account balances at a past block or transaction history. Archive nodes store the entire chain state, which is expensive to run. If your application depends on historical queries, confirm that the provider offers archive endpoints and understand any additional costs. For example, some providers include archive access in higher-tier plans.

ADNL Protocol

TON's Abstract Datagram Network Layer (ADNL) enables direct node-to-node communication without HTTP overhead. While most common use cases (e.g., reading balances, sending transactions) work fine via JSON-RPC, advanced use cases like Jetton indexing, proof verification, or validator operations may benefit from ADNL. Not all RPC providers expose ADNL; if you need it, check the provider's documentation.

Latency and Geo-Distribution

TON nodes are run in data centers around the world. Latency directly impacts the speed of your dApp, especially for Telegram Mini Apps that expect near-instant responses. When evaluating providers, look for those with multiple points of presence (PoPs) and a global load balancer. You can test latency manually using tools like curl or by hosting your application close to the provider's nodes.

Making Your First TON RPC Call

Once you've chosen a provider, test the endpoint with a simple RPC request. Here's an example using curl to call the getMasterchainInfo method on a TON HTTP v2 endpoint:

curl -X POST https://ton-endpoint.example.com/api/v2/ -H "Content-Type: application/json" -d '{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "getMasterchainInfo"
}'

Expected response (trimmed):

{
  "ok": true,
  "result": {
    "last": {
      "workchain": -1,
      "shard": "-9223372036854775808",
      "seqno": 39922000,
      "root_hash": "...",
      "file_hash": "..."
    },
    "state_root_hash": "...",
    "init": {
      "workchain": -1,
      "shard": "-9223372036854775808",
      "seqno": 0,
      "root_hash": "...",
      "file_hash": "..."
    }
  }
}

For v3, the endpoint might be /api/v3/ and the method getMasterchainInfo remains the same. Always refer to your provider's documentation for exact URLs.

Common Pitfalls When Using TON RPC Providers

1. Method compatibility: Not all providers implement every TON RPC method. Methods like getBlockTransactions or getAccountStateBySeqno may be restricted on free tiers.
2. WebSocket endpoint misconfiguration: If your app uses WSS, verify the exact endpoint path (e.g., wss://ton-endpoint.example.com/ws). Some providers use differnet paths that break handshakes.
3. Rate limit behavior: Public free endpoints may return error codes like -504 (gateway timeout) when throttled. Check the error handling in your SDK.
4. Shard‑chain routing: TON's dynamic sharding means transactions can end up in different shards. An RPC call to a non‑masterchain shard might need a proxy. Providers usually handle this transparently, but be aware.
5. Faucet integration: For testnet, ensure the provider supports the sendGrams or sendTransaction method so you can request test TON from a remote faucet.

Dedicated vs Shared TON Nodes

When moving to production, you'll face a choice between shared (public/private) endpoints and dedicated nodes.

• Shared endpoints: Good for low‑to‑medium traffic with cost efficiency. Multiple users share the same node, which can lead to occasional performance variability. Typical use: early‑stage dApps, prototyping, low‑volume wallets.
• Dedicated nodes: A private node reserved for your traffic. Offers consistent performance, higher rate limits, and full control over node configuration (e.g., archive mode, custom indexers). Ideal for high‑volume dApps, Telegram Mini Apps serving millions of users, or applications requiring reliability expectations.

Providers like OnFinality offer both shared and dedicated TON node plans, allowing you to start with shared and upgrade seamlessly as your app scales. You can view the latest RPC pricing and supported networks to compare options.

Key Takeaways

• TON's unique architecture makes provider selection different from EVM chains. Always prioritize API version support, archive access, and ADNL if needed.
• Use the decision checklist to systematically evaluate providers against your must‑have criteria.
• Test your chosen provider with simple RPC calls before integrating deeply.
• Plan for growth: start with a shared endpoint, but move to a dedicated node when traffic ramps up to maintain performance.

Frequently Asked Questions

Q: How do I find a TON RPC endpoint URL? A: After signing up with a provider, you receive a unique endpoint URL in the dashboard. Most providers also list public test endpoints for quick testing.

Q: Is there a free TON RPC provider? A: Yes, several providers offer free tiers with limited requests per day (e.g., 100k–1M requests/month). OnFinality provides a free plan for development and small projects.

Q: What is the difference between TON HTTP v2 and v3? A: v3 is the latest API version with additional methods, improved error messages, and reduced overhead. v2 is legacy but still widely supported. Use v3 if your SDK allows.

Q: Can I run my own TON node instead of using a provider? A: Yes, you can run a TON node yourself, but it requires significant resources (high‑IO storage, stable network, maintenance) and costs roughly $150–$300/month. Managed RPC providers handle the operational complexity.

Q: How do I check a provider's latency? A: Use tools like ping to the endpoint domain or measure response time with curl timing (-w %{time_total}). Some providers publish latency dashboards.

Ready to get started? Explore the TON network page for detailed setup instructions and endpoint examples.