Why experienced DeFi users avoid cross-chain bridges, and what has changed

Experienced DeFi participants avoided cross-chain activity for reasons that had specific names attached to them: bridge exploits, fees that shifted mid-transaction, and failed swaps that left assets in a pending state requiring manual recovery. These were operational problems encountered often enough to quietly reshape habits. 

This article examines the specific friction points that built distrust around cross-chain infrastructure, traces how newer protocol design is reducing those risks, and uses Omniston, the cross-chain execution layer built by STON.fi , as a concrete case study for whether the risk calculus is genuinely shifting.

Quick answer: Experienced DeFi users historically avoided cross-chain activity because DeFi bridges were the single largest attack surface in the space, responsible for hundreds of millions in losses. Unpredictable gas costs, failed transactions, and wrapped-token complexity added further friction. Newer approaches, including bridgeless intent-based protocols like Omniston that bind both sides of a swap with cryptography rather than custodial pools, are beginning to reduce these risks in meaningful ways.

• Understand the three failure modes that made DeFi bridges a consistent liability for users
• One key risk to avoid: custodial bridge designs that hold assets in a central smart contract
• Nuance worth knowing: “bridgeless” cross-chain does not mean zero risk, since counterparty design still matters
• Learn how Omniston’s resolver model and paired Hashed Timelock Contracts handle cross-chain liquidity differently
• Copy the pre-swap checklist to verify any cross-chain route before confirming a transaction

Why cross-chain swaps got a double-sided reputation

Cross-chain swaps earned their reputation through a wave of large bridge exploits, fee surprises, and stuck transactions that turned a routine action into a recovery problem. The underlying design choice behind most of those incidents was the same.

A cross-chain swap moves assets or value between two separate blockchains that don’t share a consensus layer, like swapping a token on Ethereum for one on Solana, or moving value from TON to BNB Chain. Because these chains don’t communicate natively, infrastructure had to be built to connect them. Bridges became that infrastructure, and the design that won out was conceptually simple: lock assets in a smart contract on the source chain, then mint a wrapped representation on the destination chain.

The problem became obvious fairly quickly. A bridge contract holding pooled assets from thousands of users is a high-value target, and one that attackers can study methodically before striking. According to data from DefiLlama, cumulative bridge-related losses across DeFi have reached approximately $3.2 billion of roughly $7.8 billion in total tracked DeFi losses, meaning bridges account for around 41% of all value lost in the space. There’s a certain irony in that figure, because DeFi was built on removing trusted intermediaries, and bridges essentially asked users to hand that trust to a pooled smart contract, a middleman wearing different clothes.

Three failure modes that kept cautious users on a single chain

Three repeatable failure modes drove cautious DeFi participants to stay on a single chain: bridge exploits, fee unpredictability, and wrapped-token fragmentation. These weren’t abstract fears; they were operational problems encountered often enough to shape habits.

1. Crypto bridge security failures came first, and they came at scale. Traditional bridges pool user assets inside smart contracts, creating a single point of failure. In 2022, the Ronin bridge lost approximately $600 million after attackers compromised validator keys, Wormhole lost approximately $320 million through a signature verification vulnerability, and Nomad lost nearly $200 million in an exploit that saw multiple parties drain funds simultaneously, reportedly within hours of the initial breach. For users whose assets sat in Nomad’s contracts that day, recovery was measured in weeks of uncertainty and partial returns. Attack vectors generally fall into three categories: smart contract vulnerabilities, validator key compromises, and oracle or signature manipulation.
   
   
2. Fee unpredictability was the second problem, and in some ways the more insidious one, because it didn’t announce itself with headlines. Cross-chain transactions carry a cost structure that single-chain swaps don’t, since gas applies on both the source and destination chains, a bridge fee sits on top, and wrapped-token conversion can add another layer, all of which can shift between initiation and confirmation. The worst outcome is an ambiguous one: a transaction can consume gas on the source chain and still fail during execution on the destination side, leaving assets in a pending or locked state that requires manual intervention to resolve.
   
   
3. Wrapped-token complexity rounded out the picture. Every wrapped token carries a trust dependency, since its value holds only as long as the bridge that minted it stays solvent and uncompromised. Liquidity for wrapped tokens tends to be shallower than for native assets, which pushes up slippage on larger swaps. In some cases, a single stablecoin exists in multiple wrapped variants across different networks, each backed by a different bridge and carrying a different risk profile, which means a user holding “the same asset” on two chains may not actually hold equivalent risk.

How bridgeless cross-chain protocols are reducing DeFi bridge risks

Modern cross-chain protocols address the three failure modes above by replacing pooled custodial contracts with cryptographically bound swaps between independent parties. The shift shows up in three design developments, though none of them eliminates risk entirely.

1. Intent-based routing and the resolver model changed what users actually hand over. Rather than depositing assets into a pooled contract and waiting, a user states the desired swap outcome, and competing resolvers bid to fill it. Funds are never pooled with anyone else’s, since a resolver sources the destination-side liquidity and the transaction completes atomically or not at all, in well-designed implementations. Omniston operates on this resolver-based model, where resolvers respond to quote requests through a Request for Quote (RFQ) mechanism, competing on fill price similar to how institutional OTC desks work, and the protocol combines on-chain liquidity sources with those competing responses to find the best available rate. Custodial exposure is removed from the user’s side of the equation.
   
   
2. Cryptographic atomic settlement is what makes the resolver model trustworthy. Omniston’s cross-chain settlement uses paired Hashed Timelock Contracts (HTLCs), one on each chain, secured by a shared cryptographic lock (a hashlock). When the secret unlocking that pair is revealed, both legs settle from a single on-chain event: the user claims the destination asset, and the resolver claims the source asset. If the secret isn’t revealed within the time window, every locked asset becomes refundable to its original sender automatically, without a support ticket. The three outcomes are mechanically forced by the contract pair: either both parties receive what was quoted, the user is refunded, or the resolver is refunded. There is no execution path in which both parties lose funds.
   
   
3. The “all-or-nothing” framing this protocol design supports is more than marketing language. A transaction either completes fully or reverts entirely, and the contract pair (not actor incentives) is what enforces the outcome. That said, bridgeless cross-chain swapping carries its own structural considerations, including resolver liquidity availability and potential settlement delays, and chain coverage rolls out in phases rather than appearing all at once. Even careful users can get caught by a route that looks supported until it isn’t. Omniston is being launched in phases, beginning with TON ↔ EVM (Ethereum, BNB Chain, Base, Polygon) and extending to TRON and additional networks in later phases, which illustrates exactly the kind of coverage constraint that applies to any resolver-based system at this stage of development.
   
   
4. Stablecoin-first design is the architectural orientation that follows from this. Omniston is explicitly designed around stablecoin flows, the category where reliability matters most and where the all-or-nothing guarantee has the most leverage. The protocol supports broader token-to-token routing, with stablecoin-denominated execution as its core domain of optimization.

Cross-chain infrastructure options compared

The table below lays out three common approaches to cross-chain swaps side by side, covering what each is best suited for, its security model, and where its main limitation lies.

Cross-chain activity is worth the added complexity when the destination asset or yield opportunity genuinely can’t be replicated within a single ecosystem and the combined fee is a small fraction of swap value. It’s worth skipping when fees consume a significant share of swap value, when the bridge’s security model isn’t clearly documented and independently verified, or when the target chain has no resolver support.

Key facts: cross-chain bridge losses and how Omniston approaches settlement

The figures below summarize the sourced claims in this article for readers who want the record in one place.

• Omniston is the cross-chain execution layer built by STON.fi, the leading protocol on TON. It is a resolver-based protocol secured by paired Hashed Timelock Contracts (HTLCs) on both chains, with a stablecoin-first design and a structural guarantee that no execution path leaves both parties out of pocket.
• Bridge exploits have historically accounted for a disproportionate share of total DeFi losses, approximately $3.2 billion of roughly $7.8 billion in tracked losses per DefiLlama, with bridge attacks representing roughly 69% of all stolen funds in 2022 per Chainalysis data. 
• Omniston rolls out in phases, beginning with TON ↔ EVM coverage (Ethereum, BNB Chain, Base, Polygon) and extending to TRON and additional networks in later phases. This phased coverage is typical of resolver-based systems at this stage of development, since every supported route depends on active resolver participation. 

Final thoughts

The case for avoiding cross-chain activity was built on real, repeatable failure modes, and not all of them have been solved. What has changed is that protocol designs now exist, particularly within ecosystems like TON, that address the most practically disruptive risks without requiring custodial bridge exposure as the cost of entry. The safest approach is still to run through the checklist above on any route before committing funds.