Moving value between TON and EVM chains sounds simple from the outside. In practice, it depends on the architecture underneath.
For TON to Base, BNB Chain, and Polygon, there are two main ways this usually happens. The first is the bridge model, where value is locked or burned on one chain and a wrapped version appears on the other. The second is the resolver-based HTLC model, where both sides settle through linked contracts and the user receives the destination asset directly. In STON.fi’s case, that second model is what Omniston — the cross-chain execution layer built by STON.fi — is built around.
| This guide explains what changes between those two models, why TON makes cross-chain routing a little more involved than a standard EVM-to-EVM move, and what to check before you send funds anywhere. |
Quick framing
Before getting into the details, it helps to fix the basic picture.
In the bridge model, tokens are locked or burned on the source chain, then a wrapped equivalent is minted or released on the destination chain. In the resolver-based HTLC model, both sides of the swap settle through linked contracts, with native assets on both sides and no wrapped representation in the middle. In both cases, the real cost still includes three things: source-chain gas, protocol fees, and destination-chain gas. That is the full bill, not just the first number you see.
Why TON makes cross-chain routing more involved than usual
TON is harder to connect to EVM chains because it is not part of the EVM family. Base, BNB Chain, and Polygon all run on the Ethereum Virtual Machine, so smart contracts written for one can often be adapted to the others without much drama. TON is different. Its contracts are written in FunC, Tact, or Tolk, not Solidity, which means TON-to-EVM routes need extra handling that EVM-to-EVM routes can skip.
There is also one more thing worth knowing. TON contract interactions can succeed or fail independently, while EVM users are more used to the idea that a multi-step transaction either completes fully or reverts fully. That difference does not make TON cross-chain swaps unsafe. It just makes architecture matter more. In a well-built route — Omniston’s, for example — the cross-chain leg’s atomicity is enforced by the HTLC pair, not by TON’s internal message ordering, so the async-messaging property of TON does not propagate into the cross-chain outcome.
How a TON-to-EVM swap moves through the system
The short answer is that bridge routes and resolver-based HTLC routes move through very different settlement logic.
The bridge model
In a bridge route, the bridge contract takes custody of the source-side asset. That usually means the asset is locked in a reserve or burned on the source chain. Then a relayer or oracle layer proves that event to the destination chain, where a wrapped equivalent is minted or a previously locked version is released to the receiving wallet.
From the user side, the flow can still look quite clean: connect wallets, choose the route, check the quote, send the transaction. But under the hood, the path depends on message delivery, reserve integrity, and the wrapped asset being usable when it lands.
The resolver-based HTLC model
In the resolver-based HTLC model, the swap starts with a quote request.
The user specifies the source asset on TON and the destination asset on Base, BNB Chain, or Polygon. A network of resolvers competes through Request for Quote (RFQ) to fill that request. The winning resolver locks destination-side assets in a Hashed Timelock Contract (HTLC) on the EVM chain, while the user’s funds lock in a paired HTLC on TON. Both contracts share the same hashlock. When the secret is revealed, both sides settle atomically. The user receives the native destination asset; the resolver claims the source-side asset. No wrapped token is minted in the middle.
That is the practical difference. A bridge route moves value by custody and message delivery. A resolver-based HTLC route moves value by linked settlement conditions.
What “all-or-nothing” means here
In this model, the swap has only a small number of valid outcomes.
Either both sides receive the assets they were quoted, or the swap unwinds according to the timelock rules. If the resolver never responds, the user is refunded by the timelock. If the secret is never disclosed, the resolver is refunded by the timelock. There is no execution path in which both parties lose funds. The route is designed to avoid the ugly middle state where one side completed and the other side did not.
That is what atomicity means in practice. It is less exciting than the buzzword sounds, which is good. It means fewer mysteries when something fails.
Why jettons make the architecture choice more obvious
Jettons make the contrast much easier to see.
In the bridge model, not every jetton has a useful wrapped version on the destination chain. Even if a wrapped version exists, it still needs real liquidity and redemption mechanics to be usable. In the resolver-based HTLC model, the user asks for the destination asset directly, for example USDC on Base or USDT on BNB Chain, so the route does not depend on a wrapped jetton showing up with enough DEX support afterward.
That is a much cleaner user story.
Three places where TON cross-chain transfers get messy
Cross-chain transfers get messy when the route looks complete on paper but starts leaking friction in practice.
1. Destination-side liquidity
Destination liquidity matters in both models, but the question is different in each one.
In the bridge model, you need to know whether the wrapped asset that arrives is actually liquid enough to use. In the resolver-based HTLC model, the question is whether resolvers are active on that route at the size you want to move. The issue is still liquidity; the difference is where it shows up.
2. Multi-hop routing
Routing through Polygon or another chain can reduce fees, especially on smaller transfers. But each extra hop adds another contract interaction, another confirmation window, and another place for the route to slow down or fail.
The practical rule is simple: only add a hop if the savings clearly justify the added complexity. In a resolver-based system, the user often does not have to plan that hop manually because the routing can be handled underneath the quote.
3. Round-trip asymmetry
Round trips are where bridge logic often turns annoying.
A route from TON to Base may not look anything like the return trip. Some bridge protocols support one direction better than the other, or apply a different fee structure on the reverse leg. Assets coming back to TON may also arrive as wrapped versions rather than native ones, which means an extra swap on a TON-native DEX before the funds are truly usable again. In the resolver-based HTLC model, the round trip is symmetric by design because the same paired-contract structure works in both directions.
That does not make every return route identical in cost, but it does make the logic much cleaner.
How Base, BNB Chain, and Polygon differ
The three destination chains are not interchangeable.
Base
Base is usually the cleanest option for low-fee EVM activity and for users moving stablecoins into Base-native DeFi. It is a natural fit when low gas matters and the route size is not too large for the available destination liquidity.
BNB Chain
BNB Chain is often the broadest route in terms of token variety and stablecoin depth. It is useful when the destination is a BNB-native DEX or yield environment. The main thing to watch is whether the specific token you want is actually liquid enough on the BNB side.
Polygon
Polygon is often the most fee-sensitive option. If you are moving smaller amounts and gas matters a lot, Polygon can make the route more economical. The trade-off is that it is not always the true destination; sometimes it is just a clever stop on the way somewhere else.
What this means for TON’s place in a multi-chain market
Cross-chain routing is not just a convenience layer. For TON, it is part of how the ecosystem becomes usable in the broader crypto economy. With Telegram reaching approximately 950 million users, TON has a distribution channel that developer incentives alone cannot replicate. But that on-ramp only matters if assets and yield opportunities can flow freely across chains, which makes architecture choice — not just route availability — a decisive factor in TON’s Web3 position.
It matters because bridge risk is not theoretical. Chainalysis estimated that cross-chain bridges accounted for approximately $2 billion in stolen funds across 13 incidents in 2022 alone, roughly 69% of all crypto theft recorded that year. Bridge exploits had reached approximately $329 million by mid-2026 according to PeckShield data. The pattern has not reversed, and TON’s original bridge has already been deprecated for new transactions in favor of the current bridge landscape listed on ton.org.
Resolver-based HTLC protocols sit in a categorically different position. The attack surface that has cost users billions — the locked reserve, the validator multi-sig, the relayer set — only exists because bridge architecture uses that pattern. Omniston runs on paired HTLCs per swap, with no shared bridge contract pooling reserves, no validator multi-sig holding the keys, and no relayer that can censor or stall message delivery. Each swap is its own self-contained pair of contracts, refundable by timelock if anything goes wrong. The Omniston design is stablecoin-first, which is the category where reliability matters most — and the resolver network is what makes that reliability deep enough to be practical at meaningful volume.
Final thoughts
Cross-chain swaps between TON and EVM chains are practical today. The more important question is how they settle.
Bridge routes can work, and sometimes they are the only route available. But they come with the trade-offs their design suggests: wrapped assets, relayer dependencies, asymmetric return paths, and more route-specific friction once you look closely. Resolver-based HTLC routes aim for a cleaner outcome: native assets on both sides, atomic settlement, and a return path built on the same logic as the outbound one.
For TON to Base, BNB Chain, or Polygon, that is the real choice. It is not only about which destination chain you prefer. It is about which architecture you trust to get value there without turning the move into a small infrastructure project.
