A cross-chain swap is only genuinely non-custodial when no third party takes control of the assets during the move. That sounds simple, but in cross-chain systems the custody question gets slippery very quickly.
This article gives you a practical way to evaluate that claim. By the end, you should be able to look at a bridge or cross-chain swap product and ask the right questions before trusting the “non-custodial” label.
Quick highlights:
- A cross-chain route is only genuinely non-custodial when no third party takes control of the assets during the move.
- In practice, custody risk usually reappears through reserve contracts, validator or relayer layers, or wrapped destination assets.
- Wrapped assets are not the same as receiving the native destination asset; they depend on the safety and solvency of the system behind them.
- HTLC-based settlement changes the structure by making the swap complete under shared conditions or refund automatically if it fails.
- Resolver-based HTLC systems make that model practical at scale by matching users with professional liquidity providers instead of forcing them to find counterparties themselves.
- The simplest way to evaluate any “non-custodial” claim is to ask who controls the funds, what happens if the route fails, and what exactly arrives in the destination wallet.
What “non-custodial” means in cross-chain
In a cross-chain context, “non-custodial” means the assets are not held by a platform or third party while the swap is in progress. CoinMarketCap defines a non-custodial service in exactly those terms: funds are not possessed by a platform or third party at any point during the transaction or service period.
That definition becomes harder to satisfy once two blockchains are involved.
On one chain, the model is cleaner. A wallet signs a transaction, a contract executes it, and the user keeps control unless they deliberately hand it over. Cross-chain changes the picture because value has to move between systems with different rules, different finality, and different infrastructure.
A useful way to test the claim is to ask whether three conditions hold at the same time:
- no single party can unilaterally control the locked asset during the swap
- if the swap fails, the funds return automatically
- the user receives the real destination asset, not a redeemable IOU that depends on someone else staying solvent
If one of those conditions breaks, some form of custodial exposure has usually crept back in.
How cross-chain bridge risks enter the picture
In cross-chain systems, custody risk tends to reappear in three places: the reserve contract, the validator or relayer layer, and the destination asset itself.
Reserve contracts can become invisible custodians
In many bridge models, the original asset is locked on one chain and a wrapped version is issued on another. That keeps the route working, but it also means the value of the destination token depends on the safety and solvency of the reserve system holding the original asset.
The WBTC whitepaper says this plainly. Wrapped tokens rely on trust in the institution or institutions holding the underlying asset, and it explicitly asks whether the custodian can create an arbitrary amount of tokens and how that custodian proves possession of the underlying reserve.
That is the key point. Even if the user sees a token in the wallet, the asset still depends on a custody structure behind the scenes.
Validator and relayer layers can reintroduce control
A bridge may not look centralized from the interface, but a small validator set or relayer layer can still concentrate power in practice.
Chainlink’s bridge security explainer points to insecure private key management and externally verified bridge designs as major sources of bridge risk. In those systems, a limited set of signers or operators effectively controls the outcome of the transfer.
History shows how much that matters. The Ronin bridge was drained after attackers obtained the five validator approvals needed to meet its 5-of-9 threshold; Harmony Horizon was compromised through a 2-of-5 multisig setup; and the Nomad exploit was triggered by a routine upgrade that effectively made invalid proofs pass verification.
Those are different failure modes, but they point to the same lesson: if a small set of keys, operators, or upgrade paths can decide the fate of the funds, the route is carrying custody risk whether the product says so or not.
Wrapped or redeemable assets carry trust dependencies
Even when a route “works,” the destination asset may still come with strings attached.
If what arrives is a wrapped representation, the user is relying on the system behind that wrapper: reserve integrity, mint and burn controls, and redemption credibility. WBTC is one of the cleanest examples because its own documentation openly frames the custodian question as central to the token’s trust model.
That does not automatically make wrapped assets bad. It does mean they are not the same thing as receiving the native destination asset through a fully non-custodial route.
What an HTLC-based route changes
HTLC-based swaps change the structure because they do not rely on a shared reserve pool or a wrapped token to represent the other side of the trade.
| HTLC stands for Hashed Timelock Contract. In plain English, it means both sides of the swap are locked under the same secret condition and the same deadline logic. If the secret is revealed in time, the trade settles. If it is not, the locked funds refund automatically. |
The trade-off is liquidity. Classic peer-to-peer atomic swaps are structurally clean, but they are not very convenient if every user has to find a matching counterparty by hand.
Why resolver-based HTLC systems matter
Resolver-based HTLC systems try to keep the cryptographic protection of atomic swaps while making liquidity practical enough for normal users.
The basic idea is straightforward. Instead of hunting for the other side of the trade yourself, you request a quote and professional liquidity providers compete to fill it. In STON.fi’s terminology, those providers are called resolvers.
| Resolvers provide quotes and execute trades for the protocol, competing to offer the best available prices. |
That means the user is no longer relying on a single bridge operator to hold reserves or manually route the move. The quote is requested up front, the swap is matched through resolvers, and cross-chain settlement is handled through HTLC-based flows rather than through a reserve-and-wrap model.
Where Omniston fits
Omniston is STON.fi’s execution layer for this model. STON.fi’s Omniston docs describe the system as a single RFQ-based integration for swaps on TON and cross-chain swaps, with HTLC-based cross-chain settlement.
The protocol forms a request for quote, sends it to resolvers and DEXs, selects the best quote, and executes the trade. It also describes the process as zero-trust and says atomicity means either both parties receive the intended assets or the exchange fails.
That is why Omniston is a useful example here.
The point is not that the label “non-custodial” sounds reassuring. The point is that the route is structured around quote competition plus HTLC-based all-or-nothing settlement, rather than around pooled reserves, validator-controlled minting, or wrapped assets that depend on an external custodian.
How each model scores against the non-custodial standard
The honest version of this table has no clearly good column, since every approach involves a trade-off worth naming before committing funds. The resolver-based HTLC row is highlighted because it’s the only one that satisfies all three conditions of the non-custodial standard at the same time.
| Approach | Key limitation | When to use | When to avoid |
| Lock-and-mint bridge | Bridge contract or multi-sig becomes custodian of locked assets | Accessing chains where no resolver-based alternative exists | High-value or long-duration holds where custodian risk compounds |
| Liquidity pool bridge | Pool smart contract acts as custodian; post-audit upgrades reset the risk profile | Small, frequent swaps between well-audited, unmodified contracts | Any period following an upgrade not yet independently reviewed |
| Atomic swap (HTLC), peer-to-peer variant | Both chains must support compatible hash-locking; liquidity is limited because users must find each other | Niche self-custody swaps where a counterparty already exists | Time-sensitive transfers or unsupported chain pairs |
| Resolver-based HTLC protocol (Omniston, the cross-chain execution layer built by STON.fi) | Resolver liquidity depth depends on active participants; chain coverage rolls out in phases | Cross-chain swaps where atomic settlement, no wrapped tokens, and no custodial pool all matter | Routes the resolver network does not yet cover |
| Single-chain protocol | Does not address the cross-chain use case | Users operating within one ecosystem who do not need to move value across chains | Any cross-chain use case |
Five questions to ask before trusting any cross-chain solution
These are the five questions worth running every time.
- Can one contract, multisig, or operator freeze or drain the locked funds?
- If the answer is yes, the route has a custodial chokepoint.
- If the answer is yes, the route has a custodial chokepoint.
- If the swap fails, do funds return automatically?
- If recovery depends on manual claims, support tickets, or operator discretion, the route is carrying more trust than it sounds.
- If recovery depends on manual claims, support tickets, or operator discretion, the route is carrying more trust than it sounds.
- Do you receive the native destination asset, or a wrapped or redeemable version?
- That tells you whether the route depends on a reserve or issuer behind the scenes.
- That tells you whether the route depends on a reserve or issuer behind the scenes.
- Who controls message delivery or settlement authorization?
- A small validator or relayer layer may still mean concentrated control, even if the interface looks decentralized.
- A small validator or relayer layer may still mean concentrated control, even if the interface looks decentralized.
- Has the route changed since its last audit?
- Alater upgrade can reset the risk profile completely.
A protocol that answers all five clearly is making the user’s job much easier. A protocol that cannot answer them cleanly may still be usable, but it is asking for trust somewhere.
Final thoughts
“Non-custodial” is not just a nice-sounding category. In cross-chain systems, it is a technical standard with real consequences.
The important question is not whether a product uses the word. The important question is whether the architecture actually supports it. Reserve-based bridges, multisig-controlled systems, relayer-dependent routes, and wrapped assets can all reintroduce some form of custody, even when the interface looks simple.
HTLC-based settlement changes that structure. Resolver-based systems such as Omniston then make that model practical enough to use at real scale, because users do not have to go searching for counterparties on their own.
