Cross-chain swaps are often explained simply: lock funds with a secret and a timer, then either complete the trade or get the funds back. That is true, but it misses the most important part.
Cross-chain swaps are often explained simply: lock funds with a secret and a timer, then either complete the trade or get the funds back.
That is true, but it misses the most important part.
The real challenge is coordinating two independent blockchains so neither side can take the other's assets without giving the counterparty enough time to complete the trade or recover their funds.
This is where Hash Time-Locked Contracts, or HTLCs, come in.
The hashlock connects both sides through the same secret. The timelocks determine when claims and refunds can happen.
An HTLC gives locked funds two possible outcomes.
Claim: the receiver provides the correct secret before the claim deadline.
Refund: after the deadline, the sender can recover the funds according to the contract rules.
A simplified version looks like this:
if valid_secret and claim_window_is_open: release_to_receiver else if refund_time_has_arrived: return_to_senderThis is illustrative pseudocode, not STONfi production code.
The important point is that the contract defines both outcomes in advance.
A refund is not necessarily a protocol failure. It is part of the design.
The swap begins with a random secret.
The initiator keeps the secret private and publishes only its hash.
secret = generate_random_secret() hashlock = hash(secret) publish(hashlock) keep_private(secret)Later, when the secret is used to claim one side of the swap, it becomes visible on-chain.
The other participant can then use that same secret to claim the corresponding HTLC on the other chain.
That is how two independent chains can coordinate without directly communicating with each other.
One HTLC, however, is only a conditional payment.
A cross-chain swap needs one on each side.
Suppose Alice wants an asset from Bob on another chain.
Both HTLCs use the same hashlock, but their deadlines are different.
The destination-side deadline needs to come before the source-side refund deadline.
That gap gives the second participant time to react after the secret becomes public.
TIME ───────────────────────────────────────► Destination HTLC [──────── claim window ────────| deadline ] ↓ secret revealed Source HTLC [──────────────────────────────| deadline ] reaction windowThe exact duration depends on the chains and their confirmation assumptions.
The principle does not change:
The later deadline protects the participant who needs to act after the secret is revealed.
Suppose Alice's original lock expires first.
Alice can refund her own funds.
But she still knows the secret.
If Bob's HTLC remains active, Alice could potentially reveal the secret and claim Bob's asset afterward.
The hashlock did not fail.
The deadline arrangement did.
That is why the relationship between the two timelocks is one of the most important parts of an atomic swap.
After the secret is revealed, the other party needs time to:
Detect the transaction
Read the secret
Create and broadcast a claim
Wait for confirmation
Handle congestion or finality delays
So the deadline gap needs to be large enough for realistic network conditions.
Too small, and a delayed transaction can create unnecessary risk.
Too large, and capital stays locked longer than necessary.
The timelock is therefore an engineering decision, not just a number added to the contract.
HTLCs solve the settlement problem.
They do not solve the market problem:
Who is providing the other side of the trade, and at what terms?
This is where Omniston adds another layer.
STONfi describes Omniston as an RFQ-based system that connects users with liquidity sources and resolvers for swap execution. For cross-chain routes, HTLC-based atomic swaps can handle settlement. STONfi Omniston documentation
The simplified flow is:
User request ↓ RFQ ↓ Resolvers / liquidity sources ↓ Available quotes ↓ Selected route ↓ SettlementThis separates finding a trade from settling a trade.
There are essentially two stages.
The user requests a quote.
Resolvers can respond with available terms.
If nothing suitable is found, the request can expire without requiring an HTLC refund because settlement never started.
Once the route is selected, the cross-chain settlement begins.
This distinction matters because a quote deadline and an HTLC deadline do different jobs.
A quote determines how long an offered price remains valid.
A timelock determines what happens after funds have entered settlement.
A same-chain swap operates inside one blockchain environment.
A cross-chain swap has to coordinate two independent chains.
The chains do not share one transaction state, so the settlement process needs time for events on one chain to become observable and actionable on the other.
That means some of the extra waiting is part of the security model.
The trade-off is simple:
More cross-chain coordination requires more time.
TON uses asynchronous message passing, so contract interactions can trigger additional messages and state changes.
A simplified STONfi flow can look like:
User ↓ Jetton wallet ↓ Router ↓ Pool ↓ SettlementA cross-chain trade adds another blockchain and its own confirmation process to that flow.
So it is better to think of the trade as a sequence of states rather than:
submit transaction → instantly finishedProper trade tracking becomes important because settlement can continue after the initial transaction.
The security provided by HTLCs comes with trade-offs.
Latency: users may wait through confirmations and the timelock safety window.
Capital lockup: resolver capital can remain committed while the trade is active.
Transaction costs: claims and refunds require transactions and may require network fees.
Abandoned trades: a participant can stop responding, leaving another party's capital temporarily locked.
The HTLC protects the principal, but it does not eliminate every economic cost.
The request expires.
No HTLC was created, so there is nothing to refund.
If the quote expires before settlement begins, the user can request another quote.
The HTLCs eventually reach their refund conditions, allowing the relevant funds to be recovered according to the contract rules.
The timelock gap gives the second participant time to claim after the secret becomes public.
Whether that window is sufficient depends on the assumptions used when the deadlines were configured.
The settlement still depends on the confirmation and finality assumptions of the participating chains.
The safety window needs to account for realistic conditions.
The user reveals the secret while claiming the destination asset.
The resolver sees the secret and uses it to claim the corresponding asset on the other chain.
Both sides settle without requiring a human administrator to approve the result.
The important part of an HTLC is not simply the hashlock or the timer.
It is how two HTLCs work together.
The hashlock connects the transactions.
The secret creates the event both sides can observe.
The staggered deadlines create the reaction window.
The refund conditions provide a predefined recovery path.
Omniston adds another layer by handling trade discovery through its RFQ and resolver model.
So there are two separate questions:
HTLCs: How can the trade settle safely?
Omniston: How can the system find liquidity and execute the trade?
Keeping those problems separate makes the architecture easier to understand.
Cross-chain swaps are not trust-minimized simply because funds are placed behind a hashlock.
The timing matters just as much.
The two HTLCs need deadlines arranged so that revealing the secret gives the other participant enough time to complete their side of the settlement.
That creates real trade-offs: additional time, temporary capital lockup, transaction fees, and the need to account for congestion and finality.
Omniston adds the market layer through RFQ-based discovery and resolvers, while HTLCs provide the settlement mechanism for supported cross-chain flows.
The bigger idea is simple:
A good settlement system needs a clear path for success and a clear path for failure.
If the trade completes, the contracts allow it to settle.
If it does not, the refund conditions provide a predefined way out.
