A hardware wallet screen verifies the transaction fields its firmware can decode before signing; it does not verify bridge execution on another chain. The distinction is easiest to see in a Universal Bridge transaction. The common first-time mistake is to trust the dapp's “send 100 USDC to Base” summary when the device is actually showing only a contract address and “data present.”
The numbers that matter
- Across: 12 arguments. Its depositV3 call can include the depositor, recipient, input and output tokens, two amounts, destination chain, relayer fields, three timing values, and an optional message.
- Chainlink CCIP: 6 pieces. The call contains one destination-chain selector plus the five fields in EVM2AnyMessage: receiver, data, token amounts, fee token, and extra arguments.
- **Circle CCTP V2: 7 arguments.**depositForBurn carries the amount, destination domain, mint recipient, burn token, destination caller, maximum fee, and finality threshold. Adding a hook makes it eight.
- A plain EVM transfer: 4 practical checks. You can usually review the network, recipient, amount, and maximum network fee without interpreting contract calldata.
- Blind signing: zero guarantee of readable intent. The device may still show the contract address, native value, and fee, but it cannot tell you what the encoded method will do.
What each figure means
The network shown on the device is the source chain for the transaction being signed. A destination chain is often just a number inside the calldata. CCIP uses a chain selector, CCTP uses a domain identifier, and Across uses destinationChainId; none of those is automatically the same thing as the source transaction's EVM chain ID.
The displayed “recipient” also needs careful reading. For a bridge call, the transaction's top-level to address is normally the bridge contract, such as an Across SpokePool, a CCIP Router, or Circle's TokenMessengerV2. The person receiving funds later appears inside the call as recipient, receiver, or mintRecipient. Only clear signing, with support for that exact contract and method, can turn those inner values into a useful human-readable screen.
Amounts have the same split. Across can specify both the input amount locked on the origin chain and the output amount a relayer should deliver. CCTP burns USDC on the source chain and later mints it to the encoded recipient. CCIP can carry token amounts alongside arbitrary data. The wallet can sign those requested values; it cannot promise that a relayer, attestation, or destination contract will complete the second half.
Fees are not one number. The device may show the source-chain gas limit and maximum fee, while the calldata contains a bridge fee, a CCTP maxFee, an Across reduction between input and output, or a CCIP fee paid in the native asset or LINK. Check both. A harmless-looking network fee does not make an excessive protocol fee harmless.
Clear signing is the dividing line
When clear signing is available, the signer parses supported calldata and presents the method, token, amount, destination, and relevant contract context on its trusted display. The firmware signs the exact bytes it received, so malware on the computer cannot silently substitute a different recipient after you confirm the screen.
That protection has a boundary. A descriptor can explain a known Across, CCIP, or CCTP method, but it cannot validate arbitrary hook data, destination-side code, quotes, relayers, or Circle's later attestation. If the device falls back to blind signing, stop and decode the calldata independently; “Approve” means only that you authorized the bytes shown, not that the bridge's promised result is safe.
The practical rule is simple: compare the source contract, source amount, destination chain, final recipient, token, and fee. If the hardware wallet cannot display those values, it is protecting your key—not verifying the bridge transaction's full intent.