All posts
9 min read

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

Cross-chain swap from TON to Ethereum via an atomic HTLC escrow: quote, build, track, disclose, refund. Non-custodial — keys and funds stay with you.

cross-chain swapTONEthereumHTLC escrownon-custodialMCP

Picture this: your AI agent holds USDT on TON, and the user says "move it to ETH on Ethereum." The usual route is to send the money to a centralized exchange, wait for the deposit to clear, trade manually, then withdraw to the target network. An agent can't do any of that: it has no exchange account, no KYC, and — worst of all — at every step somebody else is holding your funds. If a single link in that chain stalls, your asset gets stuck between networks with no guarantee it ever comes back.

The industry's classic answer is a bridge with a middleman you hand your money to "for safekeeping." Those are exactly the bridges that get hacked for hundreds of millions. For an autonomous agent that's a non-starter: it needs a swap where either the trade completes in full or everyone gets their funds back — with no trusted intermediary. That is precisely what a cross-chain swap from TON to Ethereum through an atomic HTLC escrow delivers. Below we'll break down how it works under the hood, using the real tools of the TONNode MCP server — no custody and no magic.

What a TON → Ethereum cross-chain swap is and why it's atomic

A cross-chain swap is an exchange of an asset on one network for an asset on another, with no shared blockchain that could record both operations in a single transaction. TON physically cannot "see" a transaction on Ethereum, and Ethereum cannot see one on TON. There is no common referee. So the naive "I send — you send" scheme runs straight into a trust problem: whoever goes first takes the risk.

The key word here is atomicity. An atomic operation either executes in full or doesn't execute at all; there is no "halfway" state. Applied to a swap, that's an iron guarantee: either both legs execute and each party gets what they expected, or the deal rolls back and everyone walks away with their original funds. The state "I paid but never got paid" simply does not exist as an outcome.

That guarantee comes from cryptography and timeouts — the HTLC mechanism — not from trusting a middleman.

Atomic HTLC escrow in plain words: hash, secret and timeout

HTLC stands for Hash Time-Locked Contract. Sounds intimidating; the idea behind it is completely ordinary. Picture a safe-deposit box with two locks:

  • The hash lock. The box opens only for someone who knows the secret — a long random string S. The box itself doesn't hold the secret, only its "fingerprint" — the hash H = hash(S). You can't reconstruct the secret from the fingerprint, but anyone who sees the secret can instantly verify the fingerprint matches. The money is locked in escrow "under this hash."
  • The time lock (timeout). If the secret is never revealed within the allotted window, the box automatically unlocks back to whoever filled it.

Here's how that yields atomicity across two networks:

  1. On the TON side, your GRAM/USDT gets locked in escrow under the hash H.
  2. The counterparty (a market maker), seeing the lock, mirrors the escrow on Ethereum under the same H — reserving your ETH.
  3. To claim the ETH on Ethereum, you reveal the secret S. But revealing S makes it public on-chain.
  4. The counterparty sees S and uses that same secret to claim your funds from the TON escrow.

There is one secret for both legs of the deal. The moment it's revealed to collect the ETH, it automatically unlocks the TON side too. Revealing it for one leg without giving up the other is impossible. And if something goes wrong and S is never revealed — once the timeout expires, both sides refund. Hence "atomic": there is no third outcome. By construction, this scheme requires zero trust in any intermediary server.

The full five-tool flow: quote → build → track → disclose/refund

In TONNode the entire HTLC exchange is broken down into five tools. The call order mirrors the HTLC logic one-to-one.

1. get_crosschain_quote — the quote

First, find out the terms: how much ETH (or USDT on Ethereum) you'll get for your funds on TON, accounting for liquidity and fees. It returns the rate, the expected output amount and the route parameters. This is a read — it locks nothing and signs nothing.

2. build_crosschain_swap_tx — unsigned HTLC escrow transaction + the secret

This is where the deal is born. The tool returns an unsigned transaction that will lock your funds in the HTLC escrow under the secret's hash, and — separately — the secret S itself. Crucially: the secret goes to you — it does not stay on the server. The transaction is signed by your wallet via TonConnect; the server never touches the signature. This is the secret you'll later reveal to complete the deal — and if the deal stalls, the locked funds come back to you on timeout, without the secret ever being revealed.

3. track_crosschain_swap — deal phases on both networks

Once you've signed and sent the escrow transaction, you need to know where the deal stands — whether your money is locked on TON, whether the counter-escrow has appeared on the Ethereum side, whether everything is ready for settlement. track_crosschain_swap shows the phases on both networks at once — your single view across two blockchains. Keep calling it until the deal reaches the "ready to disclose the secret" state.

4a. disclose_crosschain_secret — reveal the secret to settle

When tracking has confirmed the counterparty is ready and locked on-chain, you reveal the secret. This is the final step: disclosure triggers settlement — you take the ETH, the counterparty uses the same secret to take your GRAM/USDT. Call it only after you've verified on-chain readiness via track_crosschain_swap — revealing the secret early would mean handing over the key before the other half of the box is filled.

4b. build_crosschain_refund — get your funds back if the deal stalls

The safety-net scenario. If the other side never executed — the counterparty didn't mirror the escrow, the timeout ran out — build_crosschain_refund assembles an unsigned transaction refunding your funds from the escrow. That's the second lock — the time lock. The secret stays unrevealed and the locked funds come back to you. It's the emergency fuse of atomicity: a stalled deal doesn't eat your money.

The whole path, schematically:

get_crosschain_quote      → how much I'll get
build_crosschain_swap_tx  → unsigned HTLC tx + secret (the secret is yours)
        ↓ (signed in your wallet, sent)
track_crosschain_swap     → phases on TON and on Ethereum
   ├─ ready on-chain   →  disclose_crosschain_secret   → settlement
   └─ stuck, timed out →  build_crosschain_refund      → refund

Once the server is connected, you just ask the agent in plain language — it chains the tools together on its own:

Swap 50 USDT from my TON wallet to ETH on Ethereum.
Show me the quote first (get_crosschain_quote).
If the rate looks good, build the HTLC escrow (build_crosschain_swap_tx)
and let me sign it. Then track the deal (track_crosschain_swap)
and, once both sides are ready on-chain, disclose the secret to settle.
If nothing moves before the timeout, build the refund.

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

Back to the problem we opened with. A regular bridge is dangerous because you hand your funds over to an intermediary's control. TONNode is built differently, and this is its core stance: the server NEVER signs and never holds funds or private keys.

What that means for the HTLC escrow in practice:

  • build_crosschain_swap_tx hands you an unsigned transaction — until you sign it with your own wallet via TonConnect, nothing gets locked.
  • The secret S is held by you, not the server. Without your secret, nobody can settle the deal on your behalf.
  • The timeout refund (build_crosschain_refund) is also assembled as an unsigned transaction awaiting your signature.
  • Even a generated wallet (the generate_wallet tool) is handed to you and never kept on the server.

Even if the server goes down or gets compromised, it is physically incapable of stealing your funds or completing the deal without your signature and your secret. In other words, the atomic HTLC protects you from the counterparty, and the non-custodial architecture protects you from the service itself. More on this model in custodial vs non-custodial MCP and in the piece on non-custodial swaps for agents on TON.

For comparison: the official @ton/mcp from the TON Foundation is a custodial agent wallet that holds an operator key and signs by itself, and it works only inside TON with no cross-chain. The trade-off is an honest one: there, autonomous spending at the price of trusting a key; here, non-custodial design plus a route beyond TON.

Supported networks: Ethereum, Arbitrum, Base, BNB, Polygon, Avalanche

Here, TON is always the source side of the deal, and the destination is one of six EVM networks:

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

The mechanics are identical for all of them — an atomic HTLC escrow. TRON is not supported yet. If you're targeting an L2 for cheap fees, see the dedicated breakdown of the TON → Arbitrum cross-chain swap — same flow, only the destination network differs. And for why an agent needs this at all and where the value for TON comes in, read about the first cross-chain swap and its value for the network.

How to connect MCP and run your first cross-chain swap

TONNode is a hosted MCP server for TON. MCP (Model Context Protocol) is the standard through which AI agents (Claude, Cursor, ChatGPT/Codex and any MCP client) call tools. There are 16 tools in total, and all 16 are available on every plan — you only pay for throughput.

Local and free

The public config with the full read set installs with a single command — npx -y @tonnode/mcp:

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

Add this to your MCP client's config (Claude Desktop, Cursor, Codex, anything MCP-compatible), and the get_crosschain_quote, build_crosschain_swap_tx, track_crosschain_swap, disclose_crosschain_secret, build_crosschain_refund tools become available to your agent. The @tonnode/mcp package is open source (MIT), lives on npm and GitHub (tonnode/mcp), and speaks TON's native ADNL protocol — no HTTP middle layers.

Hosted — with your own key

For guaranteed throughput, plug in the hosted endpoint with your own key:

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

The plans differ only in request limits: Hobby — free forever, 60 requests/min; Pro — $29/mo, 300 requests/min; Scale — $199/mo, 1200 requests/min. The 16-tool set is the same on all of them. A free Hobby key is issued right after sign-in, no card required. A word on the currency, by the way: GRAM is the renamed Toncoin (renamed in June 2026), the network is still called TON, and GRAM is what you'll see in the quotes.

First swap in a minute

  1. Get a free Hobby key — no card, issued right after sign-in.
  2. Drop in the config (local or hosted).
  3. Give your agent the prompt from the section above and sign the escrow transaction with your own wallet.

TL;DR

Moving assets between networks doesn't have to be built on trust. An atomic HTLC escrow gives you an all-or-nothing guarantee, and TONNode's non-custodial architecture makes sure that neither your funds, nor your keys, nor the secret ever leave your control. Five tools — get_crosschain_quote, build_crosschain_swap_tx, track_crosschain_swap, disclose_crosschain_secret, build_crosschain_refund — cover the full lifecycle of the deal, emergency refund included.

You can try it on a live swap for free: grab a Hobby key and run your first cross-chain swap — no card, and 60 requests per minute is plenty. For an overview of all 16 tools, see the MCP page.

Give your agent TON access

16 MCP tools: reads, non-custodial swaps, cross-chain and wallets. Free tier — 60 req/min, no card required.