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

Un agente al que le encargan «cambiar GRAM por BNB y pagar a una contraparte en BNB Chain» choca contra un muro ya en el primer paso. No tiene ninguna forma segura de mover valor entre dos blockchains que no saben nada la una de la otra. La vía clásica es un puente centralizado o un exchange: deposita las monedas, confía, espera y reza para que los fondos no se queden atascados entre redes. Para un agente de IA autónomo eso es inaceptable: no puede «confiar» en un custodio, no tiene derecho a entregar claves ajenas a un tercero y no tiene manos para desatascar manualmente una transacción colgada.

Hace falta una forma de mover valor de TON a BNB Chain de modo que o bien todo se ejecute por completo, o bien todo vuelva a su origen — sin un intermediario que retenga el dinero. Eso es exactamente lo que hace un swap cross-chain con escrow HTLC atómico. A continuación desglosamos cómo está construido, con qué cinco herramientas MCP de TONNode el agente lleva a cabo la operación y por qué el servidor no toca tus fondos en ningún momento.

Qué es un swap cross-chain TON → BNB Chain y para qué lo necesita un agente

Un swap cross-chain es el intercambio de un activo en una red por un activo en otra, sin un libro contable común entre ambas. TON y BNB Chain son dos redes independientes con sus propias máquinas virtuales; no existe un «banco» compartido que simplemente reescriba los saldos. Así que hace falta un protocolo que sincronice dos transferencias independientes hasta hacerlas inseparables.

En TONNode el cross-chain siempre parte de TON como origen hacia una red EVM de destino — en nuestro caso, BNB Chain. No existe la dirección inversa ni «BNB como origen»: TON es siempre el punto de partida. Bloqueas GRAM o un jetton en el lado de TON y recibes el activo en el lado de BNB Chain.

GRAM es el Toncoin renombrado en junio de 2026. La red sigue llamándose TON; solo cambió el nombre de la moneda.

¿Para qué lo quiere un agente? Porque las tareas reales rara vez se quedan dentro de una sola red. Un agente-tesorero guarda la tesorería en GRAM, pero al proveedor hay que pagarle en BNB Chain. Un bot de trading detecta arbitraje entre un DEX en TON y otro en BNB. Un asistente ejecuta la orden «envía el equivalente a 50 GRAM a la contraparte en BSC». En todos los casos se necesita una forma de cruzar la frontera entre redes — determinista, sin custodio y sin intervención manual.

Cómo funciona el escrow HTLC atómico: secreto, hash y timelock

HTLC significa Hashed Timelock Contract — un contrato con cerradura de hash y bloqueo temporal. Suena complicado, pero la analogía es simple.

Imagina dos cajas fuertes: una en TON y otra en BNB Chain. Las dos se cierran con la misma cerradura, que se abre con una única llave secreta — un número aleatorio, el «secreto» S. En la blockchain no se publica el secreto, sino su hash H = hash(S) — algo así como la huella de la cerradura. Cualquiera puede comprobar que la llave encaja en la cerradura, pero a partir de la huella es imposible reconstruir la llave.

La caja de BNB Chain no la llenas tú: quien pone la pata contraria es la contraparte — un resolver (market maker) que bloquea BNB bajo el mismo hash H, contando con llevarse tus GRAM en el lado de TON con ese mismo secreto. Por eso la operación es simétrica: ambos lados están cerrados con la misma cerradura.

A partir de ahí actúan dos condiciones:

• La cerradura de hash. Solo se pueden retirar fondos de una caja presentando un secreto que coincida con el hash publicado. En cuanto el secreto se revela en un lado, se vuelve visible también en el otro — y la segunda pata de la operación se ejecuta con la misma llave. Quien retira los fondos está obligado a presentar S en claro on-chain.
• El timelock. Cada caja tiene un temporizador. Si la operación no se completa antes de que expire el timelock, los fondos vuelven a su dueño original. Los timelocks están calibrados de forma que la parte que revela el secreto primero no pueda engañar a la contraparte.

El resultado es la atomicidad: o se ejecutan las dos patas, o se devuelven las dos. Físicamente no existe un estado intermedio en el que hayas entregado tus GRAM y los BNB no lleguen. Aquí no hay ningún tercero que «garantice» la operación — la garantía la dan las matemáticas de la función hash y la lógica de los timelocks en los contratos. Es el mismo mecanismo que hay detrás de los atomic swaps y los pagos Lightning, solo que adaptado a TON y EVM.

Las cinco herramientas de la operación: cotización, construcción, tracking, revelación, refund

Todo el ciclo de vida de un swap cross-chain en TONNode está cubierto por cinco herramientas MCP. El agente las invoca en orden — como etapas de una misma operación.

get_crosschain_quote — cotización

Devuelve la cotización de la operación TON → BNB Chain: cuánto entregas en el lado de TON y cuánto recibes en el lado de BNB Chain. Todo swap empieza aquí — el agente muestra las cifras al usuario antes de que se bloquee nada.

build_crosschain_swap_tx — construcción de la transacción + secreto

Entrega una transacción de escrow HTLC sin firmar más el secreto. La transacción la firma la wallet del usuario a través de TonConnect, no el servidor. El secreto S se genera aquí mismo y queda en manos del usuario/agente — es lo que más tarde desbloqueará la segunda pata. El servidor generó la transacción y el hash, pero la firma y la posesión del secreto siguen siendo del usuario.

track_crosschain_swap — tracking de fases

Muestra las fases de la operación en ambas redes — tanto en TON como en BNB Chain: si la pata de TON está bloqueada, si apareció la pata contraria en BNB Chain, si el secreto se reveló, si el settlement se completó. Son los ojos del agente: sin tracking no sabe cuándo es seguro revelar el secreto ni cuándo toca hacer el refund.

disclose_crosschain_secret — revelación del secreto

Revela el secreto para el settlement — pero solo tras verificar on-chain que todo está listo. La herramienta no entrega S a ciegas: primero se asegura de que la pata contraria en BNB Chain realmente está en su sitio y las condiciones se cumplen. Eso te protege del escenario en el que revelas el secreto y resulta que del otro lado no hay nada que cobrar.

build_crosschain_refund — devolución desde el escrow

Construye la transacción de devolución de fondos desde el escrow si la operación se quedó colgada — una vez expirado el timelock. También es una transacción sin firmar para TonConnect. La cuerda de seguridad a la que volveremos al final.

Por qué es no custodial: el servidor no firma ni guarda claves

Aquí está la línea que define a TONNode. Las herramientas de swap, cross-chain y wallet son estrictamente no custodiales. El servidor NUNCA firma ni retiene fondos ni claves privadas — devuelve únicamente mensajes TonConnect sin firmar, que firma la wallet del usuario.

Veámoslo en concreto en el caso del cross-chain:

• build_crosschain_swap_tx entrega la transacción sin firma. La firma la pone la wallet del usuario — Tonkeeper, MyTonWallet, cualquiera compatible con TonConnect. Hasta que el usuario no confirma la transacción, no se bloquea nada.
• El secreto S viaja al cliente. El servidor no puede vaciar el escrow a escondidas: para eso hace falta la firma del dueño, y el servidor no la tiene.
• Incluso el refund es una transacción sin firmar: la devolución la inicia el usuario, no el servidor.

Conclusión práctica: un servidor comprometido no se traduce en robo de fondos — no hay nada que llevarse: ni claves, ni firmas, ni control sobre el escrow. Lo máximo que puede «romperse» es la disponibilidad del servicio (el agente se queda sin cotización), pero no tu dinero.

Compáralo con el modelo custodial, donde la wallet-agente guarda una clave de operador y firma por su cuenta. Ambos modelos tienen su razón de ser, pero para un cross-chain entre dos redes independientes la no custodia es especialmente importante — no quieres que un intermediario controle dinero atascado entre blockchains. El análisis detallado de los dos enfoques está en MCP custodial o no custodial, y cómo se ve esto en un swap normal dentro de TON, en Swap no custodial para un agente.

Qué redes están soportadas (y por qué TRON todavía no)

El cross-chain en TONNode siempre va de TON hacia una red EVM de destino. Los destinos soportados:

• Ethereum
• Arbitrum
• Base
• BNB Chain (nuestro caso)
• Polygon
• Avalanche

TRON de momento NO está soportado. La razón es técnica: el escrow HTLC atómico exige que la red de destino interprete los contratos hash-timelock de forma uniforme dentro del protocolo de escrow elegido. Las seis redes de la lista son compatibles con EVM y encajan en ese modelo; TRON, pese al parecido superficial, vive según su propio modelo y requiere una implementación de escrow aparte. Mientras no exista, TRON no está en la lista — y no vendemos deseos como si fueran hechos.

Sobre el par más popular — TON → Ethereum — hay un desglose aparte: Swap cross-chain TON → Ethereum. La mecánica es la misma; solo cambia la red de destino.

Recorrido paso a paso del swap TON → BNB vía MCP

Primero conectamos TONNode al agente. La configuración pública local @tonnode/mcp es gratuita y ofrece el set completo de herramientas de lectura — pero solo lectura. El paquete es open source (MIT), funciona sobre el protocolo nativo ADNL de TON, sin capas HTTP intermedias:

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

Una aclaración importante: las cinco herramientas cross-chain no están disponibles a través del npx público local — ahí solo hay lectura. La operación cross-chain va por el endpoint hosted con su propia clave, y para eso basta con la clave gratuita Hobby:

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

Con la clave hosted, las 16 herramientas — incluidas las cinco de cross-chain — están disponibles en cualquier plan, empezando por el Hobby gratuito. Solo pagas por el ancho de banda (Hobby — gratis, 60 peticiones/min; Pro — $29/mes, 300 peticiones/min; Scale — $199/mes, 1200 peticiones/min). El cross-chain no está encerrado detrás de un plan superior — pero el npx local no sirve para él: hace falta una clave hosted.

Ahora, el recorrido. El prompt al agente puede ser todo lo humano que quieras:

«Cambia 50 GRAM de mi wallet de TON a BNB Chain, a la dirección 0x…. Primero muéstrame la cotización y luego construye la transacción — la firmo yo.»

Lo que pasa bajo el capó:

1. Cotización. El agente llama a get_crosschain_quote (origen TON, destino BNB Chain, importe 50 GRAM) y muestra cuánto llegará en el lado de BNB Chain.
2. Construcción. Tras tu «ok», el agente llama a build_crosschain_swap_tx. Recibe la transacción de escrow HTLC sin firmar y el secreto S. Tú confirmas la transacción en tu wallet vía TonConnect. Los fondos quedan bloqueados en el escrow del lado de TON bajo el hash H.
3. Tracking. El agente llama periódicamente a track_crosschain_swap y vigila las fases en ambas redes: si la pata de TON está bloqueada, si se levantó la pata contraria en BNB Chain (la pone el resolver bajo el mismo hash H).
4. Revelación y settlement. En cuanto track_crosschain_swap indica que todo está listo, el agente llama a disclose_crosschain_secret. La herramienta comprueba on-chain que todo está listo y revela S — el secreto se vuelve visible en BNB Chain, ambas patas se ejecutan y los BNB llegan a tu dirección.
5. Confirmación. Un track_crosschain_swap final muestra que ambos lados quedaron liquidados. Operación cerrada.

La esencia es que en todo momento ves el estado de la operación en las dos redes y firmas solo lo que ves. Si te interesa la filosofía general del primer movimiento de valor desde TON vía MCP, está desglosada en La primera transferencia de valor cross-chain desde TON.

Si la operación se cuelga: devolución de fondos desde el escrow

Cross-chain significa dos redes independientes, y a veces la pata contraria no se levanta: la contraparte tiene problemas, la red está congestionada, algo salió mal. En el modelo custodial, aquí es donde empieza el intercambio de correos con el soporte. Con HTLC simplemente esperas a que venza el timelock.

Los fondos no quedan bloqueados para siempre. En cuanto el timelock expira y la operación no se ha completado, el agente llama a build_crosschain_refund y recibe una transacción sin firmar de devolución desde el escrow. La firmas con tu wallet vía TonConnect — y los GRAM bloqueados vuelven a ti. Nada de «los fondos se quedaron colgados para siempre»: es una garantía integrada en el propio contrato, no una promesa del servicio.

El prompt puede ser así:

«Mi swap cross-chain a BNB Chain no se completó. Comprueba el estado y, si el timelock ya expiró, devuélveme mis fondos.»

El agente llamará a track_crosschain_swap, comprobará que el settlement no se produjo y que el timelock quedó atrás, luego construirá la devolución con build_crosschain_refund y te entregará la transacción para firmar.

El punto clave de seguridad: el secreto vía disclose_crosschain_secret se revela solo tras comprobar on-chain que todo está listo. El agente no caerá en la trampa de haber revelado el secreto sin nada que cobrar al otro lado. O el settlement se ejecuta de forma atómica, o al vencer el timelock actúa el refund. No hay tercera opción — y eso es exactamente lo que significa la palabra «atómico».

---

Consigue tu clave gratuita y conecta el cross-chain

Las cinco herramientas cross-chain forman parte del set estándar de 16 — no hay que comprarlas aparte. Toma la clave gratuita Hobby (60 peticiones/min, sin tarjeta, se entrega nada más iniciar sesión) y conecta TONNode a tu agente: tonnode.io/dashboard?plan=hobby.

Si prefieres ver primero el set completo de 16 herramientas y sus parámetros, aquí está la página de herramientas: tonnode.io/mcp.

El cross-chain de TON a BNB Chain deja de ser una cuestión de «confía en el puente» y se convierte en una simple llamada a una herramienta — atómica, no custodial y con devolución garantizada si algo sale mal.