Cross-Chain Swaps With a Hardware Wallet: What the Device Actually Verifies

A hardware wallet guarantees one thing: the bytes you confirm on its screen are the bytes that get signed, and a compromised computer cannot change that display. It does not tell you whether the deposit address you were handed is legitimate. If the website was poisoned, both screens show the attacker's address and they match. A small test transfer and an independent block-explorer check are what cover that gap.

Published 2026-07-15 · 16 min read

Key takeaways

·A hardware wallet guarantees one property: the bytes shown on the device screen are the bytes that get signed.
·It cannot tell you whether a one-time deposit address is legitimate, because that value comes from the website, not the device.
·If the front-end is poisoned, browser and device show the same attacker address and match, so screen comparison cannot catch it.
·The Ledger Connect Kit incident was a supply-chain compromise of an NPM connector library, not a break of the secure element.
·Blind signing is where trusting the device screen stops meaning anything: it proves which bytes you sign, not what they do.

You bought the device. You plug it in, compare the address on its screen, confirm. What does that ritual actually buy you?Something precise, and smaller than the marketing implies. A hardware wallet guarantees that what you confirm on its screen is what the secure chip signs. Your computer can lie to your browser; it cannot lie to the device's display. That is a genuine, vendor-backed, architecturally enforced property, and it covers exactly one link in a cross-chain swap.It does not cover the link that has actually cost people money. A swap deposit address is a one-time address a website hands you, and your device has no idea what it is supposed to be. Poison the front-end and the device renders the attacker's address perfectly, you compare screens, they match, and the money is gone. That is roughly how December 2023 went for users of dApps embedding Ledger's Connect Kit. What follows: the workflow, an explicit can-verify / cannot-verify split in the vendors' own words, and how blind signing changes the picture. Vendor material sampled 2026-07-15; anything we could not confirm is marked as such.

The 30-Second Verdict: The Device Guarantees the Bytes, Not the Address

One sentence, and the rest of this guide is a footnote to it: a hardware wallet guarantees that the bytes you confirm on its screen are the bytes that get signed, and it guarantees nothing about whether those bytes are the right ones.

Both vendors state the first half plainly. Ledger describes the guarantee as "what you see is what you sign", and explains the mechanism: the Secure Element chip "drives the secure screen directly, no hacker can intercept this information or tamper with the transaction details it shows" (ledger.com — secure screen security model, sampled 2026-07-15). Trezor's formulation is the Trusted Display: its screen "only displays verified information" and "always shows the correct information because the device stays offline, even when your computer is connected to the internet" (trezor.io — what is a Trusted Display, sampled 2026-07-15). "Trusted Display" is not exclusively Trezor's term, incidentally; Ledger uses it for its own screen too (ledger.com — best practices, sampled 2026-07-15). Both claims are accurate. Both are narrower than most readers assume.

Here is the gap. A swap deposit address is a one-time address a website hands you, and the device learns that value from the same host you are trying to defend against. If the address was already the attacker's when the page rendered, the device displays it faithfully, the two screens match, and you confirm. The comparison ritual detects tampering between the interface and the device. It does not detect a value poisoned before the interface ever received it.

So a hardware wallet does not make a cross-chain swap safe. It closes one attack path, host-side substitution between the UI and the device, and leaves the deposit address's legitimacy, the domain you are on, the network you selected, and the meaning of anything you blind-sign uncovered. What carries that weight instead: your own bookmark, a small test transfer, an independent on-chain check with a block explorer, and keeping the hardware wallet as the source address so a failed route refunds to you.

UpSwap routes across 24+ chains, 111+ tokens and 166 chain-token combinations, all on the deposit-address model, so this applies to every route, from BTC to USDT to ETH to SOL.

Why the Source Wallet Should Be the Hardware Wallet: Refunds Trace Backwards

The strongest argument for putting a hardware wallet at the start of a swap has little to do with signing. It has to do with refunds.

When a cross-chain route fails, because no solver fills the intent before the quote expires or the amount lands below a route minimum, the refund returns to the source address: the address the deposit came from, traced on-chain. You do not type it into a form; there is no field to correct later. The mechanism and the wallet types that break it are covered in where refunds go and why the source address decides. The consequence here is one line: your source address is also your recovery address, and you choose it before you have thought about signing at all.

Which is why withdrawing from a centralized exchange straight into a swap deposit address is the quiet mistake. The source of that deposit is the exchange's hot wallet, not you, so a refund travels faithfully back to an address you never controlled and recovery becomes a support ticket at an exchange with no record of expecting the money. A hardware-wallet address is the opposite: a refund to it is your money, back where it started. Our guide on non-custodial vs custodial models maps where funds physically sit in each case.

The vendors reach that property differently. Ledger stores keys in the Secure Element, generated and held offline, isolated from the host (ledger.com — why the Nano is secure, sampled 2026-07-15). Trezor's Safe 3 and Safe 5 (OPTIGA Trust M V3) and Safe 7 (OPTIGA Trust M V3 plus TROPIC01) do not keep keys in the secure element: private keys live encrypted on the main chip, and the Secure Element holds "a secret that is used—along with your PIN—to encrypt the private keys stored on the main chip", handling PIN enforcement, attestation and seed entropy (trezor.io — secure elements in Safe devices, sampled 2026-07-15). That page describes the Safe line only and says nothing about the Model One or Model T, so do not extend it to them. Trezor separately emphasises open-source auditability: "The software used in Trezor devices has always been open-source to be fully auditable" (trezor.io — security and safety, sampled 2026-07-15). That is a claim about the software, not Trezor's stated reason for the key-storage design, and we are not presenting it as one.

For a deposit-address swap this architectural difference is close to irrelevant. Both designs produce an address whose signing key never leaves the device and whose refunds land somewhere you can reach. Whatever the pair, ETH to USDT, SOL to USDT, USDT ERC-20 to TRC-20, send from the hardware wallet and receive to an address you control.

The Workflow: Bookmark, On-Device Check, Blind-Sign Gate, Test Transfer, Explorer, Then the Rest

Sourcing note first. Neither Ledger nor Trezor publishes a cross-chain-swap procedure. What follows is a composite: steps 2 and 4 have direct vendor backing and are quoted; steps 1, 3, 5 and 6 are operational reasoning from the threat model and UpSwap's own guides, and are not vendor guidance.

Reach the swap site from your own bookmark. Not a search ad, not a DM, not a link in a reply. This step exists precisely because the device cannot do it for you: it speaks a USB or BLE protocol that never carries the origin, the TLS certificate or the DNS name, so a phishing clone signs identically to the real site.
Verify the deposit address on the device, character by character, including the middle. Ledger: "An attacker in control of your computer screen could show you a wrong address which would make him the beneficiary of any transaction sent to it" (ledger.com — best practices, sampled 2026-07-15). Trezor: "Carefully compare the receive address you copy & paste with the one shown on your Trezor device" (trezor.io — receive crypto in Suite, sampled 2026-07-15). Read that second quote with its scope in mind: it governs an address your own Trezor derived, not an externally supplied deposit address, a distinction spelled out two sections below. The middle-character emphasis is ours, aimed at address poisoning, whose lookalikes are ground out to match the leading and trailing characters.
If the device asks you to blind-sign, stop. A plain deposit transfer should not require it. A blind-signing prompt in that flow is an anomaly, and an anomaly is a reason to close the tab, not to tap through.
Send a small test transfer and confirm it arrives. Ledger: "We recommend sending a small amount first, to make sure that you have properly received it. This test should ideally be done on another computer" (ledger.com — best practices, sampled 2026-07-15). The "another computer" qualifier is the interesting half; it targets the case where the host itself is the compromise.
Verify on a block explorer that the test landed where you expected. This is the one channel that is not the swap site's front-end. If the widget was poisoned, the explorer is the thing not lying to you. Per-chain procedure in our block-explorer verification guide; if the destination stays quiet, troubleshooting a stuck swap by chain separates a slow route from a real problem.
Then send the rest, with the hardware wallet still as the source, so any refund returns to it.

The test transfer's limits in a swap. Ledger's advice is written for ordinary transfers, not routed swaps, and three things break the analogy. Many routes enforce a minimum, so a dust-sized test can be refunded or stranded instead of routed. The test consumes time on a quote that may expire while you wait for confirmations. And a one-time deposit address may not be reusable for the full amount, meaning you repeat the verification for a second address. The test is load-bearing against the threat the device cannot cover, but it is not free insurance.

Steps 4 and 5 are the ones that earn their place. Together they catch a wrong-but-faithfully-signed destination: the case where the address was already malicious in the browser, the device rendered it correctly, and the on-device comparison came back clean.

What the Device Can Verify: The Screen Is Authoritative Over Your Computer

The guarantee is real, and worth stating precisely rather than vaguely, because the precision is what tells you where it ends.

What the device verifies	Mechanism	What that defeats	Limits
The deposit address, as displayed on-device	Ledger: secure screen driven directly by the Secure Element. Trezor: Trusted Display on a device that stays offline.	Host malware, clipboard hijacking, injected-JS address substitution between the UI and the device	Verifies only that the displayed value is the signed value. Says nothing about whether the value itself is the legitimate deposit address.
Transaction details, including the amount	Fields are parsed by device firmware and rendered before the signature exists; your on-device confirmation is what releases it	A host that displays one amount and submits another	The amount row is our inference. Ledger says the device shows the "full details" of a transaction; no vendor page we retrieved enumerates amount as a separately guaranteed field per chain. Universal in practice, not a vendor claim.
Contract call details	ERC-7730 metadata lets the device render the call in plain language instead of raw calldata	Approvals whose meaning would otherwise be unreadable	Conditional, not a baseline. Requires both that the wallet interface supports the standard and that the dApp published metadata. If either is missing, the device falls back to blind signing.
Chain / network	Some device apps surface a chain identifier where the app implements it	Nothing you should rely on	Not verified. We found no Ledger or Trezor page stating a general guarantee that the device displays and lets you verify the network (checked 2026-07-15). Treat network selection as a host-side choice.

The vendor claims behind the first two rows. Ledger: "Your Ledger device's secure screen will always show the correct transaction details, even if your internet-connected device is compromised" (ledger.com — secure screen security model, sampled 2026-07-15). Separately, on a different page: "you can verify the full details of your blockchain transactions, and know exactly what you're signing before you hit 'confirm'" (ledger.com — why the Nano is secure, sampled 2026-07-15). Trezor's contribution is the mismatch rule: "If the address on your Trezor device doesn't match the one on your computer, do not send funds to this address. Your computer is compromised" (trezor.io — what is a Trusted Display, sampled 2026-07-15).

What the Device Cannot Verify

A hardware wallet will faithfully sign a transaction that sends your funds to a thief, if you confirmed that address on its screen. Nothing in the device's security model prevents that. Five things sit outside the guarantee; for a cross-chain swap, four are load-bearing.

What it cannot verify	Why the device cannot see it	What covers it instead
Whether the deposit address you were given is legitimate	The value originates entirely from the website or widget. The device has no independent notion of the correct deposit address; it signs to whatever destination the host supplies and you confirm. Compromise the front-end and both screens show the attacker's address: the browser because it was injected, the device because it renders exactly what it was handed. Both agree. Both are wrong.	A bookmarked domain, a small test transfer, and an independent block-explorer check. Not the on-device comparison.
Whether you are on the real site	The device has no concept of a domain. Origin, TLS and DNS are host-side concepts never transmitted to it, so a pixel-perfect phishing clone produces an indistinguishable signing request. Our architectural reasoning, not vendor guidance.	Establishing domain trust before the device is involved: your own bookmark, never a search ad or a link in a reply.
What a blind-signed payload actually does	Absent a parser, the device can render only a hash or raw calldata. Ledger's phrasing: "a sequence of numbers and letters (otherwise known as a hash) that most humans can't even begin to decipher" (ledger.com — blind signing explained, sampled 2026-07-15). It still proves which bytes you sign; it cannot tell you what they mean.	Clear signing where available; otherwise refusing the transaction. See the next section.
Whether you picked the wrong network	Network selection happens in the swap UI before anything reaches the device, and the device has no model of your intent. It cannot know the chain you selected is not the chain you meant.	Deciding upstream: the USDT network decision framework. If it has already happened, the wrong-network recovery matrix.
Undoing an approval you already made	A signature is final once broadcast; the device has no revocation capability. Token allowances persist until revoked in a separate new transaction, and funds sent to an attacker are gone.	A separate revocation transaction. Trezor's own remedy for a bad allowance is an external allowance checker (trezor.io — malicious smart contracts, sampled 2026-07-15), which is itself evidence the device offers no undo.

A scope distinction worth internalising. Trezor's guarantee for a receive address is stronger than anything available for a deposit address: "The address shown on your Trezor device screen will always be one belonging to you" (trezor.io — receive crypto in Suite, sampled 2026-07-15). That holds because the Trezor derived that address itself and knows it is yours. A swap deposit address is the opposite: externally supplied, third-party controlled, outside the device's knowledge entirely. The vendor sentence is true; transplanting it onto a deposit address would be false.

Blind Signing vs Clear Signing: When the Guarantee Degrades

Blind signing is approving a transaction whose contents the device cannot decode into human-readable terms. Ledger's image is the right one: "Blind signing in the digital asset world is like signing a blank check: you're authorizing a transaction without fully understanding or seeing its details" (ledger.com — blind signing explained, sampled 2026-07-15).

Notice what it does to everything above. The core guarantee survives technically: the device still proves which bytes get signed, and the host still cannot alter them. What collapses is the guarantee's usefulness. "Trust the device screen" presupposes the screen is saying something legible. When the screen shows a hash, the sentence quietly stops meaning anything.

When it is demanded. Per Ledger, blind signing arises when "the wallet interface you're using does not support the current ERC-7730 [V2] standard, or the dApp itself has not added the necessary metadata for that transaction" (sampled 2026-07-15). In practice it shows up most when a hardware wallet is connected to third-party software interfaces, which is exactly the shape of a browser-based swap flow.

Why it is dangerous, concretely. Two outcomes, both in Ledger's words: you may "send funds to unintended recipients with malicious intent", or you may "sign an approval that allows a smart contract to take your coins or tokens whenever they like" (sampled 2026-07-15). The second is worse than it sounds, because it is not a one-time loss. It is a standing permission that survives until you revoke it.

What clear signing changes. Ledger defines it as "showing users exactly what they're approving in a blockchain transaction, displayed in plain language, instead of complex codes" (ledger.com — clear signing, sampled 2026-07-15). The current mechanism is ERC-7730, the "Structured Data Clear Signing Format": a JSON metadata descriptor (Context, Metadata, Display blocks) living separately from the contract, so clear signing can be added to protocols already deployed, without redeployment (eips.ethereum.org — EIP-7730, sampled 2026-07-15). Descriptors live in a public registry hosted by the Ethereum Foundation as a neutral steward, and anyone may clone and self-host it (sampled 2026-07-15).

Where EIP-712 fits. EIP-712, typed structured data, is the older and narrower mechanism: it lets a device render structured message fields instead of an opaque hash, a real improvement for signed messages that does not cover arbitrary contract calls (eips.ethereum.org — EIP-712, sampled 2026-07-15). Worth flagging: the Ledger clear-signing page we sampled on 2026-07-15 does not mention EIP-712 at all. Ledger's current framing is built on ERC-7730. If you see "clear signing = EIP-712" stated flatly elsewhere, it is a few years out of date.

What we could not confirm as of 2026-07-15. Ledger's support material indicates blind signing is off by default and must be enabled manually per coin app, with a warning shown on blind transactions. We could not retrieve that wording verbatim, so treat the toggle path as substantively right but unconfirmed and check it on your own device. The "V2" version token above is Ledger's own; we have not independently confirmed its release timing or scope. Separately, Trezor publishes no current consolidated blind-signing explainer we could find, and the material that exists predates the Safe 5 and Safe 7. We are therefore not publishing a Ledger-vs-Trezor blind-signing comparison: the asymmetry would be a documentation artefact, not a security finding, and would make Trezor look worse than the evidence supports.

The operational rule for a swap. Sending a plain transfer to a deposit address does not need blind signing. If your device asks for it in that flow, something in the path is not what you think it is. Stop, and re-derive the address from a bookmarked domain.

Reading the Ledger Connect Kit Incident Correctly (Dec 2023, ~$600k)

This is the incident everyone reaches for, and it is almost always read backwards. The facts first.

On 14 December 2023, a former Ledger employee was phished, giving an attacker access to their NPM account. The attacker published malicious versions of the Ledger Connect Kit package (1.1.5, 1.1.6, 1.1.7) containing wallet-drainer code, which was pulled into dApps embedding the library and swapped the displayed destination for an attacker address. Over $600k was drained from users of sites including SushiSwap and Revoke.cash, per revoke.cash, first-party on its own involvement and displaying $610k (sampled 2026-07-15), corroborated by BleepingComputer. The $484k figure that circulates is not a competing final number; it was an early LookOnChain estimate published the same day, while the attack was still unfolding, via CoinDesk.

This was a software supply-chain compromise of a connector library, not a break of the device's secure element. Ledger's incident report states "the attacker did not at any time have access to any Ledger infrastructure, Ledger code repository, or to DApps themselves", and its CEO wrote that "this exploit did not and does not affect the integrity of Ledger hardware or Ledger Live" (ledger.com — security incident report and the chairman's letter, sampled 2026-07-15). Timeline: detected 1:45 PM CET, genuine version deployed by 2:18 PM CET, roughly 40 minutes; malicious code reachable about five hours in total thanks to CDN caching; active drain window under two hours. Ledger's report also acknowledges the ex-employee's NPM access "was not manually revoked on the NPMJS, which we regret", a supply-chain hygiene failure on Ledger's side, disclosed by Ledger.

Now the part that is usually told wrong. The popular lesson is that the device screen was the last line of defence, and that users who checked on-device would have caught the swapped address. For a one-time deposit address that is not true. The injected JavaScript supplied the attacker's address as the intended destination from the very start, so a user comparing browser to device would have seen a match, because there was nothing to mismatch. The poisoning happened upstream of both. This is also the one class of attack where comparing the address across several surfaces does not help, since every surface derives from the same poisoned front-end; if you have read our by-chain troubleshooting guide, read this as the exception to multi-surface comparison.

What Ledger's CEO actually claimed is narrower, and it holds up: "If the user can see what they sign on a trusted display, unintentionally signing rogue transactions can be avoided" (sampled 2026-07-15). Note the scope. The drainer worked substantially by inducing users to sign approvals and transfers whose meaning was not legible, which is blind signing. A clear-signed approval reading "give unlimited access to an unknown contract" is catchable by anyone paying attention. A swapped raw deposit address, absent an independent expectation of the correct value, largely is not.

The lesson for a cross-chain swap: (a) clear signing would have made the malicious approvals legible; (b) for a one-time deposit address, on-device verification alone is insufficient, and the test transfer plus the explorer check are the steps that cover this threat; (c) the failure was in the front-end and code-hosting layer, not in the routing layer and not in the device. Intent-based routing takes custody of nothing, so it was not the surface that broke here. If you are choosing between aggregators, the front-end is the layer worth comparing: see UpSwap vs ChangeNOW, and BTC to ETH for a worked route.

Scope, Safety, and Where to Get Help

Non-affiliation. Ledger and Trezor are independent third-party vendors. UpSwap has no commercial relationship with either, receives nothing from either, and recommends no specific model. Everything quoted here is the vendors' own published material, sampled 2026-07-15. Vendors revise documentation without notice, so treat every quote as a snapshot and verify current wording on your own device before relying on it.

Nobody will ever legitimately ask for your seed phrase. Not Ledger. Not Trezor. Not UpSwap. Not a support agent, not a "wallet validation" page, not a firmware-update prompt in a browser tab, not an airdrop claim, not a migration tool. The same goes for your private key and your wallet password. A hardware wallet's whole value proposition is that the seed never leaves the device: Ledger's guarantee that the Secure Element "drives the secure screen directly, no hacker can intercept this information or tamper with the transaction details it shows" (ledger.com — secure screen security model, sampled 2026-07-15) is worth nothing the moment you type the seed into a keyboard. No cross-chain swap ever requires it. If any page, person or prompt asks, that is the end of the interaction.

Real support never messages you first. The Connect Kit incident started with a phished employee credential, a reminder that phishing is the entry point for this class of attack rather than the exotic part of it. UpSwap's support channel is Telegram @upswapservice. We do not DM users first, we do not ask for seed phrases or private keys, and we will never ask you to "verify" a wallet by connecting it to a link we sent. Anyone doing any of those things is not us, whatever the display name says.

Scope. UpSwap covers 24+ chains, 111+ tokens and 166 chain-token combinations, and every route uses the deposit-address model, so the workflow above is identical for all of them. So is the threat model, which is why the workflow is worth learning once.

If something looks wrong, stop before you send. If the deposit address on the device does not match the browser, or the explorer shows your test transfer landing somewhere you do not recognise, do not send the remainder and ask afterwards. Reach us on Telegram at @upswapservice with your order ID and the source transaction hash, and we will trace it with you.

Frequently asked questions

Does a hardware wallet make cross-chain swaps safe?

No. It guarantees one thing: the bytes you confirm on the device screen are the bytes that get signed, and your computer cannot alter what the device displays. Ledger calls this "what you see is what you sign"; Trezor calls it the Trusted Display, a term Ledger also uses (both sampled 2026-07-15). That closes host-side address substitution between the interface and the device. It does not tell you whether the deposit address you were handed is legitimate, whether the site is real, which network you selected, or what a blind-signed payload does. A hardware wallet protects one link in the chain, a valuable one, and only one.

What is blind signing, and should I ever enable it?

Blind signing is approving a transaction the device cannot decode into readable terms. Ledger's analogy is "signing a blank check: you're authorizing a transaction without fully understanding or seeing its details" (ledger.com, sampled 2026-07-15). It arises when the wallet interface does not support the current clear-signing standard, or the dApp has not published metadata for that transaction. For a cross-chain swap you generally should not need it: sending a plain transfer to a deposit address is a readable transaction. If your device asks you to blind-sign in that flow, treat it as an anomaly and stop. Ledger's support material indicates the setting is off by default and must be enabled per coin app; we could not confirm that wording verbatim as of 2026-07-15, so verify the current path on your own device.

Ledger got hacked in 2023 — is the device broken?

No. The December 2023 Connect Kit incident was a supply-chain compromise of a connector library, not a break of the secure element. A former employee was phished, malicious versions of the NPM package (1.1.5, 1.1.6, 1.1.7) were published, and injected drainer code swapped the displayed destination address in dApps embedding the widget. Over $600k was drained from users of sites including SushiSwap and Revoke.cash (revoke.cash, sampled 2026-07-15). Ledger's report states "the attacker did not at any time have access to any Ledger infrastructure, Ledger code repository, or to DApps themselves", and the genuine version was deployed roughly 40 minutes after detection. The correct conclusion is not that hardware wallets are broken. It is that the front-end is a separate trust boundary from the device, and it needs separate defences.

Do I still need a test transfer if I use a hardware wallet?

Yes, arguably more than ever, because the test transfer covers precisely the threat the device does not. Ledger's own advice: "We recommend sending a small amount first, to make sure that you have properly received it. This test should ideally be done on another computer" (sampled 2026-07-15). Note the swap-specific limits, though. Many routes enforce a minimum, so a dust-sized test may be refunded or stranded rather than routed. The test burns time on a quote that can expire while you wait for confirmations. And a one-time deposit address may not be reusable for the full amount. Pair the test with an <a href="/guides/verify-cross-chain-swap-on-chain-block-explorer-guide">explorer check</a>: the explorer is the channel a compromised widget cannot rewrite.

Can the device tell me I'm on a fake website?

No. The device has no concept of a domain. It speaks a USB or Bluetooth signing protocol that never carries the origin, the TLS certificate or the DNS name, so a phishing clone produces a signing request indistinguishable from the genuine site's. This is architectural reasoning rather than vendor guidance, since neither Ledger nor Trezor publishes it as a sentence, but it follows directly from what the protocol transmits. Domain trust has to be established before the device is involved at all: reach the site from your own bookmark, never from a search ad, a DM, or a link in a reply.

Why does the device show a different address than my screen?

That is the alarm working, and it means exactly one thing. Trezor states it without hedging: "If the address on your Trezor device doesn't match the one on your computer, do not send funds to this address. Your computer is compromised" (<a href="https://trezor.io/guides/trezor-devices/trezor-fundamentals/what-is-a-trusted-display">trezor.io — what is a Trusted Display</a>, sampled 2026-07-15). Ledger's version of the threat: "An attacker in control of your computer screen could show you a wrong address which would make him the beneficiary of any transaction sent to it" (<a href="https://www.ledger.com/academy/hardwarewallet/best-practices-when-using-a-hardware-wallet">ledger.com — best practices</a>, sampled 2026-07-15). Do not send. Do not try again on the same machine. Check every character, including the middle ones, because <a href="/guides/address-poisoning-and-pre-send-verification-per-chain-anatomy">address-poisoning lookalikes are generated to match the leading and trailing characters</a>, which is why first-and-last checks fail.

Can a hardware wallet stop a wrong-network send?

No. The network is chosen in the swap interface before anything reaches the device, and the device has no model of your intent, so it cannot know that the chain you selected is not the chain you meant. We also could not source any general vendor guarantee that the device displays and lets you verify the network; some apps surface a chain identifier where implemented, but that is not a baseline to rely on (checked 2026-07-15). Wrong-network sends are prevented upstream, in the UI, by you. If it has already happened, the <a href="/guides/wrong-network-recovery-matrix-2026">wrong-network recovery matrix</a> maps the path chain by chain, and the <a href="/guides/usdt-network-decision-guide-erc20-trc20-bep20-spl">USDT network decision guide</a> covers the choice that causes most of these.

Is Trezor or Ledger better for cross-chain swaps?

Neither, on the dimension this guide is about. Both display the transaction on a device screen the host cannot tamper with, and both instruct you to treat that screen as authoritative over your computer, so the guarantee that matters for a deposit-address swap is equivalent. The real differences are elsewhere: coin and chain support per model, and internal architecture (Ledger stores keys in the Secure Element; Trezor's Safe 3, Safe 5 and Safe 7 keep encrypted keys on the main chip with the Secure Element holding "a secret that is used—along with your PIN—to encrypt the private keys", plus PIN enforcement and attestation — trezor.io, sampled 2026-07-15). Trezor emphasises open-source auditability; Ledger publishes more current material on clear signing and ERC-7730. Pick on chain coverage for the assets you actually move. Whichever you hold, the workflow above is identical. UpSwap has no commercial relationship with either vendor.

Swap routes referenced in this guide

Related comparisons

UpSwap vs ChangeNOW →

Other guides

Ready to swap?

Pick your tokens and swap directly — non-custodial, no KYC, all-in fixed quote.

Browse swap routes Ask on Telegram