How to Use a Hardware Wallet with Cross-Chain Bridges

A bridge does not talk to the device in any special way. The bridge website builds an ordinary contract transaction on the source chain and the wallet signs it. So the question is not whether a model supports bridging, but how it connects, which networks it covers on both sides, and whether it can decode the bridge call.

The table groups the models in our catalog by the routes our data records for them. It is not a ranking, and a route missing here means we have no documented entry, not that it is impossible.

Setup for the first route is in the MetaMask guide and the Rabby guide. Network coverage per model is compared in the ranking for EVM networks.

Ethereum's documentation describes three basic mechanisms.

• Lock and mint. The asset is locked in a contract on the source chain and a representation of it is minted on the destination chain. What you hold afterwards is a wrapped token whose value depends on the locked funds.
• Burn and mint. The asset is burned on one side and minted on the other, typically by the token's own issuer or protocol.
• Liquidity networks. You hand over the asset on the source chain and a counterparty pays you out of funds that already exist on the destination chain.

A second distinction is who runs the bridge. A native bridge is built for one particular network, for example the bridge of a rollup. A third-party bridge relies on its own validators, oracles or liquidity providers. Native rollup bridges can be slow in one direction: Arbitrum's documentation gives a typical time of about 7 days until a withdrawal from Arbitrum One to Ethereum can be claimed, and the claim is a separate transaction on Ethereum. That figure is set by the network and can change.

A bridge aggregator compares several bridges and sends your transaction through one of them. For signing, the important detail is that the aggregator routes through its own contract, so the token approval names the aggregator's contract as the spender, not the underlying bridge. LI.FI's documentation, for instance, says the address to approve comes with each quote and may vary by route.

1. Confirm both networks first. Check that your device and its app support the source chain, and decide how you will view the destination chain. The method is in how to check supported coins.
2. Open the bridge from its official address. Use a saved bookmark or the link in the project's own documentation, not a search ad.
3. Connect the hardware account. Choose your browser wallet or WalletConnect in the bridge interface and select the account that belongs to the device.
4. Enter the route. Source chain, destination chain, token and amount. Read which token you will receive; it is not always the same asset under the same name.
5. Sign the approval. For a token, the bridge first asks for permission to move it. Limit the amount to what you are bridging. A chain's own coin, such as ETH, needs no approval. How approvals and permits work is covered in the DeFi guide.
6. Sign the bridge transaction. This is the second transaction on the source chain.
7. Wait. The source transaction confirms first; the destination side follows after the bridge has processed it.
8. Find the funds on the destination chain. Between EVM chains they arrive at the same address. Some bridges need a final claim transaction on the destination chain.
9. Plan for gas. Any transaction on the destination chain is paid in that chain's coin. If you bridged only a token, you may be unable to move it until you have some of that coin there.

The bridge website can show anything. The device shows what will be signed, so that is where to check:

• The network. It should be the source chain you chose.
• The approval. Token, amount and the address receiving permission. Compare that address with the contract addresses the bridge or aggregator publishes in its documentation.
• The bridge transaction. The contract you are sending to, the amount, and, if the device decodes it, the destination chain and recipient.

How much of this is readable depends on clear signing. Our data records clear signing support for the dapp-capable models in the table except CoolWallet Pro (no entry) and those without a screen of their own (the Tangem cards and ring, Cryptnox, Ellipal X Card), where the transaction is reviewed in the phone app. That does not mean every bridge contract is decoded. When the device shows only raw data you are blind signing, and the decision rests on whether you trust the site that built the transaction.

The same-address rule holds only between EVM chains, because they share one address format. Bitcoin, Solana, Tron and Cosmos chains use other formats and other accounts on your device. When one side of the route is non-EVM, the bridge asks for a recipient address on the destination chain.

• Generate that address on the device, in the account for the destination network, and verify it on the device screen before pasting it.
• Check that your model supports the destination network at all. In our data BitBox02 and Keycard Shell have no Solana or Tron entry, and Cryptnox has no Solana entry.

Ledger. Besides MetaMask, Rabby and WalletConnect, Ledger states that cross-chain swaps are available inside Ledger Wallet, routed through providers it names as Li.Fi for EVM chains, THORChain and NEAR Intents, with each transaction confirmed on the device.

Trezor. Trezor documents connections through MetaMask and Rabby and through WalletConnect in Trezor Suite. Do not confuse this with Trezor Bridge: that was a communication program between the device and the browser, has nothing to do with cross-chain bridges, and its standalone version is deprecated according to Trezor.

• Bridge contract risk. Funds in transit or locked in a bridge sit in its contracts. Ethereum's documentation lists smart contract risk for every bridge and notes that bridges have been the target of some of the largest thefts in DeFi.
• Wrapped-asset risk. A bridged token is a claim on funds locked elsewhere. Circle, for example, states that USDC.e is issued by third parties and not by Circle, and must be swapped to native USDC before it can be redeemed.
• Fake front ends. A copy of a bridge site can request an approval to an attacker's contract. See how to avoid phishing attacks.

Start with a block explorer for the destination chain and look up your address. What the explorer shows is the actual state; the wallet app is only a view of it.

• Still in transit. The source transaction is confirmed but the destination side is not. Use the bridge's status page with the source transaction hash.
• Network not added. The funds are there, but the destination network is not enabled in your browser wallet or in the manufacturer's app. Add the network, then select the same hardware account.
• Token not listed. The network is shown but the token is not. Add it by its contract address, taken from the bridge's documentation or the explorer, not from a search result.

More cases are in wallet shows wrong balance. Entering a recovery phrase on a website is never part of fixing a missing bridge transfer.

Ethereum's documentation notes that moving assets between chains can also be done through a centralised exchange. If the exchange supports withdrawals of the asset on the target network, you deposit from one chain and withdraw to your hardware wallet address on the other. There is no approval, no bridge contract and no wrapped token, and you can withdraw the gas coin of the new chain at the same time.

The trade-offs are different, not absent: the exchange holds the funds while they pass through, it requires an account, and choosing a network your device or its app does not support on withdrawal leaves you with the same visibility problem as a bridge.