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

An agent told to "swap GRAM for BNB and pay a counterparty on BNB Chain" hits a wall at the very first step. It has no safe way to move value between two blockchains that know nothing about each other. The classic route is a centralized bridge or an exchange: deposit your coins, trust the operator, wait, and hope your funds don't get stuck between networks. For an autonomous AI agent that's a non-starter: it can't "trust" a custodian, has no business handing someone else's keys to a third party, and has no hands to manually untangle a stuck transaction.

What you need is a way to move value from TON to BNB Chain so that either everything goes through in full or everything comes back — with no middleman holding the money. That's exactly what a cross-chain swap over an atomic HTLC escrow does. Below we'll break down how it works, which five TONNode MCP tools an agent uses to run the trade, and why the server never touches your funds along the way.

What a TON → BNB Chain cross-chain swap is and why an agent needs one

A cross-chain swap is an exchange of an asset on one network for an asset on another, with no shared ledger between them. TON and BNB Chain are two independent networks with their own virtual machines; there is no common "bank" that could simply rewrite the balances. So you need a protocol that synchronizes two independent transfers so tightly that they become inseparable.

In TONNode, cross-chain always goes from TON as the source to a target EVM network — in our case, BNB Chain. There is no reverse direction and no "BNB as source": TON is always the starting point. You lock GRAM or a jetton on the TON side and receive an asset on the BNB Chain side.

GRAM is Toncoin, renamed in June 2026. The network is still called TON — only the coin's name changed.

Why does an agent need this? Because real tasks rarely stay inside a single network. A treasury agent holds its funds in GRAM, but a supplier needs to be paid on BNB Chain. A trading bot spots an arbitrage between a DEX on TON and one on BNB. An assistant gets the instruction "send the equivalent of 50 GRAM to a counterparty on BSC." In every case you need a way to cross the network boundary — deterministically, without a custodian, and without manual intervention.

How the atomic HTLC escrow works: secret, hash, and timelock

HTLC stands for Hashed Timelock Contract — a contract with a hashlock and a timelock. Sounds intimidating, but the analogy is simple.

Picture two safe-deposit boxes: one on TON, one on BNB Chain. Both are sealed with the same lock, which opens with a single secret key — a random number, the "secret" S. What goes on-chain is not the secret itself but its hash H = hash(S) — a fingerprint of the lock. Anyone can verify that a key fits the lock, but nobody can reconstruct the key from the fingerprint.

You're not the one filling the box on BNB Chain: the counter-leg is posted by a counterparty — a resolver (market maker) who locks BNB under the same hash H, expecting to claim your GRAM on the TON side with that same secret. That's what makes the trade symmetric: both sides are sealed by one lock.

From there, two conditions do all the work:

• The hashlock. Funds can only be claimed from a box by presenting a secret that matches the published hash. The moment the secret is revealed on one side, it becomes visible on the other — and the second leg of the trade settles with the same key. Whoever claims the funds must reveal S in the open, on-chain.
• The timelock. Each box has a timer. If the trade hasn't completed before the timelock expires, the funds return to their original owner. The timelocks are staggered so that the side revealing the secret first cannot cheat the other side.

The result is atomicity: either both legs execute or both get refunded. There is physically no intermediate state where you've given up your GRAM but the BNB never arrived. No third party "guarantees" the trade here — the guarantee comes from the math of the hash function and the timelock logic in the contracts. It's the same mechanism behind atomic swaps and Lightning payments, just adapted for TON and EVM.

The five tools of the trade: quote, build, track, disclose, refund

The full lifecycle of a cross-chain swap in TONNode is covered by five MCP tools. The agent calls them in sequence — like stages of a single trade.

get_crosschain_quote — the quote

Returns a quote for the TON → BNB Chain trade: how much you give up on the TON side and how much you receive on the BNB Chain side. Every swap starts here — the agent shows the numbers to the user before anything gets locked.

build_crosschain_swap_tx — transaction build + the secret

Returns an unsigned HTLC escrow transaction plus the secret. The transaction is signed by the user's wallet via TonConnect, not by the server. The secret S is generated right here and stays with the user/agent — it's what later unlocks the second leg. The server generated the transaction and the hash, but the signature and ownership of the secret remain with the user.

track_crosschain_swap — phase tracking

Shows the trade's phases on both networks — TON and BNB Chain alike: whether the TON leg is locked, whether the counter-leg has appeared on BNB Chain, whether the secret has been revealed, whether settlement is complete. This is how the agent sees: without tracking, it has no idea when it's safe to reveal the secret or whether it's time for a refund.

disclose_crosschain_secret — revealing the secret

Reveals the secret for settlement — but only after verifying readiness on-chain. The tool won't hand over S blindly: first it confirms that the counter-leg on BNB Chain is actually in place and the conditions are met. That protects you from the scenario where you've revealed the secret and there's nothing to claim on the other side.

build_crosschain_refund — refund from escrow

Builds the transaction that returns funds from escrow if the trade stalls — once the timelock has expired. Also an unsigned transaction for TonConnect. It's the safety net we'll come back to at the end.

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

This is where TONNode draws its hard line. The swap, cross-chain, and wallet tools are strictly non-custodial. The server NEVER signs or holds funds and private keys — it returns only unsigned TonConnect messages, which the user's wallet signs.

Let's spell it out for cross-chain specifically:

• build_crosschain_swap_tx returns a transaction without a signature. The signature comes from the user's wallet — Tonkeeper, MyTonWallet, anything TonConnect-compatible. Until the user confirms the transaction, nothing gets locked.
• The secret S goes to the client. The server can't quietly drain the escrow: that would require the owner's signature, and the server doesn't have it.
• Even the refund is an unsigned transaction: the return is initiated by the user, not the server.

The practical takeaway: a compromised server doesn't lead to stolen funds, because there's nothing there to steal — no keys, no signatures, no control over the escrow. The worst possible failure mode is denial of service (the agent doesn't get a quote), not loss of money.

Compare that with the custodial model, where an agent-wallet holds an operator key and signs on its own. Both models have their place, but for cross-chain across two independent networks, being non-custodial matters even more — you do not want a middleman controlling money stranded between blockchains. For a detailed breakdown of the two approaches, see Custodial vs non-custodial MCP, and for how this looks for a regular swap inside TON, see Non-custodial swaps for agents.

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

Cross-chain in TONNode always goes from TON to a target EVM network. The supported targets:

• Ethereum
• Arbitrum
• Base
• BNB Chain (our case)
• Polygon
• Avalanche

TRON is NOT supported yet. The reason is technical: an atomic HTLC escrow requires the target network to treat hash-timelock contracts identically within the chosen escrow protocol. The six networks listed are EVM-compatible and fit that model; TRON, despite the surface resemblance, lives by its own model and needs a separate escrow implementation. Until that exists, TRON isn't on the list — and we don't pass wishful thinking off as fact.

For the most popular pair — TON → Ethereum — there's a separate walkthrough: Cross-chain swap TON → Ethereum. The mechanics are identical; only the target network changes.

A step-by-step TON → BNB swap run over MCP

First, let's hook TONNode up to the agent. The local public config, @tonnode/mcp, is free and gives you the full set of read tools — but reads only. The 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"]
    }
  }
}

One important caveat: the five cross-chain tools are not available through the local public npx — that's read-only. A cross-chain trade runs through the hosted endpoint with its own key, and the free Hobby key is enough:

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

With a hosted key, all 16 tools — including the five cross-chain tools — are available on every plan, starting with the free Hobby. You only pay for throughput (Hobby — free, 60 requests/min; Pro — $29/mo, 300 requests/min; Scale — $199/mo, 1200 requests/min). Cross-chain isn't gated behind a higher plan — but the local npx won't do; you need a hosted key.

Now the run itself. The prompt to the agent can be as human as it gets:

"Swap 50 GRAM from my TON wallet to BNB Chain, to the address 0x…. Show me the quote first, then build the transaction — I'll sign it myself."

Here's what happens under the hood:

1. Quote. The agent calls get_crosschain_quote (source TON, target BNB Chain, amount 50 GRAM) and shows how much will arrive on the BNB Chain side.
2. Build. After your "go ahead," the agent calls build_crosschain_swap_tx. It receives an unsigned HTLC escrow transaction and the secret S. You confirm the transaction in your own wallet via TonConnect. Your funds get locked in escrow on the TON side under the hash H.
3. Tracking. The agent periodically calls track_crosschain_swap and watches the phases on both networks: is the TON leg locked, has the counter-leg come up on BNB Chain (posted by the resolver under the same hash H).
4. Reveal and settle. As soon as track_crosschain_swap shows readiness, the agent calls disclose_crosschain_secret. The tool verifies readiness on-chain and reveals S — the secret becomes visible on BNB Chain, both legs settle, and the BNB lands at your address.
5. Confirmation. A final track_crosschain_swap shows both sides settled. Trade closed.

The whole point is that at any moment you can see the state of the trade on both networks, and you only sign what you can see. If you're curious about the bigger picture behind that first move of value out of TON via MCP, it's covered in The first cross-chain value transfer out of TON.

If the trade stalls: getting your funds back from escrow

Cross-chain means two independent networks, and sometimes the counter-leg never comes up: the counterparty has problems, the network is congested, something went sideways. In the custodial model this is where the support-ticket saga begins. With HTLC, you simply wait out the timelock.

The funds are not locked forever. Once the timelock has expired and the trade hasn't completed, the agent calls build_crosschain_refund and gets an unsigned transaction that returns the funds from escrow. You sign it with your own wallet via TonConnect — and the locked GRAM comes back to you. No "funds stuck forever": this guarantee is built into the contract itself, not promised by a service.

The prompt can be as simple as:

"My cross-chain swap to BNB Chain didn't complete. Check the status and, if the timelock has expired, get my funds back."

The agent will call track_crosschain_swap, confirm that settlement never happened and the timelock has passed, then build the refund via build_crosschain_refund and hand you the transaction to sign.

The key security point: the secret is revealed via disclose_crosschain_secret only after an on-chain readiness check. The agent can't end up in a trap where the secret is already out and there's nothing to claim. Either settlement happens atomically, or the timelock triggers the refund. There is no third option — that's what the word "atomic" means.

---

Grab a free key and wire up cross-chain

The five cross-chain tools are part of the standard set of 16 — nothing extra to buy. Get a free Hobby key (60 requests/min, no card, issued right after sign-in) and connect TONNode to your agent: tonnode.io/dashboard?plan=hobby.

Want to browse the full set of 16 tools and their parameters first? Here's the tools page: tonnode.io/mcp.

Cross-chain from TON to BNB Chain stops being a "trust the bridge" exercise and becomes an ordinary tool call — atomic, non-custodial, and with a guaranteed refund if anything goes wrong.