Todos los artículos
8 min de lectura

Alternativas a toncenter en 2026 para desarrolladores TON

Alternativas a toncenter en 2026: análisis honesto del config público, liteservers propios y MCP para TON. Throughput garantizado y herramientas no custodiales.

alternativa a toncenterTON APIMCP para TONliteserver TONerror 429TON para desarrolladores

Alternativas a toncenter en 2026: por qué chocas con HTTP 429 y liteservers compartidos

Acceder al estado de la red TON parece engañosamente simple: llamas a https://toncenter.com/api/..., recibes un JSON y todos contentos. Justo hasta el momento en que tu bot en producción empieza a consultar balances una vez por segundo y, al llegar a la décima wallet, en lugar de un balance recibes un muro: HTTP 429 Too Many Requests. El usuario escribe a soporte diciendo que su transacción "se quedó colgada", y tú miras los logs y entiendes que no chocaste con un bug, sino con el límite público compartido.

Si esto te suena, analicemos con honestidad qué alternativas a toncenter existen en 2026, en qué se diferencian en la práctica y qué toncenter alternative 2026 tiene sentido para tu caso concreto: desde un dashboard read-only hasta un agente de IA que arma swaps por su cuenta.

Las API HTTP públicas como toncenter y tonapi.io son una puerta cómoda a la red, pero es una puerta compartida. Detrás hay un pool de liteservers que se reparten todos los que no tienen API key. En cuanto superas el límite, la API responde con un honesto HTTP 429 Too Many Requests. Sin key, el techo ronda una petición por segundo. Para un formulario de "consultar una dirección" es suficiente. Para un bot, un indexador o un agente, no.

Un pequeño paréntesis sobre folclore. En la comunidad de TON circula un meme sobre el "error 228". Aclaremos: 228 es una broma, no un código de error de la API. El código real que verás cuando te apliquen rate limit es 429. Si alguien escribe que toncenter "devuelve 228", está repitiendo el meme, no leyendo la respuesta del servidor. Si lo que buscas es cómo superar precisamente ese techo, tenemos un análisis aparte sobre cómo arreglar el 429 de toncenter.

La limitación clave de las API públicas es que compartes el pool con miles de desarrolladores más. En cuanto tu aplicación necesita un throughput predecible y no "lo que te den", toca cambiar la forma misma de acceder a la red. A continuación, tres maneras de pasarte a algo propio.

Opción 1. El config público de TON: gratis, pero con letra pequeña

El primer paso "más allá del HTTP" es conectarte a la red directamente mediante el config global de TON (global.config.json) y hablar con los liteservers por el protocolo nativo ADNL desde un SDK como @ton/ton o tonutils-go. Es gratis, está más cerca del "metal" de la red y es lo que usan por defecto la mayoría de los SDK.

La letra pequeña, que se suele descubrir ya en producción:

  • Los liteservers del config global son compartidos y limitados. Bajo carga, a menudo responden not ready o directamente terminan en timeout de ADNL. No es un bug de tu código, es un nodo público saturado.
  • No guardan historial profundo. ¿Necesitas transacciones de hace un mes? Puede que ya no estén ahí.
  • Impredecibilidad. El conjunto de servidores vivos en el config cambia, y filtrar los nodos muertos te toca a ti.

Si ya te está saliendo liteserver not ready, mira el análisis práctico de por qué el liteserver responde not ready y qué hacer. Veredicto de esta opción: excelente para entornos de desarrollo y scripts puntuales, arriesgada para producción con carga.

Opción 2. Tu propio liteserver: control total a cambio de infraestructura

La solución radical es levantar tu propio nodo y tu propio liteserver. Entonces el throughput es solo tuyo, nadie más te lo consume, y tú decides cuánto historial conservar.

El precio del control es la infraestructura:

  • levantar un nodo TON y esperar la sincronización (si quieres profundidad de archivo, es lento y devora disco);
  • mantener el servidor vivo: monitoreo, reinicios, actualizaciones ante forks de la red;
  • vigilar que el nodo no se quede rezagado respecto al masterchain y resolver tú mismo la tolerancia a fallos y los backups.

Es el camino correcto para un equipo con recursos de DevOps y la necesidad de un throughput privado y predecible. Pero si tu tarea no es "operar infraestructura de TON" sino "leer la red rápido y armar transacciones", mantener un nodo propio para eso es matar moscas a cañonazos.

Opción 3. Servidor MCP: acceso para agentes de IA y aplicaciones

Una categoría aparte que hace un par de años no existía. MCP (Model Context Protocol) es el estándar mediante el cual los agentes de IA (Claude, Cursor, ChatGPT/Codex y cualquier cliente MCP) invocan herramientas externas. Un servidor MCP para TON hace que el "ve a la blockchain" deje de ser una petición HTTP manual y pase a ser una herramienta tipada que el agente llama por sí solo.

La diferencia con las opciones anteriores no está en "cómo llamar a la API más rápido", sino en quién la llama. Si en tu stack hay un agente, un asistente o una aplicación sobre un LLM, MCP elimina la capa de wrappers caseros: el agente simplemente pide get_balance y recibe la respuesta. Y de paso se resuelve el acceso a la red, sin competir por el límite público. Qué es MCP en el contexto de TON y para qué sirve lo explicamos en detalle en la guía de MCP para TON.

TONNode: throughput garantizado más herramientas no custodiales

TONNode (sitio: tonnode.io) es un servidor MCP hosteado para TON. Resuelve dos dolores de cabeza a la vez: te da throughput garantizado con tu propia key (es decir, te saca del 429 compartido) y añade herramientas de acción, no solo de lectura. El paquete @tonnode/mcp es open source (MIT), está en npm y GitHub (tonnode/mcp) y funciona por el protocolo nativo de TON, ADNL, sin capas HTTP intermedias.

Bajo el capó hay exactamente 16 herramientas MCP, agrupadas así.

Lectura (8)

  • get_masterchain_info — la cabeza del masterchain;
  • get_balance — balance de GRAM;
  • get_account_state — estado, flags, última transacción;
  • get_transactions — historial de transacciones;
  • run_get_method — cualquier get-method read-only de un contrato;
  • get_jetton_balance — balance de un jetton (por ejemplo, USDT); la dirección de la jetton wallet se calcula on-chain, no hace falta hacerlo a mano;
  • get_jetton_info — metadatos del jetton: nombre, símbolo, decimals, emisión (los decimals son críticos para convertir las unidades "crudas" en unidades humanas: USDT tiene 6, y la mayoría de los jettons, 9);
  • parse_address — conversión y validación de EQ/UQ/raw, totalmente offline.

Swap (2)

get_swap_quote (cotización firme de DEX GRAM⇄jetton vía el protocolo Omniston, sobre la liquidez de STON.fi y DeDust) y build_swap_tx (transacción de swap sin firmar, lista para TonConnect).

Cross-chain (5)

get_crosschain_quote, build_crosschain_swap_tx, track_crosschain_swap, disclose_crosschain_secret, build_crosschain_refund — escrow atómico HTLC, TON siempre como origen, y como redes destino: Ethereum, Arbitrum, Base, BNB Chain, Polygon, Avalanche.

Wallet (1)

generate_wallet — crear una wallet TON en versiones v3r2 / v4 / v5r1 / highload_v3.

La diferencia clave frente a las soluciones custodiales es la no custodia. Las herramientas de swap, cross-chain y wallet son estrictamente no custodiales: el servidor nunca firma ni guarda fondos ni claves privadas. Devuelve mensajes TonConnect sin firmar, que firma la wallet del propio usuario. La wallet generada con generate_wallet se te entrega a ti y no queda en el servidor. Es decir, el agente puede preparar un swap GRAM⇄jetton, pero pulsar "firmar" solo puede hacerlo el dueño de la clave.

Lo que honestamente no debes esperar ahora mismo: el nodo de archivo de TONNode todavía se está sincronizando y aún no atiende peticiones — el historial profundo no se puede prometer como algo listo, está en el roadmap. También existe el liteserver dedicado single-tenant, pero solo manualmente bajo pedido, no self-serve.

Nota terminológica: GRAM es el Toncoin renombrado en junio de 2026. La red en sí sigue llamándose TON. Si ves "GRAM" en las herramientas, es ese mismo coin nativo.

Cómo elegir la alternativa según tu caso

En resumen, por escenarios:

  • Script puntual, entorno de desarrollo, "solo leer una dirección". El config público de TON o el npx -y @tonnode/mcp local y gratuito. Costo cero, pero sin garantías bajo carga.
  • Backend con carga, indexador, requisito de throughput privado y control total del historial. Tu propio liteserver/nodo — si tienes el recurso de DevOps para mantenerlo.
  • Agente de IA, asistente o aplicación sobre un LLM que necesita leer la red y preparar transacciones (swap/cross-chain) de forma no custodial. Las herramientas MCP de TONNode — sin infraestructura propia.
  • Servicio read-heavy en producción que chocó con el 429 pero no quiere administrar un nodo. El endpoint MCP hosteado de TONNode con límite garantizado por key.

Si lo que estás comparando ahora son proveedores HTTP, tenemos un repaso aparte de las alternativas a tonapi en 2026.

Cómo conectar TONNode en un par de minutos

Puedes empezar sin registro y sin tarjeta — en local, vía npx. Esto te da el set completo de lectura gratis:

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

Después de esto, al agente le puedes hablar en lenguaje humano:

Consulta el balance de USDT en la dirección UQ… y muéstralo en unidades humanas.

El agente llamará por su cuenta a get_jetton_info (para conocer los decimals) y a get_jetton_balance — no hace falta tocar ninguna API a mano. Otros prompts típicos:

  • "¿Cuántos GRAM da un swap de 100 USDT ahora mismo?" → get_swap_quote.
  • "Arma la transacción sin firmar de un swap de 100 USDT a GRAM para mi wallet" → build_swap_tx (la firma la wallet del usuario, no el servidor).
  • "Muéstrame las últimas 10 transacciones del contrato EQC…" → get_transactions.
  • "Genera una wallet nueva v5r1" → generate_wallet.

Cuando choques con el techo de throughput o quieras las herramientas de acción con tu propia key, el mismo servidor se levanta como endpoint hosteado:

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

El pricing está montado con honestidad: en todos los planes están disponibles las 16 herramientas; solo pagas por el throughput.

  • Hobby — gratis para siempre, 60 peticiones/min;
  • Pro — $29/mes, 300 peticiones/min;
  • Scale — $199/mes, 1200 peticiones/min.

La key de Hobby se emite nada más iniciar sesión, sin tarjeta. Los planes de pago se abonan en GRAM o USDT en la red TON vía TonConnect, o en BTC/ETH/SOL y otras monedas mediante una factura de xRocket en Telegram.

Plan práctico: levanta npx -y @tonnode/mcp en un minuto, dale al agente un par de herramientas de lectura, comprueba que el esquema te encaja — y solo entonces toma una key con límite garantizado. El 429 de toncenter no es una sentencia contra tu código: es la señal de que superaste el límite público.

Consigue tu key Hobby gratis (60 peticiones/min, sin tarjeta) → tonnode.io/dashboard?plan=hobby

Dale a tu agente acceso a TON

16 herramientas MCP: lectura, swaps no custodiales, cross-chain y billeteras. Plan gratuito — 60 req/min, sin tarjeta.