How to Move Tokens Between TON and Ethereum Without a Traditional Bridge
Moving tokens between TON and Ethereum used to be strongly associated with one familiar architecture: use a bridge, lock an asset on one network, wait for the system to recognize the transaction, and receive a representation or released liquidity on the other side.
But cross-chain infrastructure has evolved.
Today, users can approach the same problem from a different direction: instead of asking, “How do I transfer this asset to another blockchain?”, they can ask, “What asset do I want to receive on the other blockchain?”
That distinction is at the heart of resolver-based cross chain swaps.
With a swap-first architecture such as Omniston, developed by STON.fi, the objective is not simply to transport an asset between TON and Ethereum. The system coordinates an exchange between assets on two independent blockchains. A resolver supplies liquidity on the destination side, while linked Hashed Timelock Contracts (HTLCs) connect the two sides of the transaction.
The result is designed around an important principle: the swap should either settle according to its conditions on both sides or return the locked funds through the timelock mechanism.
Why Move Value Between TON and Ethereum?
Blockchains are isolated environments. Ethereum does not inherently know what happened on TON and TON does not inherently know what happened on Ethereum. Moving value between them therefore requires some mechanism for coordinating activity across the two networks.
The reason users want that coordination is usually practical.
A user holding assets on Ethereum may want access to TON based DeFi, TON native tokens, different liquidity opportunities or potentially lower transaction costs for subsequent activity. Conversely, a TON user may want access to Ethereum liquidity, EVM based applications, or assets that primarily exist in the Ethereum ecosystem.
The important point is that the user normally has an outcome in mind rather than an infrastructure preference.
Someone may start with USDT on Ethereum and actually want USDT on TON. Another user may hold an asset on TON but want an Ethereum based token or stablecoin. In both cases, merely moving an equivalent representation across the network is only part of the problem.
This is where the difference between bridge first and swap first architectures becomes important.
Bridge First vs Swap First
A traditional bridge is primarily designed around transferring value from one blockchain to another.
In a classic lock-and-mint model, the source asset is locked in a bridge contract. The destination network then receives a wrapped or mirrored representation. Other bridge architectures can use destination-side liquidity instead of minting a wrapped asset, but the central objective remains transportation of value across networks.
A typical bridge-first flow therefore looks like:
Asset on Ethereum → bridge → asset representation on TON → optional swap → desired TON asset
The user first completes the cross-chain transfer and then handles whatever conversion is necessary after arrival.
A swap-first approach reverses the perspective:
Asset on Ethereum → cross-chain quote → destination asset on TON
Instead of making the intermediate representation the user's main concern, the route is built around the asset the user actually wants to receive.
This is one reason modern cross-chain products can feel considerably different from traditional bridge workflows. A cross-chain swap combines the movement between networks with the exchange itself, making the final destination asset part of the original order.
Neither architecture should be understood as merely a different interface. They make different assumptions about custody, liquidity, settlement and what the user receives at the end.
Bridge-first: transport first
Suppose a user has an asset on Ethereum and wants to participate in TON DeFi.
A bridge may move the value to TON first. Depending on the bridge architecture, the user could receive a wrapped token or another representation supported by that bridge.
The process might then require another swap into the token actually needed for the desired TON application.
That creates additional route-management responsibility. The user has to understand not only how to cross the network boundary, but also whether the resulting token is accepted by the destination protocol.
Swap-first: outcome first
With a cross-chain swap, the user specifies the source asset and destination asset.
For example:
Ethereum USDT → TON USDT
The system does not need to give the user a wrapped Ethereum representation on TON and ask them to perform another conversion. Instead, the destination-side liquidity provider can supply the requested TON-side asset directly.
That is the architectural idea behind Omniston.
The important question changes from:
“How can I move this token across?”
to:
“What do I want to receive on the other chain?”
What Does the User Actually Receive?
This is one of the most important differences to understand.
A bridge can move value while leaving the user with a wrapped or mirrored representation of the original asset. That representation may be perfectly useful, but it can introduce another consideration: whether the destination protocol supports that particular version.
A swap-first architecture targets the destination asset directly.
For example, imagine a user starts with USDT on Ethereum and requests USDT on TON through an Omniston-powered route.
The desired result is not an Ethereum-wrapped representation of USDT on TON. The resolver supplies the requested destination-side asset, so the user receives the appropriate TON side token directly. STON.fi describes this as the practical difference between bridging into a wrapped Jetton and atomically swapping into a destination asset through Omniston.
The same principle works in the opposite direction.
A user might start with a TON asset and request an Ethereum token. The destination is defined by the quote and order rather than by simply reproducing the source asset on another chain.
That distinction makes the architecture particularly useful for users who already know what they want to do after the cross-chain transaction.
Where Resolver Based Execution Enters
The next question is obvious:
If there is no traditional bridge vault holding the user's assets and minting a wrapped representation, who provides the asset on the other chain?
The answer is the resolver.
A resolver is a liquidity provider participating in the Omniston network. It evaluates incoming requests, provides a quote, and commits destination-side liquidity when it agrees to fulfill the trade. Resolvers can compete for requests, meaning the cross-chain transaction can be treated as a liquidity marketplace rather than a single bridge controlled route.
Imagine a user wants to exchange Ethereum USDT for TON USDT.
The user creates a request specifying the source asset, destination asset and amount.
Omniston distributes a Request for Quote, commonly called an RFQ, to participating resolvers.
Resolvers can respond with their proposed execution terms.
A suitable resolver is selected and the two sides of the transaction are then connected through the settlement mechanism.
This matters because the resolver is not simply promising:
“I will send your destination tokens later.”
The protocol's design requires the resolver to commit destination-side assets through the corresponding settlement structure.
That commitment is what gives the system its cryptographic connection between the source and destination transactions.
Understanding HTLCs Without the Jargon
The technical foundation behind this process is the Hashed Timelock Contract, or HTLC.
The name sounds complex, but its purpose can be explained through two ideas:
A secret
and
a deadline.
First, a cryptographic secret is generated.
A hash of that secret is used as the hashlock. The hash can be shared publicly, but the original secret remains hidden until the appropriate stage of execution.
The second component is the timelock.
The contracts define a time condition under which the transaction can either be completed using the secret or refunded after the required period expires.
Omniston links two HTLCs:
A bid HTLC on the source blockchain.
An ask HTLC on the destination blockchain.
The two contracts use the same cryptographic condition.
This creates the central relationship between the two chains.
The user's source side asset is locked in the bid HTLC.
The resolver's destination-side asset is locked in the ask HTLC.
The same secret connects them.
How the Atomic Settlement Works
Consider a simplified Ethereum → TON example.
The user has USDT on Ethereum and wants USDT on TON.
Step 1: The order is created
The user specifies the source and destination assets and accepts a quote.
The system creates the cryptographic condition required for settlement, and the user's source-side funds become subject to the bid-side HTLC.
Step 2: A resolver commits
A resolver accepts the trade and commits to fulfilling the destination side.
The resolver supplies the requested TON-side asset.
Step 3: The destination side is locked
The resolver's destination asset is placed into the corresponding HTLC on TON using the same hashlock.
At this point, the source and destination sides are cryptographically connected.
Step 4: The secret is revealed
When the execution condition is satisfied, the secret becomes available on-chain.
The user can use the secret to claim the destination asset from the ask HTLC.
The resolver can use that same secret to claim the source-side asset from the bid HTLC.
One cryptographic event therefore connects both settlements.
Step 5: The timelock provides the fallback
What happens if the swap does not complete?
This is where the second half of HTLC architecture becomes important.
If the secret is never revealed within the required time window, the timelock allows the locked assets to become refundable to their original owners.
The documented Omniston model therefore describes three possible outcomes: successful settlement when the secret is disclosed, a user refund when a resolver fails to respond, or a resolver refund if the secret is never disclosed.
This is what the protocol means by all or nothing settlement.
The goal is not merely to make cross-chain swaps faster or simpler. The settlement logic is designed so the two sides of the transaction remain cryptographically connected.
Why “Without a Bridge” Does Not Mean “Without Infrastructure”
It is worth clarifying the phrase without a traditional bridge.
It does not mean blockchains suddenly communicate directly.
It does not mean there is no liquidity provider.
It does not mean there are no smart contracts.
And it does not mean there is no cross chain execution infrastructure.
Instead, it means the user is not relying on the conventional bridge pattern of putting assets into a shared bridge vault and receiving a wrapped representation on the other network.
Omniston replaces that bridge-first model with a resolver-based execution layer using linked HTLCs. STON.fi's documentation describes Omniston as an aggregation and execution layer capable of working with liquidity sources and resolvers, while the current cross-chain architecture uses resolvers and HTLC based settlement for cross chain execution.
The infrastructure is still there.
It is simply organized around execution of an exchange, rather than transport through a shared vault.
A Practical Example With STON.fi and Omniston
Now consider how the architecture appears from a user's perspective.
Suppose you have USDT on Ethereum and want USDT on TON.
Rather than beginning with a separate bridge, the practical flow through a STON.fi-powered cross-chain interface can be understood as:
Ethereum / USDT → Omniston quote → TON / USDT
The first requirement is a valid destination.
You select Ethereum as the source network, USDT as the source asset, TON as the destination network and the desired TON side asset.
Omniston then obtains quotes through its resolver network.
The resolver's quote determines how much destination-side liquidity will be provided for the source amount under the quoted conditions. STON.fi's developer documentation also describes Omniston integrations as using RFQ requests, quote streaming, transaction construction and trade status tracking.
From the user's perspective, this compresses what could otherwise become a multi-stage workflow into one intended outcome:
“I want this asset on that chain.”
Underneath, however, the protocol is coordinating multiple blockchain operations.
That is an important distinction.
A simple interface does not mean the underlying architecture is simple.
The user sees a swap.
The protocol is coordinating an RFQ, resolver liquidity, source side settlement, destination side settlement, cryptographic conditions and transaction tracking.
Why the Destination Asset Matters
Imagine two possible routes for an Ethereum user entering TON DeFi.
Route A
Ethereum USDT → Bridge → Wrapped USDT on TON → Swap → TON USDT
Route B
Ethereum USDT → Omniston → TON USDT
The two routes have the same broad objective, but the intermediate experience is different.
Route A treats the cross-chain movement as the primary operation and the token conversion as a separate problem.
Route B starts with the final outcome.
This is particularly relevant when the user knows exactly what asset is required on TON.
A destination application may expect a particular TON Jetton rather than an arbitrary wrapped representation. A swap first architecture attempts to solve that requirement before the funds arrive rather than leaving the user to resolve it afterward.
That is why STON.fi describes Omniston's approach as being centered on the destination asset rather than simply moving the source asset across the network.
The Role of RFQ Liquidity
Another important component is the Request for Quote mechanism.
An AMM typically exposes liquidity through pools.
A resolver-based system introduces another liquidity source: professional market participants that can respond to individual requests with executable pricing.
When an Omniston request is broadcast, eligible resolvers can evaluate the trade and return quotes. They bring their own capital and can compete on the execution terms they are prepared to offer.
This creates a marketplace around cross-chain execution.
Instead of relying on one permanent pool containing a representation of assets from multiple chains, destination side liquidity can be supplied by a resolver when a specific order needs to be filled.
For the user, the practical benefit is that the cross chain route can be built around an actual destination quote.
For the infrastructure, the benefit is that liquidity can be coordinated around individual transactions.
What Happens During a Larger Swap?
Large orders do not necessarily have to behave as one indivisible transaction.
The Omniston architecture described by STON.fi supports partial fills by splitting a larger order into separate sub-swaps. Each sub swap can have its own cryptographic secret, hashlock and HTLC pair.
Conceptually, a 1,000 unit order could be divided into multiple smaller executions.
That means one sub-swap can settle while another remains pending or ultimately refunds, depending on the execution conditions.
This is an important distinction from thinking of a cross chain transaction as a single giant transfer.
At the protocol level, the system can coordinate multiple settlement units.
Bridge Risk vs Resolver Based Settlement
The architectural comparison is not simply about speed.
It is also about where trust and risk are concentrated.
A traditional bridge can concentrate substantial value inside contracts or infrastructure responsible for representing or releasing assets on another chain. The security model therefore depends significantly on that bridge's architecture, operators, validators, multisig controls or other verification mechanisms.
The resolver/HTLC model takes a different approach.
Rather than maintaining one shared vault containing the user's destination representation, independent resolvers supply destination side liquidity and the settlement contracts link the source and destination sides.
That does not mean the system has no risks. Users still have to consider smart contract risk, resolver availability, liquidity conditions, incorrect addresses, network conditions and the security of the assets themselves.
But the architecture changes where the risk sits.
The intended security property is enforced by the linked HTLC conditions rather than by trusting a centralized party to manually release the other side of a transfer.
Before You Execute a TON ↔ Ethereum Swap
Even when the protocol is designed to simplify cross chain execution, users should not treat the process as “connect wallet and click blindly.”
The final checks remain important.
1. Check the source network
Make sure the asset is actually on the network you selected.
USDT on Ethereum is not the same on-chain object as USDT on TON, even though they share the same ticker and broader monetary reference.
Always verify the network before signing.
2. Check the destination network
Confirm that TON is actually the destination if that is where you intend to receive the funds.
Likewise, when moving in the opposite direction, verify the specific EVM network.
Cross-chain transactions are network specific.
3. Check the destination asset
Do not focus only on the amount.
Look carefully at the asset you are receiving.
The whole point of the swap-first approach is that the destination asset is part of the requested outcome.
4. Check the wallet address
TON addresses and EVM addresses use different formats.
EVM addresses generally begin with 0x, while TON addresses have a different structure.
A valid address on one network is not automatically a valid destination address for the other. STON.fi specifically recommends verifying the destination chain, token address and wallet compatibility before execution.
5. Review the quote
Do not treat the quote as decorative information.
Check:
amount sent → amount received → network → destination asset → applicable fees → quoted conditions
A quote should make the final outcome understandable before you approve the transaction.
6. Check resolver availability
A resolver needs to be available to fill the request.
If no suitable resolver responds, the order may not initiate.
This is not necessarily a failed transaction. It can simply mean there is not enough resolver liquidity for that particular pair and amount at that moment. STON.fi's description notes that when no resolver responds, no HTLC needs to be locked and the user retains the original funds.
7. Keep enough network gas
Cross chain execution does not eliminate blockchain transaction fees.
The source side wallet still needs enough network-native balance to execute the necessary transaction.
STON.fi's current guidance specifically notes the importance of maintaining sufficient TON for transactions involving the TON wallet.
8. Do not resubmit blindly
A transaction that appears delayed should first be investigated.
Check the relevant blockchain explorer and the transaction or trade status before creating another request.
Submitting the same order repeatedly without understanding the first transaction can make troubleshooting more complicated.
From a User's Perspective, the Flow Is Simple
The complete experience can be reduced to a few visible stages:
Choose the source asset.
Choose the destination network.
Choose the destination asset.
Request a quote.
Review the amount, fees and destination.
Approve the source transaction.
Track the execution.
Behind those actions, Omniston is coordinating a considerably more sophisticated process involving resolvers, RFQs, HTLCs and blockchain settlement.
STON.fi's developer tools expose quote retrieval, transaction construction and trade tracking to applications integrating Omniston, showing that the same infrastructure can sit underneath wallets, DeFi applications and other interfaces rather than existing only as a standalone user experience.
The Bigger Idea: Cross-Chain as an Outcome
The deeper significance of resolver-based cross chain execution is not simply that it removes one button from the user interface.
It changes how cross chain transactions can be designed.
The traditional mental model is:
Move the asset → wait for it to arrive → convert it → use it.
The newer model is:
Specify the asset you want → obtain a quote → settle the exchange across chains.
That difference sounds small, but architecturally it is significant.
The bridge first model is primarily concerned with transporting value.
The swap-first model is primarily concerned with delivering an intended outcome.
Omniston takes that concept further by combining RFQ based resolver liquidity with linked HTLC settlement. The resolver provides the destination-side liquidity, while the shared cryptographic condition connects the source and destination legs. If the required condition is met, both sides can settle; if it is not, the timelock mechanism provides the refund path described by the protocol.
Final Thoughts
Moving tokens between TON and Ethereum does not necessarily require the user to begin with a traditional bridge.
The important distinction is between transport first and outcome first cross-chain architecture.
A bridge-first approach generally focuses on getting value from one blockchain to another, potentially leaving the user with a wrapped or mirrored destination representation that may require another conversion.
A swap-first approach starts with the desired destination asset.
That is the model demonstrated by Omniston.
Through a resolver network, users can request destination focused quotes while independent liquidity providers supply the asset needed on the other side. Linked HTLCs then connect the source and destination transactions through a shared cryptographic condition and timelocks.
For a practical TON ↔ Ethereum route through STON.fi, the important principle is therefore simple:
You are not merely moving a token across a blockchain boundary. You are requesting an asset on the destination chain and allowing the infrastructure to coordinate the exchange that gets you there.
That is what makes resolver-based cross chain execution different from a traditional bridge first workflow.
And before every swap, the practical discipline remains the same: verify the wallet, network, destination asset, quote, fees and transaction status.
The interface may make cross-chain movement look like one swap, but understanding what happens underneath is what allows users to use that simplicity intelligently.
Read more about STONfi here: https://blog.ston.fi/omniston-explained-how-cross-chain-swaps-on-ton-work-without-a-bridge/