Cross-Chain Swaps from TON to Polygon: How They Work

Your USDT sits in a wallet on TON, but the payment has to happen on Polygon — that's where gas is cheap, where your DeFi contract is deployed, where the recipient accepts funds. The usual route: withdraw to an exchange, wait for the deposit to clear, sell, buy, withdraw back out to Polygon. Four steps, four fees, KYC, and full trust in an intermediary who holds your money for those minutes. For a human that's merely annoying. For an AI agent that's supposed to do it autonomously, the path is a non-starter: an agent can't pass KYC and shouldn't be holding the private key to an exchange account.

Below we break down how to solve this differently — with an atomic cross-chain swap from TON to Polygon where neither the server nor the agent ever touches your keys.

Why swap from TON to Polygon, and what TONNode does

A cross-chain swap from TON to Polygon is what you reach for when value lives on one network but needs to be spent on another, and you don't want to wait on an exchange or trust an intermediary with your funds. Typical reasons:

• pay a counterparty who only accepts payment on Polygon;
• top up a position in a protocol deployed on Polygon while your balance sits on TON;
• let an AI agent move value between networks on its own, from a single prompt — but without access to your keys.

TONNode is a hosted MCP server for TON (website: tonnode.io). MCP (Model Context Protocol) is the standard that AI agents (Claude, Cursor, ChatGPT/Codex, and any MCP client) use to call external tools. Instead of teaching your agent REST endpoints and signing transactions on its behalf, you hand it a set of 16 TON tools and it decides which ones to call. Five of those 16 handle cross-chain — they're the ones that move value out of TON, non-custodially, with no keys stored on the server.

One important mechanical constraint: in TONNode, TON is always the source. The route runs from TON outward; Polygon is the destination network here, not the starting point.

A quick terminology note: GRAM is the renamed Toncoin (the rename happened in June 2026), while the network itself is still called TON. From here on, GRAM = TON's native coin.

How a TON → Polygon cross-chain swap works: the atomic HTLC escrow

The problem with any cross-network exchange is that the two networks can't see each other. There's no shared referee guaranteeing that if you gave up funds on TON, you'll receive them on Polygon. The classic solution is an atomic HTLC escrow (hashed timelock contract). Think of it as a lockbox with two locks and a timer.

It runs on two primitives — a hashlock and a timelock:

1. A secret and its hash. A random secret S is generated, and a hash H = hash(S) is derived from it. Escrow contracts on both networks lock their funds against that hash H.
2. The hashlock. Only someone who presents an S that produces that H can unlock the escrowed funds. Until the secret is revealed, the money stays locked on both sides.
3. The timelock. Every escrow has a deadline. If the secret still hasn't been revealed by then, the sender can reclaim the funds — that's the insurance against a stuck deal.

The trick is that revealing the secret on one network mathematically enables claiming the funds on the other: as soon as S appears on-chain, the counterparty uses it to complete their half. Hence atomicity: the trade either completes on both networks or completes on neither, and the funds come back. The intermediate state of "money left TON but never arrived on Polygon" doesn't exist by design.

TONNode orchestrates this protocol through five tools, but — crucially — the secret is handed to you rather than kept on the server, and you sign every TON transaction with your own wallet.

The five cross-chain tools: from quote to settlement

All five are available on every plan. Here's the full pipeline and what each tool does.

1. get_crosschain_quote — the quote

How much you'll receive on Polygon for the amount you send from TON. The agent calls it first, to show the rate and the route before anything gets signed. It returns the trade parameters that the transaction is then built from.

2. build_crosschain_swap_tx — the unsigned HTLC escrow transaction

Builds an unsigned transaction that locks your funds in escrow on the TON side, and returns the secret. The transaction comes as a TonConnect message; your wallet signs it, not the server. You keep the secret yourself — you'll need it at settlement.

3. track_crosschain_swap — trade phases on both networks

Shows where the trade stands: whether the escrow is locked on TON, whether the counter-escrow is in place on Polygon, whether everything is ready for settlement. Your monitoring console for both networks at once.

4. disclose_crosschain_secret — reveal the secret for settlement

Reveals the secret to complete settlement — but only after an on-chain check confirms both sides are ready. Ordering is critical here: revealing the secret before the counter-escrow has actually landed on Polygon is not an option. The tool checks the state of both networks, and only then hands over the secret to be revealed.

5. build_crosschain_refund — reclaim funds from escrow

Builds an unsigned refund transaction if the trade stalled and the timelock allows you to reclaim the locked funds. More on that scenario below.

Here's what it looks like in a conversation with your agent:

Swap 250 USDT from TON to USDC on Polygon.
Show me the quote first, then build the transaction,
let me sign it with my wallet, track the status,
and reveal the secret only when both escrow sides are ready.

The full route under the hood:

1. get_crosschain_quote       → rate and route TON → Polygon
2. build_crosschain_swap_tx   → unsigned HTLC escrow + secret S
   (user signs in their wallet via TonConnect)
3. track_crosschain_swap      → wait until both networks are ready
4. disclose_crosschain_secret → reveal S after the on-chain check → settlement
5. build_crosschain_refund    → only if something went wrong

The logic is the same as in the TON to Ethereum swap — only the destination network changes.

Why this is non-custodial: the server never signs and never holds keys

This is where the most important line gets drawn. Non-custodial isn't a marketing word here — it's a property of the architecture. TONNode's cross-chain tools are strictly non-custodial: the server never signs and never holds your funds or private keys. It returns unsigned TonConnect messages, and the signature comes from your wallet.

Take build_crosschain_swap_tx as an example. The tool hands back a transaction draft and the secret — but it doesn't execute the transfer. Nothing moves until you confirm it in your wallet. The private key never leaves the wallet and never passes through the server in any form. Same story with the HTLC secret: it's given to you, so even settlement is under your control, not the server operator's.

For an AI agent this is fundamental. An autonomous agent with tool access must not be able to spend your money without your signature. The non-custodial model delivers exactly that: the agent prepares the trade; you are the only one who authorizes it. For a deeper look at the two approaches, see custodial vs non-custodial MCP and the write-up on how to safely let an agent swap on TON.

A separate note on the official @ton/mcp from the TON Foundation. It's a strong, official tool, but architecturally different: it's a custodial agent wallet (a split-key scheme — the operator key lives with the agent, the owner key with the user), it signs on its own, and it doesn't support cross-chain (TON only). It has its own strengths — autonomous spending, NFT and DNS support, the Foundation's official backing. The difference is an honest one: it's custodial and TON-only; TONNode is non-custodial, with cross-chain and a hosted option. There's a full breakdown on the comparison page with the official MCP.

The full list of supported networks (and why TRON isn't on it yet)

A cross-chain swap in TONNode goes from TON to one of these destination networks:

• Ethereum
• Arbitrum
• Base
• BNB Chain
• Polygon
• Avalanche

In every case TON is the source and the listed network is the destination. TRON is not supported yet. An atomic HTLC escrow requires a compatible hashed-timelock-contract mechanism on the destination side, wired into the trade route. The six networks above make up the EVM-compatible family that TON can build a counter-escrow on. TRON isn't wired into that route yet — not because it's "impossible in principle", but because that specific integration doesn't exist in the product today. Don't build plans around TRON until it officially shows up on the list.

The Polygon flow is no different from the Ethereum route; if you want the broader overview, there's a breakdown of the first MCP that moves cross-chain value out of TON.

What to do if the trade stalls: refunding from escrow

Cross-chain means two independent networks, and sometimes the other side never confirms: the counter-escrow didn't land, the counterparty vanished, the destination network slowed to a crawl. In a custodial model, that's the moment you're at the mercy of the intermediary holding your money. In an atomic HTLC escrow, you're not.

Every escrow contract has a timelock. If the trade didn't complete and the clock ran out, the funds don't "burn" and don't stay with the server — they come back to you. And you never revealed the secret (rightly so — disclose_crosschain_secret won't release it until the on-chain check confirms both sides are ready).

Mechanically, the refund is handled by build_crosschain_refund: it builds an unsigned transaction, you sign it with your wallet, and the locked funds return to your TON address. Here too, the server signs nothing and holds nothing.

The swap to Polygon stalled and never settled.
Refund my funds from the escrow.

The agent calls track_crosschain_swap, confirms settlement didn't happen and the timelock allows a refund, then calls build_crosschain_refund — and you sign. The worst-case outcome of a stalled trade here is getting your own money back, not losing it.

How to connect and try it: MCP config and a free key

You can start free and local. The @tonnode/mcp package is open source (MIT), lives on npm and GitHub (tonnode/mcp), and speaks TON's native ADNL protocol with no HTTP middle layers.

Free, locally. The full set of read tools on the public config, no key required:

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

The MCP client spins up the server itself via npx.

Hosted endpoint — for when you need guaranteed throughput and your own key:

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

Every plan includes all 16 tools — you pay for throughput, not for feature access:

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

A free Hobby key is issued right after sign-in, no card required. You can pay for a paid plan in GRAM or USDT on TON via TonConnect, or in BTC/ETH/SOL and other coins through an xRocket invoice in Telegram.

A couple of honest caveats so expectations stay grounded: archival history depth is still on the roadmap (the node is syncing), TONNode currently has no NFT or DNS tools, and there are no webhooks, no gasless relayer, and no written uptime guarantees. The cross-chain product is exactly the five tools described above — and they honestly move value from TON to Polygon, non-custodially.

---

Try cross-chain yourself. Grab a free Hobby key and have your agent build its first TON → Polygon swap: tonnode.io/dashboard?plan=hobby. Want to explore the full set of 16 tools first? Head over to the tools page.