Swaps cross-chain de TON a Avalanche: cómo funcionan

Por qué un agente necesita mover valor de TON a Avalanche

Tu agente encontró un buen precio para un activo en Avalanche, pero todo su balance está en GRAM sobre TON. Lo que sigue es el infierno de siempre: retirar los GRAM a un exchange, esperar el abono, pasar el KYC, comprar el token deseado, retirarlo a la red Avalanche y pagar cada paso con comisiones y tiempo. Cinco operaciones manuales, tres intermediarios de confianza y media hora durante la cual el precio ya se te escapó.

Para una persona es un fastidio. Para un agente de IA autónomo es incompatible con la autonomía: no tiene cuenta en un exchange ni derecho a pasar la verificación por ti, y construir un proceso fiable sobre un custodio que puede congelar el retiro en cualquier momento sencillamente no es una opción. En cada paso alguien retiene tu dinero, y el agente tiene que guardar en algún lugar la API key del exchange o la seed phrase de un hot wallet.

El swap cross-chain TON → Avalanche lo resuelve de otra forma. Ningún exchange en el medio. Los fondos se mueven entre redes con una garantía matemática — «o el intercambio se completa en ambas redes, o nadie pierde nada» — y no con la promesa de un intermediario. Veamos cómo funciona exactamente a través de las herramientas MCP de TONNode: sin custodio y sin claves almacenadas en el servidor.

Cómo funciona el escrow HTLC atómico entre TON y Avalanche

La mecánica clave es el escrow HTLC atómico (hashed timelock contract, escrow con hash-timelock). Suena complicado, pero la idea es simple y se explica bien con la analogía de una caja de seguridad bancaria.

Depositas fondos en una caja que solo se abre con la llave correcta — el secreto. La caja tiene un temporizador: si nadie inserta la llave en el tiempo asignado, el contenido vuelve a su dueño. Ahora coloca dos cajas así — una en TON, otra en Avalanche — y ciérralas con el mismo candado:

• Se genera un secreto aleatorio S y su hash H = hash(S). A partir del hash no se puede reconstruir el secreto, pero es fácil verificar que un secreto presentado le corresponde.
• En el lado de TON depositas GRAM en un escrow con el hashlock H.
• En el lado de Avalanche, la contraparte (un market maker) deposita el activo objetivo en su escrow con el mismo H.
• Cuando revelas el secreto S para reclamar el activo en Avalanche, S se hace público en la blockchain. El market maker lo ve y usa ese mismo S para reclamar tus GRAM del escrow en TON.

De ahí la palabra atómico. Abrir un escrow sin abrir el otro es imposible: el secreto es uno solo para ambas redes. O ambas partes reciben sus fondos, o al vencer el timeout ambas recuperan lo suyo mediante refund. El estado intermedio «el dinero salió de TON pero el activo no llegó» simplemente no existe.

Aquí la garantía la dan la criptografía y los timeouts, no la reputación de un intermediario. Y precisamente por eso no hace falta un exchange en el medio.

Las cinco herramientas de cross-chain: quote, build, track, disclose, refund

En TONNode el cross-chain se cubre con exactamente cinco herramientas MCP, y cada una se encarga de una fase de la operación:

• get_crosschain_quote — la cotización: cuánto activo recibirás en la red destino por tus GRAM o jettons, considerando la ruta y los timeouts.
• build_crosschain_swap_tx — construye la transacción HTLC de escrow sin firmar para TON y devuelve el secreto asociado (y su hash). La transacción la firma el wallet del usuario.
• track_crosschain_swap — muestra las fases de la operación en ambas redes: si tu depósito ya apareció en el escrow de TON y si el escrow de la contraparte ya apareció en Avalanche.
• disclose_crosschain_secret — revela el secreto para liquidar, tras comprobar on-chain que todo está listo (el escrow de la contraparte está en su sitio, los montos y el hash coinciden).
• build_crosschain_refund — construye la transacción de devolución de fondos del escrow si la operación se quedó colgada y el timeout ya venció.

Cinco herramientas no es «poco». Son exactamente los cinco pasos de los que físicamente se compone un swap atómico: cotizar, depositar, rastrear, liquidar y, en caso de fallo, devolver. Ni uno de más, ni uno de menos.

No custodial: el servidor no firma ni guarda claves

No es una frase de marketing, sino una restricción arquitectónica. Las herramientas de cross-chain, swap y wallet de TONNode son estrictamente no custodiales:

• El servidor nunca firma transacciones y nunca almacena fondos ni claves privadas.
• build_crosschain_swap_tx entrega un mensaje TonConnect sin firmar. La firma la pone el wallet del usuario — Tonkeeper, MyTonWallet o cualquier wallet compatible con TonConnect. El servidor solo armó el sobre correcto de la transacción.
• El secreto S del HTLC lo genera el servidor y te lo entrega junto con la transacción construida — a partir de ahí, revelarlo queda bajo tu control. Incluso la llamada a disclose_crosschain_secret es un paso consciente que inicias tú tras la comprobación on-chain, no una acción automática en algún backend.

Si el servidor de TONNode desaparece de repente en mitad de una operación, tus fondos no se pierden: están en un escrow en la blockchain, y build_crosschain_refund los devolverá al vencer el timeout. Para mover valor entre redes, ser no custodial significa algo muy simple: en el servidor no hay nada que robar ni nada que congelar.

Compáralo con el modelo custodial, donde el operador tiene la clave y firma por su cuenta. Ambos modelos tienen su lugar — esa frontera la analizamos en detalle en el texto sobre MCP custodial vs. no custodial y en el desglose del swap no custodial para agentes.

Qué redes están soportadas (y por qué TON siempre es el origen)

Las redes destino del cross-chain: Ethereum, Arbitrum, Base, BNB Chain, Polygon, Avalanche. TRON aún no está soportado — no lo incluyas en tus procesos.

Una restricción de dirección importante: TON siempre actúa como origen del swap. Depositas GRAM o un jetton en el escrow de TON y reclamas el activo de la contraparte en la red EVM destino. Es consecuencia de la mecánica: el HTLC se inicia con un depósito en TON, donde viven tu wallet y tu balance, y la contraparte lo replica en la red destino.

La conclusión práctica: si tu agente vive en TON y necesita llevar valor a Avalanche, este es exactamente el escenario para el que todo está hecho. Si en cambio necesitas traer fondos hacia TON desde fuera, esa ruta hoy no existe. El cross-chain de TON a Ethereum funciona de forma idéntica — solo cambia el parámetro de la red destino; el desglose está en el swap TON → Ethereum.

Escenario paso a paso: swap GRAM → Avalanche

Juntemos todo. Abajo va el orden real de llamadas; el agente lo recorre solo, a ti te basta con firmar la transacción en el wallet.

Paso 1. Cotización. El agente pide el precio:

«Dame una cotización cross-chain: 500 GRAM de TON a USDC en Avalanche.»

Por debajo se ejecuta get_crosschain_quote. El agente ve el monto de salida, la ruta y los parámetros de los timelocks. Si el precio convence, seguimos.

Paso 2. Construcción de la transacción HTLC de escrow.

«Me convence. Construye la transacción con esta cotización hacia mi dirección de Avalanche 0x… y devuélveme el mensaje TonConnect sin firmar y el hash del secreto.»

Se invoca build_crosschain_swap_tx. Devuelve la transacción de depósito al escrow de TON sin firmar, más el secreto y su hash H. El usuario firma el mensaje con su wallet vía TonConnect — es justo en ese momento cuando los GRAM entran al escrow en TON. El servidor no toca la firma.

Paso 3. Seguimiento del escrow de la contraparte.

«Vigila la operación con track_crosschain_swap hasta que en Avalanche aparezca el escrow de la contraparte con mi hash.»

track_crosschain_swap muestra las fases en ambas redes. Esperamos a que el market maker deposite el activo objetivo en su escrow en Avalanche bajo el mismo H. Mientras no exista el escrow de la contraparte, no se debe revelar el secreto.

Paso 4. Revelación del secreto y liquidación. Una vez que el tracking confirma on-chain que todo está listo:

«El escrow de la contraparte está en su sitio. Verifica on-chain que todo esté listo y revela el secreto con disclose_crosschain_secret.»

disclose_crosschain_secret primero comprueba que todo está listo (el escrow de la contraparte existe, los montos y el hash coinciden) y después revela el secreto. Eso abre ambos escrows: tú recibes USDC en Avalanche y la contraparte, con el mismo S, reclama los GRAM del escrow de TON. La operación se cierra de forma atómica.

Paso 5 (solo en caso de fallo). Devolución. Si el escrow de la contraparte nunca apareció y la operación se quedó colgada, el secreto no se revela. Esperamos el timeout y llamamos a build_crosschain_refund:

«La operación se colgó y el timeout venció. Construye la devolución con build_crosschain_refund.»

La herramienta construye la transacción que devuelve los GRAM del escrow de TON de vuelta a ti; el usuario la firma con su wallet. Perder fondos por culpa de una contraparte que no responde es imposible by design: los protege el timelock.

Fíjate en la disciplina: el secreto se revela solo después de que el tracking haya confirmado el escrow de la contraparte. Revelarlo antes de tiempo es la única forma de exponerte, y por eso este paso está separado en una herramienta explícita en lugar de quedar oculto en la automatización.

Conectar el servidor MCP y qué sigue

Primero, una bifurcación importante para no perder tiempo. El paquete @tonnode/mcp es open source (MIT, GitHub tonnode/mcp), funciona sobre el protocolo nativo ADNL de TON, sin capas HTTP intermedias. Ejecutado en local con la configuración pública, ofrece el set completo de lectura (8 herramientas read: balance, estado de cuenta, transacciones, get-methods y demás) — suficiente para leer TON, pero no incluye swap, cross-chain ni wallet. Configuración local para un cliente MCP (Claude, Cursor, Codex, cualquiera compatible con MCP):

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

Las cinco herramientas de cross-chain de este artículo (igual que el swap y la generación de wallets) funcionan solo a través del endpoint hosted mcp.tonnode.io con una clave Bearer. La clave Hobby es gratuita y se emite justo después de iniciar sesión, sin tarjeta (60 solicitudes/min), pero es precisamente una clave hosted, no el npx local a secas. Configuración para el pipeline cross-chain:

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

Un par de datos que despejan dudas:

• TONNode tiene 16 herramientas en total. En todos los planes están disponibles las 16 — pagas solo por el throughput, no por «desbloquear funciones». La diferencia entre las dos configuraciones de arriba no está en el set, sino en el punto de conexión: el npx local da solo lectura; el endpoint hosted con clave abre el set completo, incluidas las cinco herramientas de cross-chain.
• GRAM es el Toncoin renombrado en junio de 2026. La red se sigue llamando TON; solo cambió el nombre de la moneda.
• La clave gratuita Hobby — 60 solicitudes por minuto, sin tarjeta — alcanza para correr el pipeline cross-chain completo.

Qué sigue

Si tu agente ya vive en TON y necesitas llevar valor a Avalanche (o Ethereum, Base, Arbitrum, BNB Chain, Polygon), arma la cadena get_crosschain_quote → build_crosschain_swap_tx → track_crosschain_swap → disclose_crosschain_secret y mantén build_crosschain_refund como seguro. Por qué el cross-chain desde TON conviene resolverlo vía MCP y no vía exchange lo analizamos aparte — en este texto.

Consigue tu clave Hobby gratuita y conecta las herramientas cross-chain ahora mismo: tonnode.io/dashboard?plan=hobby. No hace falta tarjeta, y 60 solicitudes/min alcanzan para correr el pipeline completo y ver el HTLC atómico en acción.

Para ver las 16 herramientas — página de herramientas. Lo que viene después — roadmap.