What Is a TON Public Node and When Should You Use One?

Is a TON public node the right starting point?

A TON public node is a shared RPC endpoint that lets your application read the TON blockchain and submit transactions without running your own infrastructure. It is the default entry point for most developers: you copy a URL, send a request, and get a response. No sync, no disk, no server to babysit.

The catch is that "public" means shared. You are one of many callers hitting the same endpoint, with no control over capacity, no service-level agreement, and no guarantee that a method you rely on will stay available. That is fine for a prototype, a script, or a wallet you are testing. It becomes a problem the moment real users depend on your app.

Use this article to decide which side of that line you are on, and what to do next.

Quick recommendation: public node, managed RPC, or dedicated node?

If you only need to answer "does my code work against TON?", a public node is the fastest path. If you need to answer "will my app stay up under load?", you have outgrown it.

How TON RPC differs from EVM chains

If you come from Ethereum, BNB Chain, or Polygon, TON will feel unfamiliar. TON is not an EVM chain, so you will not call eth_getBalance or eth_call. Instead, TON exposes its own HTTP-based API surface, and the way you address accounts, send messages, and read state is different.

A few practical differences matter when you pick an endpoint:

• Accounts are addressed differently. TON uses its own address formats, and the same account can be represented in more than one form. Your tooling needs to normalize addresses before you compare or store them.
• Transactions are message-driven. You do not simply "send a transaction" the way you would on an EVM chain. You build and send messages, and the resulting transaction is produced by the network.
• Method names are TON-specific. Instead of eth_* methods, you work with TON's own endpoints for account state, blocks, transactions, and message submission.
• Libraries matter. Most developers interact through a TON SDK rather than raw HTTP, because the SDK handles address parsing, cell serialization, and message construction for you.

Because of this, "which TON public node should I use?" is really two questions: which endpoint, and which client library sits on top of it.

Connecting to a TON endpoint

OnFinality exposes a TON RPC endpoint over HTTP. You can see the current endpoint details on the TON network page. The pattern for a raw JSON-RPC style call looks like this:

curl -s https://ton.api.onfinality.io/public \
  -H "Content-Type: application/json" \
  -d '{
    "jsonrpc": "2.0",
    "id": 1,
    "method": "getMasterchainInfo",
    "params": []
  }'

For most application code, you will not call the endpoint directly. You will point a TON SDK at it. A typical configuration looks like this:

import { TonClient } from "@ton/ton";

const client = new TonClient({
  endpoint: "https://ton.api.onfinality.io/public",
  apiKey: process.env.ONFINALITY_API_KEY, // required for managed plans
});

const masterchain = await client.getMasterchainInfo();
console.log(masterchain);

Two things to note. First, the exact endpoint path and whether an API key is required depend on the plan you are on, so confirm against the TON network page rather than copying a URL from an old tutorial. Second, keep the endpoint in an environment variable. Hardcoding it makes it painful to switch between a public endpoint, a managed endpoint, and a testnet endpoint.

Switching to TON Testnet

Testnet is a separate network with its own endpoint. Point your client at the TON Testnet RPC configuration when you want to test message flows without touching mainnet balances. Keep testnet and mainnet configuration in separate environment files so you never accidentally submit a mainnet message from a test run.

Where public TON nodes break down

Public endpoints are not broken by design; they are just not built for production traffic. The failure modes are predictable:

• Rate limiting. Shared endpoints throttle callers to protect the pool. A burst from your backend can get rejected even if your average load is low.
• Latency variance. You share capacity with everyone else, so response times move with overall demand.
• Method gaps. Some endpoints expose a subset of methods. If you need deeper history or heavier queries, a public node may not serve them.
• No support path. When something fails, there is no one to escalate to. You debug alone.
• No visibility. You cannot see whether a slowdown is your code or the endpoint.

None of these are fatal for a prototype. All of them are fatal for a product with users.

Production readiness checklist

Before you ship a TON app on any endpoint, including a public one, walk through this list:

1. Endpoint is configurable. It lives in an environment variable, not in source code.
2. Failover exists. You have at least one backup endpoint, or a provider that handles failover for you.
3. Retries are bounded. You retry on transient errors with backoff, and you stop after a limit.
4. You can see errors. Logging captures endpoint failures separately from application errors.
5. You know your request profile. Roughly how many calls per second, and which methods dominate.
6. You have a testnet path. You can reproduce issues on TON Testnet without risking mainnet funds.
7. You know your upgrade trigger. Decide now what metric (error rate, latency, or request volume) means "move to managed RPC."

If you cannot check most of these boxes, a public node is still the right place to be. If you can check them and the endpoint is the weak link, it is time to move.

When to move to managed RPC or a dedicated node

Managed RPC and dedicated nodes solve different problems, and it helps to separate them.

A managed RPC API gives you a stable endpoint with a key, monitoring, and a support path. You do not run anything. This is the right move for most production apps: it removes rate-limit surprises and gives you someone to talk to when a query fails. OnFinality provides this as an RPC API service across many networks, with TON included.

A dedicated node gives you isolated capacity. You are not sharing throughput with other callers, which matters for high-volume indexing, analytics, or workloads with tight latency needs. This is the right move when your request profile is heavy enough that shared capacity is the bottleneck. See dedicated nodes for how that works.

A simple way to decide:

• Prototype, script, or low-volume tool: public node.
• App with users and a backend: managed RPC API.
• Heavy, sustained, or latency-sensitive load: dedicated node.

You can compare cost and throughput expectations on the RPC pricing page, and see which networks are covered on supported RPC networks.

Debugging TON RPC calls

When a TON call fails, the error usually falls into one of a few buckets. Match the symptom to the likely cause before you change code.

A useful habit is to log the endpoint URL alongside every error. Half of "TON RPC is broken" reports turn out to be two environments pointing at different endpoints.

Operational habits that save time later

A few small practices make the move from public node to production much smoother:

• Pin endpoints per environment. Dev, staging, and production should each have one clearly named endpoint.
• Separate read and write paths. Reads can often tolerate a shared endpoint; writes usually deserve the most reliable one you have.
• Watch error rate, not just latency. A fast endpoint that rejects 5% of calls is worse than a slower one that accepts all of them.
• Keep an escape hatch. Know the URL you would switch to if your primary endpoint degrades, and test that switch before you need it.
• Document your methods. List the TON methods your app actually calls. That list is what you hand to a provider when you evaluate plans.

These habits cost little now and remove most of the pain of scaling later.

Key Takeaways

• A TON public node is a shared endpoint for reading TON data and submitting messages without running infrastructure.
• TON is not an EVM chain, so method names, address handling, and transaction flow differ from Ethereum-style RPC.
• Public nodes are ideal for prototypes, scripts, and low-volume tools, but they are shared, rate-limited, and unsupported.
• Move to a managed RPC API when you have real users; move to a dedicated node when shared capacity becomes your bottleneck.
• Keep endpoints in environment variables, plan failover, and decide your upgrade trigger before you ship.
• OnFinality offers TON RPC through its RPC API service and dedicated nodes; see RPC pricing and supported RPC networks for details.

Frequently Asked Questions

What is a TON public node?

It is a shared RPC endpoint that lets you interact with the TON blockchain without running your own node. You send requests to a URL and receive responses, but you share capacity with other users and have no service guarantee.

Is a TON public node free?

Public endpoints are typically free to use, which is why they are popular for testing. Free access usually comes with rate limits and no support, so it is not a good fit for production traffic.

Can I use a TON public node in production?

You can, but you should not rely on it. Shared endpoints throttle callers and offer no failover or support. For apps with real users, a managed RPC API is the safer choice.

What is the difference between a TON public node and a dedicated node?

A public node is shared with other callers. A dedicated node gives your workload isolated capacity, which matters for high-volume or latency-sensitive applications.

How do I connect to TON from JavaScript?

Use a TON SDK such as @ton/ton and point it at an endpoint. Keep the endpoint and any API key in environment variables so you can switch between public, managed, and testnet configurations.

Do I need a separate endpoint for TON Testnet?

Yes. Testnet is a separate network with its own endpoint. See the TON Testnet RPC page for the current configuration.

Where can I find the current TON RPC endpoint?

Check the TON network page for the endpoint details that apply to your plan, rather than copying a URL from an older tutorial.

When should I move off a public node?

When you have real users, a backend, or a bot that depends on consistent responses. If endpoint errors or rate limits are affecting your app, it is time to move to managed RPC or a dedicated node.