Toncenter Alternatives in 2026 for TON Developers

Toncenter alternatives in 2026: why you keep running into HTTP 429 and shared liteservers

Reading state from the TON network looks deceptively simple: hit https://toncenter.com/api/..., get JSON back, ship it. Right up until your production bot starts polling balances once a second and, on the tenth wallet, gets a wall instead of a balance: HTTP 429 Too Many Requests. A user writes to support saying their transaction is "stuck," you stare at the logs, and it dawns on you that you haven't hit a bug — you've hit a shared public limit.

If that sounds familiar, let's honestly walk through what toncenter alternatives actually exist in 2026, how they differ in practice, and which toncenter alternative 2026 makes sense for your specific job: from a read-only dashboard to an AI agent that assembles swaps on its own.

Public HTTP APIs like toncenter and tonapi.io are a convenient door into the network — but it's a shared door. Behind it sits a pool of liteservers shared by everyone who hasn't set up a key. The moment you exceed the limit, the API responds with an honest HTTP 429 Too Many Requests. Without a key, the ceiling is roughly one request per second. For a "check a single address" form, that's plenty. For a bot, an indexer, or an agent — it isn't.

A quick detour into folklore. There's a meme floating around the TON community about "error 228." For the record: 228 is a joke, not an API error code. The real code you'll see when you get rate-limited is 429. If someone claims toncenter "returns 228," they're repeating the meme, not reading the server response. If it's specifically this ceiling you're trying to break through, we have a dedicated deep dive on how to fix toncenter 429.

The core constraint of public APIs is that you share the pool with thousands of other developers. Once your app needs predictable throughput rather than "whatever's left over," you have to change how you access the network in the first place. Below are three ways to move onto something of your own.

Option 1. The public TON config: free, with caveats

The first step "past HTTP" is connecting to the network directly via the TON global config (global.config.json) and talking to liteservers over the native ADNL protocol from an SDK like @ton/ton or tonutils-go. It's free, it's closer to the network's bare metal, and it's what most SDKs use by default.

The caveats you only discover in production:

• The liteservers in the global config are shared and rate-limited. Under load they frequently answer not ready or simply time out at the ADNL level. That's not a bug in your code — that's an overloaded public node.
• They don't keep deep history. Need transactions from a month ago? They may already be gone.
• Unpredictability. The set of live servers in the config keeps changing, and filtering out dead nodes is your problem.

If you're already seeing liteserver not ready, check out the practical breakdown of why a liteserver answers not ready and what to do about it. Bottom line for this option: great for dev environments and one-off scripts, risky for production under load.

Option 2. Your own liteserver: full control at infrastructure cost

The radical solution is to run your own node with your own liteserver. Then the throughput is yours alone, nobody next door is eating it, and you decide how much history to keep.

The price of control is infrastructure:

• spin up a TON node and wait for it to sync (for archive depth, that's slow and disk-hungry);
• keep the server alive: monitoring, restarts, upgrades for network forks;
• make sure the node doesn't fall behind the masterchain, and own failover and backups yourself.

This is the right path for a team with DevOps capacity and a hard requirement for private, predictable throughput. But if your job isn't "operate TON infrastructure" but "read the network fast and assemble transactions," maintaining your own node for that is using a sledgehammer to crack a nut.

Option 3. An MCP server: access for AI agents and apps

A separate category that simply didn't exist a couple of years ago. MCP (Model Context Protocol) is the standard AI agents (Claude, Cursor, ChatGPT/Codex, and any MCP client) use to call external tools. An MCP server for TON turns "go query the blockchain" from a hand-rolled HTTP request into a typed tool the agent calls on its own.

The difference from the previous options isn't "how to hit the API faster" — it's who does the hitting. If your stack includes an agent, an assistant, or an app built on top of an LLM, MCP removes the layer of hand-written wrappers: the agent simply asks for get_balance and gets an answer. And network access gets solved at the same time — no more racing everyone else for a slice of the public limit. What MCP means in the TON context and why it matters is covered in detail in the MCP for TON guide.

TONNode: guaranteed throughput plus non-custodial tools

TONNode (website: tonnode.io) is a hosted MCP server for TON. It solves two problems at once: it gives you guaranteed throughput on your own key (so no more shared 429) and adds action tools, not just reads. The @tonnode/mcp package is open source (MIT), lives on npm and GitHub (tonnode/mcp), and speaks TON's native ADNL protocol — no HTTP middlemen.

Under the hood there are exactly 16 MCP tools, grouped like this.

Reads (8)

• get_masterchain_info — the masterchain head;
• get_balance — GRAM balance;
• get_account_state — status, flags, last transaction;
• get_transactions — transaction history;
• run_get_method — any read-only get-method on a contract;
• get_jetton_balance — a jetton balance (USDT, for example); the jetton wallet address is derived on-chain, no manual math required;
• get_jetton_info — jetton metadata: name, symbol, decimals, supply (decimals are critical for converting raw units into human ones: USDT has 6, most jettons have 9);
• parse_address — convert and validate EQ/UQ/raw, fully offline.

Swap (2)

get_swap_quote (a firm DEX quote for GRAM⇄jetton via the Omniston protocol, on top of STON.fi and DeDust liquidity) and build_swap_tx (an unsigned swap transaction ready for TonConnect).

Cross-chain (5)

get_crosschain_quote, build_crosschain_swap_tx, track_crosschain_swap, disclose_crosschain_secret, build_crosschain_refund — atomic HTLC escrow, TON is always the source, destination networks: Ethereum, Arbitrum, Base, BNB Chain, Polygon, Avalanche.

Wallet (1)

generate_wallet — create a TON wallet, versions v3r2 / v4 / v5r1 / highload_v3.

The key difference from custodial services is that TONNode is non-custodial. The swap, cross-chain, and wallet tools are strictly non-custodial: the server never signs and never holds funds or private keys. It returns unsigned TonConnect messages that the user's own wallet signs. A wallet generated via generate_wallet is handed to you and never stored on the server. In other words, an agent can prepare a GRAM⇄jetton swap, but only the key's owner can press "sign."

What you honestly should not expect right now: TONNode's archive node is still syncing and doesn't serve requests yet — deep history can't be promised as a shipped feature, it's on the roadmap. A dedicated single-tenant liteserver also exists, but it's set up by hand on request — not self-serve.

Terminology footnote: GRAM is Toncoin, renamed in June 2026. The network itself is still called TON. If you see "GRAM" in the tools, that's the same native coin.

How to pick the right alternative for your job

Quickly, by scenario:

• One-off script, dev environment, "just read an address." The public TON config or a free local npx -y @tonnode/mcp. Zero cost, but no guarantees under load.
• A heavily loaded backend, an indexer, a requirement for private throughput and full control over history. Your own liteserver/node — if you have the DevOps capacity to maintain it.
• An AI agent, assistant, or LLM-powered app that needs to read the network and prepare transactions (swap/cross-chain) non-custodially. TONNode's MCP tools — no infrastructure on your side.
• A production read-heavy service that hit 429 but has no appetite for babysitting a node. TONNode's hosted MCP endpoint with a guaranteed limit on your key.

If what you're comparing right now is specifically HTTP providers, we have a separate review of tonapi alternatives in 2026.

Getting started with TONNode in a couple of minutes

You can start with no signup and no card at all — locally, via npx. That gets you the full read set for free:

{
  "mcpServers": {
    "ton": {
      "command": "npx",
      "args": ["-y", "@tonnode/mcp"]
    }
  }
}

After that you can just talk to the agent in plain language:

Check the USDT balance on address UQ… and show it in human-readable units.

The agent will call get_jetton_info on its own (to look up decimals) and then get_jetton_balance — no manual API calls needed. Other typical prompts:

• "How much GRAM would a 100 USDT swap get me right now?" → get_swap_quote.
• "Build an unsigned transaction swapping 100 USDT to GRAM for my wallet" → build_swap_tx (the user's wallet signs, not the server).
• "Show the last 10 transactions of contract EQC…" → get_transactions.
• "Generate a new v5r1 wallet" → generate_wallet.

Once you hit the throughput ceiling or want action tools on your own key, the same server comes up as a hosted endpoint:

{
  "mcpServers": {
    "ton": {
      "type": "http",
      "url": "https://mcp.tonnode.io/mcp",
      "headers": { "Authorization": "Bearer tn_live_…" }
    }
  }
}

The pricing is honest: every plan gets all 16 tools — you pay only for throughput.

• Hobby — free forever, 60 requests/min;
• Pro — $29/mo, 300 requests/min;
• Scale — $199/mo, 1200 requests/min.

The Hobby key is issued right after sign-in, no card required. Paid plans can be settled in GRAM or USDT on TON via TonConnect, or in BTC/ETH/SOL and others through an xRocket invoice in Telegram.

A practical plan: bring up npx -y @tonnode/mcp in a minute, hand your agent a couple of read tools, make sure the setup fits — and only then grab a key for a guaranteed limit. A 429 from toncenter isn't a verdict on your code; it's a signal you've outgrown the public limit.

Get a free Hobby key (60 requests/min, no card) → tonnode.io/dashboard?plan=hobby