Verify a receive address on the screen that holds the keys

Practical guide · prepared 19 September 2026. Sources were checked for this workflow; linked interfaces and policies can change. Research scope.

The receive address on a laptop can be replaced by malware, generated from the wrong account or copied from the wrong network. A hardware signer is useful here only if its independent display shows the address derived from the keys it holds. The check is small, but it closes a specific gap: whether the destination pasted into an exchange or shared with a payer is actually controlled by the intended wallet.

Establish the intended account first

Write down the asset, network, wallet name, account number and script type before opening the receive screen. Similar-looking account labels are not evidence. Bitcoin mainnet and a sidechain, or a native Segwit and wrapped asset account, can involve different custody even when an interface uses the same ticker. If the transfer begins at an exchange, complete the separate network-compatibility checklist too.

Connect the signing device through software you already obtained from its official source. Unlock the device locally. Generate a fresh receive address, then select the wallet's “verify,” “show on device” or equivalent action. Bitcoin Core exposes this concept through its walletdisplayaddress RPC, which asks an external signer to display and confirm a wallet address.

Compare the endpoint, not a sample

Read the full address on the device display and compare it with the final address in the sending interface. Trezor's trusted-display guide makes the boundary explicit: its display can show what the device generated or is about to sign, but cannot tell whether an address supplied by somebody else is the correct intended destination.

Checking only the first and last four characters is a convenience, not a robust verification rule. Compare the complete string in chunks, including capitalization where the format uses it. If a QR code was scanned, compare the decoded address shown in the destination field; the visual pattern of a QR code is not human-verifiable. Re-check after the final paste because clipboard malware acts between copying and submission.

Handle mismatches as evidence

If the computer and device differ, do not regenerate repeatedly until two screens happen to agree. Stop and preserve the details without sharing the seed: software name and version, device model and firmware, wallet fingerprint, account, derivation path, and the two public addresses. Likely explanations include the wrong passphrase wallet, the wrong account branch, an unverified watch-only import, or a compromised host. A device display mismatch is not solved by sending a smaller amount.

If the device cannot display receive addresses, the arrangement lacks this control. An independently derived address from a verified descriptor can provide another check, but it does not turn the computer into a trusted display. Document the limitation when deciding whether that setup is suitable for the amount and frequency involved.

Use the test amount for a different question

After the full address and network match, a modest first transfer can test the exchange's withdrawal path, confirmation handling and account monitoring. Wait for the wallet to recognize it before making a materially larger transfer. The first transfer does not validate every later address, so repeat on-device verification for each new high-consequence receive address rather than permanently whitelisting what the computer once showed.

This workflow complements watch-only monitoring: the watcher creates operational visibility; the signer proves the receive endpoint. Neither proves the exchange will send on the right network, and neither replaces a recovery rehearsal.