Cross-chain bridges have accounted for roughly 40% of all value ever stolen in Web3 since 2022 — north of $2.8 billion cumulatively — and 2026 alone has already added more than a dozen separate bridge exploits worth over $340 million to that total, including a $292 million LayerZero-related drain in April. Against that backdrop, a resolver-based model like Omniston — the cross-chain execution layer built by STON.fi, using Hashed Time-Locked Contracts (HTLCs) instead of custodial bridge infrastructure — looks like an obvious upgrade. It mostly is. But "no shared pool of collateral to steal" isn't the same claim as "no risk at all," and the honest comparison is more interesting than a simple better-worse verdict.
How Classic Bridges Actually Work — and Fail
Nearly every bridge that's ever been hacked shares the same underlying structure: assets get locked or burned on the source chain, and a wrapped, IOU-style representation gets minted or released on the destination chain. That wrapped token is only worth what the market believes the bridge's reserves can honor — which means the bridge itself becomes a single, concentrated point of custody holding potentially hundreds of millions of dollars in one place. Steal the keys, forge a validator signature, or exploit a bug in the minting logic, and an attacker doesn't need to touch any individual user's wallet — they drain the shared reserve that backs every wrapped token that bridge has ever issued.
This is precisely the failure mode behind essentially every major bridge hack: a validator-key compromise, a signature-verification bug, or a smart-contract flaw in the custody layer, each one exploitable exactly once for a payout scaled to however much total value the bridge happened to be holding at that moment. Bridge total value locked sat near $22 billion industry-wide as of early 2026 — meaning the incentive to find that one exploitable flaw has never been higher.
How Omniston's Model Works Instead
Omniston doesn't hold a shared reserve at all. Cross-chain swaps route through a Request-for-Quote (RFQ) system: a user requests a swap, connected resolvers — professional market makers — respond with signed, firm quotes, and the best one is selected. Settlement then happens through a pair of linked Hashed Time-Locked Contracts, one on each chain, using the same cryptographic hash-lock condition on both sides.
The mechanics work like this: the resolver locks the destination-chain asset in an HTLC tied to a specific hash. The user reveals the secret matching that hash to claim it, which simultaneously unlocks the user's source-chain asset for the resolver to claim. If either side fails to act within the timelock window, both sides revert automatically — the user gets their original asset back, the resolver gets theirs back, and nothing is lost to either party. Per STON.fi's own documentation, there are exactly three possible outcomes: both parties receive what was quoted, the user is refunded by timelock, or the resolver is refunded by timelock. There's no fourth case where funds get stuck in an intermediate state or both sides lose.
Source Chain (e.g. TRC-20 on TRON) Destination Chain (TON) ┌─────────────────────────┐ ┌─────────────────────────┐ │ User's asset locked │ │ Resolver's asset locked │ │ in HTLC, hash H │◄────────►│ in HTLC, same hash H │ └─────────────────────────┘ └─────────────────────────┘ │ │ ▼ ▼ User reveals secret S matching H to claim resolver's asset Revealing S on-chain also unlocks resolver's claim to user's asset │ │ ▼ ▼ Both legs settle atomically — or both revert on timeout
Most swaps using this model complete within 15 to 40 seconds, and — this is the detail that actually addresses the bridge-hack problem structurally, not just incidentally — there's no pooled collateral for an attacker to target. Each swap's exposure is scoped to that individual transaction's HTLC pair. Compromising one swap doesn't give an attacker access to any other user's funds, because there's no shared reserve connecting them.
"In a bridge hack, the attacker steals the collateral and leaves everyone else holding wrapped air. In an HTLC swap, there's no central pool of collateral to steal in the first place." — commentary on the architectural difference
The Core Security Difference, Named Plainly
The distinction underneath everything else is custody versus atomicity as the trust mechanism.
A classic bridge asks you to trust that a specific set of validators, multisig holders, or smart contracts will behave correctly and remain uncompromised for as long as your wrapped asset exists — which could be indefinitely, since there's no natural expiration on holding a wrapped token. That's an ongoing, standing trust assumption with a growing attack surface the longer the bridge operates and the more value it accumulates.
An HTLC-based swap asks you to trust cryptographic math for the duration of a single transaction — typically under a minute — with a built-in, automatic failure mode (the timelock refund) that requires no intervention from anyone if something goes wrong. There's no multisig to compromise, no validator set to bribe or coerce, and no window where your asset exists as an unbacked claim on a reserve somewhere else.
That difference is why bridge exploits tend to be catastrophic and rare — one successful attack can drain the entire reserve — while HTLC-based swap failures, when they happen, tend to be individually contained and non-catastrophic: a resolver fails to fulfill, the timelock triggers, the user gets refunded, and nothing propagates beyond that single trade.
Attack Surface, Side by Side
What Omniston Doesn't Solve — Honest Limitations
Resolver liquidity is a real, if different, kind of dependency. HTLC settlement removes custodial risk, but a swap still needs a resolver willing and able to fill it at a competitive price. Thin resolver participation on an illiquid route can mean no quote at all, or a wide effective spread — a different failure shape than a bridge hack, but still a real constraint on usability, especially for large trades or exotic chain pairs.
Chain compatibility isn't universal. Atomic-swap-style mechanisms require both chains to support compatible cryptographic hash-lock primitives, which historically limited HTLC-based approaches to a smaller set of chain pairs than bridges could support. Omniston's RFQ layer abstracts much of this complexity away for its supported routes (TON, TRON, Ethereum, Base, BNB Chain, Polygon, Avalanche, and Arbitrum, as of its current rollout), but that's still a defined, finite list — not the "connect literally anything" breadth that bridge infrastructure has spent years building toward across dozens of chains.
This model is newer and comparatively less battle-tested at scale. Classic bridges, for all their catastrophic failure history, also have years of production volume behind the routes that haven't failed — genuine operational experience across enormous cumulative transaction counts. Omniston's cross-chain HTLC model is a comparatively recent addition to the stack, and "structurally harder to exploit at scale" is a different claim than "has been tested against scale for years without incident." Integrators should treat it with the same measured caution they'd apply to any newer piece of financial infrastructure, regardless of how sound the underlying design is.
Speed and convenience still favor bridges in some scenarios. Traditional bridge transfers are more automated end-to-end for use cases that don't need a live counterparty quote — a straightforward lock-and-mint doesn't require a resolver to be online and competitively pricing your specific trade at that moment, which can matter for very large trades or unusual pairs where resolver depth hasn't caught up yet.
Where Classic Bridges Still Make Sense
It's worth resisting the temptation to declare bridges universally obsolete. They remain more versatile in raw chain coverage, connecting networks with wildly different architectures and consensus models that a hash-lock-dependent approach may never efficiently support. For infrastructure use cases — moving assets to a chain with no resolver coverage yet, or for protocols that need programmable, non-atomic cross-chain messaging rather than a simple asset swap — bridges (ideally audited, multi-sig-hardened, and monitored ones) still fill a role HTLC-based swapping doesn't directly replace.
Bottom Line
The security case for Omniston's model over classic bridges isn't marketing — it's a genuine structural improvement: removing the single, concentrated pool of collateral that has been the direct cause of essentially every major bridge hack on record, and replacing indefinite custodial trust with a bounded, automatically-refundable cryptographic guarantee scoped to one transaction at a time. That's a real, verifiable difference, not a reframing of the same risk under new branding. But it trades one set of constraints for another — resolver liquidity depth, a still-finite list of supported chains, and a shorter production track record than the bridge infrastructure it's competing with. For moving value between Omniston's currently supported chains, the HTLC/RFQ model is the structurally safer choice by a wide margin. For anything outside that supported set, classic bridges — chosen carefully, audited, and monitored — remain the only practical option, catastrophic hack history and all.
This article is based on STON.fi/Omniston documentation and public bridge-hack tracking data as of mid-2026. Cumulative loss figures, supported chain lists, and resolver liquidity conditions change — verify current specifics against docs.ston.fi and independent security trackers before relying on them for a production integration or a large cross-chain transfer.
$BTC
