Cross-Chain Swaps from TON to Base: How They Actually Work

Your AI agent has spotted an opportunity: the user's capital sits in TON, but the protocol or asset it needs lives on Base. The classic answer is "run it through a bridge." But a bridge means someone holds your funds during the crossing: a bridge contract, a relayer, a multisig of signers you never chose. Over the past few years, custodial bridges have bled more than a billion dollars of user money — not because the cryptography was weak, but because someone was holding the funds in between.

For an autonomous agent this is a double problem. First, an agent should never sign a transaction that hands funds to a third party with no guaranteed way back. Second, an agent should never have your private keys in the first place. And a classic bridge demands exactly that — trust in an intermediary.

There is another way — an atomic HTLC escrow. Below we'll walk through how to execute a cross-chain swap TON → Base so that no intermediary can touch your keys or funds at any point, and how an AI agent drives the entire flow through five TONNode MCP tools.

Why swap from TON to Base, and why this isn't a regular bridge

Base is Coinbase's L2 on top of Ethereum, built on the OP Stack. Liquidity is migrating there, DeFi protocols are shipping there, and more and more often that's where the contract your agent needs to talk to happens to live. Meanwhile your source capital is in TON — in GRAM (Toncoin renamed in June 2026; the network is still called TON) or in USDT on TON.

A regular bridge solves this through custody. You hand your funds to a bridge contract on the source chain, a relayer somewhere off to the side notices and mints the equivalent on Base. Between "sent" and "received" there is a window in which your money is controlled by someone who isn't you. For a human who moves funds once a month, that's tolerable. For an agent doing it in a loop, unsupervised — it's an unacceptable risk.

The alternative is an atomic swap, where there is no moment at which the funds belong to an intermediary. The trade either executes in full on both chains or rolls back in full. That's exactly how cross-chain works in TONNode.

How an atomic HTLC escrow between TON and Base works

HTLC — hashed timelock contract — is an escrow with two unlock conditions: a secret hash and a timelock. The easiest mental model is two safes: one on TON, one on Base. Both open with the same key — the secret. Until the secret is revealed, both stay locked.

• Hash lock. Funds on both chains are locked against the same secret hash h = hash(s). The only way to open the escrow is to present the secret s itself, whose hash matches.
• Timelock. Each safe has an expiry. If the trade doesn't complete in time, the funds return to their owner once the timelock runs out.

The back-of-a-napkin version:

1. A random secret s is generated, along with its hash h = hash(s).
2. On TON, your funds are locked in escrow under the condition: "release to whoever presents s; return to the sender if s is never presented before the deadline."
3. On Base, the counterparty (a resolver providing destination liquidity) locks their funds under the same h — with a shorter timelock.
4. You reveal s to claim the funds on Base. At that moment s becomes public on-chain.
5. The counterparty sees the revealed s and claims the locked funds on TON.

The key property: h is identical on both chains. The moment the secret is revealed to settle one side, the other side is mathematically able to complete the trade. There is no in-between state of "my money is in some stranger's hands" — only the math of the hash and the clock of the timelock. If anything goes wrong and the timelock expires, the funds return to their original owners. Atomic: either both legs execute, or both roll back.

In TONNode's design, TON is always the source of the trade, and Base (or another supported network) is the destination.

The five cross-chain swap tools in TONNode MCP

TONNode is a hosted MCP server for TON with exactly 16 tools. MCP (Model Context Protocol) is the standard through which AI agents (Claude, Cursor, ChatGPT/Codex, and any MCP client) call external tools. The cross-chain set is exactly 5 tools, available on every plan:

• get_crosschain_quote — the quote: how much you'll receive on Base for your funds from TON, accounting for the route and the timelocks.
• build_crosschain_swap_tx — builds an unsigned HTLC escrow transaction for TON and returns it together with the secret. The user's wallet signs it via TonConnect.
• track_crosschain_swap — shows the trade's phases on both chains: whether the funds are locked on TON, whether the counterparty has locked on Base, whether the secret has been revealed, and whether the trade is complete.
• disclose_crosschain_secret — reveals the secret for settlement, but only after on-chain confirmation that the opposite leg is in place.
• build_crosschain_refund — builds an unsigned transaction to reclaim funds from escrow if the trade stalls and the timelock has expired.

Note the order of responsibility: the tool that reveals the secret doesn't do it blindly — it does it after verifying readiness on Base. This protects you from revealing s in a situation where the counterparty hasn't locked anything yet.

The full flow: quote → build → track → reveal the secret

First, connect the server. Locally and for free — the @tonnode/mcp package is open source (MIT) and speaks TON's native ADNL protocol with no HTTP layers in between:

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

From here, everything happens through prompts to your agent — it breaks them down into tool calls on its own.

Step 1. The quote.

Get me a cross-chain swap quote: 200 USDT from TON to USDC on Base.
Use get_crosschain_quote.

The agent comes back with how much you'll receive on Base and what the escrow timelocks are — the numbers, before you do anything. Happy with them? Move on.

Step 2. Building the unsigned transaction.

Build the HTLC escrow transaction for this quote via build_crosschain_swap_tx.
My TON address is EQ…, my receiving address on Base is 0x…

The output is an unsigned TonConnect message with the HTLC escrow, plus the trade secret. The secret is yours — keep it safe; the server doesn't store it. Your funds get locked in escrow on TON against the hash of that secret. The signature comes from your wallet via TonConnect — the server never touches signing.

Step 3. Tracking.

Check the trade status via track_crosschain_swap by hash h….
Has the counterparty locked funds on Base?

The tool shows the phases on both chains. The agent waits until both sides are locked under the same hash.

Step 4. Revealing the secret.

Funds on Base are locked. Reveal the secret for settlement
via disclose_crosschain_secret.

Only after track_crosschain_swap confirms on-chain readiness does the agent reveal the secret. The reveal settles both escrows atomically: you receive funds on Base, and the counterparty uses the now-public secret to close their side on TON. Trade complete.

Notice the ordering: the secret is revealed last, and only after verifying the opposite escrow is actually in place. Before the reveal your funds can't go anywhere; after the reveal the trade is already atomic.

A detailed walkthrough of the same flow with Ethereum as the destination lives in a separate post: cross-chain swap TON → Ethereum — same mechanics, only the destination network differs. And for why the mere fact that an agent can move value out of TON is a new class of operation altogether, see this post.

Non-custodial: why the server never holds your keys

This isn't marketing language — it's a property of the architecture. The TONNode server never signs transactions and never holds funds or private keys. All it ever hands out is unsigned TonConnect messages and data (quotes, statuses, the secret for your own trade).

Let's lay out where everything lives, step by step:

• The private key of your TON wallet — with you only, in your wallet.
• The secret s — generated at build time and handed to you; nothing remains on the server.
• The signature on the HTLC transaction — made by your wallet via TonConnect.
• The funds on TON — in an escrow contract under a cryptographic condition, not in an intermediary's account.

Even if the server wanted to, it couldn't sign on your behalf or drain the escrow: it has neither the key nor any way to satisfy the unlock condition in its own favor. This is fundamentally different from the custodial approach, where the operator holds the key and signs for you. A full comparison of the two models is in custodial vs non-custodial MCP, and a deep dive into swapping without custody specifically is in the post on non-custodial swaps from an agent.

Which networks are supported besides Base (and why TRON isn't yet)

TON is always the source, and the destination network can be any of:

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

TRON is not supported yet. The reason is technical, not ideological: atomic HTLC escrow requires compatible hash-timelock semantics and predictable contract behavior on the destination side. If your scenario depends on TRON — don't build your agent's logic around it; it's not in the current cross-chain set. When we add it, it will show up on the roadmap: tonnode.io/roadmap.

How to connect, and what if a trade stalls: the refund

For production with guaranteed throughput, use the hosted endpoint with your own key:

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

Every key gets all 16 tools, including the full cross-chain set. You pay for throughput only, not for access to tools:

• Hobby — free forever, 60 requests/min. The key is issued right after sign-in, no card required.
• Pro — $29/mo, 300 requests/min.
• Scale — $199/mo, 1200 requests/min.

What if the counterparty never completes the trade?

This is where the timelock earns its keep. If the other side fails to execute their part and the timelock expires, your funds aren't lost — they're locked under a return-to-sender condition that kicks in after the deadline. The agent calls:

The trade stalled and the timelock has expired. Build a refund
transaction to reclaim funds from escrow via build_crosschain_refund.

build_crosschain_refund returns an unsigned refund transaction — you sign it with your own wallet and take your funds back on TON. This is the insurance built into HTLC: the trade either executes atomically or rolls back on the timelock. A stalled trade doesn't mean lost money — it means a refund. That guarantee is exactly what makes an atomic swap a safe replacement for a custodial bridge.

Where to start

A cross-chain swap TON → Base stops being an act of faith in a bridge once a hash lock and a timelock are what stand behind it, rather than someone else's custodian. Five tools, strict non-custodial design, six destination networks — all of it callable by your agent through a single MCP config.

The fastest way to try it is to grab a free Hobby key (issued right after sign-in, no card required) and run the TON → Base flow from your own agent:

• Free Hobby key → tonnode.io/dashboard?plan=hobby
• Pricing → tonnode.io/pricing
• All 16 tools → tonnode.io/mcp
• Roadmap → tonnode.io/roadmap