Most cross-chain solutions follow the same recipe: lock the asset in a custodial contract, mint a wrapped version on the other side, and hope the bridge stays solvent. Omniston, the cross-chain execution layer built by STON.fi Dev, takes a different approach. It’s a resolver-based protocol secured by linked Hashed Timelock Contracts (HTLCs) on both chains, with no shared vault and no custodian sitting on a pile of assets waiting to get exploited.
This article is about Omniston the protocol, including how it’s architected, what resolvers actually do, how HTLCs hold the whole thing together, and the all-or-nothing guarantee that drops out of the design.
Here’s what’s coming:
- How Omniston differs from a conventional bridge, and what the resolver + HTLC pair actually changes
- What resolvers do, and just as importantly, what they don’t
- How a swap moves from quote request to settlement, step by step
- How Omniston stacks up against bridges, centralized exchanges, and other intent-based protocols
- Where STON.fi fits in, and what other integrators can build on top
What Omniston is
Omniston is a resolver-based cross-chain execution layer developed by STON.fi Dev that enables atomic swaps between TON and other independent blockchains using a Hashed Timelock Contract (HTLC) model. The protocol is open for permissionless integration, so any wallet, aggregator, exchange, or DeFi app can route swaps through it via SDK or API.
A common point of confusion is whether Omniston counts as a bridge. It doesn’t, because bridges move a representation of an asset between chains by minting a wrapped token, while Omniston performs a conditional exchange between two independent blockchains with native assets staying native on both sides. Custody never leaves the user’s control, except into smart-contract escrow that’s provably refundable if the swap doesn’t complete.
Another thing worth clearing up: Omniston is built to sit underneath any cross-chain product, including wallets, aggregators, non-custodial exchanges, and DeFi apps. STON.fi built Omniston, and everyone else can build on it.
Why a resolver model instead of a vault?
The short answer is that vaults concentrate risk in one place, while a resolver model spreads execution across competing parties so no single contract holds a target-sized pile of value.
Traditional bridges concentrate value by design. To move assets from chain A to chain B, the bridge locks them in a contract on A and mints a wrapped token on B. That contract becomes a pile, and piles attract attacks. The history of bridge exploits is, more or less, the history of that pile getting hit.
Omniston replaces the pile with a marketplace. When a cross-chain swap is requested, the protocol broadcasts a Request for Quote (RFQ) to a network of independent resolvers. Resolvers compete to fill the order, the user picks the best quote, and the protocol coordinates settlement through paired HTLCs. No participant has unilateral access to the funds at any point.
What resolvers are
A resolver is a professional liquidity provider that commits its own destination-side assets to fulfill swap requests, with onboarding open to anyone meeting the protocol’s criteria. Here’s what that means in practice.
| Resolvers are independent, so they bring their own capital, set their own quotes, and compete on price. Integrators don’t need to pre-fund destination-side inventory because resolvers handle it on demand. |
The part worth pausing on is the structural alignment. A resolver doesn’t just promise to deliver; it locks its own destination-side assets in an HTLC the moment it commits to a swap. If the swap completes, the resolver claims the user’s source-side asset using the same cryptographic secret that releases the user’s destination asset. If the swap fails for any reason, both sides’ locked assets unlock back to their original owners after the timelock expires. The resolver doesn’t walk away with anything unless it actually delivers.
The HTLC mechanism, briefly
Every Omniston swap is held together by two linked Hashed Timelock Contracts that share the same cryptographic lock, so both sides settle from a single event or both refund automatically. Here’s how that lock works.
Two linked Hashed Timelock Contracts form the spine of every Omniston cross-chain swap: one on the source chain (the bid HTLC) and one on the destination chain (the ask HTLC). Both share the same cryptographic lock, called a hashlock, which is opened by revealing a secret. When that secret gets disclosed on-chain, the user claims the destination asset from the ask HTLC, and the resolver uses the same secret to claim the source asset from the bid HTLC. Both legs settle from a single cryptographic event.
If the secret isn’t revealed within the time window (because a resolver failed, because a chain stalled, because anything went wrong), every locked asset becomes refundable to its original sender. The protocol guarantees just three possible outcomes:
- Secret disclosed: both parties receive the assets they were quoted.
- Resolver fails to respond: the user is refunded by the timelock.
- Secret never disclosed: the resolver is refunded by the timelock.
There is no execution path in which both parties lose funds. This is what “all-or-nothing” means in practice: either both sides receive the intended assets, or no funds move at all.
How a swap moves from RFQ to settlement
A swap travels through five stages, from the initial order signing on the source chain to atomic settlement on both sides once the secret is revealed. The five steps below break that path down.
Step 1. Order creation. The protocol generates a cryptographic secret on the user’s behalf and computes its hash. The user signs an order specifying the asset pair and amounts, with the hashlock embedded in the order parameters. The user’s bid-side assets get locked in the bid HTLC on the source chain.
Step 2. Reservation. A resolver evaluates the bid HTLC and reserves it, signaling its intent to fulfill the swap.
Step 3. Destination lock. The resolver deploys the ask HTLC on the destination chain using the same hashlock, and locks its own ask-side assets there. Both legs are now cryptographically linked.
Step 4. Settlement. The secret is disclosed on-chain. The user claims the destination asset from the ask HTLC, and the resolver uses the same revealed secret to claim the source asset from the bid HTLC. The swap settles atomically.
Step 5 (when applicable). Partial fills. Large swaps can be split into independent sub-swaps, each with its own secret, hashlock, and HTLC pair, so a failure in one sub-swap doesn’t affect the others. A 1,000 USDT order can settle as four parallel 25% sub-swaps; if three complete and one doesn’t, the three are final and the fourth refunds.
Three resolver scenarios in practice
The mechanics get easier to picture with concrete examples, so here are three situations that show how resolvers behave under different market conditions.
- Scenario 1. A clean fill on a TON ↔ EVM pair. A user picks a TON-to-EVM token pair in an Omniston-integrated app like STON.fi. The protocol broadcasts the RFQ, multiple resolvers come back with competing quotes, and the user’s wallet selects the best one. The bid HTLC locks the source asset on TON, the resolver locks the equivalent destination asset in an ask HTLC on the EVM chain, the secret gets revealed, and both legs settle. The user sees one transaction in the interface, while the protocol coordinates two HTLCs underneath.
- Scenario 2. No resolver responds. When liquidity is thin on a given pair at a given moment, no resolver may return a quote within the RFQ window. In that case the swap simply doesn’t initiate, since no HTLC is locked and no source-side asset is touched. The user keeps their original assets and can retry later, with nothing to recover because nothing was committed in the first place.
- Scenario 3. Aggregated liquidity behind a single resolver. For larger orders, a single resolver may aggregate liquidity from several backstops, including its own inventory, partner pools, and AMM venues, to quote a price no single source could cover alone. That aggregation happens off-chain, at the resolver’s level. The on-chain footprint stays minimal: just the HTLC pair and the final secret disclosure. The protocol contract stays small and auditable, while resolvers compete on the sophistication of their routing.
Omniston versus the alternatives
Different cross-chain models make different trade-offs, and the most useful comparison is between Omniston and the specific settlement model a user is choosing not to use. The table below lays out four common approaches side by side.
| Approach | Settlement model | Trust assumption | Best fit |
| Omniston (resolver + HTLC) | Linked Hashed Timelock Contracts on both chains; resolver supplies destination-side liquidity | Cryptographic; atomic execution guaranteed by the contract pair, with no trusted custodian | Cross-chain swaps where atomic settlement and absence of wrapped tokens matter |
| Wrapped-token bridge | Custodial contract on the source chain, minted wrapped token on the destination chain | Trust in the bridge operator, multisig, or validator set holding the pool | Routes where deep wrapped-token liquidity already exists and the user accepts custody risk |
| Centralized exchange | Off-chain ledger; user deposits, exchange swaps, user withdraws | Trust in the exchange’s solvency, KYC posture, and withdrawal availability | Users whose assets are already on the exchange and who don’t need self-custody |
| Lock-and-relay bridges | Asset locked on source chain; a relayer or oracle network signals release on the destination | Trust in the relayer or oracle set | Chain pairs that don’t yet have a resolver-based protocol available |
| Omniston is itself an HTLC-based protocol, so the “intent-based / HTLC” family is the family it belongs to, and what sets Omniston apart within that family is the resolver network. |
Omniston is also stablecoin-first by design. The protocol supports broader token-to-token routing, and its execution guarantees are strongest where stablecoin flows concentrate, because that’s where users care most about predictable outcomes.
Before you initiate a cross-chain swap
A few quick checks before submitting any cross-chain request can prevent the most common failures, most of which originate from address format errors and missing liquidity. The list below covers the ones worth running every time.
- Confirm the destination chain and token address. EVM addresses start with 0x, while TON addresses look different, and an address valid on one chain is not valid on another.
- Wait for a resolver quote before proceeding. No quote means insufficient liquidity for that pair at that moment, so it’s better to wait than to retry into an empty market.
- Check the quoted rate against a reference price. Unusual slippage is much easier to spot before commitment than after.
- Verify the destination wallet supports the right token standard, which means ERC-20 for EVM chains and jetton for TON.
- If settlement takes longer than expected, check the on-chain status of the bid HTLC via a TON explorer instead of resubmitting, since duplicate submissions just complicate the picture.
- Keep a small TON balance in the source wallet. The STON.fi SDK uses a default of 0.3 TON for swap-related calls, and a wallet running near zero can stall the request before it even reaches resolvers.
Final thoughts
Omniston is what a cross-chain protocol looks like when you replace the custodial vault with a marketplace and bind both sides of every swap with cryptography. Resolvers bring the liquidity, and HTLCs bind the outcome. STON.fi is the first product built on top of it, sitting as the visible end of an execution layer that any wallet, aggregator, or DeFi app can integrate.
